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

Systemd, ten years later: a historical and technical retrospective

blog.darknedgy.net

Post reply on HN
Print view View original

331–340 of 458 posts

Re: Systemd, ten years later: a historical and technical retrospective

#331

Post by cycloptic »

lmm wrote: post #310
cycloptic wrote: post #212

Earlier quoted context omitted.

>elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility Isn't that the whole reason for using another init? Because you see full compatibility with systemd as being undesirable and you have the means yourself to maintain things yourself using other solutions? I don't get it, it sounds to me like you're now saying the opposite of what you did before. >I remember multi-s…

> Isn't that the whole reason for using another init? Because you see full compatibility with systemd as being undesirable and you have the means yourself to maintain things yourself using other solutions? Compatibility is the only way it becomes possible to make those changes. E.g. in the pre-systemd days there were at least four different syslog systems and at least three different cron systems. But because they co…

>Since they all follow common standards, any program works with any environment.... If the systemd people want to make a shiny new init with cool features, great. It's when they break compatibility with alternatives that I have a problem with it.

That is not relevant because the "common standard" in this case is the logind D-Bus API. There are no other active and viable alternatives to login management. It has two implementations, systemd-logind and elogind. You can choose either one, and only the first one requires systemd. Or if you really want you can choose to write another implementation. Or you can choose to hack GNOME and remove the logind bits and just run your display manager and shell insecurely as setuid root. Or you can revert it to some old version when consolekit was still supported. Or you can just do nothing and wait for someone else to guess what it is you want. You have options. If none of these will please you then I think you need to adjust your expectations because you can't have it all.

>The fact is that most contributions are made by RedHat employees on RedHat time, so anything that can be decided by 51% of maintainers is under RedHat's control (and I can't do anything to change that since I can't outspend RedHat).

I don't see what this has to do with anything. It's open source. If you want to collaborate, you can submit a pull request, work with the maintainers and get them to spend their paid time reviewing and merging your code. You don't need to outspend them, the code is already written and every bit of it lands on github ready for you to use it. Them getting paid more only benefits you.

>There was a decision to adopt systemd but it was very much not a consensus; there was bitter disagreement at the time (and still is).

I can't speak for other distros but looking at the actual Debian votes on systemd (not flamewars on mailing lists), your statement does not seem to reflect reality. Systemd, as well as support for alternatives like elogind, was voted in with strong consensus. https://www.debian.org/vote/2019/vote_002

>Forking by a minority is only practical if the system is made up of small components with standardised interfaces between them.

Systemd is composed of several small components, and its interfaces have become standard across many Linux distros, so this shouldn't be a problem.

>you don't have the Four Freedoms in any practical sense.

It is not reasonable to expect that every single person will have the time and expertise to contribute to any given project, or that every project will be structured in a way that lets them accept maximum contributions. I don't mean to dismiss your frustration with being unable to contribute. I get that. But you continue to have the opportunity to do so and you will for as long as these projects remain alive. The code is not going to magically disappear one day and it's up to you to find the time to actually dive in. Good luck.

Re: Systemd, ten years later: a historical and technical retrospective

#332

Post by Spivak »

epistasis wrote: post #102
Spivak wrote: post #90

Earlier quoted context omitted.

Just set ENABLE_RESOLVE=0 when compiling and resolved is gone?

You use the word "just" as if this were a simple thing to understand and know. Is this magic incantation communicates in a way that the usual people who compile this package can understand to use it without being intimately familiar with the code? I ask not rhetorically, just out of curiosity. It's not a typical type of suggestion for other packages I've encountered with open source, and it feels far more difficult t…

I mean the parent was talking about the source code being a ball of mud and it being difficult to determine what components can be removed without breaking things.

In this case it should be assumed we’re talking about someone who’s compiling systemd and familiar with the source. And yes, these are flags that anyone who builds systemd from source would be familiar with and know how to set.

It’s the same as when you run a configure script and pass —-disable-feature.

Re: Systemd, ten years later: a historical and technical retrospective

#333

Post by JoeAltmaier »

Spivak wrote: post #332
epistasis wrote: post #102

Earlier quoted context omitted.

