systemd gets inetd functions

Alain De Vos said:
E.g. there is void-linux with "runit" & gentoo-linux with "openrc".
Click to expand...
Don't forget Artix Linux, which is Arch Linux minus systemd, plus systemd "stubs" to map certain functions expected by systemd-dependent software to use the equivalent, non-systemd tool chain (e.g. elogind).

You even get a choice of init systems:
1. OpenRC (default)
2. Runit
3. s6
4. dinit

If I have to use Linux instead of FreeBSD, Artix with OpenRC is my choice. While not as stable as FreeBSD, it is rock-stable for a Linux distro - even though it is a rolling release.
 
recluce said:
If I have to use Linux instead of FreeBSD, Artix with OpenRC is my choice. While not as stable as FreeBSD, it is rock-stable for a Linux distro - even though it is a rolling release.
Click to expand...
Don't mean to be nitpicky here, but a rolling release is, by definition, not stable.
 
scottro said:
I did once see something interesting. It was to the effect that Poettering knew a lot about C but nothing about sytem administration.
Click to expand...

No, Poettering does not know a lot about C, because: there was once this stroke of genius from the systemd crew, where they wanted to have dbus implemented in the Linux kernel because it was so slow in userspace. Poettering was one of the driving factors behind it.

So when they had mostly finished their stuff, they have submitted their stroke of genius for kernel inclusion and Linus Torvalds reviewed it.

First of all most agreed that performance gains is not enough reason for something to be included into the kernel.

Second Linus not only reviewed kdbus, but also had a closer a look at dbus and profiled it. Something, which Poettering could have done by himself as well with ease.

To quote him:

That said, I have to admit to being particularly disappointed with the
performance argument for merging it. Having looked at the dbus
performance, and come to the conclusion that the reason dbus performs
abysmally badly is just pure shit user space code, I am not AT ALL
impressed by the performance argument. We don't merge kernel code just
because user space was written by a retarded monkey on crack. Kernel
code has higher standards, and yes, that also means that it tends to
perform better, but no, "user space code is shit" is not a valid
reason for pushing things into the kernel.

So quite frankly, the "better performance" argument is bogus in my opinion.

That still leaves other arguments, but it does weaken the case for
kdbus quite a bit.

Because go out and read pretty much any argument for kdbus, and the
*first* argument is always performance. The articles never say "..
because the user-space dbus code is crap", though.

There you have it. In my opinion Poettering knows not much about C at all, otherwise Linus would have not roasted him in that kind of way.
 
Alain De Vos said:
What do people not like elogind, or is there something wrong with it ?
Click to expand...
Elogind is "extracted logind" which comes from systemd, similarly to eudev which is "extracted udev" (replaced devfs). These might work just fine on their own but anything that the systemd team pushes will ultimately be a part of them, as they are parts of systemd. Consolekit2 used to do seat management.
 
You must log in or register to reply here.
Back
Top