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

101–110 of 141 posts

Re: Flatpak Will Depend on Systemd

#101

Post by nechuchelo »

danlitt wrote: post #98
nechuchelo wrote: post #82

Earlier quoted context omitted.

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

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

Re: Flatpak Will Depend on Systemd

#102

Post by gatlin »

bryanlarsen wrote: post #99
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…

How do I install only systemd-appd?

Re: Flatpak Will Depend on Systemd

#103

Post by bryanlarsen »

gatlin wrote: post #102
bryanlarsen wrote: post #99

Earlier quoted context omitted.

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…

How do I install only systemd-appd?

systemd-appd doesn't exist yet.

Re: Flatpak Will Depend on Systemd

#104

Post by gf000 »

eqvinox wrote: post #97
gf000 wrote: post #59

Earlier quoted context omitted.

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.

My point wasn't that pulseaudio is flawless, it's just that it has a much worse name than it deserves.

Re: Flatpak Will Depend on Systemd

#105

Post by oliwarner »

boje wrote: post #31

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

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

Re: Flatpak Will Depend on Systemd

#106

Post by bboozzoo »

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?

Can you share what was that thing that didn't work with systemd? I've seen pretty crazy setups and can't quite imagine how horrid of a mess those would have been if a large rc.init shell script ridden with sleeps was used instead.

Re: Flatpak Will Depend on Systemd

#107

Post by bboozzoo »

account42 wrote: post #90
aniviacat wrote: post #16

Earlier quoted context omitted.

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.

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

Why would they care about any other views but their own and those who contribute either financially or through code? Seems like all people can do these days is complain on github, X, mastodon, reddit, HN. It's only talk, talk and more talk, but no do.

Re: Flatpak Will Depend on Systemd

#108

Post by bboozzoo »

ChocolateGod wrote: post #81
shevy-java wrote: post #73

Earlier quoted context omitted.

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

> Systemd never was "merely" only an init system There is systemd the service manager/init system and systemd the project. An alternative service manager could add support for the formers unit files.

> An alternative service manager could

I guess we would care if one showed up, no?

Re: Flatpak Will Depend on Systemd

#109

Post by nottorp »

bboozzoo wrote: post #106
nottorp wrote: post #69

Earlier quoted context omitted.

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

Can you share what was that thing that didn't work with systemd? I've seen pretty crazy setups and can't quite imagine how horrid of a mess those would have been if a large rc.init shell script ridden with sleeps was used instead.

Last time? Getting pppoe to automatically start and restart if it dies. Or not that, but setting up everything for a custom router with proper dns, firewall and all the other crap, without using crippled systemd versions for services that i couldn't even uninstall because of dependencies.

Maybe it's Ubuntu's fault since they seem to want to run in containers not on bare metal lately.

I switched that box to Devuan in the mean time :)

Re: Flatpak Will Depend on Systemd

#110

Post by shevy-java »

pas wrote: post #52
boje wrote: post #31

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

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.

Those not liking systemd here already moved from debian to devuan.
Post reply on HN