Live data from Hacker News

Flatpak Will Depend on Systemd

osnews.com

71–80 of 141 posts

Re: Flatpak Will Depend on Systemd

#71

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.

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

Re: Flatpak Will Depend on Systemd

#72

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…

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.

Re: Flatpak Will Depend on Systemd

#73

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"

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.

Re: Flatpak Will Depend on Systemd

#74
post #63

Earlier quoted context omitted.

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

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.

I've noticed a trend that the same people who complain systemd does too much also have a strong affinity for the X server... with it's built in print server!

Re: Flatpak Will Depend on Systemd

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

Re: Flatpak Will Depend on Systemd

#79
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

Re: Flatpak Will Depend on Systemd

#80
post #62

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.

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.

Wayland is different, they pretended nothing except compositing and window positioning matters.
Post reply on HN