TLDR: down with sYstemd :]
Systemd, ten years later: a historical and technical retrospective
281–290 of 458 posts
Re: Systemd, ten years later: a historical and technical retrospective
#282PulseAudio is the only program I've seen really stress my Ryzen. I recommend fixing the default sampling config if you have similar issues.
This is a really entertaining writeup, given the subject matter.
Re: Systemd, ten years later: a historical and technical retrospective
#283Earlier quoted context omitted.
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?
The box in question is in use as a media server, but reloading logind logs out the X session, so it wasn't really possible to test properly until today. Having the opportunity to restart the machine (probably I just needed to systemctl daemon-reload?) the "don't kill my processes bro" options are working.
The distro is kde neon.
The point isn't that I can't (or the distro maintainers can't) get it to work, the point is that the aggressive systemd default breaks established practice, and that this is typical systemd behaviour: arrogant and uncaring. IOW user-hostile in the fullest sense of the term. It's not like this is an isolated example.
Re: Systemd, ten years later: a historical and technical retrospective
#284Earlier quoted context omitted.
Systemd has many pluses, but simplicity and intuitiveness are most certainly not among them.
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.
Technically (and I think this is what this thread's misunderstanding is coming from), this is not systemd being simple. It's systemd being easy.
Simplicity is an intrinsic property of a product, describing that it solves a problem without needing many parts. Easiness is a property of the product's user experience, describing that it can be used without much training.
Re: Systemd, ten years later: a historical and technical retrospective
#285vezzy-fnord! I have always enjoyed your commentary and perspective of operating system, it's nice to see you back again!
> it's nice to see you back again! Not for long, probably. I drifted out of this sphere years ago, and came back specifically for systemd's 10 year anniversary, as I felt obligated to at least do that. Judging by the tone of the comments, 10 years later is still too soon to discuss systemd dispassionately, but when I come back in 10 more years I'll see if things have changed.
Honest question: Which relevant technology is ever discussed dispassionately?
Re: Systemd, ten years later: a historical and technical retrospective
#286Earlier quoted context omitted.
Just set ENABLE_RESOLVE=0 when compiling and resolved is gone?
You use the word "just" as if this were a simple thing to understand and know. Is this magic incantation communicates in a way that the usual people who compile this package can understand to use it without being intimately familiar with the code? I ask not rhetorically, just out of curiosity. It's not a typical type of suggestion for other packages I've encountered with open source, and it feels far more difficult t…
It seems exactly as difficult as with any other stuff written in C. Let's say uWSGI. systemd uses meson, and there's a file listing all the options, and the first match for "resolve" seems to be that flat: https://github.com/systemd/systemd/blob/master/meson_options...
Furthermore, even if you compile it, you don't have to use it. Even if you install it, you don't have to use it. (After all it has 2-3 APIs, one of them is the /etc/resolve.conf symlink, if you instead just put 1.1.1.1 in that file, libc will not go through resolved. And similarly for the other entry points.)
It's possible to accidentally compile, install and have systemd-resolved set up on your computer, but it still seems rare that someone can compile and install systemd, yet not know what they're doing.
Re: Systemd, ten years later: a historical and technical retrospective
#287My worst gripe with systemd is that I cannot find reliable docs for older versions.
Your manpages should match the installed version.
Re: Systemd, ten years later: a historical and technical retrospective
#288Earlier quoted context omitted.
Sysvinit is still around, you can always go back to it if you really want. The package is even still in debian.
This is the kind of false argument being thrown around often in OSS discourse that ignores the structural power differential. Don't like it? Write your own/Leave. The fact is you can't go back to it as an individual, because the system has changed and as an individual you're powerless to change the situation at all, especially against an army of developers paid full-time. The latest news from Debian is sysvinit suppo…
> The fact is you can't go back to it as an individual, because the system has changed and as an individual you're powerless to change the situation at all...
Use Void Linux, help Devuan etc. You're not alone, but you're clearly in small minority.
Re: Systemd, ten years later: a historical and technical retrospective
#289Earlier quoted context omitted.
You don't want to use sqlite for logs -- it is way too complex, and in particular, it may roll back (=lose log entries) if it is low on space, and permanently damage data when writing onto disks with errors. It also makes wrong performance tradeoffs for logging -- your choices are either sync() all the time, or roll back on unexpected termination. I don't like the that journald goes backwards in space and updates ind…
No local logging will work without disk space, and if the disk is bad anything can get corrupted.
If you are low on disk space you want something predictable to happen: the oldest logs are deleted and the newest logs are written. This would be a nightmare to achieve with SQLite, as said above it's just way too complicated.
Re: Systemd, ten years later: a historical and technical retrospective
#290Earlier quoted context omitted.
> 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?
> Should any user on a shared university computer be able to spawn processes to run for all eternity?
That's for the university IT to decide, of course. Software should focus on providing general mechanism, not policy.
> Should your desktop environment crashing lead to all software continuing to run, for all eternity, leaking memory like there’s no tomorrow?
AIUI, that's pretty much what might happen if you're forced to enable the lingering option to make nohup work. Systemd does improve session management under *ix-like systems, but the fact that it doesn't manage to interoperate cleanly with the likes of tmux and screen is a pretty blatant papercut.