Flatpak Will Depend on Systemd

https://www.osnews.com/story/145071/flatpak-will-depend-on-systemd/

by birdculture • 2 months ago

103 129 2 months 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?

ChocolateGod6• 2 months ago

AppImage isn't truly cross distribution in the first place because how it handles dependencies is not truly portable.

embedding-shape2• 2 months 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.

account425• 2 months ago

Its as portable as you make it, just like with binaries in .tar.gz archives or shar installers.

bitwize• 2 months ago

Errbody seems to use AppImage anyway

Andrex• 2 months ago

God I wish.

Looking at you, DaVinci Resolve.

I'm not sure how AppImage beats Flathub, it's gotten so damn good.

yjftsjthsd-h2• 2 months ago

I'm not sure even that works; does appimage work on musl distros?

zx8080• 2 months 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• 2 months 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/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

Jnr7• 2 months 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-java7• 2 months 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• 2 months ago

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

sinpif3• 2 months ago

Does a 4 word prompt count? If so then I'm joining the effort right now.

ElenaDaibunny• 2 months ago

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

pezgrande2• 2 months ago

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

ramon156• 2 months 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).

nightfly2• 2 months 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

fc417fc8022• 2 months 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.

dockernod• 2 months ago

I unironically believe Docker is a great deal of a reason why it has freshly opinionated newcomers.

ndsipa_pomu• 2 months 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.

aniviacat• 2 months ago

The way it's structured (combining many previously separate utilities into one) hinders competition. That's tolerable while it's still one of the best solutions for the things it does, but will become an issue in the future.

account425• 2 months ago

It's already an issue now because "best" is subjective but SystemD developers only care about their own views.

theandrewbailey• 2 months ago

It violates the Unix philosophy of 'do only one thing and do it well', but personally, it has never been a problem for me.

I had a nightmare last week wherein I read a headline that systemd was writing its own kernel. When I woke up I realized it was a possibility, after all it has replaced GRUB. https://wiki.archlinux.org/title/Systemd-boot

happymellon3• 2 months ago

It violates the Unix philosophy of 'do only one thing and do it well'

How? This is really where it's basically a marketing fail.

Even your own link for system-boot shows that it is it's own rebranding of gummi-boot. It's not part of the init system, they just have an identically named project which has 100 utilities in it. It's dumb and it's community hostile.

zamadatix• 2 months ago

There is a lot systemd violates in regards to the traditional Unix philosphy rules. The one about do one thing well is probably the most arguable though since systemd is more a set of functionality across a ton of binaries, each with a more focused purpose. Where it differs is in how those interact vs a "normal" collection of Linux binaries where it's expected to be easy to swap out an individual component and still talk to the rest without implementing things like binary formats.

Jnr7• 2 months ago

after all it has replaced GRUB.

With unified kernel images there is no need for grub or any other bootloader anymore. And UKI simplifies boot configuration and helps improving security in some aspects.

gf0004• 2 months ago

Linux kernel, X server, web browsers all seriously violate the Unix philosophy.

And to be perfectly honest, it's nothing more than a philosophy - it's not some universal truth, e.g. a browser by definition is not doing "one small thing" and complex workloads are better organized by monolithic software to a certain degree.

TiredOfLife• 2 months ago

Is there any piece of modern linux that follows that Unix philosophy?

Yizahi• 2 months ago

Funny how people in this topic at the same time complain about systemd being multi-featured and then complain about abandonment of X11 in favor of of the more focused Wayland. :)

It seems to me that the real differentiator is not the number of features but software release date :)

happymellon3• 2 months ago

Because systemd confuses a lot of things by having two projects with the same name.

Systemd the init service is excellent.

Systemd the catch all for trying to rewrite all services to come up with a baseline version of everything is a strange and NIH project. They would have been far better off politically by coming up with a spec and seeing if they could submit patches to get the current services to use the APIs they were planning.

