Last edited by finalzone; 12-02-2012 at 02:41 PM. Reason: Added git repository
Extreme example totally out of proportion, just to make my case:
- And then he "raped" and "kidnapped" her.
What he raped and kidnapped her?
- No he grabbed her hand and led her to the way she was looking for, that's why I used quotes.
But we're drifting away, lets stay on topic
These are standalone binaries that work regardless of init system. Previously Arch used custom shell code to perform the same operations.
Last udev (separate) package was 182 released on 18-Mar-2012.
Yes, of course you can repackage it into separate package, however: http://lists.freedesktop.org/archive...st/006066.html
1) systemd increases the complexity of a Linux installation in order to reduce the number of processes spawned at boot time.
2) it has been shown in this discussion (just a couple of messages above mine!) that the systemd developers consider the reduction of the PID count a great achievement. This is in my opinion silly, because counting PID numers is no benchmark. Especially if the complexity added to the system in order to obtain this result isn't negligible.
3) it has been said in this discussion (again, just a couple of messages above mine) that the complexity added to the systemd binary produces an init executable which isn't that big. I've shown that that its binary is actually 4 times larger than Upstart's equivalent, uses an initialized data section that is 28 times larger, and an uninitialized one that is 18 times larger. Again, this comparison is silly too, because binary sizes are no benchmark.
4) both comparisons bearing little significance, if the reason an Upstart user should switch to the much more complex systemd is a makeshift benchmark, then he might just as well stay with Upstart, as another silly benchmark tells the opposite.
Again, the discussion I was following was this:As I understand it systemd is a system and process manager not a init. A part of systemd, the systemd binary is the init. Upstart and systemd doesn't do the same thing so a comparison of the total code size of the project is not relevant.
1) Someone: Why should people bother using Upstart? Systemd has more stuff.
2) Me: Upstart is more simple than systemd so it's more indicated _for those people who don't want the 'other stuff'_.
3) A lot of other people: No, systemd is actually more simple than Upstart, it's perfectly documented and you can know and understand every detail of how it works, just like you can with Upstart. It's just that you don't want to learn new things.
4) Me: Then I have to learn and understand these 50 or so binaries.
5) You: Meh, systemd does more stuff, so what you say is irrelevant.
Systemd binds together, in an inseparable way, init and many other traditionally separate subsystems. You can't have systemd's init without having the "other things" drawn into your Linux installation. In fact, that's the supposed advantage of using systemd, because if all you want is a fast boot, then Upstart is perfectly fine.
Since this is an Upstart discussion, we're discussing here the advantages of switching from Upstart to systemd, so you can't dismiss the added complexity as a thing we can ignore, because in Upstart we don't have it, in systemd we _need_ to have it.
If you're a distribution professional, then you can manually alter systemd's installation at will, and then you'll have to cope with all the severe and complex implications of doing so, some of them involving security, and repeat the process each time a new systemd release is out; but clearly this is not what systemd's developers expect you to do with their software, as you can see for yourself by looking directly for their opinion on the net. And certainly it's much more laborious than just continuing to use Upstart - if you're content with it.
(Which, as a side note, is what I personally would like to do, but the inclusion of udev into systemd is making it objectively more difficult for me.)
So now its a bad thing if you have processes that not PID 1?Systemd binds together, in an inseparable way, init and many other traditionally separate subsystems. You can't have systemd's init without having the "other things" drawn into your Linux installation.