If you visit the Flatpak website today, it lists, as the very first advantage of the project: “Build for every distro: create one app and distribute it to the entire Linux desktop market.” If you then move on to the list of supported distributions, you’ll see the usual suspects, but also distributions like Void Linux, Guix, and Alpine. These last three all have one thing in common: they use an init system other than systemd, because Flatpak doesn’t care what init system you use. It seems that for the next major version of Flatpak, however, that’s going to change: systemd will probably become a dependency for Flatpak.
Speaking at the Linux App Summit, Arian Vovk and Sebastian Wick held a great talk about the future of Flatpak. The current version of Flatpak will continue to see a ton of improvements, but at the same time, the limits of what can be done with its decades-old design have become harder and harder to work around. As such, they’re also planning for and working on what they call Flatpak Next, or perhaps Flatpak 2.0, which is effectively a rewrite of Flatpak based on what they’ve learned over the years, making use of modern technologies and ideas that have gained ground since the initial design of Flatpak 1.x.
It’s important to note that everything discussed during the talk is planning, and not a single line of code has been written yet. This means that all of these plans are subject to change, and as the work progresses over the coming years, the end result may turn out very different from what’s been detailed in the talk. In addition, and I can’t stress this enough: if anything in this discussion gives you even the smallest of inklings to go and harass, attack, insult, or otherwise bother anyone involved in Flatpak, systemd, or related technologies, please be so kind as to book an appointment for a yoga class or whatever. It seems like you need it.
Right at the onset of the talk, Vovk and Wick explain that they want to move the permission management from Flatpak into the service layer, through a new service called systemd-appd. Systemd-appd gives applications an identifier and stores their permissions, and then this data can be queried by the rest of the system. In turn, this enables a slew of other features, not least of which is subsandboxing. At the moment, the plan is to introduce this feature in the current version of Flatpak, thereby introducing a dependency on systemd into Flatpak.
From what I understand from Vovk, they were intending to be “super considerate” of distributions and people not using systemd, which I take to mean we’d eventually end up in a situation very similar to systemd-logind, which was extracted from systemd into a separate daemon, elogind, so that distributions using other init systems could still make use of desktop environments depending on systemd-logind. I imagine Flatpak developers wanted to make as many affordances as realistically possible for something similar to happen to systemd-appd, thus ensuring Flatpak would remain available on distributions not using systemd.
Obviously, people who are using distributions like Void or Alpine were concerned about the future of Flatpak on their systems. If Flatpak gains a hard dependency on systemd, Flatpak would no longer work on distributions without systemd, so the talk raised questions – sadly, it seems the questions were directed at someone not technically involved with Flatpak development, and his replies were not particularly helpful and often just downright insulting and inflammatory.
Even though he’s not involved in Flatpak development, enough people assumed that he was, and a toxic brew stirred. Users with genuine, friendly questions about the future of Flatpak on their systems were met with derision and insults, and it spiraled out of control from there, drawing in the rabid anti-systemd Red Hat conspiracy lunatics (and worse). Things got progressively worse for everyone involved, particularly for Flatpak’s developers.
And so we ended up at the situation where everyone’s mad and Flatpak’s developers are “not feeling inclined to spend [their] time on that shit anymore” when it comes to accommodating and making affordances for distributions and people not using systemd. The end result will most likely be that any future Flatpak dependency on systemd will be stricter, and making any independent elogind-like daemon will be much harder than it was going to be. Nobody wins, everybody loses, all because some people thought it necessary and productive to be insulting and inflammatory.
As things currently stands, it’s very likely that over the coming years, Flatpak will gain a dependency on systemd, possibly without any affordances for an independent daemon to replicate systemd-appd functionality on distributions that do not use systemd. In other words, Flatpak would no longer be able to boast that it enables “Build for every distro: create one app and distribute it to the entire Linux desktop market.”, as it would no longer be distribution-agnostic. And that’s a shame, because Flatpak fills a real need for users, regardless of whatever init system they use.
Which is apparently something some people base their entire identity on, because they’re weirdos.
🙁
sixtyfive,
Agreed. Distros that don’t want systemd benefit from flatpak too.
But the pressure to comply can end up strangling alternatives.
Edit: I quoted sixtyfive correctly, the empty blockquote is a wordpress bug.
Alfman,
I had at one point came to accept systemd. But I’m once again pushed against it.
Its current design, whatever the original goals could be, is based on ease of deployment of corporate linux. Be it large IBM/RedHat sites, or cloud instances on AWS. In any case it makes “anonymous”, nameless, soulless machine much easier.
(I used to name mine with themes, like “jupiter.home.net”, “wolverine.local”, etc. AWS/GCP/Azure uses s0232dd.g01.north.us.cloud.net)
Not sure there is a solution to this never ending overreach. Linux contributors are more than happy to give away their freedoms and identity.
So it is like with Ubuntus snap.
Snap needs systemd, too.
“because they’re weirdos.” This feels like an attempt to forestall debate, when there are, in fact significant questions yet to be satisfactorily resolved. In any case, that a bloated, inefficient distribution format may choose to depend on an expansive, corporate controlled subsystem seems a match made in heaven!
This is one of the most tribal websites on the Internet. The fact that there are good and bad groups as a matter of policy goes much deeper than this comment.
Remember when Linux was this open platform where everyone could do what they wanted? Now it’s IBM’s way or the *screeching*. The community has been choosing convenience over freedom for the last 10 years and IBM/Redhat is now closing off the exits. Embrace Extend Extinguish. Redhat perfected what Microsoft started.
Darkmage,
It is very sad to see your heroes become the villain.
RedHat was supposed to be the “commercial” Linux that is fighting against closed source. Sure, they were not perfect, but they were among the second gen (after Slackware, with debian) and always gave something to the community.
They gave us Fedora, and allowed CentOS for a very long time.
They actually fought against Microsoft (though they lost, another story)
But after IBM takeover RedHad is no longer the same.
In my view, it is extremely important that we have a way to release an application for Linux that allows it to be easily installed and run successfully on every Linux distribution. If Flatpak does not want to perform that role, we need something else.
*nod* I suspect this will result in some people returning to offering a Docker option for their GUI applications, given that it needs to be some kind of containerization if you want to abstract over glibc vs. musl-libc.
I hope they don’t. Why would anyone want to poison, even a server machine, let alone their own desktop, with Docker?
Sure, it would need containerization, but please not Docker.
@a_very_dumb_nickname
Is it Docker specifically that you dislike or OCI in general? Are you ok with Podman or do you dislike that as well. If so, why?
I use Distrobox with Podman pretty heavily and prefer it to Flatpak overall. So, I hardly use Flatpak. But I still see Flatpak as a distribution mechanism for apps to be incredibly important.
I don’t have much experience with Podman, but it is definitely better.
I ended up using macOS on my laptop and Proxmox in the home lab to have the best of both worlds.
Systemd is a framework that is easy to develop around and solves a bunch of issues with creating a modern and scalable os, it really shouldnt be a shock that tools are developed to be a part of it or depend on it when there arent a whole lot of alternatives to some of the bits. The flatpak guys have their reasoning as to why this component should be a systemd one, while they likely could develop it as a non-integrated project it makes sense to depend on another project that does a bunch of the plumbing you need. Most of these devs dont hate the anti-systemd position but it makes it less easy to get something working when you are duplicating work done by someone else. But that was clearly before the hate that those mastodon posts by Jorge got, it was insane. You can have some concerns as the mastodon post by Thom did as it was less clear from the presentation what was exactly going on but hot damn do some of you anti-systemd people look like the worst of the linux flamewar idiots
Shugo,
That sentiment goes in both directions. Systemd goes against the unix principal of simple standalone tools that do one thing well whereas systemd has become an octopus with lots of inter-dependencies.. Some people are ok with that, but it’s understandable why other people would not be. They’re not idiots for wanting to stick with more traditional unix principals.
I’d argue that, at some point, you have to have interdependencies if you want to maintain the (in my opinion, more important) property of having each component do one thing well.
As for the core systemd binary itself, the argument (which I generally agree with) is that, given the needs of a modern system, it is acceptable to consider “managing a service’s lifecycle” as “one thing” to be done well. Look at things like runit.
I’m reminded of how systemd is Linux-specific because cgroups is Linux-specific… yes… because POSIX has no way to perform certain lifecycle mananagement tasks in a truly reliable fashion… just a bunch of hacks which approximate reliability. Under KDE 3, Konsole had a lot of code to implement fake transparency because X11 didn’t support compositing. Now it doesn’t.
ssokolow,
It might be true for tightly coupled components. Gcc uses Glibc, and vice versa. Xconfig and Xserver are interlinked
But the idea was every standalone thing that does “one thing well” (or here a group of things) could be replaced, and we would still have a consistent system.
Do not like bash? There is tcsh
Do not like Gcc + Glibc? There is llvm and llvm-libc (or more practically musl)
Do not like init? You have tinit/minit/others
Do not like binutils? There is BusyBox
Do not like systemd?
You are out of luck.
Your containers, networking, wifi, desktop environment, suspend resume… basically nothing works.
It is not longer a GNU/Linux distribution but a systemd/Linux distribution now. In fact it is much tighter than GNU, since we had BSD/Linux as well, and it still worked.
This is a “Don’t like it? Compete!” situation.
There was stagnation in the services POSIXy OSes provides for two decades, so someone finally decided to sit down and write a richer offering, a ton of distros jumped on it because their clients want that richer set of services, and now people are complaining because applications want to take advantage of the richer services.
The world is moving on and, if you want to remain compatible, you have to implement a compatible provider for those services.
…not unlike the transition from “because every UNIX implemented its own proprietary extensions beyond the bare minimum, X11 implemented an OS within an OS, right down to user-mode drivers” to “On Linux, X.org and Wayland depend on Kernel Mode Setting and evdev”.
ssokolow,
I’ll do “old man yelling at the clouds”, but this feels more like a hostile corporate takeover situation to me.
And I have seen the Proper Way™, that is why this feels extra worrisome.
“Back in my day”… when Slackware was new, Debian was not a thing, and there were still years for first 0.1 alpha of GNOME to drop… it was all volunteer ecosystem.
However when GNOME came with their corporate sponsors, they did things the right way.
There was “mc” (midnight commander) which they wanted to use as the desktop file manager. Instead of forcing hard GNOME dependencies to it, they maintained a separate “mc-gnome” project, (or was it “gnome-mc“, either way…) And when they build their own thing (Nautilus) and separated ways, there was no long term harm to mc. It still exists today.
(They did not even break GTK applications or tightly integrate them with their DE. Today? Is there any pure GTK app left)?
These things?
They are just corporate devs using shortcuts to release products in the shortest time.
“Don’t like it?”
No, I actually welcome contributions, but these are no such thing.
This particular instance, adding systemd to package managers is… basically because Google Chrome and Valve’s Steam needs “container in container” setups, and need a quick way to gain security.
Unlike past, where they would maintain “flatpak-systemd“, they just hard code this requirement in.
And in the future if they part ways… volunteers will have to clean up their mess.
Sorry, but this is not about progress, this is embracing corporate agenda at the expense of Linux soul.
For systemd itself, If it were just Red Hat or all RPM-based distros, I’d agree… but when essentially all mainstream distros, including Debian, picked up systemd as their default (with Debian having this whole argument and mechanism for supporting alternative init systems), it suggests an organic demand for the functionality provided.
As for this mechanism specifically, Linux has sandboxing APIs but, because they’re not nestable (i.e. if you have access to them from inside a sandbox, you can un-sandbox yourself), Flatpak cooked up its own API which needs to be explicitly supported. Electron-based things and other Chromium-derived things currently get subsandboxing with Flatpak via an LD_PRELOAD hack named Zypak, and so it’s a reasonable argument that it’s unsustainable to be doing so for everything which wants to subsandbox but doesn’t see Flatpak as a big enough market to have a custom backend for it.
I honestly think the situation is more like this:
1. Red Hat scratches their own itch so they have a solution to sell to RHEL customers and throws their solution over the fence. (This has always been a part of how open-source works. It’s why we have such ecosystem fragmentation and why we used to have an infamously tangled mess of an audio stack.)
2. Other people see it as “good enough” and don’t see it as worth the effort to split the ecosystem with a competing solution. (This is what distinguished things like PulseAudio and systemd from prior efforts.)
If anything, I’d say that what’s changed is that people pushing for old-school UNIX at the expense of “UNIX is a game you play which may produce useful outputs as a side-effect” lack of polish managed to stubbornly stick to “No, you don’t need that feature. You’re doing it wrong.” for so long that, when Red Hat funded a “good enough” solution for what other demographics were asking for, the people who might produce competing offerings were all burned out and just accepted it.
I suspect a general trend toward “f**k it. I don’t care anymore” is also the explanation for the direction this is going.
ssokolow,
It would be interesting, if we also did not see this same exact thing in the past.
Google was the one who brought containers to Linux. Many people do not know the history, and assume “docker” was the first. They were not.
Google, requiring sandboxing in their “datacenter is my computer” architecture (Borg), added what is called “cgroups” to Linux kernel.
They could have kept this entirely to themselves. They could even write a very Google specific “semi-closed” solution similar to what is pushed today.
But they chose the open way. The Correct Way™
Today?
Instead of repeating what they demonstrated are capable of, implementing this at the shared level, are now pushing for hard coded extension that pushes distros that don’t want, or cannot support systemd out of the Linux container ecosystem.
Why should I not find this concerning?
What else can they “f-it” in the future?
Of course it’s concerning…but I don’t think it’s conspiratorial or some kind of Embrace, Extend, Extinguish strategy.
If anything, I’d call it “Goddammit. The GNOME 3.x mindset is spreading more. How much do we need to reinvent to successfully quarantine GNOME?” without it being anything to do with some kind of corporate edict… just a bunch of individuals who think they know best and, at the moment, have wound up in the position of being stewards of infrastructure that the open-source world may need to duplicate.
ssokolow,
I don’t think there is a grand conspiracy either
but we could argue there is exactly a corporate push for takeover.
Why else would we have articles almost every week, in the form of:
“Essential project X is changing core behavior” (looks into it… just another corporate dictate)
Just like this one, and many others prior.
I don’t think they are stewards, but rather usurpers.
I’m not saying corporate people cannot be stewards. They can, and they have been in the past. They have even done a great job, and that is why this new “infiltration” was easy.
And they do unilateral decisions against community pushback (“f-it”) in many many cases.
They have replaced baseutils with an incomplete and buggy Rust implementation (there is nothing wrong with liking Rust, but there is a lot of issues when replacing exiting systems without proper acceptance tests. It was a cart before horse situation. Probably some folks got promotions and bonuses and had to fnish by Q3!)
They have bullied Mozilla Firefox into accepting non-standard web extensions
They have tangled DRM deep into the stack
They have removed theming from GNOME and GTK applications (for uniformity on corporate desktops, look up libadwaita)
They have of course pushed systemd everywhere, even for traditionally separate tasks like name resolution (we had perfected upnp/mdns in the past)
They have time and time again pushed for hard dependencies that broke existing projects or target systems (like real niche ones open source supposed to showcase), only because they could not maintain proper separation.
I can go on…
But in every case, when there was a clash between corporate needs and open source community, they successfully pushed their own agenda. Hence “embrace”, “extend”, and we are at “extinguish” for anything that happens to be outside of their comfort zone.
Wish we woke up earlier.
Im not going to call them idiots for not wanting systemd but the devs have an idea that they feel is best developed as a systemd component as its functionality exists for free in a large marjority of current linux distros. The devs were cognisant of there being distros without it but the anti-systemd folks didnt give them much chance to respond before going all in. And that was before you get the “influencers” wading in
Shugo,
The issue is… this was not even discussed as a generic solution. Like many other forced pushes in Linux:
Paraphrasing of course. But this is how it feels for someone who does not want to use these technologies, and just wants to be left alone.
@sukru
That was not the initial plan.
They did that because they felt fed up with the anti-systemd crowd who brought the pitch forks against them.
Add to that that they went against someone who has nothing to do with flatpak development and who had the bright idea to add fuel to the fire and all hell broke lose.
Unfortunately, because of a few idiots now we’re in this sad situation where distros not using systemd have high chances of losing flatpak support.
Let’s hope that heads cool off on both sides and they can re-start the conversation in a more civilized way.
richarson,
That does not sound very professional does it?
@Alfman
I have to dissagree with you on this one, even Lennart Poettering himself debunked most of those “not the unix way” myths surrounding systemd.
First, systemd is not a single binary but a collection of binaries and libraries, each doing their own work and interacting with each other (exactly the unix way!).
It is a monolithic software repository where every component is developed. Guess what other projects follow that same approach? The BSDs, arguably real descendants of Unix.
We could argue about implementation details, and I may not agree with some of systemd’s aproaches, but saying it goes against the Unix principals makes me think you’re not that well informed about it (I do consider you very knowledgable about technology in general and Unix/Linux specifically).
richarson,
I don’t know what you are referring to, but if his argument is about a “single binary”, that’s a bit of a red herring. It doesn’t matter that it’s a collection of binaries it’s the coupling between them. The result is that systemd ends up making linux more monolithic and forcing alternatives out, alternatives that worked just fine with other init systems. For better or worse it’s making linux be more like windows. People can still be for it, but it definitely goes against unix roots. We can’t even read/search/process log files anymore because systemd replaced them all with it’s own binary format. I’m not making the case this is automatically bad for everyone, but in terms of unix: design philosophy can’t we agree it’s at least a bit jarring? For anyone/anything to work with logs files now we must now use systemd dependencies.
We can have differing opinions about it, but please don’t use ad hominem arguments. It *is* about implementation details. I think the disagreement is that we’re focusing on different meanings of “monolitic”. An OS using a “monolithic software repository” is one thing, but how those components are actually designed is another. IMHO the unix philosophy favors software that is loosely coupled and interchangeable. Building systems this way keeps alternatives viable.
I’m just a random dude on the internet who talks too much, hence the verbose=1. It’s an opinionated topic and I don’t think anyone is strictly right or wrong here, Most people wouldn’t mind systemd if it stuck to init systems. What people are wary of is systemd’ taking over. so much of the OS. That flatpak could be next is disheartening. But maybe it’s inevitable that linux becomes systemd (or is it systemd becoming linux? I’m not sure).
equery f systemd | grep -i /usr/bin | wc -l = 68. systemd is composed of 68 binaries (some are links, lets round down to 50). Each is replaceable. Many services are dbus services, you can supplement your own.
The interdependencies were always there, but more haphazard : you always had to depend on some binary to unlock your encrypted drive.
Yes, now there is commonly a dependency on “systemd” in the sense of depending on features a systemd-enabled system provides. I mean, KDE getting rid of its bash init script and using systemd user services has been a net win for everybody: session startup is now more organized, and KDE doesn’t need to maintain the master launch script with ugly hacks for dbus autostart services.
Using logind (elogind exists, making my point) facilities allows GNOME and KDE (and all others) to not duplicate session management code, and have consistent behaviour.
I honestly don’t understand the argument of “should be standalone tools”: it does exactly that. By that argument busybox is an abomination : many tools in a single binary, differentiated on fork by argv[0]. (Just to be clear: I love busybox and find this solution for lowering its footprint very elegant)
Serafean,
I don’t know why people keep bringing up the number of files.
It’s more about tools not being so tightly coupled. I get that some people don’t care, but some of us find it undesirable for so many subsystems in the OS to be dictated by systemd. The fact that busybox combines so many tools makes it more like an archive, which may or may not be desired, but functionality those tools are practically completely independent from each other. There’s no coupling or inter dependencies and zero friction using busybox with other unix tools. This isn’t the case with systemd though, distros are being coerced into doing things the systemd way. Now that pressure could come from flatpak. Again you may not care, but some people do.
Wait, the asshole who caused this is unrelated to all this? And works on Developer Relations???????? Crazy twist.
Looking at Jorge’s gruff and dismissive responses om Mastodon, it seems like he was inviting negative reaction. I guess it must have been his first time on Linux social media, or something.
He’s just one of those people who thrives on conflict. Probably the worst sort of person to advocate for a project.
Yay, irrelevant 😀 Whatever distro I’m using, one of the very first things I’m sticking to is to eradicate any sign of snap and flatpak, regardless on what they depend on. So happy to not care about one more idiotic debate 😛
“[…] application for Linux that allows it to be easily installed and run successfully […]” I’ve been around a while, and I don’t find it funny any longer that a lot of new&easier ways to do things somehow frequently turn out to actually be larger, slower, harder, stupider than they used to be.
Flatpak distribution is a mess fully dependent on a private company, security model is totally random (systemd sandbox won’t help if app permissions are dictated by an app submitter), and it is susceptible to supply chain attacks and namesquatting. It is easier to run shitty software in a VM.