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

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

#111

Post by blibble » Mon, May 04, 2020, 4:33 AM UTC

cmeacham98 wrote: post #32

throw0101a wrote: post #24

Earlier quoted context omitted.

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

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…

at university I remember working around the auto-killing of logged out users processes by running screen, then inside that screen ssh'ing into localhost

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

#112

Post by Karunamon » Mon, May 04, 2020, 4:39 AM UTC

CountSessine wrote: post #107

Karunamon wrote: post #99

Earlier quoted context omitted.

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…

Very narcissistic. If it’s so awful for you then don’t use it. But it solved a lot of other peoples problems, like rogue sessions on lab computers and broken executables that accidentally signal() themselves into orphan-hood because SIGHUP is truly one of the dumbest legacies of posix around, maybe just short of posix AIO. Seriously - don’t use it if you hate it so much.

Yes, my systems are primarily operated for my benefit. This should not be a controversial stance, and certainly not one worth hurling insults about.

>Seriously - don’t use it if you hate it so much.

Oh how I WISH that were a viable option. Few things would make me happier than that overcomplicated, opinionated, arrogant pile of unsafe code being excised viscera ex machnia from any system I have the misfortune of managing.

Sadly I'm stuck with it if I want to run any mainstream Linux distros.

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

#113

Post by baybal2 » Mon, May 04, 2020, 4: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..

> there is no turning back.

Iron grip, aggression, pushiness are needed to lobby systemd out.

Another important initiative is to not to let Poettering, Sievers and co. continue throwing new systemds onto distributives. A preemptive action is needed.

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

#114

Post by anon102010 » Mon, May 04, 2020, 4:54 AM UTC

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…

I'm not getting this at all - so this is a can't duplicate. What distro are you using?

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

#115

Post by WesternStar » Mon, May 04, 2020, 4:54 AM UTC

MereInterest wrote: post #61

yawaramin wrote: post #33

Earlier quoted context omitted.

That thread also mentions the solution that will work: https://askubuntu.com/a/904125 I.e., systemd-run --scope --user screen

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. It is not obvious apriori that it is worthwhile to preserve existing conventions and not break existing code.

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

#116

Post by nine_k » Mon, May 04, 2020, 4:55 AM UTC

m45t3r wrote: post #108

nine_k wrote: post #86

My beef with systemd is not its reinventing things. That part may actually be good. One problem is that a number of reinventions were poorly made. E.g. the log format. Yes, unstructured logs have a ton of drawbacks. Can we take some ridiculously well-tested, reliable embedded database or serialization format (like sqlite) and use it as log storage? Alas. Another problem is the "I know better" attitude. Are user proce…

> Are user processes allowed to run after logout? Which DNS to use during startup? What logging in should look like? In each such case, existing behavior which was widely considered as not broken was replaced by a different behavior, often even without an escape hatch. The new behavior(s) in such cases should be made possible, but the default should be the old behavior. All those examples you gave are possible to dis…

Good thing sanity prevails in distro maintainers! But not in upstream, as you duly note.

I also remember that even 2-3 years ago the situation was not as nice yet.

I think what became systemd could have been great software, if not for the, mmm, cavalier attitude of its creators (not necessarily personal; it might be amended by RH corporate deadlines).

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

#117

Post by CountSessine » Mon, May 04, 2020, 4:57 AM UTC

Karunamon wrote: post #112

CountSessine wrote: post #107

Earlier quoted context omitted.

Very narcissistic. If it’s so awful for you then don’t use it. But it solved a lot of other peoples problems, like rogue sessions on lab computers and broken executables that accidentally signal() themselves into orphan-hood because SIGHUP is truly one of the dumbest legacies of posix around, maybe just short of posix AIO. Seriously - don’t use it if you hate it so much.

Yes, my systems are primarily operated for my benefit. This should not be a controversial stance, and certainly not one worth hurling insults about. > Seriously - don’t use it if you hate it so much. Oh how I WISH that were a viable option. Few things would make me happier than that overcomplicated, opinionated, arrogant pile of unsafe code being excised viscera ex machnia from any system I have the misfortune of man…

Sadly I'm stuck with it if I want to run any mainstream Linux distros.

