Upstream, the Fedora KDE Plasma edition is also doing well. Nice to see that within the first release after promotion to a full edition.

I feel it has gotten much better in recent years. The first time I tried KDE 5 it looked weird to me. But now I acutally quite like KDE 6. Or maybe I’ve just learned to tolerate it…

What kind of issues did/do you encounter?

The VS Code/Codium essentially provide a separate development environment within the flatpak container. All the tools there, and the shell are separate from your actual system. There are some ways to work around this (https://github.com/flathub/com.vscodium.codium/blob/master/README.md). I gave up on the Flatpak and installed a native package. Containers are nice, but they have their limitations.

Try CachyOS or Bazzite!

Bazzite, sure, but it’s not gonna magically solve these kind of issues.

However, if one is struggling as a beginner with Linux, I would strongly advise against switching to an Arch-based distro (CachyOS). Arch is great, but this is not its target audience.

I strongly disagree with u/brucethemoose here. You wrote below that you’re currently using Linux Mint, which is a great distro for beginners. In my opinion, Bazzite offers nothing essential that is not available on Mint. IMHO, the easiest ways to play games are:

• Use Steam to play your Steam games (native or using Proton). This should just work (on both distros)
• Use Heroic Games Launcher to play games from GOG, Epic, or non-store games. The recommendation is to install the Flatpak version, which is available on both distros. Afterwards, the setup step is to install a Proton-GE version before you can play your games (https://github.com/Heroic-Games-Launcher/HeroicGamesLauncher/wiki/Linux-Quick-Start-Guide).

You can - of course - still switch to a different distro if you like, but this is not necessary or helpful to run games.

Unfortunately, the former is not possible due to asinine requirements by the HDMI Forum: https://www.phoronix.com/news/HDMI-2.1-OSS-Rejected The only option is to use DisplayPort instead (or perhaps an adapter).

That sounds pretty bad and probably means other things are broken too. The easiest option would probably be a reinstall at this point, but if you want to learn something you can also try to salvage your install.

To recover, it’s probably easiest to manually configure your Ethernet connection as described by InnerScientist and then re-install the network-manager package.

You can check the status of the network-manager package using dpgk. It should look like this (ii at the start, but it sounds like it’s not installed in your case):

$ dpkg -l | grep -i network-manager
ii  network-manager                         1.52.1-1                        amd64        network management framework (daemon and userspace tools)
ii  network-manager-l10n                    1.52.1-1                        all          network management framework (translation files)

You can also check /var/log/apt/history.log to see what went wrong and if there are other things you need to fix.

I performed the upgrade in two steps apt upgrade --without-new-pkgs and apt full-upgrade (based on the release notes). I can see the following on the line Upgrade: for the command apt full-upgrade:

network-manager:amd64 (1.42.4-1+deb12u1, 1.52.1-1)

On the Remove: line you can see the packages that were removed. Unfortunately, the names of many libraries were changed in this release (e.g., libreadline8:amd64 to libreadline8t64:amd64), so there’s a lot of noise in there. Maybe you can look at that line and ignore everything that starts with lib to see if any other important packages were removed.

I’m running Ubuntu on a server. I’ve enabled the free Ubuntu Pro subscription to get ESM patches for the universe repository. Not sure if it really matters, but better safe than sorry.

The easiest distros to run Resolve would probably be Rocky Linux 8, Alma Linux 8 (both are based on RHEL 8). Instead of the EOL Rocky/Alma 8.6, you should use release 8.10 (8.6 would update to 8.10 anyway). However, while still currently “supported”, these are still shipping (mostly) 6-year-old (!) packages. Also, only a small number of packages is actively supported by Red Hat. IMO, this implies that these distros offer a lower level of security. The most critical parts (browser, kernel) are still well-supported, so the difference is probably not too large for most regular users. However, you may also struggle to run some other software (although Flatpaks are available). It’s unfortunate that Resolve only supports an ancient version of Rocky (Rocky 10 is now out)…

The Linux Experiment recently looked into touchscreen support of different desktop enviromenents. His findings mostly align with your comment. However, this seems to be one of the rare cases where the distro matters for Gnome. Upstream Gnome (e.g., as shipped by Fedora) works fine with touch screens, but support on Ubuntu Gnome appears to be quite broken.

The Linux Experiment videos:

• 1: KDE, Ubuntu Gnome
• 2: Fedora Gnome, Others

I wanted to write the same thing. E.g., you can run this in bash to set the permissions for all .conf files to 600:

find /mnt/the/directory -iname "*.conf" -exec chmod 600 {} \;

Yes, I would recommend creating a backup (perhaps on your phone or a different computer over the network) and then upgrading to 21 and then 22. IMHO Mint has steadily gotten better and there is typically no reason to stay on an older version.

It sounds like Proton VPN (or its repo) is causing issues for you. Given that it’s a paid service, you can probably contact their support.

Alternatively, you can also look for the repo file in /etc/yum.repos.d, something like /etc/yum.repos.d/file_name.repo, for Proton VPN. You can then disable it by renaming it to .repo.disabled and try again (sudo dnf upgrade in the terminal). Note: This is not really a permanent solution, as it will disable updates for Proton VPN.

Nice, congrats on getting it to work! :) Native Debian packages are also nice. It can just get difficult if you want the latest stuff.

I used the docker compose template from https://hub.docker.com/_/drupal and mostly changed the image:

# Drupal with PostgreSQL
#
# Access via "http://localhost:8080"
#   (or "http://$(docker-machine ip):8080" if using docker-machine)
#
# During initial Drupal setup,
# Database type: PostgreSQL
# Database name: postgres
# Database username: postgres
# Database password: example
# ADVANCED OPTIONS; Database host: postgres

version: '3.1'

services:

  drupal:
    # image: drupal:10-apache
    # image: drupal:10.3.7-apache-bookworm
    # image: drupal:10.3.6-apache-bookworm
    image: drupal:11.0.5-apache-bookworm
    # image: drupal:10-php8.3-fpm-alpine
    ports:
      - 8080:80
    volumes:
      - /var/www/html/modules
      - /var/www/html/profiles
      - /var/www/html/themes
      # this takes advantage of the feature in Docker that a new anonymous
      # volume (which is what we're creating here) will be initialized with the
      # existing content of the image at the same location
      - /var/www/html/sites
    restart: always
    environment:
      PHP_MEMORY_LIMIT: "1024M"

  postgres:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: example
    restart: always

The details for the v11 image are here: https://hub.docker.com/layers/library/drupal/11.0.5-apache-bookworm/images/sha256-0e41e0173b4b5d470d30e2486016e1355608ab40651549e3e146a7334f9c8f77?context=explore

Yes, the docker images don’t use the sury.org php packages (they use the php docker image).

“11.0.5-apache-bookworm” also seems to work, maybe you can try that version?

I wanted to recommend using a Docker container but I ran into the same issue with the default config for “drupal:10-apache” (aka “drupal:10.3.7-apache-bookworm”). Opening “node/add/article” results in the OOM error. Downgrading to “drupal:10.3.6-apache-bookworm” resolved the issue. Looks like a Drupal regression to me. Maybe you can also try an older version of Drupal 11?

If you don’t want to reinstall the OS, you can probably use Clonezilla: https://clonezilla.org/show-live-doc-content.php?topic=clonezilla-live/doc/03_Disk_to_disk_clone

Maybe you need to update the drive ids for your bootloader (grub) afterwards, not sure about that.

Edit: Maybe the advanced “-g auto” option does that for you.

It seems that 18.04 was the last release for 32-bit x86 (i386): https://askubuntu.com/questions/1376090/latest-version-of-ubuntu-for-i386-architecture-32-bit

But you could just go for Debian which still supports it.