Wayland wants to avoid problems that X11, Windows, and MacOS have. It deliberately avoids some “features” that application developers expect. A lot of it relates to security and privacy.

An example is that a window does not know where it is positioned on your screen and it cannot choose where to place its windows. Personally, I love this behavior. It means I can open an open and it opens in a consistent location (for most Wayland compositors, that’s centered on the screen). But others don’t like that. They would like the app to control where it opens; for some apps (a niche nowadays) you may have an application window and multiple more supporting windows, but on Wayland, they would all just get opened on top of each other rather than being placed around the main window.

The main issue is that old Boxes is based on SPICE. It was/is a Red Hat project, but they stopped caring for it and deprecated it. So old Boxes is built on legacy tech that will pretty much just bit rot over time.

Something strange with the March 2026 results was that it had two new distro entries, “0 64 bit” at 17.60% and “64 bit” at 8%. In April, one of those entries disappeared and the other’s share dropped significantly. In May, both were gone entirely and Linux was back to a more reasonable marketshare of 4%.

Overall probably closer to the truth.

I wish people didn’t obsess over these large numbers as much. Like when Linux suddenly hit 5% on Steam when that was clearly just an outlier and was destined to fall right back down.

One annoyance about Python is that I also have a Mac. By default, it comes with no Python. If you install XCode, you get Python 3.9. And of course you can get the latest version from Homebrew.

Granted, I don’t think Amber would help much in this situation either. macOS comes with bash 3.2 and Amber probably targets a newer version that that. So either way I would need to homebrew install newer versions.

Not a DE thing. In /etc/crypttab, you can point to.a keyfile or password to unlock the disk.

So you unlock the OS disk, and on that now readable OS disk are keyfiles and passwords that then unlock the other disks.

Sorry, I should note that 26.3 is not released yet. This is a “snapshot”, aka a development build. The full version of 26.3 will be released in a couple of months.

I updated the title to reflect that 26.3 is not released yet.

Definitely agree, particularly when it comes to security.

Valve takes a snapshot of Arch repos, frozen in time. They then spend months developing on top of this version. And by the time it’s released, it’s multiple months out of date. They don’t pull in security updates; Arch is a rolling release, they don’t backport fixes like Debian or Fedora does.

Definitely misremembering.

Helium is great. I love how it focuses on having 0 distractions. No popups, great default settings.

Yes, but still important to keep in mind because it broke release expectations. Pop!_OS used release new versions every 6 months and then stopped releasing new versions while working on COSMIC and now only does LTS releases.

And now that COSMIC is “done”, it’s still not quite clear when they will release 26.04. I actually just found a quote from the CEO of System76 where he said “Future Pop!_OS releases, starting with Pop!_OS 26.04 LTS, will now align with the Ubuntu LTS release timing (approximately two weeks after the Ubuntu release date)” but that obviously didn’t happen.

Pop!_OS gets Cosmic updates before they are even technically released.

Pop!_OS packages are not cutting edge. They are based on Ubuntu LTS. They do keep some packages more up to date than Ubuntu, such as Cosmic, kernel, mesa. But the vast majority of packages are from Ubuntu LTS unmodified.

Pop!_OS has also been lagging in using the latest Ubuntu LTS. They stuck to 22.04 for almost 4 years before releasing 24.04. It’s also not clear when they will update Pop!_OS to 26.04, but that should not take as long as 24.04.

Yes, the packaging mess that Atomic distros cause.

I want a couple of functional things:

• To be able to safely upgrade my system silently, without interruptions, and rollback of necessary
• To know my system is not drifting away from upstream defaults and to restore it to a “factory” state
• To sandbox applications

I’d like to be able to do all that efficiently and cleanly too. Atomic systems generally fulfill those first two while traditional distros struggle, which is why I stick to Atomic distros.

But whereas you can use a single package manager on Arch and get everything (albeit without easy sandboxing), Atomics keep adding more and more. Here’s your rpm-ostree, flatpak, toolbox, homebrew, sysexts, etc.

I find sysexts particularly insulting because they regress so much on traditional packages for so little upside. Doesn’t even have dependency management.