Instead they just have a bundle of things they have tried to reinvent, some more successfully than others. Hence the divisions in the communities.

Izkata4• 2 months ago

Systemd the init service is excellent.

When it's not actively going against decades of convention and breaking solid programs everyone has used forever: https://superuser.com/questions/1372963/how-do-i-keep-system...

(screen was also affected, not just tmux)

I'm not sure if it was linked from there, but somewhere in the discussions the systemd devs' recommended fix was for screen/tmux/anything else affected to add some systemd integration for their new API.

As far as I'm aware the complaints about this stopped only because distros override the setting, while it's still the default for stock systemd.

PhilipRoman• 2 months ago

It is a fantastic init system/service supervisor. My problem with it is basically everything else. I think its developers see systemd as central to the entire system, basically the userspace counterpart to the kernel. I prefer the approach of 'dinit', but I understand why they designed it that way.

Due to this design they often have underspecified interaction between the different components, since the assumption is that everyone will use largely the same baseline systemd environment and as long as it works, who cares what it does underneath. If the different parts were more independent, they would be forced to develop a cleaner API contract between them.

mrktf• 2 months ago

I will add this: if you treat systemd as one trick pony and use for few use-cases which developers envisioned - it run flawlessly, but moment do something not in this path prepare for problems and inferior experience (example of randomly picked tool: timedatectl - no force update date like ntpdate command, you cannot quickly insert ethernet cable update date and disconnect... need to wait for synchronization)

Avshalom3• 2 months ago

Okay so back in ~2000 the audio system in Linux was ALSA and it kinda sucked so along come a guy named Lennart Poettering who wrote pulseaudio which improved things in a lot of ways but also kinda constantly didn't work. Poettering in those years constantly blamed everything on other software in the stack and became kinda wildly disliked. We all had to use pulseaudio though because everything important decided to integrate it.

Jump forward to systemd and absolutely none of trust Poettering farther than we can throw him. At the same time systemd basically did the job of half a dozen programs which offends a lot of people on philosophical grounds. Simultaneously a bunch of things start hard requiring this program that people neither trust nor like.

Jnr7• 2 months ago

Yes, but people learned from issues that pulseaudio had and then came pipewire. Everyone is happy now.

I don't know about the philosophical aspects, but from pure technical point of view systemd brought some order into the mess. Before systemd it seemed like most distros were barely holding together with duct tape. Systemd standardized a lot of things.

I am fine with a little bit of controversy if the result is a much better desktop OS experience for the user. And as a relatively long time Linux user, I can certainly say it is much better now than it was 20 years ago.

gf0004• 2 months ago

Well, for ALSA and pulseaudio, the latter more or less just surfaced the tons of bugs in the underlying, at the time very shitty audio drivers. Remember, only pulseaudio is a sound server, so ALSA wasn't even exercising many of the more "advanced" features, and drivers were only supporting the most basic stuff.

adjejmxbdjdn• 2 months ago

So he creates a program that was good enough that pretty much everyone started using it.

And he complained about a lot of dependencies but then went and actually wrote fixes/solutions for them that was so good that nearly everyone started using and even depending on it.

It sounds like the people who were sitting on the sidelines complaining about his complaining had ample opportunities to write better alternatives than the programs he wrote but didn’t do so. Instead they relied on character attacks and FUD (well, except the folks who developed pipewire), while Poettering wa engage in elite hacking by implementing solutions and letting users and distro makers decide whether they wanted to use those solutions.

I don’t see how Poettering is the villain here.

pezgrande2• 2 months ago

Interesting... didn't know this part of Linux history. I remember complaining about pulseaudio crashing a lot though ha. Thanks for sharing it.

lousken• 2 months ago

... and it's not even written in Rust

greatgib2• 2 months ago

I don't know recently, but at the time that systemd was shoved through our throat, you could look at the source code and it was a giant ball of horse shit. Following bad practices, hard coding things, ... With absolutely strong tendency to not give a shit about feedbacks from others, and supporting anything except the highway case that is the only one that they cared about.

