[pcpuser]

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

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.

Additionally and away from my point, I believe that Systemd won our because they chose to embrace some complexity to solve really hard problems. Let's not pretend that a modern "init" does only system initialisation by calling shell scripts and then disappearing.

[msgodel]

All of us paying attention saw how the systemd authors shopped their stuff around issue trackers and mailing lists telling everyone "it's just the way it is now." They absolutely did manufacture the situation. They pushed hard enough doing this that it's resulted in multiple large distros being forked by groups of former maintainers.

[panick21_]

Oh my god, they told other people they are developing open source software and that they like their own software. Say it aint so. Have we informed the authorities about this?

[pcpuser]

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

[gatlin]

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.

[pcpuser]

What does "shopped around" mean? That's not a common or accepted idiom for code. Or not one I've come across anyway.

Also show me evidence of them "shopping around" code. I'll wait.

[nixosbestos]

Truly, don't bother. I've been watching this conversation play out for 10 years. I've watched it play out with systemd, udev, rust, Wayland.

Just ignore them. Their validation is meaningless. Their ignorance is mostly meaningless, too, for reasons that feel mean to type out.

[justinrubek]

I'm getting the sense that both sets of parties here have a strong opinion and that this isn't a real discussion because of that.

[gatlin]

My task here was to reprimand you for arguing disingenuously, not to teach you language or do homework for you. What an appallingly entitled way to carry yourself.

[rbanffy]

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

[codeguro]

obligatory: https://news.ycombinator.com/item?id=11797075

[gatlin]

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

[panick21_]

There are pros and con with binary logs. One isn't magically better.

The tools they have for their logs are pretty good, and its incredibly easy to disable, if you do, you will never notice a difference.

Helping engineers solve technical problems is not 'success'? Its only 'success' if open source nerds use it in their basement to run on an old sun workstation? What kind of dumb logic is that?

Why do you think Linux sees so much development?

[gatlin]

Logs that I can read are objectively better. I must assert that point because it is true.

[pcpuser]

Ths only issue that non-human readable log storage has caused is the endless nagging on forums. Literally never been an issue besides.

[taskforcegemini]

literally has, or there would be no "nagging". I have yet to experience a benefit for those binary logs

[growse]

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?

[LargoLasskhyfv]

Some anecdotical evidence of mine. I tend to kill -9 Firefox or derivatives before system, or browser updates, to reliably get my tabs and cookies (for selected sites) back, without the need for any extensions.

Usually I'm doing that from within htop, or btop++. Under systemd that is slow, the process-tree of FF takes several seconds to vanish.

That felt very wrong. I increased the update frequency of htop and btop++ to 200ms (usually they poll/actualize/redraw at 2 seconds only) to investigate.

Then I retested that with Runit/S6(6) on the same systems.

Magic! The process-tree is instantly gone! And if you only SigHup it, it instantly reappears. BAM! BAM! BAM!

This applies to all sorts of process-trees also, not only FF.

Compared to that systemd feels like a sloth.

Yes, Yes, I did that under several different distros, initially AntiX, recently "init diversity edition"(Debian derivative optimized for 'live-booting', running from RAM, in all sorts of 'Frugal' installs), some Arch-derivatives, sometimes 'riced' to the max, and default Debian, just to be sure.

Over several years. Initially on a Core-i7 640LM with only 8GB RAM, more recently on Core-i5 7500t, and Core-i7 7700t with 32GB RAM.

Verdict: systematically slo(w)thified.

[LargoLasskhyfv]

Do you think this is any different on more modern systems? Fear not, it gets worse with more cores!1!!

[tempfile]

> You make it sound like systemd manufactured this monoculture somehow.

Where are you getting this from? I do not see it at all. The parent comment just says that it is an emergent compromise they don't think is a good one. That the code cannot be audited is also not necessarily a quality issue, either. It is just impossible to feasibly audit over 10 million lines of C. (this criticism applies equally to the kernel, although I doubt anyone would claim the kernel is less audited than systemd)

> Let's not pretend that a modern "init" does only system initialisation by calling shell scripts and then disappearing.

Nobody is pretending this. the comment you are replying to literally says "I don't think it represents the current state of the community".

[pona-a]

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.

[juped]

systemd isn't even a constraint solving system, it's highly "imperative", there's just memes floating around that think it is??? not even poettering would claim that

[adrian_b]

What you say would be more credible if you would provide a list of those "hard problems".

I have been using Linux on many desktops, laptops, servers, including on my primary workstations, for the last 30 years. I have also managed Linux on the computers of other people who have successfully used Linux for many years, despite the fact that they did not know what "Linux" is.

During all these years, both at home and at various companies, I have never encountered any of those problems for which systemd is supposedly required.

Using systemd appears to be a matter of preference, not of necessity. However I have never seen any Linux users who could explain their preference for systemd.

Systemd is ubiquitous now because it has been chosen by the maintainers of most major Linux distributions, not because it has been chosen by any end-users. Most maintainers also have not chosen it for any personal reasons, but because the maintenance of the distribution would have become a PITA without systemd, due to the dependencies introduced by a few important packages, like GNOME, which were thought to be indispensable in any distribution.

Perhaps systemd has some advantages that I am not aware of, but with certainty the proponents of systemd suck at selling it, because they have never been able to describe those advantages. Instead of trying to convince others that systemd is technically superior, the dependencies upon systemd have been imposed by force upon all Linux users by a relatively small number of developers.

By coincidence, just these days I have begun to study elogind, which is mentioned in TFA and which is a workaround for not having a complete systemd.

Until a couple of weeks ago, I had succeeded to not use even elogind, but the last version of the Xorg server has acquired a hard dependency on systemd, so after upgrading it now I have to run this additional useless elogind daemon, to simulate the presence of systemd. I have begun to study elogind because launching it early during boot seems to have introduced some bugs in the behavior of the Linux virtual consoles. Even if I normally do not use those, I have been intrigued so I have started to investigate what elogind really does.

After these news about GNOME, I think that I will be forced to do a much more thorough study of elogind and systemd than I would have ever wanted to do, in order to write some replacements for satisfying any systemd dependencies in the applications that I am interested. I do not use GNOME, but there are useful applications that expect some GNOME services, and those may become now more dependent of systemd.

I hate that I will have to do a lot of work without any obvious useful purpose, just to keep running the same programs that previously worked fine without systemd.