6 ms·

Flatpak Will Depend on Systemd

103 points by birdculture 5mo ago

ElenaDaibunny 5mo ago
At this point the Linux desktop stack has a harder systemd dependency than most people realize, Flatpak was one of the last holdouts.
embedding-shape 5mo ago
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?
- ChocolateGod 5mo ago
  AppImage isn't truly cross distribution in the first place because how it handles dependencies is not truly portable.
  - embedding-shape 5mo ago
    I mean yeah, it doesn't aim to be a "cross-platform compilation/building system" so of course dependencies is up to you to solve, AFAIK AppImage only aims to solve packaging itself, not what goes into that package.
    - ChocolateGod 5mo ago
      Which doesn't solve the same problem that Flatpak solves, namely having a package format that a developer can target and it run the same everywhere.
  - account42 5mo ago
    Its as portable as you make it, just like with binaries in .tar.gz archives or shar installers.
- bitwize 5mo ago
  Errbody seems to use AppImage anyway
  - Andrex 5mo ago
    God I wish. Looking at you, DaVinci Resolve. I'm not sure how AppImage beats Flathub, it's gotten so damn good.
- yjftsjthsd-h 5mo ago
  I'm not sure even that works; does appimage work on musl distros?
zx8080 5mo ago
> 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.
- nar001 5mo ago
  Sorry but you're wrong, Flatpak has been around for longer than that, specifically at least 2014 and was known as xdg-app before https://github.com/alexlarsson/xdg-app/commit/a640cd365bd21743165adedb00bd9fac981687b2 https://github.com/alexlarsson/xdg-app/commit/a640cd365bd217... And if you look at the history page of Flatpak, you'll see that the project has been in development in some form or another for roughly 20 years https://github.com/flatpak/flatpak/wiki/Flatpak's-History https://github.com/flatpak/flatpak/wiki/Flatpak's-History
- deleted 5mo ago
  [deleted]
- Jnr 5mo ago
  But the architecture and approach is probably a bit older than that. Systemd came out in ~2010 and maybe it was not clear if it will stay around for long enough and gain as much popularity as it did?
- shevy-java 5mo ago
  Flatpak is quite old, even before 2016. Didn't we have klick on KDE too? And even before that ... what was the name, not guix, but like versioned app-dirs everywhere (not GoboLinux, but some other name ... not stow either; I forgot the name, but their idea was basically how each installed program is not only versioned but viewable via a GUI too; I think this must have been around 2006 or something like that).
postepowanieadm 5mo ago
Makes sense. BTW. are there efforts to migrate systemd to rust?
- deleted 5mo ago
  [deleted]
- deleted 5mo ago
  [deleted]
- sinpif 5mo ago
  Does a 4 word prompt count? If so then I'm joining the effort right now.
pezgrande 5mo ago
As a Linux normie, I've never understood why systemd is/was so much opinioned about.
- ramon156 5mo ago
  I wasn't there but from what I understood was that people didn't like the fact it was re-inventing an already-existing wheel. In the long run it was useful for some (at least for me it was).
- nightfly 5mo ago
  People seem to think it tries and do too much. As a sysadmin I love systemd, especially way more than the init scripts it replaced
  - fc417fc802 5mo ago
    It's not that it does too much it's that it's monolithic (you can't necessarily swap out components) combined with the fact that the project is gradually subsuming more and more of the userspace utilities. Having the entirety of the userspace half of the OS under a single umbrella seems like a bad idea.
    - Jnr 5mo ago
      I think it came from the necessity for rapid integrations between different parts of the OS. And if it is handled as a single project it takes less time to improve it, since you don't have to align with 10 different projects and their release cycles.
- dockernod 5mo ago
  I unironically believe Docker is a great deal of a reason why it has freshly opinionated newcomers.
  - ndsipa_pomu 5mo ago
    I don't understand that as you don't usually interact with systemd in a container. If Flatpak does end up depending on systemd, then that'll make Flatpak less useful for containers.
