Live data from Hacker News

Systemd, ten years later: a historical and technical retrospective

blog.darknedgy.net

51–60 of 458 posts

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

#51
post #43
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"…

Weren't Debian maintainers affected by the fact that it was... problematic to run Gnome without systemd? (Which might be entirety not systemd's fault.)

Correct. By the time the question of default init system was being decided by the Technical Committee, the tentacles of systemd were so entrenched that its relative merits or detriments as an init system were of little importance. As Russ Allbery (a committee member) pointed out at the time:

"We’re not really talking about choosing between two competing ecosystems. Rather, we’re talking about whether or not to swap out a core component of an existing integrated ecosystem with a component that we like better."

Also (to try holding back the tide of historical revisionism) let me highlight that Debian's decision was in no way unanimous and the process was not without its own controversy. In reality, the Tech Committee was divided down the middle when it came to their vote on the default init system, and the tie was only decided by the double vote of Bdale Garbee, the chairman of the committee.

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

#53
post #48
post #40

Earlier quoted context omitted.

Yeah, don't get me started on the fragile glass test tube called systemd-resolved that fails in mysterious ways when I use wicd on Ubuntu and the WiFi gets momentarily disconnected. I don't see the sense behind treating name resolution as something so special that it has to be part of an init system. I like the overall theoretical concept of systemd but it has ugly implementation details like this.

But systemd-resolved is such an odd complaint since it’s only connection to systemd is the name and that it’s in the same repo. It’s not connected to the init system at all.

The entire repo is a big ball of mud. No one knows which parts can be removed without breaking things.

Heck, the author of this article couldn’t even find a design doc or adequate manual for the init part of the train wreck, and it’s been in development for ten years.

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

#54
post #47
post #43

Earlier quoted context omitted.

Weren't Debian maintainers affected by the fact that it was... problematic to run Gnome without systemd? (Which might be entirety not systemd's fault.)

GNOME didn't have any significant systemd integration until well after Debian had decided to go ahead with it. I remember this being a strong supporter, among others: https://lists.debian.org/debian-ctte/2014/01/msg00287.html

Then why did Josselin Mouette, a GNOME packager for Debian, write this in October 2013:

"GNOME in jessie will need systemd as the init system to work with all its features, just like it needs the network configuration to be handled by NetworkManager."

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

#55
post #46

Earlier quoted context omitted.

To answer your question: remote login, start screen, ctl-A d (detach), log out, log back in, screen -r (resume) - there is no screen session because it was killed by systemd immediately after log out. (syslog entry: May 3 09:01:25 $HOSTNAME systemd[1]: session-6.scope: Killing process 3290 (screen) with signal SIGTERM. ) But that's hardly the point, the point is the toxic "you're doing it wrong" mentality that infest…

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

[deleted]

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

#56
post #34
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"…

udev was the biggest step towards "dynamic systems". Or should i say "hotplug" was, since it is more or less the same thing. I completely agree that the init should be an event based system. I'm not arguing that. I never argued that. I did not in fact argue much other then the statement that nobody should say their opinion about anything.

You say i left out stuff. I did. A lot more stuff then you wrote here. It would be a looooooong list of things, all of them simple (including "networking" and encrypted filesystems). I mentioned udev as an example of something slightly more complex, but even it is not.

> .. much better model than SysV init ..

You talk as a user, as in an admin. I talk as someone who was once interested in how all these stuff actually work. What i played with (read about, coded, and researched in general) includes init, udev, network hardware management (how ip and iw actually do stuff, excluding wpa), and more. What have i learned ? That almost all of it is done by the kernel. SystemD is not the only.. program that responds to events and goes over a graph and such. In fact, it is not even that hard to do what it does. Remember how i asked why udev doesn't have a generic event.. protocol ? You can scrap udev if you don't use systemD. And why ? For better integration ? The kernel tells udev when a device appears. So why doesn't udev just send a message of some sort ? It could even have a "mode" where it doesn't do anything unless it receives a message telling it to. So why not ? Oh, i don't think it's malice.

> The Debian community had a deep examination of the alternatives and picked systemd because it made sense, not because Red Hat has some brainwashing program.

The debian debate was a clusterfuck of grand proportions. There was one (1!) post on the whole debate that addressed the technical aspects. In the end the conclusion was that it is easier to just use systemD as stuff depends on it more and more (GNOME, notably, funny). RH is a huge company, they are not altruistic in their goals. I wouldn't say malice, but i wouldn't say innocence either.

And again, nothing of substance was said. Just fancy words and feelings. Brainwashing..

PS Fun fact: Xorg depends on udev to send it events over dbus when you plug something related to it. It still works without it, until you re-plug your mouse.

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

#57
post #34
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"…

There is no competitor because there was no problem. For most of use cases SysV, rc.d worked. Just like ifconfig.

Arch Linux switched to systemd earlier than Debian. And I have not noticed. Arch community accepts breaking changes. Debian? I believe they value stability.

Systemd should have matured, proved its citizenship and qualities. And it would have been accepted. Instead it usurped. People had no choice but to abandon their platforms. Decade of angry forum thread shows that there is a problem. Just like with python3, it's better to learn. And it is especially painful that there was PulseAudio just before. Same pointless change. Removed it and never looked back. ALSA works for me, still.

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

#58
post #34
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"…

> 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 were already solved adequately in the Linux 0.9 days, and the BSD’s still use old fashioned shell based inits, and work fine in my experience.

In fact, the only time I’ve had issues with any of this stuff has been in the last ten years, and only on systemd-based distros.

The genius of init systems is that they factor all this stuff out, and just handle starting and stopping daemons.

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

#59
post #56
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"…

udev was the biggest step towards "dynamic systems". Or should i say "hotplug" was, since it is more or less the same thing. I completely agree that the init should be an event based system. I'm not arguing that. I never argued that. I did not in fact argue much other then the statement that nobody should say their opinion about anything. You say i left out stuff. I did. A lot more stuff then you wrote here. It would…

Wasn’t the debian vote stacked by a bunch of Canonical employees that voted on party lines, since Ubuntu had already decided on systemd?

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

#60
post #53
post #48

Earlier quoted context omitted.

But systemd-resolved is such an odd complaint since it’s only connection to systemd is the name and that it’s in the same repo. It’s not connected to the init system at all.

The entire repo is a big ball of mud. No one knows which parts can be removed without breaking things. Heck, the author of this article couldn’t even find a design doc or adequate manual for the init part of the train wreck, and it’s been in development for ten years .

[deleted]
Post reply on HN