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

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

#241

Post by spc476 » Mon, May 04, 2020, 9:28 AM UTC

WesternStar wrote: post #115

MereInterest wrote: post #61

Earlier quoted context omitted.

I know that there is a separate command that can be used to tell systemd to allow a program to live. I know that there are systemd libraries that an executable can link against in order to opt out of the new behavior. These do not matter, because they shows that systemd is willing to break existing programs, and to break specified conventions. Systemd developers cannot be trusted to provide a foundation to build upon…

I see this kind of talking about stuff like the Unix way and existing conventions and programs. I almost have to ask myself when did we end up in a mausoleum. The Unix way is just a guideline from a time some folks wrote some code. A seminal and important time. Its just one(perhaps of many) piece of anecdata. Old code is old code. It's useful but the patterns and conventions it was built on may no longer be relevant.…

The way Linux works now seems sane. You might very well have seen a change in the way Linux works. But when you've seen it change, multiple times, and each time 50% of what you know has to be tossed out and relearned, it gets tiresome. At times it just seems like it's change just for change's sake.

I want to have fun with the computer, not run madly just to stay in place like the Red Queen. Remember to re-read your own comment 30 years from now and see if you feel the same way.

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

#242

Post by lorenzhs » Mon, May 04, 2020, 9:29 AM UTC

dTal wrote: post #207

Conan_Kudo wrote: post #192

Earlier quoted context omitted.

> 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 sysvini…

And if that's all it did, we wouldn't be having this discussion. Instead it is becoming some sort of self-appointed "userland middleware", which nobody asked for. People resent "better init" turning into "henceforth home directories will behave differently".

That's a dishonest argument and you know it. The entire home directories thing is aimed at enterprises, and nobody wants to enable it for individuals' machines. Poettering said as much in the talk where he presented it. It would be much more reasonable to respond to people who dislike systemd if they wouldn't constantly make bad-faith dishonest claims about it.

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

#243

Post by kuschku » Mon, May 04, 2020, 9:29 AM UTC

kelnos wrote: post #187

thristian wrote: post #91

Earlier quoted context omitted.

The trouble is that 'nohup' is not a particular state that specifically marks processes that want to survive logout. Instead, the rule is that processes running inside a particular terminal are killed when that terminal closes, and processes running outside any terminal run as they please. If you SSH to a server, or telnet, or login on the text console, or via a serial port, you get a terminal and everything you run…

> However, if you login to a graphical desktop, that is not a text terminal, and therefore everything is effectively nohup'd No, it's not. I think you're looking at this in the wrong way. The concept here is one of sessions and the parent-child relationship between them, as well as the decisions parent processes make when they create and manage (or don't manage) child processes. If you log in to a text console, you e…

> and it takes all its children with it.

Now what happens if it crashes? Repeatedly? Or if a user intentionally manipulates their session to keep running?

Should any user on a shared university computer be able to spawn processes to run for all eternity?

Should your desktop environment crashing lead to all software continuing to run, for all eternity, leaking memory like there’s no tomorrow?

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

#244

Post by ttctciyf » Mon, May 04, 2020, 9:32 AM UTC

grandinj wrote: post #226

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…

Given the insanely vitriolic level of personal criticism leveled at the systemd people on an ongoing basis, some degree of glibness is an unfortunate byproduct. How about we give them some benefit of the doubt, that they are mostly trying to make things better, and instead ask them "what is the technically correct way, in the systemd world, of implementing this functionality?" I suspect the answer, for screen, would…

> "what is the technically correct way, in the systemd world, of implementing this functionality?"

In the case of terminating programs left running in an ssh shell by a logged out user, it's a pretty simple answer IMO: just leave it alone - if the admin of the ssh server wants to terminate user processes on logout I think that's where the burden should lie and there's no good reason for systemd to get involved, that I can see.

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

#245

Post by josteink » Mon, May 04, 2020, 9:32 AM UTC

kelnos wrote: post #208

josteink wrote: post #167

Earlier quoted context omitted.

Simple... for what? I’d like to setup a service, which depends on another service, and which must always be running, and if it goes down, it needs to have all forked processes killed, must be restarted, and it needs to run as a specific user. With systemd? 5 lines or so of boilerplate, independent of distro. I don’t know about you, but I call that simple.

I think this subthread is talking about the complexity of a system's implementation, not that of its user interface.

As a user, systemd wins for me hands down, because it is simple to use. That it masks complexity away from me is a feature, not a bug. This is also why distros is implementing it almost everywhere: It makes their job easier.

Now if you are measuring the complexity of the system's (full) implementation, you can't really compare systemd to to SysV-init. You need to compare a systemd-based system to a SysV-init based system.

And then you need to account for the 100s of inconsistently written shell-scripts, all the code distributed in the mess of third party dependencies (sh, bash, Perl, Awk, Python, su, supervisord, cron, etc) to ensure that the functionality of the systems you are comparing is really somewhat equal, not to mention the added complexity of the glue between all those components, and how it may fail.