I would wish we would stop creating so many package managers and just focus on improving existing ones.

In a more ideal world we would have something like

• Distro based on Freedesktop runtimes
• Flatpak that officially supports both GUI applications, CLI applications, and even daemons/services
• Flatpak would also be able to reuse the Freedesktop runtimes of the host system

Technically yes, practically no.

Windows doesn’t include the drivers to read Linux file systems (except through WSL) and Vanguard sure doesn’t either.

If you encrypt your disks, then it definitely can’t.

Certainly an interesting vulnerability, but one you shouldn’t worry about.

If you do really care about sandbox security, the first thing I would recommend doing is globally blocking filesystem access to anywhere in your $HOME that runs script code, such as:

• bash files like ~/.bashrc and ~/.bash_profile
• ~/.local/bin and ~/bin
• ~/.ssh

I have a script that I use to control flatpak overrides and I do something like this:

# paths to block
GLOBAL_RESTRICTION_PATHS=(
    "~/.bash_logout"
    "~/.bash_profile"
    "~/.bashrc"
    "~/.profile"
    "~/.ssh"
    "~/.zshenv"
        "xdg-config/zsh"
    "~/.local/bin"
    "xdg-config/systemd"
)

# globally block these paths
for path in "${GLOBAL_RESTRICTION_PATHS[@]}"; do
    flatpak --user override --nofilesystem="$path"
done

# but allow some apps like text editors to access them
for path in "${GLOBAL_RESTRICTION_PATHS[@]}"; do
    flatpak --user override --filesystem="$path" org.gnome.TextEditor
done

Proton did not claim anything; the CEO of Proton claimed that Republicans (not Trump) would do better on big tech anti-trust.

This view is not that crazy given that the person Trump appointed was doing her job quite well. Too well to the point that Trump removed her from the position later on.

You’re forgetting that Universal Blue doesn’t just ship Fedora stuff.

They include stuff from Homebrew and Flathub out of the box.

Homebrew shipped the backdoored xz library while (by luck) Fedora stable didn’t.

Do they still do 15 minute bugs? That could still use some work.

Occasionally I get an itch to try Plasma and immediately get disappointed every time as I encounter some sort of bug just setting up the panel. Last time I tried was 6.6.5, so it wasn’t just a point 0 software issue.

As a side note, I still get so confused by the “new” panel/desktop edit mode introduced in 6.1.

I don’t think there’s much of a package up-to-date difference between LMDE and Linux Mint. Both Debian and Ubuntu LTS are released every two years. Ubuntu in even years, Debian in odd years. So every year they trade being more up to date.

Main difference now is that Linux Mint has access to Ubuntu’s hardware ennoblement stack.

Preface: I have been daily driving Fedora Atomic for the last couple of years and have also used a bit of Aeon and NixOS.

My opinion is that while atomic/immutable desktops are overall a good idea, they are marred by poor planning, a refusal to fix existing tools, and some cope.

There are way too many package managers and waste in this space. I think flatpak is a large cause of all this friction due to fact that it is always “sandboxed” and only focuses on GUI apps. The fact that it does not aim to support CLI apps (despite being able to handle them quite well!) means that we must have another tool, traditionally podman via toolbox/distrobox. The sandbox doesn’t play well with certain subsets of apps, notably things like VSCode. At least Flatpak Next seems like it will address this part with its unsandboxed mode.

I also find it quite strange how some developers revel in wasted space and inefficiency. So many duplicated libraries between the host, flatpak, podman, and homebrew. With better planning, we could’ve had shared runtimes (such as Freedesktop) between the OS, flatpak, and whatever CLI package manager. Instead we have something like Fedora packages for the host OS and podman (not shared), flatpak using Freedesktop, and brew shipping their own stuff.

I also think that systemd sysexts are poorly designed, it’s crazy they’re being pushed. It’s pretty much a package manager without dependency management. And for what upsides? It has no sandboxing, it’s not portable between distros and distro versions, and must vendor dependencies to work around having no concept of dependencies. And we’re already seeing fragmentation with Fedora and OpenSUSE working on their own frontends to manage sysexts.