Live data from Hacker News

Systemd by Example (2021)

seb.jambor.dev

51–60 of 115 posts

Re: Systemd by Example (2021)

#51
post #35
post #21

Earlier quoted context omitted.

Not a lot of people, a very loud minority. They can go use Void Linux or other niche distros which replace it with the monstrosity that were SysV init scripts. It's the type of people that never had to write one of those scripts by hand, and maybe support two or three different distros. The UX of systemd tools (systemctl, journalctl) is a bit crap, to be honest, but systemd does what it needs to do well and it is an…

That's serveral conjectures on your part. Give me metrics about the minority and then back up the fact that most of those people never wrote a sysinit or rc script by hand. Like it or not Systemd breaks the Unix way and for a certain amount of people (I am not pretending to have a measuring stick) the dogma and philosophy are much more important than perceived ease of use or features.

Why would I care about "breaking the Unix way"?

Re: Systemd by Example (2021)

#52

Systemd is one of the things that is really enhanced by ChatGPT. “Write me a service to start this program” Or “Write a socket activated service to…..” Or “Write a systemd timer that runs every ten minutes” Etc etc

LLMs have increased my understanding of systemd, and I think I do way more exciting stuff with it!

Re: Systemd by Example (2021)

#53
post #29

Earlier quoted context omitted.

>`cron` works best if you desire simplicity above all else It may be simple, but it's config file is hard to comprehend compared to a systemd timer. Being able to just use "Friday 17:00" or "hourly" is so much more readable.

Debugging and tracability is just nuts too. With a timer and a run-once service it's easy to see what happens, happened, and will happen: systemctl status foo.timer tells you when it has last triggered and when it will triggered next, if it is still enabled. systemctl status foo.service tells you if it has been triggered from the timer and when, or ran manually with start I get the conceptual utter simplicity of cron…

Exactly, and there are still alot of old school "cron" users who don't touch the better "anacron" processes. I hate managing that stuff. Systemd > Anacron > Cron

Re: Systemd by Example (2021)

#54

I wish I could make friends with systemd like y'all. I spent at least a week wrestling unsuccessfully with systemd (admittedly starting from complete ignorance) to make a service that synchronizes a local directory on a laptop with a remote directory on a server after a docker container is stopped but before the filesystems and network stack are torn down during poweroff. It was easy enough to accomplish by manually…

Docker and systemd aren't exactly good friends, this is partially why Red Hat created Podman.

Podmans integration with systemd is much greater, especially when you use quadlets (systemd controlled podman containers).

Re: Systemd by Example (2021)

#55
post #51
post #35

Earlier quoted context omitted.

That's serveral conjectures on your part. Give me metrics about the minority and then back up the fact that most of those people never wrote a sysinit or rc script by hand. Like it or not Systemd breaks the Unix way and for a certain amount of people (I am not pretending to have a measuring stick) the dogma and philosophy are much more important than perceived ease of use or features.

Why would I care about "breaking the Unix way"?

Because people who probably have never used Unix said it's superior.

Re: Systemd by Example (2021)

#56
post #43

Ha, systemd is basically my git. I'm always surprised by how many developers don't grok git despite understanding significantly more complex things. I keep thinking if they would just take a day or two, they would get it and then wouldn't complain about having to copy paste commands and "rm -rf && git clone" to fix their workspaces. And yet I do the _exact_ same thing with systemd. I don't get it, I don't like it, an…

I know how you feel. I finally brewed myself a pot of coffee the other day and just followed the advice I always give everyone else-RTFM:

https://www.freedesktop.org/software/systemd/man/latest/syst...

It's pretty well documented, especially for Linux. Follow the links from that page at least one level deep.

Part of the complexity is that it's tightly integrated into the same Linux concepts that enable containers. In fact, systemd-nspawn can manage containers on your behalf.

But start with the concepts and unit files, then read the man pages for systemctl and journalctl. That'll get you most of the knowledge you need to interact with it on a day-to-day basis.

Re: Systemd by Example (2021)

#57
From the personal experience, systemd works quite well when it works, but sometimes I ran into problems with it that were very hard for me to solve. I admit I never became a systemd expert, but I think I had a decent working knowledge of it.

This was the final straw though: https://forums.debian.net/viewtopic.php?t=154562

I am back to sysvinit and happy.

Re: Systemd by Example (2021)

#58
post #45
post #35

Earlier quoted context omitted.

That's serveral conjectures on your part. Give me metrics about the minority and then back up the fact that most of those people never wrote a sysinit or rc script by hand. Like it or not Systemd breaks the Unix way and for a certain amount of people (I am not pretending to have a measuring stick) the dogma and philosophy are much more important than perceived ease of use or features.

All the major distros, especially server distros, run systemd. That is proof enough that NOT running systemd is a niche and unsupported configuration in any half-serious setup. A conjecture is not automatically wrong. The point of a conjecture is to challenge someone else to prove it wrong. You'd have a hard time showing proof that systemd is niche. And honestly, it does not break UNIX , let's be serious now. A hapha…

> A haphazard bunch of shell scripts is not much better than a monolithic binary

If know shell scripts you can read and adapt the former. You can keep the state in vcs without needing a compile artifact or a compiler.

How much work is it to add a bespoke feature to systemd?

It's a tradeoff for sure, but let's not pretend simplicity has no benefits.

And knowledge of Cron transfers to the bsds.

Re: Systemd by Example (2021)

#59

Earlier quoted context omitted.

I started writing a "oh, I never found it that difficult" comment. Then I thought to test my own belief and tried to type out a cron schedule for "run this every hour", and... Well... https://crontab.guru/#*_0/1_*_*_ * Oops. Point taken :)

As well as the already-mentioned `n * * * *` solution, there's also dropping a symlink in /etc/cron.hourly to the program to run. Or a 2-line shell script if you need to add command-line params. (The other line is the shebang.)

The cron.hourly directory is a non-standard Linux concept provided by run-parts. The FreeBSD equivalent is periodic, but that's really for system tasks and doesn't have anything more granular than daily.

Re: Systemd by Example (2021)

#60
post #45
post #35

Earlier quoted context omitted.

That's serveral conjectures on your part. Give me metrics about the minority and then back up the fact that most of those people never wrote a sysinit or rc script by hand. Like it or not Systemd breaks the Unix way and for a certain amount of people (I am not pretending to have a measuring stick) the dogma and philosophy are much more important than perceived ease of use or features.

All the major distros, especially server distros, run systemd. That is proof enough that NOT running systemd is a niche and unsupported configuration in any half-serious setup. A conjecture is not automatically wrong. The point of a conjecture is to challenge someone else to prove it wrong. You'd have a hard time showing proof that systemd is niche. And honestly, it does not break UNIX , let's be serious now. A hapha…

> I am an engineer with software to run and deadlines to meet.

Sure, but UNIX, with its minimalist philosophy, was - luckily for us! - not created under that slogan. With respect to quality, this slogan has always been the one driving its decrease that we see all around us today.

Post reply on HN