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

231–240 of 458 posts

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

#231

Post by rcxdude »

kelnos wrote: post #187
thristian wrote: post #91

Earlier quoted context omitted.

The trouble is that 'nohup' is not a particular state that specifically marks processes that want to survive logout. Instead, the rule is that processes running inside a particular terminal are killed when that terminal closes, and processes running outside any terminal run as they please. If you SSH to a server, or telnet, or login on the text console, or via a serial port, you get a terminal and everything you run…

> However, if you login to a graphical desktop, that is not a text terminal, and therefore everything is effectively nohup'd No, it's not. I think you're looking at this in the wrong way. The concept here is one of sessions and the parent-child relationship between them, as well as the decisions parent processes make when they create and manage (or don't manage) child processes. If you log in to a text console, you e…

> If you log in to a text console, you end up with a process (like bash) controlling the terminal. If you run normal programs in the foreground, or even in the background (as long as you don't disconnect them from the controlling terminal), they are all children of that bash process. When you quit bash, all its children get terminated as well.

> When you log into a graphical session, the login manager (or whatever) will start your desktop's session (which might just be a plain shell script, maybe just your window manager, or might be a full-blown session manager, or something else entirely). Whatever that is, it starts other applications (say your window manager, a panel or dock, desktop manager, etc.), which then can start other applications (browser, chat, media player). If you log out of your desktop, ultimately what happens is that original session-starter (script, WM, session manager, whatever) quits, and it takes all its children with it.

This isn't how it works though: killing a parent does not kill its child, which is probably one of the bigger design flaws in the original unix (and probably persists because through another design flaw it's the only way to reparent processes, as the insane double-fork 'daemonisation' routine demonstrates). This is one of the things systemd aims to fix: by keeping track of process relationships with cgroups it can kill all the of the processes spawned in a session.

And I'm not sure about your assertion about graphical sessions: pretty much all processes on my PC have no controlling terminal.

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

#232

Post by BiteCode_dev »

gorgoiler wrote: post #119

When writing software, it’s comparatively easy to come up with grand new ideas and turn them into lines of code and files filled with modules. What’s much harder is (1) to expand ones code without coupling everything together (2) present it in a persuasive way that naturally builds a user base. SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to…

> SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to convince the PHB we should rewrite everything in Haskell.

I've seen this scenario played out, and it always fails. The product never ships, of ships in such a bad shape the users have a terrible user experience.

That's not what happened with systemd. It shipped. And after a few iterations, it actually provided a better user experience.

I don't know about sysadmins, but as a simple end user of Ubuntu, systemd is the best user experience I ever had for what matters to me: setuping my services.

It's quite easy to create your unit files, declare service dependencies, stop, restart, and so on. It's declarative, conf is reasonably straighforward to read an understand, documentation is there, and my system boot is stable on laptop and on my servers.

Maybe for "advanced case X", there is problem. Apparently, a lot of power users say there is. But I also know the FOSS community has some people advocating purity over practicality, don't care much about the people with less skills than them, don't understand user friendliness or will fight for their ego. So I have no way to be sure if the problem is real, or just another free software drama.

But at this point I don't care: for the average Joe like me, it's great, and I'm very happy it has been chosen by Centos and Debian as the default.

Apparently nobody in the entire history of init system have managed to provide something decent for, you know, initializing the system. I never heard a herd of devs claiming that one is the fantastic, and they were all terrible to use when I tried.

Well, I don't care for choice in my init system. I want it to work.

And systemd works fine for me.

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

#233

Post by pas »

nine_k wrote: post #86

My beef with systemd is not its reinventing things. That part may actually be good. One problem is that a number of reinventions were poorly made. E.g. the log format. Yes, unstructured logs have a ton of drawbacks. Can we take some ridiculously well-tested, reliable embedded database or serialization format (like sqlite) and use it as log storage? Alas. Another problem is the "I know better" attitude. Are user proce…

Linux desktop security was (and largely still is) in shambles. Logind at least tried to force some sanity.

Was is executed well? No, not at all. In typical FOSS fashion it just changed from one release to the other, and that's it.

Yes, there were probably notes about it somewhere in a long forgotten changelog deeplinked 4-5 clicks below the surface of Debian's and Ubuntu's homepage.

Should have they introduced a deprecation period? I don't know, maybe, probably. (But who are "they"? systemd maintainers? Debian/Ubuntu?)

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

#234

Post by dijit »

theamk wrote: post #135
hedora wrote: post #58

Earlier quoted context omitted.

> you left out networking and authentication, network service dependencies, filesystems, volume encryption, etc. – not to mention automatic restarts, conditional behavior based on the network or other devices (stuff needs to happen when I leave the office), and the various edge cases which I’ve seen in three decades running Unix systems. I’ve been running Unix systems for 25 years. All of the things you mentioned wer…

