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

Introducing stronger dependencies on systemd

blogs.gnome.org

Post reply on HN
Print view View original

101–110 of 179 posts

Re: Introducing stronger dependencies on systemd

#101

Post by rbanffy »

gatlin wrote: post #98
pcpuser wrote: post #91

Earlier quoted context omitted.

Care to share any evidence to back up the tall claim that systemd authors forced their code on anyone?

The claim was "shopped around" and if you are going to change people's words do not be surprised when nobody takes your challenge. And preemptively: absence of evidence is not evidence of absence.

> absence of evidence is not evidence of absence

After holding up well for a long time, absence of evidence becomes a good indicator for actual evidence of absence.

Re: Introducing stronger dependencies on systemd

#102

Post by rbanffy »

pona-a wrote: post #92
growse wrote: post #84

Earlier quoted context omitted.

> Replying to some sibling comments asking why anyone wouldn't want to use systemd. I get why some people don't want to use systemd. That's fine. I really don't understand why this group of people are so passionate about broadcasting this opinion to anyone within earshot. They don't like a piece of software, great! They've got different values! Use something else!

I think you're missing the point. This is a thread about GNOME, a major desktop environment, declaring systemd-userdb as a necessary requirement for its future version, asking the non-systemd community to provide an API-compatible implementation if they want to keep using GNOME. I personally do not use GNOME, nor am I running a non-systemd system at the moment. This is the first time I wrote a single word about syste…

> if they want to keep using GNOME

It's fine if they don't. Other users of GNOME will want to push back on API changes and deprecation. This is normal in software.

Re: Introducing stronger dependencies on systemd

#103

Post by growse »

gatlin wrote: post #97
pcpuser wrote: post #85

Earlier quoted context omitted.

There's so much I disagree with in the beginning but the ending is what actually grinds my gears. You make it sound like systemd manufactured this monoculture somehow. This is also the point I've seen people throw in a comparison to some closed-source org with money to burn and questionable morals. Systemd was chosen by distros and users across different communities because it solves hard problems better than the oth…

> good tooling My completely oblique, binary logs disagree. It won because it solved problems companies with money needed solved. There is no indication that it succeeded on merit.

I'm interested in your idea that "merit" is some sort of objective measure.

If it works for me but not for you, does it have more merit?

Re: Introducing stronger dependencies on systemd

#104

Post by rbanffy »

sph wrote: post #40

I have yet to hear an argument against systemd which isn’t a variation of: - """bloat""" - I dislike Poettering. Remember pulseaudio? - a core user-space layer for modern applications that can’t only rely on the spartan kernel syscall API? Literally 1984. Given that systemd is good enough and is running on 99% of desktops and servers, I always find it hilarious to see how the vocal minority is overrepresented on this…

> I always find it hilarious to see how the vocal minority is overrepresented on this forum.

Those who oppose the norm are usually a lot more vocal than the people who support it, or just don't care. This is why you get bathtub curves in ratings - you can bet the low ratings are over-represented in comparison with the meh and the praise.

Re: Introducing stronger dependencies on systemd

#105

Post by pona-a »

pcpuser wrote: post #85
pona-a wrote: post #57

Replying to some sibling comments asking why anyone wouldn't want to use systemd. People want to understand their software as well as it's practically possible. It's not an uncommon preference; worse-is-better was quite successful for a reason. As systemd stands, it's an unauditable mess of tightly-coupled components built to handle any conceivable need. These features create new attack vectors: for instance, systemd…

There's so much I disagree with in the beginning but the ending is what actually grinds my gears. You make it sound like systemd manufactured this monoculture somehow. This is also the point I've seen people throw in a comparison to some closed-source org with money to burn and questionable morals. Systemd was chosen by distros and users across different communities because it solves hard problems better than the oth…

I believe you are making assumptions about my beliefs that don't follow from what I said.

> I believe that systemd won out because they chose to embrace some complexity to solve really hard problems. Let's not pretend that a modern "init" does only system initialization by calling shell scripts and then disappearing.

I made a point to clarify I do not think SysV init scripts are a good solution for most systems Starting the services in a correct maximally parallel order is a constraint satisfaction problem, and many modern alternative init systems understand that. My personal favorite, dinit, explicitly uses the systemd model to great success, being faster than runit or OpenRC with less LoC. If someone finds that too opaque, they are free to use a more imperative init system without any obstacles.

> They chose to solve hard problems and people adopted it. It's not anything more sinister. It's definitely not an "un-auditable mess". It's written in well-formatted C with structure, good tooling, and an open community. You can disagree with the ideology but that's open source for you.

A piece of software being hard to understand doesn't imply it's because it's badly written. systemd is simply more complex as an "enterprise" piece of software. Think about it: RedHat's business is selling support contracts, so they won't risk losing a major contract by not implementing a feature their client needs, even if most won't use it. This both made it more robust and much wider in scope than other init systems, maintained mostly by hobbyist desktops.

For contrast, despite Canonical having killed Upstart in 2014, Google still feels confident enough in its security to deploy it across millions of ChromeOS devices, because it's a simple program that does one thing well, and thus no more risky than any other privileged binary.

