Flatpak Will Depend on Systemd

embedding-shape

So for us who want to continue distribute across multiple distributions, even those that doesn't run systemd, is there only AppImage remaining now as a truly cross-distribution packaging format?

zx8080

> 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 Nit: on "decades-old", Flatpack is from ~2016 only.

postepowanieadm

Makes sense. BTW. are there efforts to migrate systemd to rust?

ElenaDaibunny

At this point the Linux desktop stack has a harder systemd dependency than most people realize, Flatpak was one of the last holdouts.

pezgrande

As a Linux normie, I've never understood why systemd is/was so much opinioned about.

nightfly

> 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

nechuchelo

While I think systemd is a great init system (as well as some other components under the systemd umbrella), I really dislike when components up in the stack hard-depend on it. We can't use GNOME, plasma-login-manager, and soon Flatpak without systemd. Maybe systemd should have been an API + a spec instead of an unportable implementation.

moebrowne

Better title: Flatpak is thinking about depending on Systemd > It’s important to note that everything discussed during the talk is planning, and not a single line of code has been written yet

boje

Linux Desktop is starting to smell a lot like Android now judging by how vertically integrated it is becoming. With the push for a permissively-licensed (MIT, BSD etc.) userland and concentration of developers within a small group of companies and orgs sponsored by them, they might eventually do what Google is doing and start delaying releases for sourcecode, or stop altogether. (MIT, BSD and other licenses do not mandate the distribution of source code alongside binaries like the GPL family does.) It's may get harder in the future to have a Linux desktop that keeps up with the times and also does not include third-party cruft or spyware in the future.

yxhuvud

Curious question: Do snaps interact with or depend on systemd?

codethief

> 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. This is fantastic news! As I've argued here on HN many times over the years, proper permission management is probably the single most important piece that's been keeping us from sandboxing everything by default, like on Android and iOS.

loloquwowndueo

That’s it. I’m ditching flatpak for snaps. Just kidding!

rho138

The text color schema for the website is a bit rough for reading. Gray-on-white isn’t a great combo

DCKing

There will be more of this going forward, I think. Systemd is really not just an init system, it's a full cohesive management system for Linux distros and they've never pretended otherwise. A modular one but still a comprehensive one. Because of that its mere existence is an affront to many people with traditional opinions on Linux and Unix. systemd-appd sounds like it could make some inroads in the threat model that Windows and Linux still have in 2026 (and macOS is still reeling from): anything that runs as my user, can access anything running as _my_ user. I don't think this threat model was tenable in 2016, much less in 2026. But moving away from that also breaks with the Unix tradition. Systemd as the system management layer is becoming a centerpoint for moving Linux forward, on servers but especially so on the desktop, and it does so at the cost of breaking with traditional views. It's kind of hard to watch: I want Linux to move forward, and there's just a lot of good ideas there. But it will be painful for a large Linux community to break with traditions.

shevy-java

> Systemd-appd gives applications an identifier and stores their permissions Soon systemd will sniff more data - such as the age: https://github.com/systemd/systemd/pull/40954#issuecomment-4... And the usual copium aka this is very harmless, nothing evil is done, nothing bad can happen. That'll cover the age. In the future systemd will sniff for more private data. For those who think this is a conspiracy theory, well - look at the last some decade or so, and query which claims made early on, about systemd, suddenly become true at a later point in time. The systemd folks are kind of smart, though, because they provide "merely an init system" (right? Or was the comparison always unfair, because e. g. sysinit never was about adding layer of layer on top of layers) and they build on top of it, for other applications to tap into systemd - at the cost of adding a dependency. Even LFS/BLFS succumbed recently and now only offers systemd-builds. Personally I think this is kind of betrayal to the spirit of LFS, but Bruce gave an objective argument, which is the time investment for maintaining non-systemd and systemd, and on this particular point he is quite correct. Time is a finite ressource. What we kind of see here is that systemd keeps on growing and growing. It is the ultimate virus. You can't get rid of it. Now flatpak fell for it too, though objectively speaking I fail to see why flatpaks should have a dependency on systemd to begin with. Thankfully I use versioned AppDirs (similar to GoboLinux) so I could not care any less about flatpaks (don't need them, I already use any version of a program I want to), but flatpak also betrayed its original vision. For some reason those grand visions always become worse over time. But no worries folks - we know one thing is true, and that is that systemd will grow even bigger. It will not stop until it has swallowed EVERYTHING.

mgrunwald_

Flatpak project maintainers, please do not do that. Leave Flatpak universally accessible. I like my alternative Linux distros without systemd.

nottorp

Hmm I just realized. Systemd is a great example of embrace and extend that was actually succesful. Microsoft should have just hired Poettering.

anarki8

Seems previously one of the goals for the Flatpak project was to develop a universal app packaging format for Linux OS family that suits even exotic ones like Alpine and Void (and it did fantastic job at that). Now the direction changed with the new team/leadership towards integration, security and control instead of "it works everywhere". Hopefully basic features will still work without systemd-appd, otherwise we would be back to "Linux desktop has no universal packaging format" considering that: * Most appimages often rely on specific libc of the base system; * Snap does not fully work outside of Ubuntu ecosystem.

Sweepi

Title should be "Flatpack 2.0 considered to be depended on Systemd"

HelloNurse

Is there a written explanation of the "Flatpak Next" plan? What is it supposed to change, and what does it need from systemd? The article contains only a vague half paragraph of architecture: > 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 first sight this "new service" seems single purpose enough to get a satisfactory and relatively simple standard specification and multiple implementations with or without systemd: what am I missing? Conversely, isn't depending on future systemd developments rather than current features strangely aggressive? And what other speculated Flatpak features introduce other dependencies from systemd? Discussing whether unwanted dependencies can be made optional or eliminated requires technical details.