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.
Systemd by Example (2021)
51–60 of 115 posts
Re: Systemd by Example (2021)
#52Systemd 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
Re: Systemd by Example (2021)
#53Earlier 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…
Re: Systemd by Example (2021)
#54I 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…
Podmans integration with systemd is much greater, especially when you use quadlets (systemd controlled podman containers).
Re: Systemd by Example (2021)
#55Earlier 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"?
Re: Systemd by Example (2021)
#56Ha, 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…
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)
#57This 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)
#58Earlier 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…
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)
#59Earlier 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.)
Re: Systemd by Example (2021)
#60Earlier 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…
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.