Re: [gentoo-dev] Questions about SystemD and OpenRC

[Canek Peláez Valdés]

On Thu, Aug 9, 2012 at 3:42 AM, Luca Barbato <lu_zero@g.o> wrote:
[snip]
> Repeat after me: having your first process require anything more than
> libc is stupid and dangerous.

No, it's not. You can (and should) depend on whatever libraries helps
to achieve the desired goals. If one of the libraries has a bug, guess
what? It should be fixed. And then you repeat until all the used
libraries are as stable as libc (or more, if possible), and then the
statement that "having your first process require anything more than
libc is stupid and dangerous" makes no sense at all.

(As a side note, I would like to see the bugrate of libpthread,
libudev, libpam, libaudit, libcap, libdbus, etc. I'm pretty sure the
latest versions are pretty much rock solid).

That's in part what I like the approach taken by systemd (and
PulseAudio, by the way); it wants to be a proper solution, and if in
using something else they detect a bug, they push to get the bug fixed
in the external library (or the kernel sometimes). They don't
"workaround" real problems. It's the only way to guarantee that the
*whole* stack (not only libc, or the kernel) actually works as it
should.

So yes, PID 1 should use whatever libraries it makes sense to use, and
if there are bugs in them *they should get fixed*. Otherwise lets
program everything in assembler, because maybe gcc has a bug
somewhere.

> Once that concept gets accepted then we could discuss about why
> reinventing shellscript may not be that sound and other less glaring,
> horrid and appalling design choices.

The didn't reinvent shellscript; they replaced it with unit files.
That's the best design choice about systemd, IMHO: the unit files say
*what* a service should do, not *how*. And besides, you can still use
shellscript if your daemon is so fucked up that a regular unit file
doesn't cover your case. You should fix your daemon, really; but the
option to use shellscript is still there.

> Most ideas behind systemd are interesting, their current implementation
> is sometimes completely wrong and given the experience with pulseaudio
> we all know that they won't change even if you provide code for it.

Really? I'm subscribed to the systemd ML, and the author accept all
kind of contributions. If they don't agree with one in particular they
explain why and the discuss a compromise if necessary. Doing the
following in my git clone of the project:

git log --format='%aN' | sort -u | wc

shows a total of 337 contributors to systemd. So I really believe that
you are talking nonsense in this particular point.

> Obviously it is always fun seeing people first say "accept it or fork
> it", then "do not keep your fork you are wasting time" once somebody
> starts forking and/or working for an alternative.

By all means, fork it. Just allow Gentoo users to use udev/systemd as
upstream intended. And while we are at it, don't put OpenRC in the
dependency list of baselayout, otherwise it gets pulled in (and
sysvinit with it) for all systemd users even if we don't use it at
all. I maintain a really small overlay to use systemd exclusively in
Gentoo, so I don't need to install OpenRC and sysvinit:

https://github.com/canek-pelaez/gentoo-systemd-only/
http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México