> systemd was chosen by distros and users across different communities because it solves hard problems better than the others. We can debate about why that is, but the maintainers of Systemd aren't running smear campaigns against other open source projects. Often systemd is the subject of such ire.

I'm not ascribing any intent to systemd maintainers. But it's undeniable there exists a connection between GNOME, Freedesktop, and systemd, namely that each receive support from RedHat and share the most active RedHat contributors. When systemd releases a new feature, GNOME very soon integrates it, which FreeDesktop then uses as a justification for their new specification, which other desktops soon follow. This often lead us to fast-tracking adoption of genuinely good standards, but there is the confounding factor of funding to their general merit.

Re: Introducing stronger dependencies on systemd

#106

Post by pona-a »

calcifer wrote: post #94
greatgib wrote: post #87

Earlier quoted context omitted.

Systemd is crap. Works in the main use case, mess up otherwise. It is the windows kernel of linux distributions. Here for example, suddenly systemd will be mandatory despite systemd not caring for multiple session of a single user. Not only not yet implemented but totally that don't need it personally so no one can want to have it. And so again the capability of our linux based distribution will be restricted for som…

> Where it is not the responsibility of the initsystem systemd is not an init system. It's an umbrella project with many distinct tools and services, only one of which is an init provider.

What makes it problematic is that they still end up with cross-dependencies. I might find resolved or logind great tools, but I can't use them without systemd, even though I can sitll use systemd without resolved. They all reinforce systemd as an irreplaceable component that will only grow more hooks for these subprojects, becoming increasingly unimplementable and complex.

Re: Introducing stronger dependencies on systemd

#107

Post by noname120 »

msgodel wrote: post #52
fotomar wrote: post #50

Earlier quoted context omitted.

[flagged]

During Microsoft's most recent shareholder meeting the CEO actually bragged about spamming HN and successfully getting people to use Azure that way. I wouldn't be surprised if they were at least partly behind the big systemd/gnome pushes.

It's a lie. Here is a verbatim transcript and you'll find that there was no mention of Hacker News whatsoever or anything close to that:

https://www.microsoft.com/en-us/investor/events/fy-2025/2024...

Re: Introducing stronger dependencies on systemd

#108

Post by pona-a »

airhangerf15 wrote: post #95
bobowzki wrote: post #7

Earlier quoted context omitted.

What do you recommend instead?

If you've never tried a tiling window manager, give them a try. I've been on i3 for over a decade and love it. It takes a lot more work to setup, but once you get going, it's an amazing environment. If you insist on using Wayland, Hyprland is an excellent choice. It's the least broken tiling widow manager for Wayalnd. Sway was the original i3-compatiable replacement and it's still not all that great.

Can you explain what's wrong with sway? I've been using it for quite a while and it's been the one of the most stable pieces of graphical Linux software I've yet seen. It seems to handle most of my features, except i3-like layout saving.

Re: Introducing stronger dependencies on systemd

#109

Post by jeroenhd »

pona-a wrote: post #57

Replying to some sibling comments asking why anyone wouldn't want to use systemd. People want to understand their software as well as it's practically possible. It's not an uncommon preference; worse-is-better was quite successful for a reason. As systemd stands, it's an unauditable mess of tightly-coupled components built to handle any conceivable need. These features create new attack vectors: for instance, systemd…

The end of the article details the steps necessary for people who want to run Gnome without systemd. There is a monoculture of sorts, which is that bespoke init systems aren't tested or supported by Gnome itself, but like you already need to do to get Gnome working normally, you can still patch in support for whatever system you prefer. The article even provides a list of services and APIs that you will need to hook up to Gnome to make it work.

You don't need to reimplement logind or D-Bus, but you will need to patch your mechanisms of choice into Gnome itself. Gnome isn't planning on maintaining a second copy of common system services that exist on modern systems anymore (a copy that is based on a hack in the first place). The burden of maintenance now falls on whoever wants to provide their own alternative.

All the extra work you need to do to get alternative init systems working is work the Gnome team no longer needs to do.

Re: Introducing stronger dependencies on systemd

#110

Post by jeroenhd »

greatgib wrote: post #87
haileys wrote: post #39

This is a sensible move. systemd is a good piece of software, and foundational Linux infrastructure which by now is very widely deployed. I’ve been doing Linux a long time and my experience is that systemd is much more pleasant to work with than the brittle duct tape and shell script stuff which came before.

Systemd is crap. Works in the main use case, mess up otherwise. It is the windows kernel of linux distributions. Here for example, suddenly systemd will be mandatory despite systemd not caring for multiple session of a single user. Not only not yet implemented but totally that don't need it personally so no one can want to have it. And so again the capability of our linux based distribution will be restricted for som…

systemd is far from perfect, but it's the best we've got on Linux. Treating systemd like an init system is like treating your car like a Bluetooth speaker: yes, you can connect your phone to the speaker system over bluetooth and yes you can take the speakers with you to most places, but the speakers are only a small part of what you're taking along with you

Nobody is forcing systemd down anyone's throats. You can use init.d if you like, or OpenRC, or whatever you prefer. What's happening instead is that people who maintain software are no longer interested in maintaing init.d scripts or working around the missing features many supposed alternatives lack.

Post reply on HN