Flatpak-NG sounds like bad news for systemd refuseniks Flatpak development has been very quiet for years. Discussions about a next-generation take are happening – and some of the signs are worrying if, like many FOSS folks, you are systemd-intolerant. In the course of researching our article on MX Linux 25.2, we came across an interesting Reddit discussion from last month, which in …
Let it be a systemd only application so we can get rid of it once and for all. Flatcrap, snap (as in the sound things do when they break), whatever.
If, instead of a single program I have to download a full virtual machine in order to edit a couple of lines in a text file, count me out.
This is one of those cases where doing nothing would have been better than the solutions given. Snap and flatpack just introduce a new layer of security problems, while systemd is just generally pointless while also introducing a new attack vector and complexity. The fact that all three make it very hard to migrate away from them and so grant their developers something of a job for life is of course a pure coincidence.
To be fair to it, systemd is not pointless. It does a bunch of things that are not trivial to do any other way. It has uses.
If it's good at any of those things - or for that matter even better than the alternatives that ended up stillborn because all the effort went into systemd - is a different matter entirely.
> Oh great! Now give a list of the "bunch of things" that systemd does which aren't common in all Linux distributions.
Seat management is a big one, especially for people with specialised accessibility needs: linking the local keyboard, mouse, touchscreen, video, and audio hardware to a particular logged in session as opposed to leaving them floating around usable by anyone.
It uses kernel namespaces to handle process isolation: it can run things in containers without another container tool. This also means it can replace "sudo" and run things as root or at given privilege levels or under given accounts.
It can dynamically trigger processes when hardware is added or removed.
It can dynamically handle hardware and logical devices when a process or daemon needs it, which is part of how snapd works -- mounting volumes for processes, unmounting them, replacing them.
There is quite a lot, and I have not read much about anyone else's init alternatives trying to replicate the functionality -- which is why an increasing number of tools require systemd. Some just carve out bits of systemd and run them on their own to simulate it, like seatd and elogind.
Chimera Linux is about the only project that's told me in any detail about what it is trying to do to replace systemd instead of just going to 1990s level functionality.
Subtitle for the hard of thinking: I am not saying these are good things, or desirable, or necessary. I am merely answering the question.
Respectfully, I think your answer proves the point, just not the one you were hoping to make.
systemd was offered as a replacement for the ancient and creaking init system... but the amount of scope creep that the project has gorged itself on is frankly ridiculous. It fundamentally violates the Unix philosophy of having software "do one thing and do it well" - of being simple pieces of code connected by clean interfaces, to borrow from TAoUP.
In short, the issues with systemd include:-
1. The Scope Creep
Originally offered as a simple replacement for System V's "init" process, systemd now encompasses device management, user logins, network configuration, system logging and even local DNS services...
2. Binary Logs (my personal bugbear)
Many people think of this as "just" a requirement to use e.g. journalctl when they might want to use grep or sed... but I have supported "hosted" instances of Linux running on top of other OS platforms. Much of the time that might work well... but what if you're running a virtualized RHEL on top of IBM zOS on an IBM Z-Series mainframe? It would be *so much* easier to review plaintext log files using native zOS tools (because your Linux environment is dead). The fact that there isn't even an option to do this [while other functionality keeps getting added to systemd] gets pretty frustrating.
3. Hard Dependencies
Systemd and its components are deeply intertwined [no clean interfaces], to the extent that many core desktop tools and network managers now require it to function. This not only creates something of a monoculture, it risks fragility and instability issues.
4. Complexity
I'm not sure the decision to replace readable shell scripts with declarative unit files is a net benefit. Yes, it can make parallel booting quite a lot faster, you have to trade that against the percentage of time your Linux host spends in boot state rather than actual operational running... The problem with declarative unit files is that they abstract away mechanical control, making it harder to troubleshoot when things break.
5. Opacity / Monolithic Design
Systemd has basically moved multiple and entirely distinct functional elements inside PID 1, which in turn creates a potential single point of failure. Now, if a core service hits an issue, it can bring down your whole system. For example, if you're running a distro that uses the built in systemd-resolved, then you are running your local DNS resolver *in your init process*. Why would you want to do that?
There's a good reason that the "rules" in "The Art of Unix Programming" has "The Rule of Modularity" ("Write simple parts connected by clean interfaces") as it's very first Rule. It's because those are words to live - or die - by.
To quote a bit more: "The only way to write complex software that won't fall on its face is to hold its global complexity down - to built it out of simple parts connected by well-defined interfaces, so that most problems are local and you can have some hope of upgrading a party without breaking the whole."
The developers of systemd could have stopped after they had provided a neat and modern replacement for systemd. The continued because they could.
They never stopped to consider whether they *should*.
I appreciate the mention of accessibility for those with disabilities (which is, at some point in our lives, all of us, even if it's just for a a few minutes or hours). For all my dislike of the walled cesspits, they at least lower barriers to increase reach. I'd far rather our boats be lifted equitably in a rising tide rather than the bigger boats be lifted more, and their occupants of the grandest shout down "hey! At least you're riding a little higher in the water; be grateful we gave you that."
Every time I read “if it’s not broken, don’t fix it” my mind adds “for me” in there.
Your definition of “not broken” is not the same as mine, and mine is not the same as (say) an admin looking after a massive server farm.
“Broken”, in a lot of people’s minds, has elided well beyond “doesn’t work at all” to “doesn’t work in the way I learned Unix worked when I was at college in the 1970s/80s”.
I figured the Flatpak haters and systemd haters would be in the same camp, so Flatpak may as well become dependent on systemd. For myself, I'm pretty neutral on systemd, but I'm generally opposed to Flatpak and Snap for the reason that their packages tend to be so huge compared to a native installation. Perhaps Flatpak-NG will have smaller packages, which would be a worthwhile improvement.
"Flatpak haters and systemd haters"
While those undoubtedly exist my experience is that valid arguments can be made as to whether or not they are needed for a given use. I personally like flatpaks and prefer non-systemd systems. The ever increasing "being a requirement" and it's seemingly endless glomming of far from needed "features" are my biggest problems with systemd but that is far from hating it. In fact I have kept up to date versions of Linux Mint on one computer so that I can learn about how to use it if/when I need to. If flatpak makes systemd a requirement I will have to move to Linux Mint permanently and that familiarity will help with the transition.
"generally opposed to Flatpak and Snap for the reason that their packages tend to be so huge compared to a native installation"
For a more complete response see my previous comment above. Short and sweet, I don't like it either but given the general abundance of hardware resources in modern computers and the very useful niche they fill which is the reason they exist, that is a minor problem for me.
P.S. The use of "haters" is a bad faith addition to any argument, unless it's use is truly warranted.
"If, instead of a single program I have to download a full virtual machine in order to edit a couple of lines in a text file, count me out."
Please provide a good argument instead of this silly fluff. I use flatpak because it allows me to use and update to the latest version of KiCad. I use a "stable" distribution (I want my OS rock solid, applications not quite so much) just about any major application package that I use or might be interested in is several revisions behind. Newer revisions from rolling or semi-rolling spin offs won't run due to differences in libraries which is EXACTLY why flatpak exists. I use flatpak for libreoffice because I almost never use libreoffice (and never when I only need to edit a few lines of text) and it needs over 40 packages updated when there are security fixes. I use flatpak for PySolFC (solitaire) because my distribution does not have it in the repository which is not an uncommon problem with any distribution. I use flatpaks for applications that I want to check out with one or more of the above advantages but may eventually remove. I generally limit installing flatpaks for only the previously given reasons.
Responding to other comments, as far as application size goes yeah I'd like them to be smaller but given what they do and what is required to do it I don't see a way around it. Since I now consider 16 GiB RAM to be the minimum for a modern GUI system with 32 GiB preferable (hopefully bought before the recent massive price increases) their RAM footprint is a minor concern given what I use them for. Using 1 TB or greater SSDs, again minimum configuration/hopefully bought before price increases, makes their disk footprint less problematic. To help with that I keep most of my user files on a hard drive 4 TB NFS server which also allows my multiple computers to access those files without the constant need to keep them synchronized. I chose NFS because I just need a file server but SAMBA could be used as well and might be (?) easier to install/configure.
As far as security goes that is probably my biggest concern with flatpaks but then again as shown by several recent repository attacks that concern is not limited to flatpaks.
LibO is what made me turn to flatpak too. I'm on Gentoo and LibO would be the single biggest compiling task on my whole system, well ahead of gcc, llvm/clang etc. On my old i686 laptop it was likely not even doable due to RAM requirements of the build, and even on my late-'10s Thinkpad it would likely be a >24hr slog.
Gentoo appreciate this and always provided binary packages of LibO (and OO.o before that), but they are notoriously temperamental due to DLL hell. Some of the libs it uses are antisocially ABI-unstable (side-eyes harfbuzz, and I believe poppler used to be an offender too) to the extent that not only are you lucky if your system state at any given time satisfies the conditions for libreoffice-bin to be installed in the first place; once you manage it, its presence will often make it all but impossible to upgrade the rest of your system because those dependencies conflict with those of other key components. AAARGH. There has been a stickied thread about this in the Gentoo forum for ~35% of the time I've been alive.
I threw in the towel and went AppImage first, but those can still be prey to the same DLL-hell issues depending what libs the packager decides to leave the host system to supply. I forget which one it was that broke, but it taught me that, as Henry Jones Snr put it, "Our situation has not improved."
And so, reluctantly, I turned to flatpak as the Last Chance Saloon. I don't like the disk cost, but it works, integrates and updates with zero pain other than that. Like many here I'm fortunate in not requiring to use an "office" suite very often in my duties, but when I need it, I *need* it.
So if this comes to pass, systemd will be the next shit sandwich I have to choke down. I've used it; I don't hate it; I just don't like it so much better than OpenRC that I relish the task of migrating my running system from one to the other, purely for the sake of that seldom-used "office" suite, and purely because some library developers insist on moving fast and breaking things all.the.ruddy.time. The latter is where my ire tends to be directed, and I'd honestly rather apps progressed more slowly/lived without certain features than make use of such antisocial libs. Gah.
> I have to download a full virtual machine in order to edit a couple of lines in a text file
Do not worry. You will have to download a full virtual machine to be *prevented* from editing a couple of lines in a text file.
The isolation is a great way to break any non-trivial program in subtle ways, botch extensibility, integration or seldom used functionality, etc. It is a lot of work to get it right, for any value of right. So web browsers will be still allowed to do anything, including things like screen capture, because otherwise the masses will be up in arms. Whereas specialised software will be rendered unusable by making the things it needs to do to work weird, if not blocked entirely. It has always been the case, and it is only getting worse.
"six other init systems besides systemd, and we've seen little sign of them cooperating to create an alternative to systemd that provides even a subset of its wider functionality"
I'd guess it's because those six and their users all see the absence of that wider functionality as a feature.
Updated my version of Gimp recently on Ubuntu. Came out as a Flatpak bundle (previous ones were traditional packets).
Now I'm blessed with the immense privilege of having to execute *** 2 *** sort actions before any attempt to save a file:
a) sort by name - to have existing files in the directory sorted by alphabetical order, which they aren't by default
b) sort by type - to have sub-directories first, before files, which isn't by default.
... and no way to save this as the default settings.
We're progressing every day.
Well, there is installation convenience for the end-user, and fire-and-forget software release for developers.
The problem is, less-than-favorable compromises has, and will, be made for that to happen. Which inevitably leads back to good ol' "if it's worth doing, it's worth doing it right the first time" rearing its head once more...
I swear that Linux distributions are just setting out to destroy the whole point of Linux now.
I hate systemd with a passion. It's ALWAYS the cause of my problems. And I don't have complex needs.
I hate flakpak with a passion. And snap. I hate anything that's not a basic, old-fashioned, dependency-handling package manager going through an authorised channel. Snap - it's just whatever junk someone's thrown in there. The "steam" snap package doesn't even work on Ubuntu! It loads but no games run whatsoever. What kind of impression is that for the DEFAULT STORE on Ubuntu? Literally from a fresh install of the latest Ubuntu, I got five snap packages in before I gave up, deleted them all, redid them all as apt packages. Because they DIDN'T WORK for basic big-name open-source stuff, or were years out of date.
Then you have the myriad "let's bundle everything because we can't handle dependencies and we'd like random third-parties to be able to just bundle whatever version of whatever they like in with our software and never keep it up to date" - AppImage, Docker, etc. etc. etc.
Now we have Ubuntu shovelling (yes) AI into itself.
Seriously, I don't know what's going on any more, it's all so much horseshit.
If you don't like systemd and Snaps... why are you running Ubuntu? Canonical's ideal distribution is a kernel, systemd, and snapd and I don't even know how committed they are to that bit about the kernel. It's quite literally what they are working towards with Core.
Like, if I don't like hash browns and syrup I'm going to avoid dining in a Waffle House...
This post has been deleted by its author
Because, like someone interested in computers that's ageing, I was happy to take the leap and jump into "modern" Linux despite my reservations.
If this is "the way to do things", i'm happy to give it a fair shot.
And I did. And the sticking issues... were all the stuff that's supposed to be "new" and "better".
(P.S. I ran Slackware for a decade as a primary desktop, back in the Slackware 9.0-11.0 era... I'm not scared of some manual labour and a bit of a learning curve...)
One would have thought that the sort of person who is averse to systemd would be similarly averse to flatpak, snap and similar binary blob installers.
They are basically Trojan horses used for smuggling proprietary software into GNU/Linux systems.
It is always best to install any software not packaged by your distribution in its native .deb or .rpm format from Source Code, i.e. a git repository or source .tar.gz file. (And check the download for anything that might be a pre-compiled binary.)
" Snap's implementation is much simpler and cleaner than Flatpak's, as is the distribution model – which, as we've reported before, is entirely open source."
So in the most unlikely event that Canonical goes under, snap can be forked and worked on? Sounds sensible
"That includes MX Linux, Alpine Linux, Devuan, Slackware, and many other smaller projects. For many of these, Flatpak is a lifeline: the only way to access much of the wider Linux app market."
OK, many of these, so not all. Flatpak support can be added to Slackware current, but I'm unaware of any plan to replace slackbuilds.
I'd been thinking about a move to Devuan to get away from Debian 13's systemd, but given what I read about how you have to manually install NVidia drivers and the like, I've decided to put up with the bloatware and risks. Manual installation of "foreign system" packages is a horribly risky way of installing and maintaining software with as many dependencies as the likes of CUDA have.