nightfly 5mo ago
> 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
- tapoxi 5mo ago
  Seems reasonable to me, it's a rearchitecture to move things up to the systemd level where it makes sense for the majority of distributions but still allow alternative implementations. I wouldn't recommend reading that comment thread, it immediately jumps into "this is fascism!" which is why it's hard to take people seriously sometimes.
deleted 5mo ago
[deleted]
nechuchelo 5mo ago
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.
- danlitt 5mo ago
  FWIW GNOME can be used without systemd, and this is how Guix System does it. I think over time more and more components are depending on systemd, but at the current moment it is still feasible to swap them out for replacements that don't.
  - nechuchelo 5mo ago
    Can it still? IIRC Guix still has GNOME 48 while GNOME said they'll be increasing they dependence on systemd after version 49 or 50[1]. I'd be happy if Guix can support future version as this seems like an end game distro for me, and I'm (slowly) looking into moving there but my understanding is I'd need to stay with KDE Plasma in the long-term. [1] https://lwn.net/Articles/1025560/ https://lwn.net/Articles/1025560/
    - danlitt 5mo ago
      You are right, work on packaging GNOME 49 is still ongoing & may take a while (it is a hard job and not many people are working on it). It is not considered a dead end yet, as far as I can tell: https://lists.gnu.org/archive/html/guix-devel/2026-02/msg00144.html https://lists.gnu.org/archive/html/guix-devel/2026-02/msg001... > my understanding is I'd need to stay with KDE Plasma in the long-term Has KDE committed not to hard-depend on systemd in the future? I would be glad to discover that.
      - nechuchelo 5mo ago
        > gnome-session-shepherd Very nice, hope they can get it working. > Has KDE committed not to hard-depend on systemd in the future? I would be glad to discover that. I was reading somewhere some KDE developers were saying that while some of the components (like plasma-login-manager) might depend on systemd, the core Plasma will not. They're the only major DE remaining on FreeBSD after all.
dig1 5mo ago
[dead]
openclawclub 5mo ago
[flagged]
vibekoter 5mo ago
[dead]
moebrowne 5mo ago
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
- mathw 5mo ago
  Exactly that - the headline is unsupported by the article, but works very well as clickbait.
  - shevy-java 5mo ago
    They said that in the past about many things too - including KDE. I remember the old discussions from a few years, aka KDE will not depend on systemd. Back then I predicted it will happen. Lo and behold - it happened. Isn't it fascinating how naysayers ended up being right, later down the road? This happens often because they tend to be more critical in their thinking than the three seconds memory folks.
boje 5mo ago
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.
- denkmoon 5mo ago
  I just don’t see it. Linux is about choice, if something sucks there is almost certainly an alternative. All 3 people using flatpak but not systemd will just have to use one of the million other ways to install a program.
- loloquwowndueo 5mo ago
  Luckily “Linux desktop” is not a single thing. There are many options to choose from. I’d dial the FUD down just a bit.
  - yjftsjthsd-h 5mo ago
    The entire problem here is that flatpak is exerting pressure to make it a single thing.
  - pjmlp 5mo ago
    Which is a big reason why the Year of Linux Desktop has been delivered in WSL and Virtualization Framework, eventually Googlebooks.
    - loloquwowndueo 5mo ago
      Dunno man, for me the year of Linux Desktop was 1996. Happy ever since.
- 5mo ago
yxhuvud 5mo ago
Curious question: Do snaps interact with or depend on systemd?
- loloquwowndueo 5mo ago
  Yes.
