Version 5 of systemd-free Debian remix Devuan is here | Hacker News Reader

Version 5 of systemd-free Debian remix Devuan is here

theregister.com

28 pointslproven18 comments

For those looking to understand some of the history of the anti-systemd feelings, I found this presentation useful: The Tragedy of systemd (https://www.youtube.com/watch?v=o_AIw9bGogo)

Another one - https://www.theregister.com/2014/04/05/torvalds_sievers_dust...

So the objection here is what….. bugs?

Is the implication that systemd has bugs and nothing else does? If so that’s nonsensical.

I have to wonder, if an in-depth explanation is needed to say why it's bad, then is it really that bad?

I have been using Debian for a long time, and I moved to systemd when they switched and I have not had any issues with it that I can think of.

The presentation doesn't really say it's bad. The presenter just gives a context of why it has stirred up so much controversy, and how it has the potential to improve the way things are done on Linux.

The presentation is more of a defense of systemd

I develop and maintain a plurality of custom linux distros for embedded hardware using Yocto. I used to be the InitV guy, the first half of my distros use it and it's horrible. Every change breaks something. Services start and don't stop or vice versa. I recently switched to using Systemd and life is so much better. You can actually reason about systemd's operation and load order. The systems I build linux for have 128MB of ram up to 1GB of ram, are mostly 32 bit and use SD-Card like storage. In other words not exactly super performant and systemd boots in the same time as InitV. At worst it's 2-3 seconds slower. If I can't tell the difference on a $20 microprocessor I guarantee you can't either on the current state of the art CPU's. For reference my latest systemd based distro is 32 bits, runs at 400MHz and possesses a proud 200bogoMips of grunt.

I don't think people complain about systemd being slow. It's supposed to be faster than initV because of parallel/delayed startup.

But initV is the wrong comparison point anyway. Runit, upstart, openRC are all much better than initV. I certainly had less problems with openRC on my gentoo box than with systemD on my ubuntu box -- mainly because of all the add-ons (ntp, dns etc.) beyond init itself.

Some debian zealots do not understand: they say debian has the sysvinit alternatives which are available. It is some lack of perspective or it is hypocritical since they perfectly know how important being the "default" is. Devuan is no-systemd by default, and yes, it does matter a lot, namely the software stack has been tested/debugged to be consistent and working without systemd.

The banned packages list is surprisingly not that long, and a good chunk of the packages listed there are systemd helper utilities:

https://pkgmaster.devuan.org/bannedpackages.txt

A lot of work was put in in order to achieve such "small list". We are talking about half a decade of work and breaking thru some blockades...

I wish we could have a systemd that JUST does the job of init, and leaves the system logging, DNS resolving, etc. to the prexisting software that does a better job of it.

You literally don't need to use those features to use systemd. There's no requirement on journald or systemd-resolved if you just want to use systemd as an init.

Distros are typically configured to use these features because they bring a bunch of benefits and are simpler to configure, but they're completely optional. At my job we manage an embedded Linux distro (using Yocto) and while we've been using systemd as init for a while, we only enabled journald relatively recently, and don't use the other stuff.

> There's no requirement on journald

Are you sure? I don't think it's possible to disable the journal for the whole system.

> You literally don't need to use those features to use systemd. There's no requirement on journald or systemd-resolved if you just want to use systemd as an init.

Unit/Service file syntax controls per-service logging, PID1 is rather tightly coupled to journald in implementing those features.

Hence the service manager explicitly checks that journald is running at startup:

https://github.com/systemd/systemd/blob/v254/src/core/manage...

Other components like resolved and networkd are optional however.

Does that actually require journald to be running though. Following that code through to the actual check gets to the comment:

> The journal is fully and entirely up? If so, let's permit logging to it, if that's configured. If the journal is down, don't ever log to it, otherwise we might end up deadlocking ourselves as we might trigger an activation ourselves we can't fulfill.

I have never run in such a configuration, but based on this code, it sounds like there is explicit support for running without journald.

The code just has to tolerate a period where journald's starting but not yet available, since it's PID1 which starts journald, to avoid deadlock. Chicken-egg problem.

There's assumptions throughout PID1 that journald is the logger, units which log get journald deps added:

https://github.com/systemd/systemd/blob/v254/src/core/unit.c...

Salient point being, this is all journald-coupled, not some abstracted logging concept you can substitute with any other thing.

The problem with supporting a journald-less mode as some first class thing is it's basically a degraded functional state.

Edit:

Here, I dug up the documentation speaking to this when journald was being developed:

  > I am using systemd on an embedded system and am not interested in
  > persistent logging, can I opt out of the journal?
  >
  > No you can't really. However, what you can do is tell systemd that
  > you don't want persistent logging, by removing (or not creating in
  > the first place) the /var/log/journal directory, in which case
  > journald will log only to /run/log/journal (which it does in any
  > case during early boot). /run is volatile and lost on reboots, in
  > contrast to /var. On top of that you can configure the maximum disk
  > space the journal may consume to a low value.

From the google doc linked @ https://0pointer.de/blog/projects/the-journal.html in the FAQ section.

Distrowatch's Advanced Search page:

(note the "Init software" section of checkbox choices, near the end...)

https://distrowatch.com/search.php#advanced

Reply on news.ycombinator.com