And as anyone could have expected, systemd broke a lot of things, and sometimes very badly with their shitty code. Like this time that they wiped the nvram memory of laptop transforming them into bricks...

nightfly2• 2 months 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• 2 months 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.

nechuchelo3• 2 months 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.

danlitt2• 2 months 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.

nechuchelo3• 2 months 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/

ChocolateGod6• 2 months ago

Maybe systemd should have been an API + a spec instead of an unportable implementation.

There's nothing really stopping other init systems from implementing it's unit spec, some hobby ones have done so.

In the case of GNOME, KDE etc depending on it, the reason mainly boils down to "we could implement our own manager for handling desktop daemons etc or just get systemd to do it for us"

shevy-java7• 2 months ago

But why would they do so? That makes no objective sense.

Systemd never was "merely" only an init system. And it makes no sense for init systems to grow to systemd-size either, in order to solve non-init related issues.

In the case of GNOME, KDE etc depending on it, the reason mainly boils down to "we could implement our own manager for handling desktop daemons etc or just get systemd to do it for us"

That's not quite true. GNOME always was close to systemd devs due to funding. KDE was less close, but even within KDE some people lobbied for it such as dave edmunson or however you spell the name, and "me-needs-a-donate-daemon" Nate, who you are not allowed to critisize on #kde reddit. But I agree that they could simplify some code by depending on systemd. Of course this now means that KDE is sold in a dead-lock with systemd. I wonder if I can still use konsole without systemd. I tend to use iceWM since it is so much faster than KDE or GNOME, but when konsole depends on systemd I may indeed need to switch to another terminal. That will be painful though, but there is no stopping systemd - it infects and taints.

eqvinox2• 2 months ago

This really isn't about the unit spec, it's about the 100 other things systemd does.

(Some it does well, some it doesn't, and some it shouldn't.)

maxloh• 2 months ago

Maybe this statement actually holds in reverse?

Quoting vbernat's comment on Lobsters:

  systemd was a "gift" for people running alternative desktop systems. Previously, many services were bundled with GNOME and you had to go through many hops to use them on a non-GNOME desktop (for example, GNOME Power Manager). systemd replaced many of these GNOME-only piece of software that were constantly breaking when you tried to use them outside of GNOME. Alternative desktop environments didn't need to write their own version of system-related tools.
  
  So, while this may be seen as centralization, I don't think we would have seen so many desktop environments without systemd. In the past (15+ years), systems were simpler and there was not many things to abstract.

https://lobste.rs/s/gfbpgq/flatpak_will_depend_on_systemd#c_...

fc417fc8022• 2 months ago

That is a good point but it isn't mutually exclusive with the idea that systemd ought to be a standardized API as opposed to a reference implementation without a standard.

Also despite all its convenience it's not without its drawbacks. Among other things you can no longer just launch a daemon from a chroot now you need a full blown container sporting its own init.

guilhas• 2 months ago

This is I think false

Even if some gnome specific tool didn't work there, guides would point to xfce's tools or lxde or kde or some independent

Or some cli command that I would personally prefer

And even recently these tools were quite bad, so CLI commands, file changes, or extra packages are normally necessary

sinpif3• 2 months ago

I'm all for integration of system services if it helps bring a more cohesive OS. Interchangeability is a nice thing when building a system but I don't need it as a user.

nottorp5• 2 months ago

... have you ever tried to customize a systemd based distro for something they haven't thought of originally?

Jnr7• 2 months ago

Like wayland?

Where none of the desktop environments offer the same feature set. And the more compositors there are the harder it is for apps to use those new protocols, and guaranteeing a ton of bug reports from users using an unsupported compositor. That just hinders Linux desktop app development.

sam_lowry_• 2 months ago

Wayland is different, they pretended nothing except compositing and window positioning matters.

shevy-java7• 2 months ago