codethief 5mo ago
> 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.
- m4rtink 5mo ago
  Yeah, it sounds promising but far from simple in practice. :) There were some early attempts in mobile Linux distros, like original Ubuntu Touch or even Nokias MeeGo and it turns out the main issue is actually improving security while not blocking whole categories of applications from working. In the early Ubuntu Touch case I remember that you had to as a user allow your image viewer access to individual pictures from SD card, one by one, to see them in the app. This made it basically useless. In the MeeGo use case IIRC third party chroot/shell environments like Termux were impossible due to the way their security/sandboxing system was setup. At the same time all apps had internet and microphone access & it was impossible to disallow it per app.
loloquwowndueo 5mo ago
That’s it. I’m ditching flatpak for snaps. Just kidding!
rho138 5mo ago
The text color schema for the website is a bit rough for reading. Gray-on-white isn’t a great combo
DCKing 5mo ago
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 5mo ago
  > Systemd is not an init system: it's a full cohesive management system for Linux distros. Exactly. If you look back at the old discussions, you see how people tried to claim systemd is merely an init system, but it never was. So all comparisons to e. g. sysinit and what not, were unfair. Dishonest. The systemd devs were not interested in fair discussions. They wanted more control. And they very ruthlessly went forward with it - also thanks to corporate support. Just look at Poettering censoring discussions and stopping them whenever he could. > But moving away from that also breaks with the Unix tradition. Systemd never cared about UNIX. Poettering does not even understand UNIX on top of that. > Systemd as the system management layer is becoming a centerpoint for moving Linux forward Forward to ...? I don't really see it as moving "forward". I see it as more top-down control singularized into one crew that manages the software here. > on servers but especially so on the desktop, and it does so at the cost of breaking with traditional views Well, I would not call it "traditional", as the name is loaded. I see it more as a way to gain more control over the whole ecosystem. We see the same happen with wayland, but on a smaller scale, as wayland does not try to integrate a billion features and functionality. > 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. I don't like systemd, but I view this more realistic. I saw how the non-systemd distributions struggled and eventually most went extinct or were converted into systemd. Only few remain strong, and those few are often also dead - like slackware. And yes I know the spin-offs, but seriously, slackware is a dead man walking. Void is not dead, but yikes, it's not moving forward either. It is not only systemd though. The whole linux stack got a lot bigger and more complicated. Nowadays you often need python, meson, llvm, mesa and so forth to compile things. Everything got bigger too. A lot of software was abandoned downstream, such as fluxbox - may be irrelevant to most folks, but this is one example of sooo many more. At the base of this problem sits the funding issue. Corporations have a lot more net-control over the ecosystem nowadays. Due to the funding. I think we need to solve this issue of funding, because otherwise we'll end up with systemd-like projects sitting at the key areas.
shevy-java 5mo ago
> 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-4045027951 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_ 5mo ago
Flatpak project maintainers, please do not do that. Leave Flatpak universally accessible. I like my alternative Linux distros without systemd.
nottorp 5mo ago
Hmm I just realized. Systemd is a great example of embrace and extend that was actually succesful. Microsoft should have just hired Poettering.
- AnonymousPlanet 5mo ago
  They did. https://news.ycombinator.com/item?id=32007955 https://news.ycombinator.com/item?id=32007955
- weikju 5mo ago
  You’re 4 years too late [1]. And as per Wikipedia he left this year. [1] https://www.phoronix.com/news/Systemd-Creator-Microsoft https://www.phoronix.com/news/Systemd-Creator-Microsoft
  - nottorp 5mo ago
    Looks like I like my Poettering news like my gaming: https://xkcd.com/606/ https://xkcd.com/606/
    - kelvinjps10 5mo ago
      I do the same as the comic
