Yes I have do the same, layer small packages, use Flatpaks and complex stuff like (R + rstudio + COPR + Modules) or (QGis + grass + python + plugins) or IDEs in a distrobox.
At least in Distrobox you can also create rootful containers which could run an entire DE, or run libvirtd in there and use virt-manager in a rootless box, connected over ssh. Totally works but its a bit complicated. But for software with systemd or USB access this is needed.
Flatpaks share libraries, but they are sometimes not packaged well, contrary to distro packages, which on the other hand may pull in loots of dependencies.
Would be interesting to run all packages in a rootful distrobox and have Fedora RPMs on the other hand.
There are some hardening problems though, that I dont really understand, with user namespaces being blocked in the hardened kernel. On Arch there is bubblewrap-suid which fixes that in a way I also dont understand yet, but Podman, Distrobox, Toolbox, Docker etc dont work yet, and may not work too.
Having compared snaps in ubuntu 23.10 to flatpaks on opensuse tumbleweed, I can safely say that snaps tend to be faster for me with less weirdness happening during usage. Some programs were the same (obsidian for example) other comparisons were done from the same category (Firefox snap vs chromium flatpak). I genuinely prefer snap and don’t see the issues people often quote. Also, that the backend isn’t open isn’t a big deal to me, as snaps themselves generally still are.
Recently switched to using Flatpaks instead of random .debs for a number of apps on my system. /var/lib/flatpak takes up 7GiB, which honestly isn’t that much (even though it’s like quarter of the OS size), given that’s the software I use most of the time.
Was skeptical at first about Flatpaks, but SteamOS showed me that is great at just giving OS developers access to a fully populated app store with minimal work.
Honestly, nowadays I’d say “ability to install flatpaks” should be the criteria on which we decide whether an OS is really “linux” or not (that is, SteamOS is, but Android isn’t).
Edit: Okay. I said something stupid here, my bad. What I was trying to get at is the distinction between Android, etc. and “Desktop” Linuxes like traditional distros, Chromebooks and the Steam Deck. Even though it technically runs Linux, it’s hard to argue that developers for Android are really writing apps that work on “Linux”. Wheras if someone releases a Flatpak version of their app because they think the Steam deck is cool, it works on other distros “for free”.
Yup, Flatpaks are indeed great. Isolation, modern versions, no weird dependencies.
I have to manage a Debian PC fleet and I am too stupid for Ansible, so they all just got cleaned up extremely, all that bloat gone, apps replaced with flatpaks and now the system has like ⅓ the packages. Automatic updates then, VirtualBox is the only stupid thing with their kmod and all, but Virtmanager is also already on there.
Not all apps can be flatpaks, for example virt-manager, gnome-boxes can but its really restricted then.
But keeping the system slim just makes so much sense, its like removing this distro randomness which I am sure is needed for Linux to get their shit together and stop doing the same work at 10 different places.
Its good and bad. Bad because the base system cant use it and its not the main packaging choice.
Lots of good apps like OBS use outdated runtimes, which simply should not be used anymore. I am not sure if this is a security issue but probably it is, and it creates this unnecessary Runtime bloat.
I hate this philosophy so much! I hate developers for it! It’s like they gave up on even trying to do anything about retrocompatibility and managing libraries and dependancies.
Anyway it will collapse soon. I just wish it was sooner.
An answer that posit that disk space is infinite and free and embrace the black box philosophy. Soon we will have machine priests doing rituals to maintain them I guess.
Honestly I get both sides of it. Your view makes sense as an end-user and from a philosophical perspective. But some people have legacy software that needs conflicting dependency versions, for instance. It’s just a trade-off.
Yeah, package maintainers should have their dependencies figured out. “Managing dependencies is too hard” is a distro packager’s problem to figure out, and isn’t a user problem. When they solve it and give you a package, you don’t need to figure it out anymore.
Plus, frequent breaking changes in library APIs is a big no-no, so this is avoided whenever possible by responsible authors. Additionally, authors relying on libs with shitty practices is also a no-no. But again, you don’t need to worry about dependences because your packager figured this out, included the correct files with working links, and gave them to you as a solved problem.
Honestly this. It’s so nice to not have to hunt for a specific library that depends on 20 other libraries. I’d rather pay in disk space than deal with that.
Add comment