A gentoo dev actually showed that GNOME can work without systemd. The gentoo wiki explained it.

I never tested this myself, as I also dislike GNOME3 from a UI view (I am fine with mate-desktop though), but I found this to be epic from the Gentoo folks - a single man flipping a finger to the systemd devs. The underdog winning the fight.

A shame gentoo kind of went into its own hole for years ...

bryanlarsen3• 2 months ago

The headline is inflammatory and misleading. IIUC, flatpak is not depending on systemd as a whole, they're depending on a new component called systemd-appd, which does permissions stuff. This will allow alternate implementations, like how elogind grew out of systemd-logind.

IOW, it is an API + a spec, just like what you're asking for. But it's implementation first, because any API + spec designed by committee rather than being driven by an implementation universally sucks.

gatlin• 2 months ago

How do I install only systemd-appd?

moebrowne• 2 months 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• 2 months ago

Exactly that - the headline is unsupported by the article, but works very well as clickbait.

shevy-java7• 2 months 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• 2 months 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• 2 months 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.

loloquwowndueo4• 2 months 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-h2• 2 months ago

The entire problem here is that flatpak is exerting pressure to make it a single thing.

pjmlp• 2 months ago

Which is a big reason why the Year of Linux Desktop has been delivered in WSL and Virtualization Framework, eventually Googlebooks.

jdiff• 2 months ago

This makes no sense given development is not driven by any one entity that might work privately and start publishing later. All development on these projects is done in the open by a variety of entities who have no mutual interest in colluding in this way.

Systemd is a mix of GPL2 and LGPL. Flatpak is LGPL. Neither has a CLA. Many other parts of the ecosystem are GPLs. It makes no sense for this ecosystem to start serving up primarily FOSS applications with FOSS ethos-es as a proprietarified storefront.

pas• 2 months ago

if people want that they will keep using and supporting (and contributing to) Debian. so far it seems that there's quite some trust toward these projects.

the evolutionarily optimal ratio of predator:prey fluctuates based on how close/far are we to ZIRP.

shevy-java7• 2 months ago

Those not liking systemd here already moved from debian to devuan.

debugnik2• 2 months ago

they might eventually do what Google is doing and start delaying releases for sourcecode

Who is "they" here? There's no value to gain from closing the freedesktop ecosystem: no company has a distribution chokepoint like Google does with Play Store, the overall PC market is in decline and everyone would switch to existing anti-systemd alternatives.

Meneth• 2 months ago

I would imagine Red Hat are pretty close to "they", since they created Systemd and then there was the RHEL redistribution controversy [ https://old.reddit.com/r/Fedora/comments/14k8jmw/can_someone... ].

oliwarner• 2 months ago

they might eventually

That seems like a long series of pessimistic stretches.

I don't love churn but this slow plumbing unification around systemd is delivering a better experience for most. And I don't recognise the push away from copyleft, certainly not in this context.

yxhuvud• 2 months ago

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

loloquwowndueo4• 2 months ago

Yes.

codethief• 2 months 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• 2 months 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.

loloquwowndueo4• 2 months ago

That’s it. I’m ditching flatpak for snaps.

Just kidding!

rho138• 2 months ago

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

DCKing• 2 months 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-java7• 2 months 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.

account425• 2 months ago

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.

Are we talking about open source operating systems hero or app delivery mechanisms?

shevy-java7• 2 months 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-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_• 2 months ago

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

nottorp5• 2 months 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• 2 months ago

They did.

https://news.ycombinator.com/item?id=32007955

weikju• 2 months 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

nottorp5• 2 months ago

Looks like I like my Poettering news like my gaming:

https://xkcd.com/606/

anarki8• 2 months 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• 2 months ago

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

HelloNurse• 2 months 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• 2 months 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• 2 months ago

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

greatgib2• 2 months 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• 2 months ago

Self-correcting problem.

Flatpak Will Depend on Systemd

Related Stories