Live data from Hacker News

Systemd by Example (2021)

seb.jambor.dev

61–70 of 115 posts

Re: Systemd by Example (2021)

#61
post #21
post #13

A lot of people still probably hate on systemd, but it and journalctl are pretty nice to me.

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…

> monstrosity that were SysV init scripts

I'm really tired of people pretending that systemd is the only modern init system around. If you're going to compare it to the status quo, at least don't strawman it. If SysV init scripts are your comparison, it just sounds like you're regurgitating outdated talking points.

Re: Systemd by Example (2021)

#62
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"?

Right. Why would one care about principles.

Re: Systemd by Example (2021)

#63
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'm always surprised by how many developers don't grok despite understanding significantly more complex things.

You used git as a (counter?) example, but for me systemd has this issue because it's because I touch it so infrequently that whatever I learned about it has aged out of mental cache.

I have the same issue with `jq`, GNU `parallel`, and `ffmpeg` (which I'll grant even if I used it daily I probably wouldn't be able to keep up.

> UX of using journalctl and systemctl is so bad (for me)

Not JUST you. I've heard all the arguments 100x for "binary logs good/bad", but I feel this was a step down for some puritanical idea that doesn't translate for many to practicality.

Re: Systemd by Example (2021)

#64

Systemd is a pretty neat little thing. It's what keeps me running Ubuntu and Debian servers instead of switching to Alpine, at least in those situations where I can't containerize what I want to do. The thing that got me into it was systemd timers. I really like being able to split up what should run from when should it run. `cron` works best if you desire simplicity above all else, and Slack used `cron` for a very l…

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

I also enjoy that you can ask systemd to validate your timer/cron, in case you struggle with the syntax:

    systemd-analyze calendar "Mon,Tue *-*-01..04 12:00:00"

Re: Systemd by Example (2021)

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

[deleted]

Re: Systemd by Example (2021)

#67

Earlier quoted context omitted.

I'm sure the few people who run BSD systems will be fine with cron's arcane syntax.

Portable has a well-defined meaning. You can argue that no other system matters (which I strongly disagree with for reasons I don't want to get into right now), but that doesn't make systemd timers any more portable.

I’d argue that the degree of portability implied by the term is very much context dependent. “Portable between Linux systems” is a perfectly valid use of the term, imo.

Do you take portable to mean a program that can run on every processor arch and OS available?

Re: Systemd by Example (2021)

#68
post #49

Earlier quoted context omitted.

I'm sure the few people who run BSD systems will be fine with cron's arcane syntax.

systemd is is many things, but obvious and accessible is not one of them. It has a lot of power and flexibility, but the trade off is a lot of complexity. Just look at the unit configuration file: https://www.freedesktop.org/software/systemd/man/latest/syst... I've never heard of a systemd timer before, but I guessed it was a type of unit file, so I just read the documentation: https://www.freedesktop.org/software/sy…

I'm not quite sure why you felt pressed to write this long-winded response to something I didn't write. I never said that systemd is easy. I said that if someone is running *BSD, today, in 2024, they'll cope with cron's syntax.

I'll still reply to one part:

> Oh, I see I can use "hourly" but it turns out that's syntactic sugar for:

> *-*-* *:00:00

>Is that really any easier than the cron equivalent?

> 0 * * * *

...Yes? Ask someone who's not familiar either with cron or systemd to guess what each one mean, with the context that it's supposed to be something related to dates and times. If you're vaguely familiar with how dates are usually written down, and that a star is a wildcard, you can immediately guess that the first one means "any year, any month, any day, any hour, at the first minute, first second". The cron one? It's anyone's guess.

Re: Systemd by Example (2021)

#69

Earlier quoted context omitted.

I'm sure the few people who run BSD systems will be fine with cron's arcane syntax.

Portable has a well-defined meaning. You can argue that no other system matters (which I strongly disagree with for reasons I don't want to get into right now), but that doesn't make systemd timers any more portable.

Okay, can you define precisely what portable means?

Re: Systemd by Example (2021)

#70
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'm always surprised by how many developers don't grok despite understanding significantly more complex things. You used git as a (counter?) example, but for me systemd has this issue because it's because I touch it so infrequently that whatever I learned about it has aged out of mental cache. I have the same issue with `jq`, GNU `parallel`, and `ffmpeg` (which I'll grant even if I used it daily I probably wouldn't…

how on earth is remembering the location of some log file, buried in /var/log somewhere, hopefully, or maybe next to the application in /etc/ or /opt/, easier than remembering journalctl -u unitfilename ? or journalctl -u unitfilename -f to follow the logs -- the very same flag tail uses?

after a decade of systemd usage I've never once had to actually think about the format the logs are stored in, or where they're stored; journalctl is actually easier than using tail and cat

Post reply on HN