Live data from Hacker News

Systemd, ten years later: a historical and technical retrospective

blog.darknedgy.net

411–420 of 458 posts

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

#411
post #217

Earlier quoted context omitted.

Sadly, systemd has corporate backing, which is a very hard fight to win for a ragtag bunch of nerds with dayjobs who have the completely unreasonable expectation of not having their shit broken , regardless of how much energy we have. Money and full-time devs beats energy every day of the week.

My point was that there is nothing (no competing implementation) to be judged against, so it rather wins de facto .

This is like declaring McDonalds burgers the best because small burger joints can't offer Burgers _and also_ ice creams, salads, chicken and toys for children.

If we're talking about init; there are actually better inits already available but you'll never hear about them (runit, for instance) precisely because you don't just leave systemd.

You leave the systemd ecosystem.

This is the main point of the article: systemd as a "job system" is actually quite bad, but the ecosystem has some value in some places and you have to buy the shit with the pig.

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

#412
post #122
post #45

Earlier quoted context omitted.

It's worth considering why the topic makes such a regular appearance. I suggest it might be because that so many users of this website find it to be a remarkable example of not only how something so widely unpopular can become so widely established, but also being something that they have to contend with frequently.

It would appear from distribution adoption that systemd is a lot more popular than it is unpopular.

Please read the article before commenting.

> Indeed, one ought to observe that the most important consumers of an init system are not sysadmins and ops people as commonly believed, but rather distro maintainers. It is their laziness that determines the balance.

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

#414

Earlier quoted context omitted.

One small example that i've struggled with is logging. It used to be I could reuse my editor knowledge to search and read log files. Now every time I want to look at a log I have to re-read the man pages to figure out the proper incantation.

Learning new tricks gets harder when we get older. Is that the software’s fault?

You could make several arguments here, but they're all small until you aggregate them.

1) Breaking working systems should be dissuaded, especially when it comes to human interaction. There's a reason that Microsoft still has a start menu and "File/Edit" menu's

2) There is a certain level of arrogance to the notion that a developer of core infrastructure for literally millions of users can just change things and expect everyone to fall in line without giving credible reason for people to do that.

3) Adding an additional tool to everyones cognitive load should be done with care and delicacy, as it stood there was one set of tools for _all_ file accesses, and there is now a new one.

PS; on a personal note, I'm glad I do not work with you, I find your attitude in the grandparent comment deplorable.

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

#415
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…

> What you are missing is that it is possible for two things to be true at once.

Actually, it's possible for more than two things to be true at once. It could be:

1. It could be true sysv init sucked. (Actually, it wasn't that bad as a modular version of local.rc, but parallel and delayed startup was always just a kludge).

2. It could be true that systemd is a good init system. (For me it's a step change improvement sysv init for parallel and delayed start up. About my only complaint is you don't see failures on "systemctl start xxx"; you have to run journalctl.)

3. It could be that adding another 1M lines of code into the systemd source unrelated to starting stuff was an unsound engineering decision - almost inexplicable coming as it does from a senior engineer. Keeping things in separate source databases with explicit interfaces is a well understood way of reducing the chances of ending up with a ball of mud.

4. It could be that moving sending state changes via an RPC interface (dbus) so you have a million places you have to inspect to understand the state of the system and how it got there rather than writing the desired state of the system to disk with a journal where everyone can inspect it was a bad idea.

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

#416
post #289
post #158

Earlier quoted context omitted.

No local logging will work without disk space, and if the disk is bad anything can get corrupted.

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.

Does logrotate or plain old write() actually handle those error cases by default?

It sounds like you're arguing to use an even more sophisticated logging system than the status quota of blindly writing bytes to disk.

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

#417
post #108
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…

> Are user processes allowed to run after logout? Which DNS to use during startup? What logging in should look like? In each such case, existing behavior which was widely considered as not broken was replaced by a different behavior, often even without an escape hatch. The new behavior(s) in such cases should be made possible, but the default should be the old behavior. All those examples you gave are possible to dis…

resolved has been enabled in Ubuntu for years and in the next Fedora.

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

#418

Earlier quoted context omitted.

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.

The article did a good job articulating that the "end users" of an init system aren't sysadmins, they're distro maintainers. If most distros have switched then it must make things better for them.

The problem, of course, being that for most init systems the "end users" are the distro maintainers but for systemd, because it spreads itself into so many other things, it also impacts the sysadmins and the upstream third party package developers. Who then complain about it and are met with "it was good enough for Debian and Fedora" even though they aren't the ones complaining.

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

#419
post #412
post #122

Earlier quoted context omitted.

It would appear from distribution adoption that systemd is a lot more popular than it is unpopular.

Please read the article before commenting. > Indeed, one ought to observe that the most important consumers of an init system are not sysadmins and ops people as commonly believed, but rather distro maintainers. It is their laziness that determines the balance.

I had. :(

Users choose their distribution, ultimately. I don’t agree with the author’s conclusion there.

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

#420
post #393
post #351

Earlier quoted context omitted.

Puzzle level 1) ini file: you mean, "add -x to the invocation, get back a few screenful of text, wade through that looking for "export" lines and copy them to your terminal, find "start-stop-daemon" line, copy the part of the line and remove irrelevant parameters, and paste into your terminal as well? I would not call this "easy" or "solved". Possible, yes. Pleasant, no. Puzzle level 2) inherited env -- I think you m…

> you mean, "add -x to the invocation, get back a few screenful of text, wade through that looking for "export" lines and copy them to your terminal, find "start-stop-daemon" line, copy the part of the line and remove irrelevant parameters, and paste into your terminal as well? I mean, yes? Granted I'm not a developer but printing out exactly what's happening line by line with all variables expanded and all logical c…

Are you perhaps confusing something?

> A "bad" daemon might not print anything to stdout when invoked (which goes to dmesg) but regardless, this whole comment just reeks of someone who hasn't actually dealt with systems before 2014.

The daemons never print to dmesg -- they may print to syslog, but not all do. The only daemon that I know of that prints to dmesg is systemd :)

To be specific, let's do a simple example. Here is an actual sysvinit file, /etc/init.d/hwclock.sh . It contains:

                if /sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --hctosys $HWCLOCKPARS $BADYEAR; then
                    #   Announce the local time.
                    verbose_log_action_msg "System Clock set to: `date $UTC`"
                else
                    log_warning_msg "Unable to set System Clock to: `date $UTC`"
                fi
This version has been around since at least 1998 [0]. Old school enough for you?

So here is a simple question: let's say my hwclock chip/driver is unreliable and it did not work on startup for some reason, so that "hwclock" call is failing. My kernel timezone is not set right, the clock is off, and the system does log_warning_msg to warn you about it. How do I find out about this warning?

To make your job simpler, here is how the how this function is defined on my system:

    if log_use_fancy_output; then
        YELLOW=`$TPUT setaf 3`
        NORMAL=`$TPUT op`
        echo " $YELLOW*$NORMAL $@" || true
    else
        echo " * $@" || true
    fi

Note no dmesg here, no syslog, no other loggers. You can say "bootlog", but it has been broken every time I tried to use it.

Now, nothing is impossible! I can hack this script so it writes to a temporary file. I can re-execute it again, and hope it fails again. But this gets old, you know? I can spend all day debugging early boot shell, but I did it for a long time already, so now I just want to type "systemctl show --failed", see all the failed services, fix it quickly, and move on to more interesting stuff.

[0] https://www.mail-archive.com/debian-bugs-dist@lists.debian.o...

Post reply on HN