deleted 5mo ago
[deleted]
anarki8 5mo ago
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 5mo ago
Title should be "Flatpack 2.0 considered to be depended on Systemd"
HelloNurse 5mo ago
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.
JCattheATM 5mo ago
This is bad news, and exactly the type of viral problem criticics of systemd warned about. Systemd advocates always downplay the issue, but here we are. I love using Alpine, and for the few packages that don't have a musl version available (e.g. Steam), flatpak has been a great way to run them. Hopefully someone will maintain a fork.
egorfine 5mo ago
I think they now have to make age verification mandatory, require snapd and rewrite everything in Rust.
greatgib 5mo ago
Kind of another proof that Systemd is a cancer... Little by little, all parts of the stack have to switch to have strong dependencies to it. All of that for things totally unrelated to the feature of "init system". And just in the end, we will finish with the same kind of monolith that we can experience with Windows.
musicale 5mo ago
Self-correcting problem.

103 points by birdculture 5mo ago

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

embedding-shape 5mo ago

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?

ChocolateGod 5mo ago
AppImage isn't truly cross distribution in the first place because how it handles dependencies is not truly portable.
- embedding-shape 5mo ago
  I mean yeah, it doesn't aim to be a "cross-platform compilation/building system" so of course dependencies is up to you to solve, AFAIK AppImage only aims to solve packaging itself, not what goes into that package.
  - ChocolateGod 5mo ago
    Which doesn't solve the same problem that Flatpak solves, namely having a package format that a developer can target and it run the same everywhere.
- account42 5mo ago
  Its as portable as you make it, just like with binaries in .tar.gz archives or shar installers.
bitwize 5mo ago
Errbody seems to use AppImage anyway
- Andrex 5mo ago
  God I wish. Looking at you, DaVinci Resolve. I'm not sure how AppImage beats Flathub, it's gotten so damn good.
yjftsjthsd-h 5mo ago
I'm not sure even that works; does appimage work on musl distros?

zx8080 5mo ago

> 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.

nar001 5mo ago
Sorry but you're wrong, Flatpak has been around for longer than that, specifically at least 2014 and was known as xdg-app before https://github.com/alexlarsson/xdg-app/commit/a640cd365bd21743165adedb00bd9fac981687b2 https://github.com/alexlarsson/xdg-app/commit/a640cd365bd217... And if you look at the history page of Flatpak, you'll see that the project has been in development in some form or another for roughly 20 years https://github.com/flatpak/flatpak/wiki/Flatpak's-History https://github.com/flatpak/flatpak/wiki/Flatpak's-History
deleted 5mo ago
[deleted]
Jnr 5mo ago
But the architecture and approach is probably a bit older than that. Systemd came out in ~2010 and maybe it was not clear if it will stay around for long enough and gain as much popularity as it did?
shevy-java 5mo ago
Flatpak is quite old, even before 2016. Didn't we have klick on KDE too? And even before that ... what was the name, not guix, but like versioned app-dirs everywhere (not GoboLinux, but some other name ... not stow either; I forgot the name, but their idea was basically how each installed program is not only versioned but viewable via a GUI too; I think this must have been around 2006 or something like that).

postepowanieadm 5mo ago

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

deleted 5mo ago
[deleted]
deleted 5mo ago
[deleted]
sinpif 5mo ago
Does a 4 word prompt count? If so then I'm joining the effort right now.

pezgrande 5mo ago

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

ramon156 5mo ago
I wasn't there but from what I understood was that people didn't like the fact it was re-inventing an already-existing wheel. In the long run it was useful for some (at least for me it was).
nightfly 5mo ago
People seem to think it tries and do too much. As a sysadmin I love systemd, especially way more than the init scripts it replaced
- fc417fc802 5mo ago
  It's not that it does too much it's that it's monolithic (you can't necessarily swap out components) combined with the fact that the project is gradually subsuming more and more of the userspace utilities. Having the entirety of the userspace half of the OS under a single umbrella seems like a bad idea.
  - Jnr 5mo ago
    I think it came from the necessity for rapid integrations between different parts of the OS. And if it is handled as a single project it takes less time to improve it, since you don't have to align with 10 different projects and their release cycles.
