[digi_owl]

Some parts may be useful, some parts are downright awful, but the clincher is that it is all a big wadded up ball of code.

Damn it, the LFS team basically adopted eudev, of Gentoo fame, because extracting udev from systemd required manual intervention over and over.

[noinsight]

> a big wadded up ball of code.

To be clear, they're all under the same umbrella project, but separate components and not everything is in PID 1. People seem to be confused by that.

[digi_owl]

Plenty of the "separate" components share core code at compile time. If they were truly separate they could be downloaded piecemeal and compiled independently.

[scrollaway]

It's kind of annoying reading people lecturing projects they clearly don't know the internals of on how much better their code would be if they did X.

This applies not just to your comment here but to a ton of comments that pop up on HN all the time. Why not in Go? Why not in Rust? Why not in React and node and electron and why don't you use my library that's still in alpha? It's not OOP. You're not using tabs. MIT is too permissive. GPL is too restrictive. And obviously, this should be a set of tiny separate libraries, how dare you work on free software with different ideas than mine.

I once found a project called Razor-qt. It was a desktop environment that included a bunch of interdependant binaries all under the same repo. I didn't like that very much. I joined it, worked on it, ended up leading the project and merging it with LXDE into LXQt. When came the time for the reorganization, I did push to create tiny components that "could be downloaded piecemeal and compiled independently". And we did end up going that route.

You know what I didn't do? I didn't go on HN and complain about a project I didn't know the internals of at the time.

But hey, maybe you know better. ¯\_(ツ)_/¯

[jcadam]

Ah, but did you force others to use your project? People find that sort of thing annoying at best, infuriating at worst, and they will tend to act out in various ways (to include finding fault with the thing they never asked for that's being shoved down their throat).

[scrollaway]

All my life I've been forced to use things such as Windows, Flash, Skype and Photoshop. Forced because of lock-in strategies in a field with difficult alternatives.

"Forced" is not a term that applies to systemd. People say "forced" because their distro adopted it - guess why their distro adopted it? Because they researched it and found it was good. That is the common theme.

Nobody forced you. If you're an arch linux user, for example, one of the distros that switched the earliest, you'd have been more than welcome to discuss counter-points to systemd on the mailing list.

Of course, most of those that attempted doing so were ridiculed out because in free software, or at least on the Arch ML, there is very little tolerance for bullshit. Most (MOST, not all) of the arguments against systemd are in fact bullshit. Hell, even on HN I've seen people crap on systemd because "it's lennartware".

PS: To be clear, there is plenty wrong with systemd. It's far from perfect, it's still very young and I'm not particularly fond of its "all in one" tendencies myself. But most people in this thread have clearly zero ground to comment on its internals, yet many do.

[rdslw]

You're plainly wrong.

1) You write "Most (MOST, not all) of the arguments against systemd are in fact bullshit".

2) And yet you (wrongly) write "there is plenty wrong with systemd"

To be in line with your 1) statement you should write 'it is only small things with systemd which are wrong. Because everything - MOST = small, and not 'plenty'.

Yet you dont do, and you write 'plenty'. Why? Because you know, the moment you write 'there is only a small amount of things wrong with systemd' you will be easily challenged.

So, from logic perspective, you're wrong and you contradict yourself.

[krylon]

OTOH, sharing code between different components developed under an umbrella project is not bad per se - if they require the functionality, re-implementing it from scratch for each component would not be a good idea, either. Duplicating and manually syncing the code also has its share of problems.

[JdeBP]

Is there any chance -- any chance at all -- that we cannot do the same dance of ineptly-phrased-objection followed by rebuttal-that-misses-the-point when it comes to this particular facet of the discussion?

Both sides of this are wrong. The people complaining about "monolithic" are groping in the dark for ideas such as low coupling. The people saying "but count the binaries!" are not addressing the questions of fully documented interfaces between said binaries, composability, and interoperability.

The "uselessd guy" explained this quite well, as have many other people. Can you please advance to not dancing this same old dance every time?

* https://news.ycombinator.com/item?id=12879771

* https://news.ycombinator.com/item?id=12652071

* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/

[d33]

It's not only about whether you do it, it's also about HOW you do it. I once saw a slide from FOSDEM which listed lots of CLI tools that systemd replaced. Some of them seemed quite trivial and if they all depend on low-level systemd, I believe it really is bad design.

[wott]

But this tends towards Windows model, not a form of UNIX-like model. If I wanted a Windows-like, I'd use a Windows.

[rkrzr]

This is indeed an issue in practice:

I recently wanted to use the "systemd-journal-gatewayd" component in Ubuntu 16.04, which ships with systemd v229. Yet, the feature I needed was only available in v231.

Although I'm only interested in a newer version of "systemd-journal-gatewayd" there is no way to upgrade just this one component, it seems.

[traviscj]

I don't get this. How do you know that the v231 for that component will work with older versions of everything else? If you do, why not just compile it yourself? If you don't like that, why not upgrade everything to v231?

[Elhana]

That is the point - you often can't just recompile journald part, because it is tied to systemd interfaces and you might not be able to easily upgrade systemd, because it is a production system you can't simply reboot like your home server. The only way to do that is backporting specific patches to the older version.

If it were a separate component, it would have a bunch of ifdefs covering several versions of systemd, possibly with some features disabled if older version doesn't support it. However, that somewhat increases code complexity for developers and systemd devs refuse to do that.

That is the point of 'monolithic' criticism - despite being many binaries, you can't easily just build single one and make that work.

[ripdog]

There is systemctl reexec, so can't you upgrade systemd without a reboot using that?