You use the word "just" as if this were a simple thing to understand and know. Is this magic incantation communicates in a way that the usual people who compile this package can understand to use it without being intimately familiar with the code? I ask not rhetorically, just out of curiosity. It's not a typical type of suggestion for other packages I've encountered with open source, and it feels far more difficult t…

I mean the parent was talking about the source code being a ball of mud and it being difficult to determine what components can be removed without breaking things. In this case it should be assumed we’re talking about someone who’s compiling systemd and familiar with the source. And yes, these are flags that anyone who builds systemd from source would be familiar with and know how to set. It’s the same as when you ru…

So common with open source - flags that once worked are now tangled up with subsequent code/flags and won't even compile if not part of some common configuration. Because its not fun to exhaustively test all combinations, it doesn't get done.

Re: Systemd, ten years later: a historical and technical retrospective

#334

Post by fetbaffe »

novok wrote: post #219
sneak wrote: post #118

Earlier quoted context omitted.

It's astounding to me the issues people have with this. systemd's existence doesn't preclude anyone from using the old, pre-systemd ways of doing things. There are thousands of linux distributions, and afaik there are at least a dozen which are primarily defined as never-using-systemd. Face it: the linux userspace has always sucked. Linus punted on it way-back-when (to be fair, he was a solo dev working on a kernel,…

Linux types I've noticed tend to be more holy war orientated. Where did the classic vim vs emacs holy war come from also?

You can say that about Apple users too, but the zealotry has somewhat declined as Apple products has become more mainstream.

Historically Linux users where people that actively choose to use Linux based on a combination of technical & philosophical reasons, thus they are more passionate about it.

Most common Windows users get Windows preinstalled from the store where they bought the computer. It is not really an active choice based on reason, therefore no reason to have a holy war.

The more Linux becomes mainstream, the holy wars will become more & more fringe. Systemd is pushing Linux more into the mainstream.

Re: Systemd, ten years later: a historical and technical retrospective

#335

Post by AndrewStephens »

I do really appreciate this type of long form, researched blog post. I have no strong opinions on systemd, I've made simple service units and it has worked well enough. Having the history behind the design is a great aid to understanding.

Re: Systemd, ten years later: a historical and technical retrospective

#336

Post by kuschku »

zozbot234 wrote: post #290
kuschku wrote: post #243

Earlier quoted context omitted.

> and it takes all its children with it. Now what happens if it crashes? Repeatedly? Or if a user intentionally manipulates their session to keep running? Should any user on a shared university computer be able to spawn processes to run for all eternity? Should your desktop environment crashing lead to all software continuing to run, for all eternity, leaking memory like there’s no tomorrow?

> Should any user on a shared university computer be able to spawn processes to run for all eternity? That's for the university IT to decide, of course. Software should focus on providing general mechanism, not policy. > Should your desktop environment crashing lead to all software continuing to run, for all eternity, leaking memory like there’s no tomorrow? AIUI, that's pretty much what might happen if you're forced…

> the fact that it doesn't manage to interoperate cleanly with the likes of tmux and screen is a pretty blatant papercut.

Interoperating with broken hacky solutions is nothing admirable. At some point, you have to introduce a new API, which handles this properly, and introduce a way to give/take permissions for these things (so e.g. zoom doesn’t just run their dataminer forever through the same mechanism).

Re: Systemd, ten years later: a historical and technical retrospective

#337

Post by Spivak »

zeveb wrote: post #327
Spivak wrote: post #90

Earlier quoted context omitted.

Just set ENABLE_RESOLVE=0 when compiling and resolved is gone?

> Just set ENABLE_RESOLVE=0 when compiling and resolved is gone? From HHGTTG: "But the plans were on display …" "On display? I eventually had to go down to the cellar to find them." "That's the display department." "With a flashlight." "Ah, well, the lights had probably gone." "So had the stairs." "But look, you found the notice, didn't you?" "Yes," said Arthur, "yes I did. It was on display in the bottom of a locked…

This is a config option that you pass when compiling systemd in the same was as --enable-feature in a ./configure script. If you are familiar with the systemd source you would be aware of these options. They’re not hidden.