> All of the things you mentioned were already solved adequately really? Let's say (not entirely hypothetically) that you have a daemon. This daemon has a config file, which is large and complex. This daemon's /etc/init.d file builds command-line dynamically, then passes it to start-stop-daemon as usual. Puzzle level 1) You made a typo in init file, so that daemon does not start. The "start" command succeeds, but the…

Not sure if joking (since, sysvinit is very old and was in need of replacement) so I'll answer in good faith.

> You made a typo in init file, so that daemon does not start. The "start" command succeeds, but there is no output anywhere, and process does not start. How do you debug it in the sysvinit world?

"oh my process failed; let's add `-x` to the invocation."

> You made a typo in init file, so that daemon does not start. The "start" command succeeds, but there is no output anywhere, and process does not start. How do you debug it in the sysvinit world?

as above.

> One day, you happened to be in the server room, watching server boot (you normally reboot it remotely). You have noticed a red message scroll up the screen. This looks important! Too bad it already scrolled off the screen and out of the scrollback buffer too. How do you see it?

`dmesg` or /var/log/messages (or /var/log/dmesg)

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

#235

Post by JoshTriplett »

kelnos wrote: post #163
theamk wrote: post #127

Earlier quoted context omitted.

I think you underestimate how badly the old sysvinit sucked in the world with many good distribution-provided packages. It was pretty good in the good, old days, where a sysadmin could list every daemon the system runs by heart, but it was breaking apart when you had tons of random packages: Package X uses "start-stop-daemon" in ini file, so there is no way to get error messages if config file is incorrect. Package B…

> Debian, Ubuntu, Arch all chose the systemd voluntarily. My understanding (I believe detailed in the article) is that Debian, at least, chose systemd because they were forced to if they wanted a reasonable default GNOME experience for their users. If they hadn't, GNOME would have been missing some features that would have been obvious and jarring. You can certainly argue that they made the wrong call there, and that…

> 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, and upstart. All of that evaluation occurred publicly, and is archived on Debian's mailing lists and bug-tracking system.

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

#236

Post by BiteCode_dev »

AnthonyMouse wrote: post #138
theamk wrote: post #127

Earlier quoted context omitted.

I think you underestimate how badly the old sysvinit sucked in the world with many good distribution-provided packages. It was pretty good in the good, old days, where a sysadmin could list every daemon the system runs by heart, but it was breaking apart when you had tons of random packages: Package X uses "start-stop-daemon" in ini file, so there is no way to get error messages if config file is incorrect. Package B…

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.

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

#237

Post by dijit »

jcelerier wrote: post #206
rleigh wrote: post #156

Earlier quoted context omitted.

> It's dramatically simpler and more intuitive than what it replaced I hope you're being deeply ironic. It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex. sysvinit had a socket interface with a single message type. It had a sin…

> It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex. As a user I 100% disagree. Before systemd I had to learn a few dozen of different config formats for various things * various distros, now all my systems are configured in a…

It's interesting how many people have such wildly different experiences with systemd.

For me systemd has hidden some really horrible things behind it's dependency graph (which is a black box) and socket activation issues (for instance, cockpit "listens" on a port, but it's really systemd's socket activation (PID1) and there was a RCE against it).

The configuration file format is, in my mind, mysterious, with random keys in the unit file which have random meaning, and behaviour that is anything but deterministic.

But I've been using systemd for a long time (since Fedora 21). Maybe we're all coloured by not only when we first encountered it but by our distro and how simple they make things? FWIW I'm using Debian and Arch these days and still struggle to "enjoy" systemd, but it definitely functions better on my arch machine.

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

#238

Post by dvfjsdhgfv »

A key quote:

> As it turns out, there was a little-known Freedesktop-affiliated project called xdg-hostname in 2009 which was a start towards creating such D-Bus “utility daemons” for use in desktop widgets and others, all as a standalone project. Had this been followed through instead of having the utility daemons end up being part of the systemd source tree, a good deal of political acrimony could have been avoided – though at the cost of reducing systemd’s leverage.

That is, if they used xdg-hostname instead, SystemD wouldn't be tightly coupled with Gnome, so users could choose between SystemD and InitV, and all this mess could have been avoided.

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

#239

Post by cycloptic »

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.

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

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

#240

Post by vezzy-fnord »

JoshTriplett wrote: post #235
kelnos wrote: post #163

Earlier quoted context omitted.

> Debian, Ubuntu, Arch all chose the systemd voluntarily. My understanding (I believe detailed in the article) is that Debian, at least, chose systemd because they were forced to if they wanted a reasonable default GNOME experience for their users. If they hadn't, GNOME would have been missing some features that would have been obvious and jarring. You can certainly argue that they made the wrong call there, and that…

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

Post reply on HN