You’re just adding arguments on arguments that aren’t making any sense now. You’re original comment and understanding has been addressed.

My main point is that I’m worried about additional complexity. On most atomic distros, you’re not supposed to touch the base system, so various tools are preinstalled or available: flatpak, podman, homebrew, snap, appimages, systemd sysext.

The BSDs seem to enjoy a separation of OS and user packages with reduced complexity. Though their task is easier since they are complete operating systems, whereas linux is just a kernel and many different projects put together, and many different groups putting out their own distros with varying packages and compatibility.

Both RPM and dpkg support being able to unpackaged or install packages into your local home directory

These don’t seem to be advertised features. More like hacky workarounds. Complex rpm commands. Ubuntu thread with various proposed solutions.

It would be really cool if dnf and apt got good, easy, simple support for installing packages into the home folder. But that’s not what’s happening. The proposed solution seems to be systemd sysext, which again, prompted me to have worries about complexities about how software is being managed on more “modern” distributions.

You’re just adding arguments on arguments that aren’t making any sense now. You’re original comment and understanding has been addressed

And I keep discussing it because I enjoy doing so.

Thats not what I’m saying.

My first point is that homebrew is only good for CLI applications. Almost no GUI apps are available, the only one I know of is xeyes.

My second point is that homebrew is unsanboxed. That’s good for programs that don’t work well sandboxed, such as fetch tools like fastfetch.

This leaves a gap of a good supported way to install GUI apps that are unsandboxed. I used to need this when I used an Android phone with a custom OS. I needed to have unsandboxed Chromium with adb tools to flash and update the OS. However, when sandboxed, Chromium doesn’t have access to adb tools.

You can use the Warehouse app to do this: https://flathub.org/apps/io.github.flattool.Warehouse

Wouldn’t recommend doing it with the CLI, they don’t make it easy.

I’m not saying they’re running with special privileges, just that they’re part of the “OS”. Stuff that comes included with every system and that should not be removed.

You’re not really “managing” the OS files, you’re just applying patches and upgrading to new releases. All the interesting stuff (from the user perspective) is done using pkg on FreeBSD and pkg_* on OpenBSD; it’s with those you install your packages like the DE/WM, web browser, CLI tools, etc.

There’s a couple of benefits to splitting these. Makes it easier to “reset” the system to its default state and makes it impossible to accidentally break the OS (you can’t accidentally remove any critical components like the kernel).

Homebrew is good for unsandboxed CLI programs, but unfortunately not GUI apps.

An issue I ran in the past when using a custom OS on my phone was that flatpak, containers, or snap were able to talk to my phone properly to flash the OS. So on an atomic distro, I would either have to install Chromium using something like rpm-ostree, systemd systext, or boot into a traditional distro like Debian.

I’m not sure what you mean with the update tooling having some “clear separation of OS from these packages”, but maybe you want to try and expand on that a bit

On FreeBSD and OpenBSD, OS upgrades are handled by the freebsd-update and syspatch commands respectively. User package installs are handled by the pkg and pkg_* commands respectively.

The pkg tools do not touch the base OS. That also helps avoiding issues like uninstalling critical system packages and makes it easier to wipe the system to a “clean” state, undoing user modifications.

It’s hard to succinctly describe the difference between BSD and Linux, but essentially, in BSD the OS is everything: kernel, tools, extensions…etc

It also certainly helps that neither FreeBSD or OpenBSD comes with desktop environments by default. That muddies the water of what is an OS package and what is a user package. If desktop environments were treated as OS packages, then it would not be possible for the users to uninstall the DE apps.

I’m worried about complexity. Traditional Linux package management isn’t perfect. Atomic distros try to address this in various ways, including but not limited to a clear separation of OS and user packages.

For example, on Fedora Silverblue you’re not meant to modify the base OS with rpm-ostree. You’re supposed to use flatpak and toolbox (homebrew and appimages are also options, but not preinstalled). But these have limitations that rpms do not.

On the BSDs, this isn’t really a problem. It manages a clear OS and user package split without the sandboxing limitations. That’s not to say that sandboxing is bad, I fully support it, but when you run into the currently unfixed limitations, it’s a pain. As an example, in the snap and flatpak versions of Chromium-based browsers, you can’t use Android’s adb tools, which I used to need when using custom OSs on my Pixel. You either have to overlay the rpm or use a non-atomic distro.

Systemd sysext is being thrown around as the solution to this problem as the way to install software that needs to be unsandboxed but without modifying the base OS. But I don’t see why instead we can’t just still be able to install RPMs on the base system, but to places like /usr/local/bin. The systemd sysext method seems like an unnecessary reliance on systemd and additional complexity. Take this for example: https://github.com/mmcnutt/Bazzite-Discover-Sys-Ext. There’s so much work being done, what what is basically just taking the existing Plasma Discover rpm and converting it into a new format.

Fedora Atomic variants just differ in the desktop environments.

You can see Universal Blue stuff here: https://universal-blue.org/. But in short, Bazzite is for gaming and the others are for regular desktop uses. All have a “batteries-included” attitude. There’s also some images meant for servers.

Debian 12.7 is a year old. You’re supposed to upgrade to the latest version (currently 12.11) before doing the upgrade.

For fastest hardware support, you will want a rolling distribution like Arch (requires a do-it-yourself attitude) or OpenSUSE Tumbleweed (complete out of box, but some quirks, like missing codecs requires manual work). Fedora also has decent new hardware support, not rolling so not as good, but same problem as OpenSUSE Tumbleweed. You can also consider derivitives like CachyOS (Arch, but has a nice installer).

Ubuntu and Linux Mint have OK new hardware support. Twice a year they release new “hardware enablement upgrades” to bring new support.

And worst is Debian. They don’t do hardware ennoblement upgrades at all. It’s something you have to do yourself by using backports. They bring new hardware enablement by default with new releases every 2 years.

GrapheneOS is talking to OEMs to create a phone. Up to this point, they’ve only supported Pixels because they’ve had the best security. But with Android 16, Google stopped sharing important files that make it more difficult to continue supporting Pixels. Hence the desire to create their own device.

Yes. It’s not clear if this was photoshopped or a bug that has been around for years, I believe related to GeForce NOW streaming. The two clients share some code, and GeForce NOW does have an age requirement.

https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/572753/nvidia-app-accessibility/

We have to wait and see if it’s really mediocre. Gnome Web certainly has performance issues, but those may be due to WebkitGTK.

Orion is not using WebkitGTK, despite using GTK and Libadwaita. Their port may not have the same performance issues.

And when I say performance issues, I don’t mean benchmarks. Gnome Web actually does pretty decent on benchmarks, but things like scrolling with a mouse just don’t feel smooth (but do with a trackpad).

This also affects dnf since OpenH264 is distributed from Cisco’s server’s, not Fedora’s.

You can follow this blog post: https://yselkowitz.github.io/blog/2025/08/12/openh264-fedora-flatpaks.html

Should be fine with option 1. Just need to install flatpak-module-tools beforehand.

For Linux, the protection is weak.

But if properly implemented, it’s good. But it would be a hassle to do and would require users to register new keys and blacklist Microsoft’s.

Measured boot is a better solution for Linux. It’s decentralized and does not rely on Microsoft. It uses the TPM to “measure” various parts of the UEFI, bootloader, and OS to ensure they have not been tampered with.

Xwayland doesn’t have all keystroke access, though Plasma does have a feature that lets you do just that.