[CaptSpify]

I'll put my opinion in the middle ground with systemd as well. I like a lot about it, and I dislike a lot about it. I really think the best thing they could have done would have been to make it modular. If people could just turn off the "features" that they don't want, there wouldn't be so much bitching about it.

Instead they keep trying to shove everything into one giant pile, and don't understand why people get upset.

[MertsA]

>the best thing they could have done would have been to make it modular.

They did, systemd is very modular in nature. The only things that aren't modular that spring to mind is the journal and systemd the init requires dbus (sort of).

systemd the project has a little bit of everything that you need in an operating system but systemd the init is stripped down to being able to parse unit files, supervise services, and generate and walk the dependency graph from where you currently are to where you're aiming to be.

All of the random features that you always hear about are all individual self contained services. So for example, systemd the init knows nothing about the format of /etc/fstab or SysVInit scripts. It only understands how to work with unit files, the way this works is that there's separate self contained generators that parse /etc/fstab and all of the old init scripts and creates unit files that only exist in a tmpfs directory.

If you don't want something like systemd-networkd then you don't have to have it. You can just compile systemd without it, turn it off at runtime, or just configure systemd to not start said service. You can take systemd and make it suitable for everything from embedded use, to servers, to a multiseat desktop.

[srslack]

You'll find that there's pretty much nothing you can't outright disable, except for journald. journald needs to be running, but you can turn off the binary logging and redirect everything to syslog. systemd itself is a collection of system daemons, as well as small programs to interact with those daemons, and almost all of them are disabled by default. That's my experience on Arch, and they adhere strictly to upstream defaults. If that weren't enough you could simply leave out the daemons you don't like at compile time.

[JdeBP]

> you can turn off the binary logging

Every time that people write that they tell other people who do know systemd that they do not know it. The journal cannot be turned off. Making it be stored in files in /run/log/journal/ instead of in files in /var/log/journal/ is not turning it off. It's making it non-persistent so that it doesn't last across system restarts, delegating the job of writing persistent logs to post-processing services that (nowadays) read the journal using its systemd-specific database access facilities. Ironically, making it not be stored in any files at all would actually prohibit the post-processing services from working, as they would have nothing to read and to process into their own formats.

* http://unix.stackexchange.com/a/332315/5132

[srslack]

>they tell other people who do know systemd that they do not know it.

I appreciate the concern, thanks.

>The journal cannot be turned off.

The persistent binary logging is turned off, which is what people bitch about. Obviously, many of systemd's monitoring features are tied to the journal, and as stated journald still needs to be running, obviously writing to a non-persistent journal for these and forwarding logs (if specified.)

>delegating the job of writing persistent logs to post-processing services that (nowadays) read the journal using its systemd-specific database access facilities.

It's true that syslog-ng pulls messages from the journal, whereas syslog implementations that are not aware are provided with them over a compatibility socket, but this is a performance optimization, to reduce system overhead. Not really an important distinction.

The context was turning persistent logs off and switching to on-disk and persistent text logs with syslog. If you really wanted to nitpick: dbus and udev are totally non-optional.

[majewsky]

Is udev optional on any Linux system? (Okay, you probably don't need it on embedded, but then you likely won't want to afford systemd anyway.)

[JdeBP]

Yes. For starters, vdev and mdev exist.

* https://news.ycombinator.com/item?id=11302557

* https://news.ycombinator.com/item?id=11609980

[lksgkjhsgkjh]

vdev was already given up again:

> This system is mothballed.

From its Github page at https://github.com/jcnelson/vdev

[microcolonel]

The repository and build system are set up to allow you to disable almost everything (except core services like evdev, the "systemd" init process, journald, and D-Bus).

Distributions have just found it so pointless to strip it down that they've left it largely as one package. You're entirely welcome to use your distribution's packaging scripts to produce a reduced package, if one doesn't exist yet.

As far as I'm concerned, I'm happy that it's a single repository tracking consistent, interoperable versions of each of the systems in systemd. This means that there are few dependencies to track.

People get upset because they're too lazy to run the build system themselves. People who are unwilling to run the build system and read the mailinglist are unfit to ship anything short of the whole thing anyway. In my opinion, if these people are complaining, it is meaningless. They are not the sort of people who can figure out how to fit their system into 8MB of flash on a tiny SoC, so them complaining that the systemd package is more than 10 megs is like a child complaining that their bedsheets are too barbie and not buzz lightyear enough.

[CaptSpify]

> core services like evdev, the "systemd" init process, journald, and D-Bus

Oh, so just most of the things that people hate about it. No biggie then. /sarcasm

> People get upset because they're too lazy to run the build system themselves. People who are unwilling to run the build system and read the mailinglist are unfit to ship anything short of the whole thing anyway. In my opinion, if these people are complaining, it is meaningless. They are not the sort of people who can figure out how to fit their system into 8MB of flash on a tiny SoC, so them complaining that the systemd package is more than 10 megs is like a child complaining that their bedsheets are too barbie and not buzz lightyear enough.

I can't say I've ever seen anyone complain about that. I have seen, however, people complain about broken logs, unreliable processes, butchered output, hacky fixes, obscure errors, etc.

And this is the attitude that I have an issue with. Systemd has a lot of good sides, but it also has a lot of warts. Pretending that people's legitimate concerns are nonsense is a waste of everyones time, and are what makes people who have issues want to complain at every turn.