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

131–140 of 458 posts

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

#131

Post by fsh »

ttctciyf wrote: post #75
cesarb wrote: post #46

Earlier quoted context omitted.

> remote login, start screen, ctl-A d (detach), log out, log back in, screen -r (resume) I just tried it on a fully up-to-date CentOS 8 box (which uses systemd), and it worked perfectly fine: after logging back in through ssh, `screen -r` restored the screen session as expected. From what I have read, that screen session would only be killed if I had set KillUserProcesses=yes on /etc/systemd/logind.conf, which is not…

Switching to CentOS in order to use screen is not an appealing option, and the config appears not to work on my current distro (that might be my poor testing, but it's certainly not the default anyhow.) I understand Slackware still lacks systemd, so maybe that's a better choice for me :)

Please submit a bug report if the option doesn't work for you.

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

#132

Post by dralley »

sneak wrote: post #122
gjvc wrote: 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.

One of the reasons distributions appreciate systemd because systemd unit files are easy to write and can easily be written and maintained upstream and used with very few if any modifications downstream.

Your average HN user doesn't see or particularly care that it makes things easier for distro maintainers, so it's much easier to push the corporate conspiracy angle than to accept that a lot of the hand-wringing takes huge amounts not-very-fun volunteer labor for granted.

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

#133

Post by oefrha »

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…

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

Define “usual people who compile this package”. In my books those are distro maintainers who indeed should be familiar with options provided by the init system they choose. If you decide to include oddballs who compile everything themselves (Linux from scratch?) then again, yes, they are expected to know a thing or two or dig into options or even code from time to time.

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

#134

Post by esoterae »

acdha wrote: post #34
gens wrote: post #14

Earlier quoted context omitted.

Voting share ? There is no vote unless you work for RH. And even then. An init system is harder then it seems ? You and Jonnax seem to think that unless you made it you have no right to say anything. Have you ever made an init system ? Researched what exactly goes into it ? Sure, there's more then just starting programs. But not much more. The only really complicated thing about getting a [linux] computer from kernel…

> An init system is harder then it seems ? You and Jonnax seem to think that unless you made it you have no right to say anything. Have you ever made an init system ? Researched what exactly goes into it ? Sure, there's more then just starting programs. But not much more. The only really complicated thing about getting a [linux] computer from kernel boot to firefox is setting up devices. And even that [udev,"hotplug"…

> Again, I’m not saying that systemd is perfect but that most of the complaints tend not to acknowledge the many problems it solved

It solved nothing but the problems made up to justify its existence. And the ones those faux solutions created downstream. Boot ordering problem? Feh. What a gaslight fest. All caused by chasing 1.2s faster boots. What a colossal waste of everyone's time. This is the same cancer that Shuttleworth tried to foist on everyone with that UI abomination. Servers are desktops are laptops are tablets are phones!

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

#135

Post by theamk »

hedora wrote: post #58
acdha wrote: post #34

Earlier quoted context omitted.

> An init system is harder then it seems ? You and Jonnax seem to think that unless you made it you have no right to say anything. Have you ever made an init system ? Researched what exactly goes into it ? Sure, there's more then just starting programs. But not much more. The only really complicated thing about getting a [linux] computer from kernel boot to firefox is setting up devices. And even that [udev,"hotplug"…

> 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 there is no output anywhere, and process does not start. How do you debug it in the sysvinit world?

Puzzle level 2)

Turns out this daemon used LC_ALL (PATH? HOME?) when parsing config, so it works fine when started or restarted from command line, but fails when started as an part of startup process. How do you debug this?

Puzzle level 3)

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?

The problem of all the init systems is they could be great, but their development just stopped at some point -- and instead of fixing the real annoyances in a general way, they were just saying "this is all fine". Until systemd came and ate their lunch.

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

#136

Post by realusername »

theamk wrote: post #129
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…

You don't want to use sqlite for logs -- it is way too complex, and in particular, it may roll back (=lose log entries) if it is low on space, and permanently damage data when writing onto disks with errors. It also makes wrong performance tradeoffs for logging -- your choices are either sync() all the time, or roll back on unexpected termination. I don't like the that journald goes backwards in space and updates ind…

Sqlite is battle-tested though, it has one of the most comprehensive test suite and is used on billions of devices already.

What systemd is doing with this log storage system is reinventing sqlite, because systemd has a fairly new and not battle-tested database implementation, it has shortcomings.

I would argue that either they use plain text logs like before or use sqlite but they should not reinvent a new db.

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

#137

Post by cycloptic »

esoterae wrote: post #126
WesternStar wrote: post #115

Earlier quoted context omitted.

I see this kind of talking about stuff like the Unix way and existing conventions and programs. I almost have to ask myself when did we end up in a mausoleum. The Unix way is just a guideline from a time some folks wrote some code. A seminal and important time. Its just one(perhaps of many) piece of anecdata. Old code is old code. It's useful but the patterns and conventions it was built on may no longer be relevant.…

The conventions "Do one thing and do it well", and "Don't break the user experience" are not threadbare or shabby. Not UNIX nor its derivatives did spring fully formed from the foreheads of K̶n̶u̶t̶h̶ Thompson or Ritchie; it was written as a series of counterpoints to the prevailing designs and implementations of the day. To us the ashes of our ancestors are sacred and their resting place is hallowed ground. You wand…

Donald Knuth was not a designer of Unix, and he is still alive.

Also, Linux is not Unix and was never intended to be Unix or follow its conventions.

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

#138

Post by AnthonyMouse »

theamk wrote: post #127
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…

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 the Americans are doing okay but the fact is that the USSR was the first to put a man into space. As if that justifies everything else they did.

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

#139

Post by gorgoiler »

theamk wrote: post #127
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…

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…

A lot of init problems you describe are very real, but it felt like by the late 00s they had mostly been solved with efforts like linting and standards, as well as LSB init shell functions making init a much more standardized process.

PAM was and still is quite hard to understand but, again, it had enough power and flexibility with @ based includes to allow individual distributions to lay things out sensibly and allow new packages to follow a coherent standard that emerged rather than being forced.

Concurrent init systems helped drive a lot of this, back when there was a sweet spot of Linux complexity increasing faster than processing power could handle. (Nowadays I feel like boot speed is less important, given how many more resources a modern machine has, though it’s still a concern for low resource platforms.)

I guess I’ve just never seen revolution as a solution to hacks and untidiness. Linting, guidelines and policy, with technically compelling reasons to encourage people to follow them have seen much more success, where I’ve seen them deployed, than centralized authority.

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

#140

Post by riskyfive »

Nextgrid wrote: post #124
gjvc wrote: 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.

Is it actually unpopular or is there just a vocal minority constantly complaining about it while a much larger part of the user base is happily using it?

It's unpopular. It has funding. No other project in the space has funding, so it wins by default.
Post reply on HN