Systemd, ten years later: a historical and technical retrospective • Hacker News Board

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

#71

Post by cat199 » Mon, May 04, 2020, 2:32 AM UTC

acdha wrote: 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…

> how open-source projects work

they work differently depending on the project.

so this statement:

> requires buy-in from an unusually large number of parties since it affects the OS, everyone shipping daemons, and the operators.

is only true in some cases.

c.f. rcng, which was developed by a very small few people, and is a generally sane improvement on previous BSD init that i've really never heard any complaints against vs the previous method.

same could have been true here. it was not - and the need for 'consensus' was largely sidestepped by the 'market pressure' of gnome being dependent on systemd features, and the leading core desktop environment that people had already attached themselves to, esp in the enterprise market.

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

#72

Post by downerending » Mon, May 04, 2020, 2:34 AM UTC

0zymandiass wrote: post #39

zozbot234 wrote: post #7

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!

Systemd has many pluses, but simplicity and intuitiveness are most certainly not among them.

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

#73

Post by Spivak » Mon, May 04, 2020, 2:35 AM UTC

xani wrote: post #23

ratsmack wrote: post #2

>systemd still remains poorly understood and understudied from both a technical and social level despite paradoxically having disproportionate levels of attention focused on it. This statement makes no sense. It is well understood and has been studied and critiqued by many, including me. Also, I don't know what "social level" has to do with anything here. It was just created for the commercial aspect of Linux and for…

Pretty much. If it was just some guys project nobody would give a shit until it was actually well tested and proven. But it was made by guy hired by Red Hat so instead of maturing and having to take actual user feedback before being used in anything significant it was pushed by a guy that vision is limited to "It works fine on my laptop". Who then decided to reinvent everything along the way like log storage that sti…

This has not been my experience at all. The systemd project seems to take extreme care to adhere to the spec when implementing features. They don’t adhere to “this is how it used to work” which is where the bulk of the issue seems to be. The big controversy was when systemd-resolved implemented the spec to the letter and broke people’s assumption that listing DNS servers in order means they’ll be queried in that order.

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

#74

Post by pknopf » Mon, May 04, 2020, 2:37 AM UTC

zozbot234 wrote: post #29

ttctciyf wrote: 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…

This is yet another example of pointless incidental complexity in systemd. The whole point of "nohup"-based tools like tmux and screen is to cleanly separate the management of user sessions from the incidental mechanism of whether a remote connection is being closed (the 'HUP' in nohup is short for "hang up" i.e. close a [possibly remote] connection). Systemd should simply acknowledge this fact and keep the user sess…

I'm not seeing a lot of hope here. There is an incredible investment in systemd by distributions, there is no turning back.

Help me..

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

#75

Post by ttctciyf » Mon, May 04, 2020, 2:43 AM UTC

cesarb wrote: post #46

ttctciyf wrote: post #20

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…

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 :)

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

#76

Post by BeetleB » Mon, May 04, 2020, 2:44 AM UTC

pknopf wrote: post #74

zozbot234 wrote: post #29

Earlier quoted context omitted.

This is yet another example of pointless incidental complexity in systemd. The whole point of "nohup"-based tools like tmux and screen is to cleanly separate the management of user sessions from the incidental mechanism of whether a remote connection is being closed (the 'HUP' in nohup is short for "hang up" i.e. close a [possibly remote] connection). Systemd should simply acknowledge this fact and keep the user sess…

I'm not seeing a lot of hope here. There is an incredible investment in systemd by distributions, there is no turning back. Help me..

Gentoo is reaching out to you.

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

#77

Post by ycombobreaker » Mon, May 04, 2020, 2:45 AM UTC

Spivak wrote: post #66

throw0101a wrote: post #35

Earlier quoted context omitted.

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

I mean that is their position yes. It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.” This is basically the same behavior as Windows where anything not going through the task scheduler ends when you log out. This is a feature that sysadmins have been asking for. On any multi-user system you run into this crap where background processes for users who are long-since gon…

> it’s weird that “logging out” doesn’t imply “and end all my programs.”

Weirdness is in the eye of the beholder. I regularly run programs whose lifecycles are not in sync with my login session. Why do I need to stick around to see a batch job complete?

I can understand that different folks have different backgrounds which changes expectations... but come on... somebody bringing up tmux, screen, etc. should simply end the conversation. "Oh, that is a common and historical use case that I have not considered, today I learned something."

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

#78

Post by edoceo » Mon, May 04, 2020, 2:45 AM UTC

pknopf wrote: post #74

zozbot234 wrote: post #29

Earlier quoted context omitted.

This is yet another example of pointless incidental complexity in systemd. The whole point of "nohup"-based tools like tmux and screen is to cleanly separate the management of user sessions from the incidental mechanism of whether a remote connection is being closed (the 'HUP' in nohup is short for "hang up" i.e. close a [possibly remote] connection). Systemd should simply acknowledge this fact and keep the user sess…

I'm not seeing a lot of hope here. There is an incredible investment in systemd by distributions, there is no turning back. Help me..

OpenRC, it's available on some Linux distros.

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

#79

Post by bdavis__ » Mon, May 04, 2020, 2:55 AM UTC

zozbot234 wrote: post #7

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.

i hope you are correct.

it is so easy to deprecate someone else's skills and knowledge with massive change like this. would it be that hard to respect some of the users?

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

#80

Post by wtallis » Mon, May 04, 2020, 3:07 AM UTC

Spivak wrote: post #73

xani wrote: post #23

Earlier quoted context omitted.

Pretty much. If it was just some guys project nobody would give a shit until it was actually well tested and proven. But it was made by guy hired by Red Hat so instead of maturing and having to take actual user feedback before being used in anything significant it was pushed by a guy that vision is limited to "It works fine on my laptop". Who then decided to reinvent everything along the way like log storage that sti…

This has not been my experience at all. The systemd project seems to take extreme care to adhere to the spec when implementing features. They don’t adhere to “this is how it used to work” which is where the bulk of the issue seems to be. The big controversy was when systemd-resolved implemented the spec to the letter and broke people’s assumption that listing DNS servers in order means they’ll be queried in that orde…

> The systemd project seems to take extreme care to adhere to the spec when implementing features. They don’t adhere to “this is how it used to work” which is where the bulk of the issue seems to be.

Really, the issue here is that "how it used to work" is mostly unambiguous, but I have no clue what you mean by "the spec", and I suspect you're actually referring to a multitude of specs, several of which were only created in the process of writing the relevant systemd components.