Debian Tech Committee Falling Further Into Disarray

[pal666]

Everything besides reaping zombies. Each and every action, each and every dependency (dbus!) increases the chance of bugs. Each line of code adds complexity.

you seem to like making fool of yourself in public.
if it will not use DBUS!!!!1111 then it will have to invent its own ipc just to make more its own bugs because noone else will test it. with each line of code for making its own crappy ipc will come more complexity and bugs.
btw, why you don't have enough brain to count every line of piles of shit from {/usr,}/{s,}bin/ , called directly or indirectly by sysvinit ?

[TheBlackCat]

systemd Broken by design http://ewontfix.com/

Great, another source that says systemD has too much in pid 1, without listing what should be moved out of pid 1.

[erendorn]

1) It does far too much in pid 1. This greatly increases the risk to system stability. "All eggs in one basket" is simply stupid.

Far too much doesn't seem to be that much: http://people.debian.org/~stapelberg...endencies.html
(note: the link actually lists what is in PID 1)

[Vim_User]

Great, another source that says systemD has too much in pid 1, without listing what should be moved out of pid 1.

Actually, that article explains exactly what the author thinks should be in PID1. Have you even read it?

[oleid]

Far too much doesn't seem to be that much: http://people.debian.org/~stapelberg...endencies.html
(note: the link actually lists what is in PID 1)

What's your point? Do you suggest copying the code to pid1 and make it bigger?

It doesn't matter how many shared libraries are used, it matters, though, how buggy the code in Pid1 is that uses it.

[oleid]

Holy crap, systemD requires reboot to upgrade? Really? I haven't heard that yet! Is this shit for real?

No, AFAIK

systemctl daemon-reexec

reloads PID1.

[oleid]

Actually, that article explains exactly what the author thinks should be in PID1. Have you even read it?

I don't really get the point of moving most of the stuff out of PID1 to PID2. It won't reduce possible security issues and the scenario about a failing re-exec is quite artificial. And even if it occurs, why not making the kernel re-execute PID1 if it fails?

[pal666]

systemd Broken by design http://ewontfix.com/

guy just advocates his own useless solutions
his argument is ridiculous
to avoid kernel panic on dead pid1 he moves everything but one line for loop to pid2
but kernel panics on dead pid1 for a reason and this reason is not "someone must reap zombies" but "thing, responsible for controlling all system daemons, must be alive"
if you make that thing pid2, then you must panic on dead pid2, stupid!

[TheBlackCat]

Actually, that article explains exactly what the author thinks should be in PID1. Have you even read it?

Sorry, you are right, technically the author suggests moving stuff from pid1 to pid2, which (as pal says) doesn't actually change much at a practical level. You would still have systemD, just being run in pid2 instead of pid1.

[erendorn]

What's your point? Do you suggest copying the code to pid1 and make it bigger?

It doesn't matter how many shared libraries are used, it matters, though, how buggy the code in Pid1 is that uses it.

You said systemd puts too many thing on PID 1, so I went to check that assertion, and actually most of the systemd ecosystem is out of PID 1. that's all.