On Thu, Aug 9, 2012 at 3:42 AM, Luca Barbato <[email protected]> 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
