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

21–30 of 458 posts

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

#21

Post by dirtydroog »

fao_ wrote: post #19
gerdesj wrote: 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.

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

found the project manager!

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

#22

Post by e12e »

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.

See:

https://www.pcworld.com/article/3078732/debian-and-fedora-us...

https://unix.stackexchange.com/questions/420594/why-process-...

https://askubuntu.com/questions/1169211/how-can-i-fix-nohup-...

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

#23

Post by xani »

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 still takes over hundred of file opens (and tens of seconds) to get "the last 5 log lines of a command" ( https://github.com/systemd/systemd/issues/2460 ), because why the fuck use say SQLite when you can have fun evening inventing your own shitty binary journal format.

I do find a lot of stuff behind systemd useful but the ever-present half-assness of its solutions is annoying. Half-assed logging here, half-assed dhcp client there, quarter-assed ntp client elsewhere, all while basic functionality is still riddled with edge cases.

Still a net positive over having to fix yet another fucked up init script...

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

#24

Post by throw0101a »

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.

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

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

#25

Post by throw0101a »

dooglius wrote: post #15
catalogia wrote: post #12

Earlier quoted context omitted.

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.

> Sane distros will change the default.

And sane developers don't break multi-decade behaviour in the first place.

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

#27

Post by [deleted] »

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.

[deleted]

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

#28

Post by throw0101a »

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…

> 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 protocol? Now I have to run journald and rsyslog. And why doesn't it have an ACID file format that doesn't self-corrupt at times? Why couldn't they just use SQLite or OpenLDAP's LMDB?)

What does systemd 245's systemd-homed have to do with an init replacement?

* https://www.techrepublic.com/article/linux-home-directory-ma...

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

#29

Post by zozbot234 »

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 session going when a program has been launched under nohup, instead it tightly couples its own "session" concept to the remote connection and then adds a totally ad-hoc, hacked-together feature called EnableLinger to somehow make nohup work anyway. It's amazing.

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

#30

Post by detaro »

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.

> The link you provide is absolutely huge

The first message in the bugtracker already has the context of whats happening.

Post reply on HN