Live data from Hacker News

Systemd, ten years later: a historical and technical retrospective

blog.darknedgy.net

31–40 of 458 posts

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

#31
The dependency problems he's describing sound like they could be relatively easily fixed with some new systemd keywords?

Of course it would take some time to migrate existing unit files.

It doesn't sound like a fundamental critique. Would be nice to turn this into a constructive proposal to fix systemd.

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

#32
post #16

Earlier quoted context omitted.

Screen still works. I use it all the time. Do you have decent examples of it failing to work? If so, then that sounds like a bug against screen. The link you provide is absolutely huge and from three years ago. Please give me a simple "stages to reproduce ..." style report. Please keep it simple and short and I'll fill in the blanks if I can and only trouble you for stuff I'm too daft to work out.

> Do you have decent examples of it failing to work? Poettering: > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out […] * https://lists.freedesktop.org/archives/systemd-devel/2011-Ju...

This is such a classic example of the type of argument I see from most anti-systemd proponents that it made me laugh out loud when I clicked your link.

For the lazy, here's the context of that cherry-picked sentence:

> In order not to break screen we currently do not set kill-user=1 or kill-session=1.

> Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out (think university, where students not logged in on a workstation should not be able to waste CPU), in other cases its a bad thing however (i.e. in yours). That means it must be configurable whether screen is considered an independent session or not.

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

#33
post #9

As a somewhat dilettante and casual home sysadmin (currently) I was messing around with screen on a box downstairs and ran into this: https://www.reddit.com/r/programming/comments/4ldewx/systemd... Namely that systemd doesn't allow persistent processes started from the shell by default, preferring to terminate them when the user logs out. This would include processes like "screen" whose entire raison d'etre is to per…

That thread also mentions the solution that will work: https://askubuntu.com/a/904125

I.e.,

    systemd-run --scope --user screen

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

#34
post #14
post #5

I think this really sums this article up: > One thing I’m certain of is that this shift cannot emerge from dilettantes, outsiders and proverbial basement hackers. One does not unseat a platform without already being part of the patriciate that calls the shots on what gets integrated where across the largest nodes in the ecosystem. It’s a long, turgid “why wasn’t I consulted?” complaint which really just comes back to…

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"] is not complicated as much as it is.. obscure. I know about these stuff, do you ?

I know enough to know that 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. Every other operating system Linux is competing with has a much better model than SysV init (Windows has since the early 1990s!), and the world changed from static servers which rarely changed to most systems needing dynamic behavior – what worked in an old server room isn’t a good fit for a laptop!

Again, I’m not saying that systemd is perfect but that most of the complaints tend not to acknowledge the many problems it solved and a decade of angry forum threads doesn’t seem to have resulted in any concerted effort to build a serious competitor. 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.

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

#35

Earlier quoted context omitted.

> Do you have decent examples of it failing to work? Poettering: > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out […] * https://lists.freedesktop.org/archives/systemd-devel/2011-Ju...

This is such a classic example of the type of argument I see from most anti-systemd proponents that it made me laugh out loud when I clicked your link. For the lazy, here's the context of that cherry-picked sentence: > In order not to break screen we currently do not set kill-user=1 or kill-session=1. > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out (think un…

Translation: We broke long-standing POSIX/Unix behaviour of noHUP and think that's a good thing.

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

#36

Earlier quoted context omitted.

> Do you have decent examples of it failing to work? Poettering: > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out […] * https://lists.freedesktop.org/archives/systemd-devel/2011-Ju...

This is such a classic example of the type of argument I see from most anti-systemd proponents that it made me laugh out loud when I clicked your link. For the lazy, here's the context of that cherry-picked sentence: > In order not to break screen we currently do not set kill-user=1 or kill-session=1. > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out (think un…

Why exactly should students not be able to use CPU cycles while not logged in? I certainly did this as a student and would probably not have complained if it decided to kill my processes when doing so.

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

#39

Systemd is an amazingly clear example of the second-system effect, as described in The Mythical Man Month . I fully expect it to be replaced down the line by something dramatically simpler and more intuitive, but that might take some time. Nonetheless, it does seem to solve some real problems with the earlier, rc-scripts approach.

It's dramatically simpler and more intuitive than what it replaced, so I'm super excited when someone comes up with something even better!

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

#40
post #5

I think this really sums this article up: > One thing I’m certain of is that this shift cannot emerge from dilettantes, outsiders and proverbial basement hackers. One does not unseat a platform without already being part of the patriciate that calls the shots on what gets integrated where across the largest nodes in the ecosystem. It’s a long, turgid “why wasn’t I consulted?” complaint which really just comes back to…

> An init system is harder than it might seem at first […] systemd-as-init-system is not the problem. systemd-as-kitchen-sink is the problem. It's the tight coupling that annoys many people. Does udevd really need to be in the same repo? While there may be some nice things about journald, does it really have to be in the same source package? (And why can't it support remote logging with the industry standard syslog p…

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.

Post reply on HN