Live data from Hacker News

Systemd 252

github.com

51–60 of 317 posts

Re: Systemd 252

#51
post #41
post #2

Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.

I had to chattr +i /etc/resolv.conf because my resolv.conf would keep getting truncated (as in empty) every time I restarted an lxd container. Rock solid my ass.

lxd is not part of systemd.

Re: Systemd 252

#52

Earlier quoted context omitted.

Not sure I fully understand this argument. Can you expand? I'm not familiar with nohup and its role.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/n... blocks SIGHUP and captures output in a file. That lets me type nohup ./long_batch_job.sh & and walk away, knowing that it will keep running after my shell exits and the controlling terminal is lost. systemd broke that at some point, for no obvious reason. I think there is some nonstandard route to make systemd run something in the background, but end use…

Unix traditionally has never had proper seat and/or session management, with all the chaos this entails. With systemd, they added it. You’re effectively proposing that systemd (or anything else) should never implement session management. The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup command in a detached session.

Re: Systemd 252

#53
post #2

Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.

+1 for systemd-networkd too: it let me declaratively describe some netns/ipvlan interfacing the other day that netplan et al simply couldn't.

It could use with some more netns awareness but its pretty great at the current stage

Re: Systemd 252

#54

Earlier quoted context omitted.

I'm not a Linux expert, but I thought that systemd was generally hated?

I would say it really depends on the context! Some reasons systemd is bad: - Its a "big" for small docker containers (which is part of why a lot of people like Alpine Linux). - It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script. - the binaries are all a lot bigger in terms if SLOC and in terms of storage space than the solutions…

> It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script

I never really understood this point — it’s not some proprietary format that has to be reverse engineered, you quite literally has both encrypt and decrypt source code available for every single version it has been released. You can also just pipe the binary output through the provided “decrypt” tool and then further use the usual unix tools if you wish.

But let’s add the advantages of this logging: systemd can log events from the very start of the boot process, which was not possible before.

Re: Systemd 252

#55
post #2

Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.

I'm not a Linux expert, but I thought that systemd was generally hated?

It started with bad press because author made pulseaudio and its design didn't appeal to many (lots of features but missing pieces, not due to dev but market forces and drivers). So when the same guy says he's gonna rewrite pid1 with a radically different design people went ballistic.

My personal opinion is that proper dependency based init systems are amazing but I'm not fond of some slightly superficial aspect of systemd (syntax, parameters, logic, config files).. to the point I think in a few years someone may make a cleaner variant.

Re: Systemd 252

#56
post #21

Earlier quoted context omitted.

I've developed a distrust for anyone who hates on systemd in 2022, especially if their rationale is vague dogma like "it does more than 1 thing, it's not Unix-like!" It's usually a signal that the person is not a practioner. Systemd is the most important and well-developed Linux framework, besides the Linux kernel itself.

I don't trust anyone's opinion, for or against, unless they've used alternatives. I've used systemd, I'll probably use it again, and I'll keep hating on it if someone gets me started. Fortunately on my own systems I've been a happy OpenRC user instead.

I've used both (OpenRC and systemd). I like the simplicity of OpenRC and still uses it on a few servers running on Gentoo, but on a laptop/desktop I think systemd is a better fit, having user services with user level logging for example.

Re: Systemd 252

#57
post #4

Earlier quoted context omitted.

I'm not a Linux expert, but I thought that systemd was generally hated?

Seems pretty great to me. Never understood the hate.

I was sold after a single session of writing a couple of dependent services. Logging, retries, cleanup. Everything was so ridiculously straightforward, rather than a bunch of bash hacks and lock files.

I have trouble believing that people who loath it so much have actually sat down to read the documentation.

Re: Systemd 252

#59
I love systemd for everything except its cron replacement, somehow it's a real mess. Yet I desperately want something more modern to play with journald well. Any advice?

Re: Systemd 252

#60
post #52

Earlier quoted context omitted.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/n... blocks SIGHUP and captures output in a file. That lets me type nohup ./long_batch_job.sh & and walk away, knowing that it will keep running after my shell exits and the controlling terminal is lost. systemd broke that at some point, for no obvious reason. I think there is some nonstandard route to make systemd run something in the background, but end use…

Unix traditionally has never had proper seat and/or session management, with all the chaos this entails. With systemd, they added it. You’re effectively proposing that systemd (or anything else) should never implement session management. The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup comm…

I’m guessing you don’t mean setsid(2), but when you say “seat and/or session management,” what does that mean concretly? Why should init be involved instead of something under the user’s control?
Post reply on HN