And when you do that comparison, I do believe you will end up concluding that 1. full systems are somewhat complex, for both systems, and 2. that systemd-based systems are not fundamentally more complex, and 3. systemd-based systems have the benefit of a single, centralized implementation for all these core functions, so that developers don't have to reimplement them inconsistently, and possibly buggy.

With systemd, for better or worse, either your entire init-chain is broken or it isn't, so when it works, you know it works. With SysV-init you have no such guarantees.

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

#246

Post by lorenzhs » Mon, May 04, 2020, 9:33 AM UTC

anewvillager wrote: post #199

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?

Revelling in their rejection of systemd. It's childish nonsense and a pretty reliable indicator that a person is bitter about it and their comment most likely not worth reading.

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

#247

Post by jcelerier » Mon, May 04, 2020, 9:33 AM UTC

dijit wrote: post #237

jcelerier wrote: post #206

Earlier quoted context omitted.

> It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex. As a user I 100% disagree. Before systemd I had to learn a few dozen of different config formats for various things * various distros, now all my systems are configured in a…

It's interesting how many people have such wildly different experiences with systemd. For me systemd has hidden some really horrible things behind it's dependency graph (which is a black box) and socket activation issues (for instance, cockpit "listens" on a port, but it's really systemd's socket activation (PID1) and there was a RCE against it). The configuration file format is, in my mind, mysterious, with random k…

> For me systemd has hidden some really horrible things behind it's dependency graph (which is a black box) and socket activation issues (for instance, cockpit "listens" on a port, but it's really systemd's socket activation (PID1) and there was a RCE against it).

I don't understand how this is an horrible thing. Thanks to it you can do stuff as

    systemd-analyze dot > /tmp/foo.dot ; xdot /tmp/foo.dot

and have an interactive representation of your boot flow graph, where you can click on any node to highlight any other dependent node. This is super nice ! systemd-analyze critical-chain was also very good to try to find out which service was keeping my NAS stuck for 5 minutes on boot.

     The configuration file format is, in my mind, mysterious, with random keys in the unit file which have random meaning, and behaviour that is anything but deterministic.

To give you my experience I was never able to do anything with older systems without reading tutorials on the internet while with systemd I'm able to solve my problems with man systemd-whatever most of the time, e.g. just look at `man systemd.service` or `man systemd.network` with actual configuration examples for common use cases

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

#248

Post by crazy_hombre » Mon, May 04, 2020, 9:35 AM UTC

Karunamon wrote: post #99

cmeacham98 wrote: post #32

Earlier quoted context omitted.

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…

My argument is remarkably simple. 1. Systemd did not solve any problems I actually had. 2. Systemd introduced problems that I did not have previously. 3. Systemd did not provide me any net benefit, that is, the few benefits it did provide over Upstart/SysV/etc. (easier service configuration and ordering) did not overshadow the issues it caused. Its introduction into my home and professional computing life has been a…

systemd did make package maintainer's lives a lot easier. We don't often see the shift to systemd from their perspective. They are the ones making the distros so I think they are the ones who really get to say what goes and doesn't go in a distro. They don't have to keep maintaining long init scripts for the hundreds of packages that they are responsible for. Unit files are so much easier to deal with.

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

#249

Post by kuschku » Mon, May 04, 2020, 9:37 AM UTC

blibble wrote: post #96

throw0101a wrote: post #28

Earlier quoted context omitted.

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

> So, for the simple act of logging in, three mechanisms are required (systemd, /etc/shadow, /etc/passwd). This is inefficient, and Poettering has decided to make a drastic change. That change is homed. With homed, all information will be placed in a cryptographically signed JSON record for each user. 10 years ago this would have been considered satire

homed is a purely optional, independent tool, for use in situations where you’d use roaming home directories on windows, or similar technology.

No one is forcing you to change your broken buggy 30-year old shell scripts, you can always continue using them.

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

#250

Post by sjwright » Mon, May 04, 2020, 9:39 AM UTC

aerique wrote: post #214

anewvillager wrote: post #199

Earlier quoted context omitted.

Why do systemd detractors keep styling it as SystemD? I'm honestly curious. You know it's written all lowercase, right?

Basically to annoy you. Yes, it's childish but also very satisfying. Do you want us to even give that up now that we're stuck with SystemD?

You seem to be under the misapprehension that anyone remotely cares. Childish tantrums are counter-productive as they almost entirely blowback onto your own psychological state rather than affecting anyone else's. You are permanently stuck with the contents of your brain; everyone else has a quick chuckle at the troll and continues scrolling past.

Clearly you are immensely frustrated. I suspect this stems from the fact that nearly everyone else either doesn't know and is unaffected, or prefers SyStEmD over sysvinit, or doesn't care one way or the other. For me the whole debate is hilarious because every single objection I've heard about sYsTeMd is one or more of the following:

1. Factually incorrect;

2. Resolved with a trivial config change;

3. Preference for the familiar;

4. Preference for theoretical principles over pragmatism;

5. The kernel is orders of magnitude worse ("but that's different").