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

21–30 of 141 posts

Re: Flatpak Will Depend on Systemd

#21

Post by tapoxi »

nightfly wrote: post #7

> 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

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.

Re: Flatpak Will Depend on Systemd

#22

Post by [deleted] »

zx8080 wrote: post #3

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

[deleted]

Re: Flatpak Will Depend on Systemd

#23

Post by ChocolateGod »

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"

Re: Flatpak Will Depend on Systemd

#24

Post by maxloh »

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

Re: Flatpak Will Depend on Systemd

#25

Post by happymellon »

pezgrande wrote: post #6

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

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.

Re: Flatpak Will Depend on Systemd

#28

Post by Jnr »

zx8080 wrote: post #3

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

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?

Re: Flatpak Will Depend on Systemd

#29

Post by PhilipRoman »

pezgrande wrote: post #6

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

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.

Re: Flatpak Will Depend on Systemd

#30

Post by happymellon »

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

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

Post reply on HN