[sph]

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 established component of a modern Linux system.

[generalizations]

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

[okanat]

Sorry but this argument really falls flat. All of the other init systems' service files are reminiscent of SysV say OpenRC or runit.

Moreover systemd achieves what it does because it provides a unified way of doing system administration. It is not only a service manager. It is the much needed dynamic system layer for Linux.

A modern Linux engineer or a sysadmin, no longer needs to make 5 to 10 different services work together by duct taping everything or writing abstraction layers per integration. Any system that has the correct level of abstraction will be at least as complex as systemd.

[sph]

> systemd is the only modern init system around

I never said it was. I said it's the only relevant one. Upstart was half-decent, for example, but no one uses it any more. Yes, there are other modern init systems, none that are so brilliantly designed and perfect that are worth this kind of resistance. They're all crappy in their own way. So what if systemd has won.

I do not get why people want to die on this inconsequential hill.

> regurgitating outdated talking points

No, I'm not being paid by Poettering. I've been running Linux systems and software for 25 years, and I have formed my opinion on the matter, thank you very much.

[zb10948]

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.

[sph]

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 haphazard bunch of shell scripts is not much better than a monolithic binary, and UNIX does not give a damn either way.

I do not care about dogma and philosophy, I am an engineer with software to run and deadlines to meet.

[Koshkin]

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

[sph]

UNIX was created by engineers to run software, not as a philosophical device.

Sorry to say, yours is a terrible excuse. I respect that you might not like systemd, no software is perfect and systemd has many flaws, but the "think of the UNIX philosophy" is righteous nonsense that I cannot take seriously.

The real world is not black-and-white, with or against us. One of the most beloved UNIX tools, Emacs, is as far removed from the minimalist philosophy that some have decided to be UNIX's crowning achievement. It is not. Linux and UNIX have not won because we're all into minimalism, or dogmatic zealotry.

[Koshkin]

To be fair, "Unix philosophy" was originated by said engineers themselves.

https://en.wikipedia.org/wiki/Unix_philosophy

Speaking of emacs, it was created outside Unix, to be later reincarnated by Stallman as part of his "GNU's Not Unix" project.

[e12e]

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

[op00to]

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

[PlutoIsAPlanet]

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

[fsflover]

It's outlined here: https://en.wikipedia.org/wiki/Unix_philosophy

[op00to]

I don't care about a 50 year old technology philosophy. Times have changed.

Cloud computing and the prevalence of highly distributed systems have completely changed how software is deployed, scaled, and managed. These environments often rely on complex orchestration which can stretch the boundaries of the UNIX philosophy towards systems that are more about interactions between distributed components than about simple, single-purpose tools.

[fsflover]

I don't see how it's relevant. An orchestration tool can also follow the Unix way by not implementing too much functionality and relying on the small tools for subtasks.

[okanat]

And do you know what systemd is? A project that produces multiple orthogonal executables that share a syntax paradigm and communicate over standardized IPC mechanisms.

I think the only valid-ish argument these Unix philosophy discussions boil down to "why didn't they use purely text based interfaces". Well because they are inefficent and hard to debug and reason with. Making things text only doesn't make them more understandable but they make sure the programs waste energy and development time in meaningless parsing code that is full of security issues.

[op00to]

Why? For old time’s sake?

[Koshkin]

Right. Why would one care about principles.

[op00to]

They’re not my principles, and I spent the first 15 years of my career administering real capital U UNIX systems.

[mardifoufs]

Do you care about my principles too? Mine don't involve a Unix philosophy.

[graemep]

> which replace it with the monstrosity that were SysV init scripts

Void does not use SysV init scripts. Neither do the other distros I know of that do not use systemd.

[frankjr]

> The UX of systemd tools (systemctl, journalctl) is a bit crap, to be honest

Huh, what do you mean? I'm pretty happy with those.

[sph]

I really dislike that systemctl subcommands do not respect the accepted standard of `command subcommand -h`. For example, try `git branch -h` or `systemctl start -h`. The latter won't give any useful information.

The man page does not help either. `man git branch` opens the manual of the `git-branch` binary, so only the relevant options are shown. `man systemctl start` will show the man of the entire systemctl command, which is a bit unwieldy.

`journalctl` is the same: it both does paging through the logs, but also manages rotating or vacuuming the logs. Why not have two commands?

[mixmastamyk]

I just did `systemctl start -h` and got a ton of information. Is the problem it is too much?

[UI_at_80x24]

>The UX of systemd tools (systemctl, journalctl) is a bit crap....

And this is easily 80% of why I don't like it. I _know_ it's better* but my use-cases have never clashed with the limitations of init.d.

*better: I've recently had an issue that I was trying to troubleshoot while using `journalctl -fu service-name` and it just wasn't giving me enough information/the same content that /var/log/messages was giving me on my other OS (FreeBSD). Perhaps there was a flag I was missing (increase verbosity??) but the UX did get in the way.

Side note: I do chuckle every time I end up using the -fu flag. =)

[frankjr]

You can see the raw message with `-o verbose` (or json/json-pretty/...). You can also pick just the fields you want with `--output-fields`.

  $ journalctl -f -u sshd

  Feb 15 13:21:56 vm sshd[4844]: pam_unix(sshd:session): session opened for user user(uid=1000) by user(uid=0)

vs

  $ journalctl -f -u sshd -o verbose
 
  Thu 2024-02-15 13:21:56.886724 UTC [...]
    PRIORITY=6
    _SYSTEMD_SLICE=system.slice
    _BOOT_ID=8e87dffc55844df1b122cfa31010b1df
    _HOSTNAME=vm
    _RUNTIME_SCOPE=system
    _UID=0
    _GID=0
    _CAP_EFFECTIVE=1ffffffffff
    _TRANSPORT=syslog
    SYSLOG_IDENTIFIER=sshd
    SYSLOG_PID=4844
    SYSLOG_TIMESTAMP=Feb 15 13:21:56 
    _PID=4844
    _COMM=sshd
    _EXE=/usr/bin/sshd
    _CMDLINE="sshd: user [priv]"
    _SYSTEMD_CGROUP=/system.slice/sshd.service
    _SYSTEMD_UNIT=sshd.service
    _SYSTEMD_INVOCATION_ID=4065f778bd534ab98f1849d858d0f49e
    SYSLOG_FACILITY=10
    MESSAGE=pam_unix(sshd:session): session opened for user user(uid=1000) by user(uid=0)
    _SOURCE_REALTIME_TIMESTAMP=1708003316886724