Boohoo! Then man-up and look at all the alternatives out there! You can boot a Linux system with a simple 5-line shell script as /bin/init if you want! You clearly don’t care much about desktop Linux, because those of us that do don’t want a hundred rogue clipboard processes running in the background after we log out. Build a server box with Linux from scratch!

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

#118

Post by sneak » Mon, May 04, 2020, 5:02 AM UTC

nine_k wrote: post #86

My beef with systemd is not its reinventing things. That part may actually be good. One problem is that a number of reinventions were poorly made. E.g. the log format. Yes, unstructured logs have a ton of drawbacks. Can we take some ridiculously well-tested, reliable embedded database or serialization format (like sqlite) and use it as log storage? Alas. Another problem is the "I know better" attitude. Are user proce…

It's astounding to me the issues people have with this. systemd's existence doesn't preclude anyone from using the old, pre-systemd ways of doing things. There are thousands of linux distributions, and afaik there are at least a dozen which are primarily defined as never-using-systemd.

Face it: the linux userspace has always sucked. Linus punted on it way-back-when (to be fair, he was a solo dev working on a kernel, he had his hands full) and opted for the gnu tools, but those (other than the compiler and libc and a few other spots like grep) have never been best-in-class. It was always just sort of "good enough" to avoid swimming upstream (no pun intended) and trying to swap them out.

Someone decided to make an attempt at making the situation better in one way, doing things differently. Perhaps it was a mediocre attempt, even. (I'm just speaking for sake of discussion here; I haven't read the systemd code, just making a point.). Still, nobody was forced to use it, and indeed many options for avoiding it exist.

Somehow, this ended in a holy war and corresponding schism. It makes no sense to me. Are linux users upset that someone dared question their decades of suffering under a poorly-designed userspace? Agree or disagree with systemd's decisions, it's hard to fault someone for making and releasing software and offering it as an alternative, even if it sucks.

I'm all for experimentation in this space. The old way of doing things was super janky, and I think systemd is an improvement in a lot of ways. I (thanks to a lot more time stuck in my house) have two recent Gentoo installs, one with systemd and one without. They both work, but one works better.

"This is the way we've always done it" seems in opposition to the hacker ethos, to me. Doing things differently to see if there might be a better way seems like it's always valuable, considering that nobody's deleting /etc/init.d/* from your system if you don't participate.

Traditions are not always inherently valuable. Try new things. Discard the ones that don't work for you.

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

#119

Post by gorgoiler » Mon, May 04, 2020, 5:10 AM UTC

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 convince the PHB we should rewrite everything in Haskell.

At this point the gentler folk start quietly honing their CVs and sneaking their personal belongings off their desks, one night at a time, in the hope no one notices they are all about to quit.

It felt like Unix systems administration was a haven from this sort of politics — I don’t remember tmux, git, or python trying to push behavior changes on upstream components of the OS[1]. I’m sure it’s why Unix attracted a certain type of personality for so many years and I’m sad to see that changing.

[1] If you are thinking “but those are command line utilities, whereas the init process is a much more specialized case” then I’d encourage you to revisit the Unix principles of every component being a small and simple program! Even init, cron, and login! It’s not some grand ideal to be zealously adhered to: it’s the principles of small components that mean the same OS can run on a quad core Xeon as runs on a $45 network switch.

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

#120

Post by TA0x0 » Mon, May 04, 2020, 5:10 AM UTC

Spivak wrote: post #70

dooglius wrote: post #36

Earlier quoted context omitted.

Why exactly should students not be able to use CPU cycles while not logged in? I certainly did this as a student and would probably not have complained if it decided to kill my processes when doing so.

You don’t deserve the downvotes. This is precisely the use-case this feature is good for. Multi-user systems where persistent background tasks for unprivileged users doesn’t make sense and is more indicative of a misbehaving program than a user trying to run a job. Oh my god the number of times we had to bounce systems because the unintended background processes of long gone users overloaded the system.

Sounds like you had junior admins at best leading your university's *NIX department.

A mid-level admin in 1995 could have easily made a 100 line script to kill background processes from non-logged in users that were running over three hours (or whatever).

systemd brought nothing to this arena.