dockernod 5mo ago
I unironically believe Docker is a great deal of a reason why it has freshly opinionated newcomers.
- ndsipa_pomu 5mo ago
  I don't understand that as you don't usually interact with systemd in a container. If Flatpak does end up depending on systemd, then that'll make Flatpak less useful for containers.

nightfly 5mo ago

> 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

tapoxi 5mo ago
Seems reasonable to me, it's a rearchitecture to move things up to the systemd level where it makes sense for the majority of distributions but still allow alternative implementations. I wouldn't recommend reading that comment thread, it immediately jumps into "this is fascism!" which is why it's hard to take people seriously sometimes.

deleted 5mo ago

[deleted]

nechuchelo 5mo ago

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.

danlitt 5mo ago
FWIW GNOME can be used without systemd, and this is how Guix System does it. I think over time more and more components are depending on systemd, but at the current moment it is still feasible to swap them out for replacements that don't.
- nechuchelo 5mo ago
  Can it still? IIRC Guix still has GNOME 48 while GNOME said they'll be increasing they dependence on systemd after version 49 or 50[1]. I'd be happy if Guix can support future version as this seems like an end game distro for me, and I'm (slowly) looking into moving there but my understanding is I'd need to stay with KDE Plasma in the long-term. [1] https://lwn.net/Articles/1025560/ https://lwn.net/Articles/1025560/
  - danlitt 5mo ago
    You are right, work on packaging GNOME 49 is still ongoing & may take a while (it is a hard job and not many people are working on it). It is not considered a dead end yet, as far as I can tell: https://lists.gnu.org/archive/html/guix-devel/2026-02/msg00144.html https://lists.gnu.org/archive/html/guix-devel/2026-02/msg001... > my understanding is I'd need to stay with KDE Plasma in the long-term Has KDE committed not to hard-depend on systemd in the future? I would be glad to discover that.
    - nechuchelo 5mo ago
      > gnome-session-shepherd Very nice, hope they can get it working. > Has KDE committed not to hard-depend on systemd in the future? I would be glad to discover that. I was reading somewhere some KDE developers were saying that while some of the components (like plasma-login-manager) might depend on systemd, the core Plasma will not. They're the only major DE remaining on FreeBSD after all.

dig1 5mo ago

[dead]

openclawclub 5mo ago

[flagged]

vibekoter 5mo ago

[dead]

moebrowne 5mo ago

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

mathw 5mo ago
Exactly that - the headline is unsupported by the article, but works very well as clickbait.
- shevy-java 5mo ago
  They said that in the past about many things too - including KDE. I remember the old discussions from a few years, aka KDE will not depend on systemd. Back then I predicted it will happen. Lo and behold - it happened. Isn't it fascinating how naysayers ended up being right, later down the road? This happens often because they tend to be more critical in their thinking than the three seconds memory folks.

boje 5mo ago

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.

denkmoon 5mo ago
I just don’t see it. Linux is about choice, if something sucks there is almost certainly an alternative. All 3 people using flatpak but not systemd will just have to use one of the million other ways to install a program.
loloquwowndueo 5mo ago
Luckily “Linux desktop” is not a single thing. There are many options to choose from. I’d dial the FUD down just a bit.
- yjftsjthsd-h 5mo ago
  The entire problem here is that flatpak is exerting pressure to make it a single thing.
- pjmlp 5mo ago
  Which is a big reason why the Year of Linux Desktop has been delivered in WSL and Virtualization Framework, eventually Googlebooks.
  - loloquwowndueo 5mo ago
    Dunno man, for me the year of Linux Desktop was 1996. Happy ever since.
5mo ago

yxhuvud 5mo ago

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

loloquwowndueo 5mo ago
Yes.

codethief 5mo ago

> 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.