Re: Systemd, ten years later: a historical and technical retrospective

#338

Post by mindslight »

BiteCode_dev wrote: post #236
AnthonyMouse wrote: post #138

Earlier quoted context omitted.

What you are missing is that it is possible for two things to be true at once. It is possible for sysvinit to suck and for systemd to suck in entirely different and potentially much worse ways. It's as though someone is complaining about having to live under the USSR and how bad things are, and then someone responds that the German rocket program has been dismantled and the British never really had much of one and th…

I hear that a lot. It's not my experience. Setuping services has been a pain for 15 years for me. Then with systemd it was suddenly easy. Detractors keep repeating systemd sucks, but that this point, Debian and Fedora apparently decided it was good enough. And I never heard an end user complain. I've stopped to be open to convincing.

I don't know if I qualify as an "end user" to you, but I definitely have complaints. I started with an open mind about systemd, because I'm not so attached to any init system in general. So my issue is not that systemd is a monolith or breaks with tradition (sysv init scripts were also a hot mess). My problem is that systemd looks and acts like a freshly written proof of concept that needs to be polished up, but when you dig in to debug a problem you're having, you inevitably end up at bug reports that condescendingly defend the current state of affairs as desired behavior.

"Your issue is user error, because systemd doesn't provide the logical guarantee you want, and adding a hook is outside the scope of systemd." I've run into several instances of this, the worse one being around unit ordering and network interfaces. I eventually solved it with a hack service that put 'sleep 90' between network.target and network-online.target. So much for that startup parallelism.

Another issue is that a dependency loop will cause it to just randomly drop units. There's no insight into this until you notice it happening and go digging. In the abstract, yes there is nothing else systemd could do apart from refuse to boot. Except the problem has only been dragged into the abstract by using a configuration model that punts on real world concerns.

Both of these are exacerbated by magic processes that half-parse crypttab/fstab/interfaces to create runtime units. I don't know if these are from Debian or the upstream. But if the systemd way is better, why haven't those been fully moved to native systemd?

Re: Systemd, ten years later: a historical and technical retrospective

#339

Post by dijit »

saati wrote: post #308
mantap wrote: post #289

Earlier quoted context omitted.

If you are low on disk space you want something predictable to happen: the oldest logs are deleted and the newest logs are written. This would be a nightmare to achieve with SQLite, as said above it's just way too complicated.

If you actually care about your logs you should log to a centralized service anyway, and if any of your computers actually ran out of disk space you should fire your sysadmins/sres for incompetence.

This comment denotes, strongly, the dissonance that occurs when talking about something so general.

It’s my opinion (as an infrastructure type) that centralised binary logging is an absolute necessity above 20 instances.

But that leaves out every person with a laptop, or those people with a very low volume of little instances.

Structured logging is difficult, that’s why logstash is so flexible about input and conversions. And I think that was the impetus for systemd’s journals; to log structurally.

However. The parent is wrong if he thinks decisions should be made under low disk conditions. Having a rotate rule to keep your sliding window of logs to a certain size is fine. But your servers (and laptops, and desktops) should not be taking arbitrary decisions based on this kind of condition.

Re: Systemd, ten years later: a historical and technical retrospective

#340

Post by nlgza »

BiteCode_dev wrote: post #236
AnthonyMouse wrote: post #138

Earlier quoted context omitted.

What you are missing is that it is possible for two things to be true at once. It is possible for sysvinit to suck and for systemd to suck in entirely different and potentially much worse ways. It's as though someone is complaining about having to live under the USSR and how bad things are, and then someone responds that the German rocket program has been dismantled and the British never really had much of one and th…

I hear that a lot. It's not my experience. Setuping services has been a pain for 15 years for me. Then with systemd it was suddenly easy. Detractors keep repeating systemd sucks, but that this point, Debian and Fedora apparently decided it was good enough. And I never heard an end user complain. I've stopped to be open to convincing.

It is even easier with daemontools, which is much more lightweight and follows the Unix philosophy.

But somehow distro maintainers can never integrate djbware for political reasons. In the case of RedHat, also NIH syndrome.

Post reply on HN