Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flatpak Will Depend on Systemd

osnews.com

Post reply on HN
Print view View original

91–100 of 141 posts

Re: Flatpak Will Depend on Systemd

#91

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

Re: Flatpak Will Depend on Systemd

#92

Post by account42 »

ChocolateGod wrote: post #11
embedding-shape wrote: post #2

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?

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

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

Re: Flatpak Will Depend on Systemd

#93

Post by Yizahi »

theandrewbailey wrote: post #20
pezgrande wrote: post #6

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

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

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 :)

Re: Flatpak Will Depend on Systemd

#94

Post by nottorp »

weikju wrote: post #79
nottorp wrote: post #75

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

You’re 4 years too late [1]. And as per Wikipedia he left this year. [1] https://www.phoronix.com/news/Systemd-Creator-Microsoft

Looks like I like my Poettering news like my gaming:

https://xkcd.com/606/

Re: Flatpak Will Depend on Systemd

#95

Post by ahartmetz »

nottorp wrote: post #72
adjejmxbdjdn wrote: post #61

Earlier quoted context omitted.

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 th…

> I don’t see how Poettering is the villain here. Poettering seems to be good at politics. Where politics means having his way. Not so much at writing working code, or interoperability.

>good at politics

A son of GDR diplomats, according to an old version of his Wikipedia page. That information seems to be memory-holed now. Now you only find that he grew up in South America without any hint of a reason.

Re: Flatpak Will Depend on Systemd

#96

Post by eqvinox »

ChocolateGod wrote: post #23
nechuchelo wrote: post #12

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.

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

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

Re: Flatpak Will Depend on Systemd

#97

Post by eqvinox »

gf000 wrote: post #59
Avshalom wrote: post #32

Earlier quoted context omitted.

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 int…

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.

That's at odds with the fact that pulseaudio is incapable of exposing the audio reference clocks from sound hardware, which is a fundamental aspect of digital audio engineering. Its design doesn't even acknowledge the existence of an audio clock.

That's fine for basic audio but completely excludes any higher demand application, including high quality A/V sync. Best you can do is work around and best effort guess.

Re: Flatpak Will Depend on Systemd

#98

Post by danlitt »

nechuchelo wrote: post #82
danlitt wrote: post #19

Earlier quoted context omitted.

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.

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/

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

Re: Flatpak Will Depend on Systemd

#99

Post by bryanlarsen »

nechuchelo wrote: post #12

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.

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.

Re: Flatpak Will Depend on Systemd

#100

Post by sinpif »

nottorp wrote: post #69
sinpif wrote: post #38

Earlier quoted context omitted.

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.

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

No. From your tone it sounds like it's probably not as easy as you'd like. I don't really have a response to that. System customization is not something I'm interested in.
Post reply on HN