It has always been rather insane to me that user facing applications share packages with the base system.

The atomic distro approach works a lot better for me. Would not go back to a "normal" distro from https://getaurora.dev.

▲

yepitwas 3 days ago | parent | next [-]

Lots of Linux users hate it, but as a one-time Linux user (about a decade as my main desktop OS) who now does 100% of important computer use on macOS or iOS, I find the division of “stable macOS base all the way through a working and feature-complete GUI desktop; homebrew (and the App Store) for user software; docker and language-specific package/env managers for development dependencies” to be basically perfect. Trying to use linuces where the base system and user packages are all managed together feels insane, now.

▲

const_cast 3 days ago | parent [-]

It depends a lot on the distro and how volatile it is and what tools are available.

I run Debian stable, and it's not immutable, but it is very unchanging. I don't worry much about system libraries and tooling.

The downside to that is that then userland application are out of date - in enters Flatpak. I run most GUI applications in flatpak. This has a lot of benefits. They're containerized, so they maintain their own libraries. They can be bleeding edge but I don't have to worry about it affecting system packages. I also get much simpler control - no fiddling with apparmor, the built-in Flatpak permission system is powerful enough.

The blind spot then is CLI apps and tooling. Usually it doesn't matter too much being bound to system packages, but if it really does, I can always containerize those too. I only do it for my PHP dev environment.

▲

curt15 3 days ago | parent | next [-]

>The blind spot then is CLI apps and tooling. Usually it doesn't matter too much being bound to system packages, but if it really does, I can always containerize those too. I only do it for my PHP dev environment.

Do you encounter any friction getting different containerised tools to talk together? Can you compose them in the classical unix fashion?

	▲	const_cast 3 days ago \| parent [-]
		I put them on the same container, basically. I bundle my PHP binaries, modules, and tooling all together and then use it on container. It defeats the purpose a bit, but it keeps the system clean. No NPM packages cluttering everything, no composer packages leaking, etc. Cross container, I'm sure, is more complex.

▲

mikae1 3 days ago | parent | prev [-]

> I run Debian stable, and it's not immutable, but it is very unchanging. I don't worry much about system libraries and tooling.

I basically did the same with Tumbleweed for a couple of years. Can't stand the point release distros. Lagging behind a year or two when it comes to the DE is not something I fancy. Never liked Tumbleweed much though. Felt very unpolished when using Plasma.

> The blind spot then is CLI apps and tooling.

I can really recommend homebrew. Works well. apt is for the system, homebrew is for user facing CLI apps. :)

	▲	fdrs 2 days ago \| parent [-]
		I did the same. I have a debian stable. Everything else besides build-essential, firefox and gnome is either docker, homebrew or flatpak

▲

giancarlostoro 3 days ago | parent | prev [-]

This. I always dreamed of a Debian / Ubuntu Distro where you could fully separate the "SYSTEM ENV" from the Userland ENV with userland referring to system ENV and then if userland ENV has a different, USerland takes presedence when its the user running the command, vs if its some automated service. I do not know if there's something like this for Linux outside of maybe containers? I guess that comes sorta close.

	▲	heavyset_go 3 days ago \| parent [-]
		I think GoboLinux might scratch that itch. Apps are bundled and installed like they are on macOS, and there's a very strict distinction between literal 'System', 'Users' and 'Programs' directories.