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

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

#11

Post by anotheracct_ » Sun, May 03, 2020, 11:49 PM UTC

acdha wrote: post #4

JChase2 wrote: post #3

Earlier quoted context omitted.

I'd say software doesn't always win out on it's merits, there's almost definitely some social aspects regarding what does and does not get adopted. I do agree the commercial interests probably played the largest role, though. I think beyond the initial knee-jerk one might have towards this it's pretty comprehensive and there's interesting points here that are at least worth exploring.

Aren’t those social aspects part of their merits? A big part of why systemd won widespread adoption was by stepping up – the number of people working on the others wasn’t enough to be more competitive. I lost track of the number of Upstart bugs we avoided by switching to systemd, and that had the backing of one of the most popular Linux distributions.

> Aren’t those social aspects part of their merits? A big part of why systemd won widespread adoption was by stepping up – the number of people working on the others wasn’t enough to be more competitive.

They had the people because they had the money. The debate about systemd is only partly technical; it's mostly a culture war about how Red Hat is hostilely taking over the free software ecosystem, and how that invokes memories of embrace/extend/extinguish.

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

#12

Post by catalogia » Sun, May 03, 2020, 11:51 PM UTC

dmurray wrote: post #10

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…

Does nohup work? That's what I would expect to be the standard solution, as the Unix tool that "does this one thing and does it well".

No. SystemD defaults to breaking nohup, tmux, screen, emacs server, etc.

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

#13

Post by acdha » Sun, May 03, 2020, 11:53 PM UTC

JChase2 wrote: post #8

acdha wrote: post #4

Earlier quoted context omitted.

Aren’t those social aspects part of their merits? A big part of why systemd won widespread adoption was by stepping up – the number of people working on the others wasn’t enough to be more competitive. I lost track of the number of Upstart bugs we avoided by switching to systemd, and that had the backing of one of the most popular Linux distributions.

I suppose so ya, can't sustain without a community or company unless you want to do all the work yourself.

Another factor I was thinking is that almost everything in systemd is there because someone saw a need, even if it’s a niche – things like mounts aren’t a big deal for many people but the people who had something which wasn’t well served before wanted something better in a new system. Trying to replace a core component will flush out a lot of those smaller communities.

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

#14

Post by gens » Sun, May 03, 2020, 11:57 PM 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…

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 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'l defend a newbies right to say anything. Nobody was born with all the knowledge of the world. I will not have compassion for your kind of ignorance.

SystemD is about as much an init as my foot is me. That is the problem that most of those you so casually dismiss have with it. That and that it wants to become mandatory. Could they have just extended udev instead of integrating it ? An i wrong to say that ? Is my opinion wrong because i don't have "Red Hat senior engineer" next to my name ? Programming is just a hobby for me. I don't even have a degree in it. So i'm ignorant on the subject ?

Funny thing.. most of those on teh internets who are vehement in favor of systemD don't know much about how a computer system boots and what goes into that.

edit: Never mind. I see feelings and fancy words are still more valuable then knowledge or thinking. Maybe one day, when computing is not as young of a science as it is now.

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

#15

Post by dooglius » Mon, May 04, 2020, 12:00 AM UTC

catalogia wrote: post #12

dmurray wrote: post #10

Earlier quoted context omitted.

Does nohup work? That's what I would expect to be the standard solution, as the Unix tool that "does this one thing and does it well".

No. SystemD defaults to breaking nohup, tmux, screen, emacs server, etc.

You shouldn't be downvoted, this is correct. Sane distros will change the default.

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

#16

Post by gerdesj » Mon, May 04, 2020, 12:01 AM UTC

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…

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.

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

#17

Post by [deleted] » Mon, May 04, 2020, 12:02 AM UTC

anotheracct_ wrote: post #11

acdha wrote: post #4

Earlier quoted context omitted.

Aren’t those social aspects part of their merits? A big part of why systemd won widespread adoption was by stepping up – the number of people working on the others wasn’t enough to be more competitive. I lost track of the number of Upstart bugs we avoided by switching to systemd, and that had the backing of one of the most popular Linux distributions.

> Aren’t those social aspects part of their merits? A big part of why systemd won widespread adoption was by stepping up – the number of people working on the others wasn’t enough to be more competitive. They had the people because they had the money. The debate about systemd is only partly technical; it's mostly a culture war about how Red Hat is hostilely taking over the free software ecosystem, and how that invoke…

[deleted]

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

#18

Post by fao_ » Mon, May 04, 2020, 12:03 AM UTC

catalogia wrote: post #12

dmurray wrote: post #10

Earlier quoted context omitted.

Does nohup work? That's what I would expect to be the standard solution, as the Unix tool that "does this one thing and does it well".

No. SystemD defaults to breaking nohup, tmux, screen, emacs server, etc.

I'm not sure why you're getting downvoted when it's the stated position of the systemd developers that they default to breaking those things. They've acknowledged it publicly. Hell, there was even a thread on the exact issue with tmux 4 years ago: https://news.ycombinator.com/item?id=11797075

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

#19

Post by fao_ » Mon, May 04, 2020, 12:04 AM UTC

gerdesj wrote: post #16

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…

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.

Maybe you should offer to move this bug report conversation somewhere more appropriate? It seems that this is better suited to a github issues thread

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

#20

Post by ttctciyf » Mon, May 04, 2020, 12:08 AM UTC

gerdesj wrote: post #16

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…

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.

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 infests the systemd project and its adherents. I've run into this in so many ways since ceding defeat and allowing it onto my systems. This is just the latest in a long line of examples.