3 ms·
Thanks for the detailed response. It makes a certain amount of sense. The right course of action would be "meh, don't like systemd, I'll build a better
by zaphar 12y ago
Thanks for the detailed response. It makes a certain amount of sense.
The right course of action would be "meh, don't like
systemd, I'll build a better offering." Talk is cheap,
code is what counts.
This statement seems to ignore Upstart though. Which is again from a very cursory examination exactly that. A better and more modular init without some of the complaints of systemd and yet is not gaining the mind share.
Why isn't it considered a viable alternative?
- Xylakant 12y agoWell, ubuntu used upstart and moved away, redhat/centos the same (though the centos 6.5 version of upstart was horribly outdated and crappy in terms of features). I actually kinda liked upstart, but I prefer systemd.
- lomnakkus 12y agoUpstart's event-based model was semi-broken and AFAIR the original author admitted as much. (I believe he posted a message stating this to a maining list, but I cannot find it ATM.) Exposing the event model directly to the jobs also made reasoning about the current system state (which is what actually matters, not how we got there) tended to make upstart jobs a lot more complicated than necessary. (This is from memory, it's been ages since I actually looked at upstart jobs.)
- the_why_of_y 12y agoHere are some specific examples: read comments #6 and #8 on this 5 year old unfixed bug and weep: https://bugs.launchpad.net/upstart/+bug/447654 https://bugs.launchpad.net/upstart/+bug/447654 in comment #7 on this (unfixed) bug Scott says it could be solved by having upstart use cgroups instead of ptrace to track processes: https://bugs.launchpad.net/upstart/+bug/406397 https://bugs.launchpad.net/upstart/+bug/406397