Systemd, ten years later: a historical and technical retrospective • Hacker News Board

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

#371

Post by bkor » Mon, May 04, 2020, 3:48 PM UTC

astrobe_ wrote: post #298

JoshTriplett wrote: post #235

Earlier quoted context omitted.

> My understanding (I believe detailed in the article) is that Debian, at least, chose systemd because they were forced to This (and much of the article) is incorrect. Debian went through an extensive evaluation process at the time, over the course of 4 months, considering several different init systems, and chose systemd based on this detailed technical evaluation. That evaluation also considered sysvinit, openrc, a…

Debian also ran a poll a few months ago in order to reevaluate that choice, at least partially. Quite the hint that all is not jimmy-dandy. As a programmer in embedded, Systemd feels like it solves problems we didn't have, and introduces problems we didn't have. I what point is it more conservatism than "if it ain't broken, don't fix it"? God only knows. Well, every time the Systemd topic pops on HN or Reddit (and ev…

Can you reference that poll? There was a GR, which is entirely different than a poll. The outcome of that was also pretty clear, Debian as a whole is ok to depend a bit more on systemd. I don't get why you use it as an example of the opposite.

See https://lwn.net/Articles/808217/ for the outcome of the GR.

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

#372

Post by Spivak » Mon, May 04, 2020, 3:52 PM UTC

TA0x0 wrote: post #222

cycloptic wrote: post #147

Earlier quoted context omitted.

I don't understand this angle. You acknowledge the functionality could have been useful even 25 years ago; it makes perfect sense for a daemon developer to integrate the functionality into a session manager and put it behind a config flag which is exactly what they did.

The functionality existed 25 years ago. systemd coming along and poorly implementing it provides nothing.

The functionality of implementing it yourself?

But that’s such a useless definition because then all software “provides nothing” since it’s implementation proves that you could have written it yourself.

logind is far more robust than any of the janky shell scripts I’ve seen over the years to accomplish this.

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

#373

Post by sjwright » Mon, May 04, 2020, 3:53 PM UTC

zeveb wrote: post #320

sjwright wrote: post #263

Earlier quoted context omitted.

And that was one of the sillier holy wars, since text editors have near-zero network effects and it's trivial for distros to ship both. (FWIW I use nano.)

> And that was one of the sillier holy wars, since text editors have near-zero network effects and it's trivial for distros to ship both. Text editors like vi may have near-zero network effects, but operating systems like emacs and vim have plenty of network effects. If I spend months building an amazing interface to git in Emacs but my colleague uses vim, our organisation is hurt. That's (I think) why people care: t…

I’m mostly kidding about nano, I only use that when I have to. My main editor is HomeSite+ 5.5 running on Windows XP in a virtual machine on my Mac. And I’m not kidding.

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

#374

Post by Spivak » Mon, May 04, 2020, 4:00 PM UTC

Supermancho wrote: post #103

ycombobreaker wrote: post #77

Earlier quoted context omitted.

> it’s weird that “logging out” doesn’t imply “and end all my programs.” Weirdness is in the eye of the beholder. I regularly run programs whose lifecycles are not in sync with my login session. Why do I need to stick around to see a batch job complete? I can understand that different folks have different backgrounds which changes expectations... but come on... somebody bringing up tmux, screen, etc. should simply en…

>> it’s weird that “logging out” doesn’t imply “and end all my programs.” > Weirdness is in the eye of the beholder It's a windows acolyte mindset. Many people don't imagine that a login is just another program, rather than the parent process.

Yes but that model conflicts with the human notion of being “logged in” to a system.

And the current behavior is literally what you describe. It’s just the quirk of subreapers being implemented recently that daemonizing a process wasn’t local to your session.

It makes zero sense that a process that double forks is reparented by init instead of your session leader. If how things worked currently was proposed today it would sound crazy.

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

#375

Post by JoshTriplett » Mon, May 04, 2020, 4:01 PM UTC

vezzy-fnord wrote: post #240

JoshTriplett wrote: post #235

Earlier quoted context omitted.

> My understanding (I believe detailed in the article) is that Debian, at least, chose systemd because they were forced to This (and much of the article) is incorrect. Debian went through an extensive evaluation process at the time, over the course of 4 months, considering several different init systems, and chose systemd based on this detailed technical evaluation. That evaluation also considered sysvinit, openrc, a…

All of my views come straight from primary sources which I meticulously uncovered, including Debian mailing lists. I realize that you have been one of the more visible members of the pro-systemd side for years now, so I'd definitely like a more coherent rebuttal to both the historical and technical sections. Of course, you'd probably consider any kind of response to be undignified, and I understand.

I participated in those discussions first-hand, and recall them rather well. At no point was "we don't have a choice" taken seriously as an argument; even most of the pro-systemd folks didn't consider that a valid argument for systemd, and many of the most judicious and respected voices in the discussion called out such arguments as being unhelpful. Debian is large enough and stubborn enough that they're more than willing (occasionally entirely too willing) to do their own thing if they think they have a better path.

As for the rest, I consider https://news.ycombinator.com/item?id=23062725 a good start. systemd was successful because it provided working code that people (including distribution maintainers) wanted to use, for a variety of reasons. This is the type of problem where no amount of architecture-in-a-vacuum discussions make up for actually doing the work and handling all the myriad cases that come up when people use it in practice. systemd did that; the next init system after systemd will need to do that as well.

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

#376

Post by TA0x0 » Mon, May 04, 2020, 4:02 PM UTC

cycloptic wrote: post #239

TA0x0 wrote: post #222

Earlier quoted context omitted.

The functionality existed 25 years ago. systemd coming along and poorly implementing it provides nothing.

If you already had that feature then you are free to use your 25-year-old solution instead of systemd.

You have to, since systemd implemented the feature incorrectly. You're missing the forest for the trees.

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

#377

Post by thayne » Mon, May 04, 2020, 4:10 PM UTC

yrro wrote: post #193

thayne wrote: post #104

Earlier quoted context omitted.

> The stated workarounds - fiddling with some options like "KillUserProcesses=no" in logind.conf &co. - have so far failed. Strange, KillUserProcess=no worked fine for me

In addition I'm pretty sure every distribution ships with it disabled anyway.

Not Archlinux. But That's not surprising given arch's policy of keeping things as close to upstream as possible.

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

#378

Post by growse » Mon, May 04, 2020, 4:22 PM UTC

SQLite wrote: post #363

growse wrote: post #359

Earlier quoted context omitted.

SQLite doesn't work reliably on NFS, which rules it out for any PXE-booted system with an NFS root.

The issue with NFS and SQLite is that posix advisory locks do not work, or do not work well, on many NFS installations. As long as advisory locks work over NFS, or as long as there is only one client trying to access the database at a time, so that locks are not really needed, SQLite works fine over NFS. NFS is a lot slower, but that's just the nature of NFS and SQLite can't do anything about that. You can ask SQLite…

Fair. In my experience, the fact that NFS is both pervasive and often broken, for something like a system-wide log manager you can't always assume that your root fs is reliable.

Is dot-file locking a compile- or run-time option?

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

#379

Post by TA0x0 » Mon, May 04, 2020, 4:23 PM UTC

Spivak wrote: post #372

TA0x0 wrote: post #222

Earlier quoted context omitted.

The functionality existed 25 years ago. systemd coming along and poorly implementing it provides nothing.

The functionality of implementing it yourself? But that’s such a useless definition because then all software “provides nothing” since it’s implementation proves that you could have written it yourself. logind is far more robust than any of the janky shell scripts I’ve seen over the years to accomplish this.

The functionality to gracefully end long running background processes has been a part of standard killall, pkill, etc. for quite some time.

Even then, yes, the functionality of using ps and kill together has existed for 20+ years. Those tools are already implemented, providing the functionality for decades.

In no universe is logind considered robust, and basic scripts from middling UNIX admins have provided this functionality for decades, untouched. Even the "janky" ones.

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

#380

Post by michaelmrose » Mon, May 04, 2020, 4:23 PM UTC

tomatocracy wrote: post #261

cycloptic wrote: post #177

Earlier quoted context omitted.

This is not true in any way. Gnome still works on non-systemd systems but you have to install elogind. And, there were valid technical reasons to have gnome depend on a login manager, in particular supporting multi-seat securely is very difficult without one. I should also mention that the previous "standardised interface" for this was ConsoleKit which was also written by the same developers as gnome and systemd. So…

I noticed the ConsoleKit->logind change at the time being largely justified by support for multiseat but had forgotten about it. It seems like a rather extreme case of the tail wagging the dog but perhaps I'm missing something. How many people use multi-seat in large deployments? Where and why?

Virtually nobody is using multi-seat and none should.

For most cases you would get better results by networking n cheap boxes rather than trying to buy a single beefy box to support n users on every dimension including perhaps even power usage if you used low power devices.

Contention for io is a problem. Everyone wanting to say decode video simultaneously is a problem. Browsers high ram usage is a problem.