m4rtink 5mo ago
Yeah, it sounds promising but far from simple in practice. :) There were some early attempts in mobile Linux distros, like original Ubuntu Touch or even Nokias MeeGo and it turns out the main issue is actually improving security while not blocking whole categories of applications from working. In the early Ubuntu Touch case I remember that you had to as a user allow your image viewer access to individual pictures from SD card, one by one, to see them in the app. This made it basically useless. In the MeeGo use case IIRC third party chroot/shell environments like Termux were impossible due to the way their security/sandboxing system was setup. At the same time all apps had internet and microphone access & it was impossible to disallow it per app.

loloquwowndueo 5mo ago

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

rho138 5mo ago

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

DCKing 5mo ago

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 5mo ago
> Systemd is not an init system: it's a full cohesive management system for Linux distros. Exactly. If you look back at the old discussions, you see how people tried to claim systemd is merely an init system, but it never was. So all comparisons to e. g. sysinit and what not, were unfair. Dishonest. The systemd devs were not interested in fair discussions. They wanted more control. And they very ruthlessly went forward with it - also thanks to corporate support. Just look at Poettering censoring discussions and stopping them whenever he could. > But moving away from that also breaks with the Unix tradition. Systemd never cared about UNIX. Poettering does not even understand UNIX on top of that. > Systemd as the system management layer is becoming a centerpoint for moving Linux forward Forward to ...? I don't really see it as moving "forward". I see it as more top-down control singularized into one crew that manages the software here. > on servers but especially so on the desktop, and it does so at the cost of breaking with traditional views Well, I would not call it "traditional", as the name is loaded. I see it more as a way to gain more control over the whole ecosystem. We see the same happen with wayland, but on a smaller scale, as wayland does not try to integrate a billion features and functionality. > 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. I don't like systemd, but I view this more realistic. I saw how the non-systemd distributions struggled and eventually most went extinct or were converted into systemd. Only few remain strong, and those few are often also dead - like slackware. And yes I know the spin-offs, but seriously, slackware is a dead man walking. Void is not dead, but yikes, it's not moving forward either. It is not only systemd though. The whole linux stack got a lot bigger and more complicated. Nowadays you often need python, meson, llvm, mesa and so forth to compile things. Everything got bigger too. A lot of software was abandoned downstream, such as fluxbox - may be irrelevant to most folks, but this is one example of sooo many more. At the base of this problem sits the funding issue. Corporations have a lot more net-control over the ecosystem nowadays. Due to the funding. I think we need to solve this issue of funding, because otherwise we'll end up with systemd-like projects sitting at the key areas.

shevy-java 5mo ago

> 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-4045027951 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_ 5mo ago

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

nottorp 5mo ago

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

AnonymousPlanet 5mo ago
They did. https://news.ycombinator.com/item?id=32007955 https://news.ycombinator.com/item?id=32007955
weikju 5mo ago
You’re 4 years too late [1]. And as per Wikipedia he left this year. [1] https://www.phoronix.com/news/Systemd-Creator-Microsoft https://www.phoronix.com/news/Systemd-Creator-Microsoft
- nottorp 5mo ago
  Looks like I like my Poettering news like my gaming: https://xkcd.com/606/ https://xkcd.com/606/
  - kelvinjps10 5mo ago
    I do the same as the comic

deleted 5mo ago

[deleted]

anarki8 5mo ago

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 5mo ago

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

HelloNurse 5mo ago

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.

JCattheATM 5mo ago

This is bad news, and exactly the type of viral problem criticics of systemd warned about. Systemd advocates always downplay the issue, but here we are. I love using Alpine, and for the few packages that don't have a musl version available (e.g. Steam), flatpak has been a great way to run them. Hopefully someone will maintain a fork.

egorfine 5mo ago

I think they now have to make age verification mandatory, require snapd and rewrite everything in Rust.

greatgib 5mo ago

Kind of another proof that Systemd is a cancer... Little by little, all parts of the stack have to switch to have strong dependencies to it. All of that for things totally unrelated to the feature of "init system". And just in the end, we will finish with the same kind of monolith that we can experience with Windows.

musicale 5mo ago

Self-correcting problem.