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

191–200 of 458 posts

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

#191

Post by cycloptic »

AnthonyMouse wrote: post #173
cycloptic wrote: post #170

Earlier quoted context omitted.

Yes, they did. It they didn't break it was because those inits were compatible with sysvinit scripts. You lose that once you start porting your init scripts over to rc or whatever it is you replaced your init with, and now your system will break if you try to switch to something else.

Your init scripts would have to be replaced, that's to be expected, and when multiple ordinary init systems are popular, packages could easily support more than one since an init script is generally only a few lines. I'm talking about all the things that now break not related to the normal function of init at all.

If those inits supported newer features, the init scripts would easily grow longer than a few lines and become incompatible once they use those features. I don't see how that's any different from what's going on here.

If your complaint is that the scope of init systems has been expanded, I don't know what to tell you other than that it was inevitable. Systemd is not the first project to try and do this.

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

#192

Post by Conan_Kudo »

gorgoiler wrote: post #139
theamk wrote: post #127

Earlier quoted context omitted.

I think you underestimate how badly the old sysvinit sucked in the world with many good distribution-provided packages. It was pretty good in the good, old days, where a sysadmin could list every daemon the system runs by heart, but it was breaking apart when you had tons of random packages: Package X uses "start-stop-daemon" in ini file, so there is no way to get error messages if config file is incorrect. Package B…

A lot of init problems you describe are very real, but it felt like by the late 00s they had mostly been solved with efforts like linting and standards, as well as LSB init shell functions making init a much more standardized process. PAM was and still is quite hard to understand but, again, it had enough power and flexibility with @ based includes to allow individual distributions to lay things out sensibly and allo…

> A lot of init problems you describe are very real, but it felt like by the late 00s they had mostly been solved with efforts like linting and standards, as well as LSB init shell functions making init a much more standardized process.

These improvements weren't real. There was a long tail of scripts that didn't follow the standard and never would. Every distribution still had their own customizations on how sysvinit scripts worked (e.g. debian with start-stop-daemon, suse with insserv, etc.)

And rc was different on almost every major distro family, which made life even more difficult for no particularly good reason.

And there's a certain point where all these things you are doing are ultimately to paper over the "hacks and untidiness" of everything. The introduction of systemd had two major effects:

1. It broke all non-LSB init scripts (because LSB is all it supported)

2. It introduced a straightforward declarative syntax for system resources (units for services, timers, mounts, etc.)

I would argue that the above two things have done more to standardize the Linux plumbing layer and help people take fuller advantage of it than literally all the linting, guidelines, and policywork we did for the decade prior.

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

#193

Post by yrro »

thayne wrote: post #104
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…

> The stated workarounds - fiddling with some options like "KillUserProcesses=no" in logind.conf &co. - have so far failed. Strange, KillUserProcess=no worked fine for me

In addition I'm pretty sure every distribution ships with it disabled anyway.

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

#194

Post by cyphax »

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…

I read this comment, thought after having recently installed Debian replacing Slackware I'd wipe it again because that's unacceptable. So I ssh'd into the machine, started a screen session, detached it, killed ssh session, ssh back in and the session was still there. Is this an older problem? So far, after coming from Slackware, systemd hasn't been in the way so much, thankfully.

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

#195

Post by yrro »

ttctciyf wrote: post #20
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.

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…

Which distro is this?

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

#196

Post by lmm »

cycloptic wrote: post #177
lmm wrote: post #164

Earlier quoted context omitted.

Systemd deliberately refused to conform to standardised interfaces and got other packages to be changed to explicitly depend on it instead (e.g. RedHat made changes to Gnome to make it break under non-systemd). This was not necessary to achieve the technical things that systemd wanted to achieve - competing alternatives (e.g. runit) didn't need that. (Though it probably was necessary to force adoption).

This is not true in any way. Gnome still works on non-systemd systems but you have to install elogind. And, there were valid technical reasons to have gnome depend on a login manager, in particular supporting multi-seat securely is very difficult without one. I should also mention that the previous "standardised interface" for this was ConsoleKit which was also written by the same developers as gnome and systemd. So…

> This is not true in any way. Gnome still works on non-systemd systems but you have to install elogind.

elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility. It's like saying that windows programs work on Linux, you just have to use wine - it's sort of true for now, but it's not something you can rely on.

> And, there were valid technical reasons to have gnome depend on a login manager, in particular supporting multi-seat securely is very difficult without one. I should also mention that the previous "standardised interface" for this was ConsoleKit which was also written by the same developers as gnome and systemd.

I remember multi-seat working fine long before either systemd or ConsoleKit, so that seems pretty questionable.

> I would advise those projects to put their money where their mouth is and either start making improvements to elogind, or develop a new login manager that better fulfills the needs of gnome.

"The needs of gnome" are a constantly moving set of goalposts under the control of RedHat. Gnome worked fine long before systemd and systemd has not noticeably improved it (if anything the opposite); there was no technical consensus that the current hard-dependency was necessary, it was forced through because RedHat wanted it that way. So they're not going to accept patches to offer compatibility with non-systemd, and if they do then they'll just find a different way to hard-depend on a different part of systemd.

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

#197

Post by lawnchair_larry »

JChase2 wrote: post #105
pknopf wrote: post #74

Earlier quoted context omitted.

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

Slackware doesn't use it, and Patrick Volkerding recently got a Patreon account set up so Slackware 15.0 or 14.3 will hopefully be out soonish with updated packages. I'm writing this on 14.2 and have been running it since it came out with basically no issues. Also have it on a backup server, runs great.

But it’s 2020, and we need package management.

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

#198

Post by kelnos »

wrycoder wrote: post #85
pknopf wrote: post #74

Earlier quoted context omitted.

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

Devuan.org

I still don't entirely get the point of Devuan. I put Debian buster on a low-RAM embedded box, and since systemd eats up precious RAM I'd rather keep, I just switched to OpenRC with

    apt install openrc && apt purge systemd
If I needed it, Debian packages elogind as well.

Rebooted and it worked perfectly. Now, I get that Debian doesn't really support OpenRC[0] (or sysvinit), and it could break in horrible ways when bullseye goes stable, or get removed entirely, but... I don't see why we need a fork before that happens? It seems like it's a lot of work to maintain a distro fork, when I feel like that effort could be more productively redirected to stronger maintenance and advocacy of OpenRC and/or sysvinit in Debian itself?

[0] Debian's openrc package hasn't been updated in a little over a year, which is indeed concerning. sysvinit does seem to be more actively maintained, though.

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

#199

Post by anewvillager »

gorgoiler wrote: post #119

When writing software, it’s comparatively easy to come up with grand new ideas and turn them into lines of code and files filled with modules. What’s much harder is (1) to expand ones code without coupling everything together (2) present it in a persuasive way that naturally builds a user base. SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to…

Why do systemd detractors keep styling it as SystemD? I'm honestly curious.

You know it's written all lowercase, right?

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

#200

Post by [deleted] »

sneak wrote: post #122
gjvc wrote: post #45

Earlier quoted context omitted.

It's worth considering why the topic makes such a regular appearance. I suggest it might be because that so many users of this website find it to be a remarkable example of not only how something so widely unpopular can become so widely established, but also being something that they have to contend with frequently.

It would appear from distribution adoption that systemd is a lot more popular than it is unpopular.

[deleted]
Post reply on HN