Upstart Now Available In Debian Unstable

[LightBit]

Sounds much better, thank you. You have to be really careful with what words you use on this topic. Some people will believe everything as soon as it's a thing they can use against systemd! And stealing definitely implies that something illegal/wrongful happened, which is not the case.

This is why I used quotes.

[finalzone]

They didn't actually stole it. Kay Sievers is systemd dev and he was also udev maintainer. http://lwn.net/Articles/490413/

Kay Sievers is still udev maintainer. From the same link you posted, udev and systemd are still separated binaries though they share the same git repository.

[LightBit]

Kay Sievers is still udev maintainer. From the same link you posted, udev and systemd are still separated binaries though they share the same git repository.

Who said that? I said they are in the same package.

[droste]

This is why I used quotes.

That's not how quotes work Just because you know what you really meant, doesn't mean that others do. To use a quoted word it has to be suitable for the situation. The word to steal has one meaning: Take something away illegally. Which is not suitable in any way here: It's still there and it wasn't illegal.

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

[Gusar]

As I understands it the last version of the old init in Arch linux is supposed to use some of the stuff in systemd without using the init systemd?

Yes, Arch initscripts (which use sysvinit) run the following binaries: systemd-vconsole-setup, systemd-remount-fs, systemd-random-seed, systemd-modules-load, systemd-cryptsetup, systemd-tmpfiles, systemd-sysctl, systemd-binfmt

These are standalone binaries that work regardless of init system. Previously Arch used custom shell code to perform the same operations.

[finalzone]

Who said that? I said they are in the same package.

http://cgit.freedesktop.org/systemd/...d/log/src/udev which I attached on earlier post..
udev can still be compiled as separated package if you closely look.

[LightBit]

http://cgit.freedesktop.org/systemd/...d/log/src/udev which I attached on earlier post..
udev can still be compiled as separated package if you closely look.

See here: http://www.kernel.org/pub/linux/utils/kernel/hotplug/
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

[peppepz]

What has that todo with PID?

Where did I say that binary size is correlated to PID numbers?

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.

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.

Again, the discussion I was following was this:

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.)

[Akka]

Where did I say that binary size is correlated to PID numbers?

I quoted it..

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.

So now its a bad thing if you have processes that not PID 1?

[peppepz]

I quoted it..

No you didn't. The phrase you quoted has a different meaning in English and I've just explained it to you in other words.

So now its a bad thing if you have processes that not PID 1?

I think I've spammed this thread with my opinion about that quite enough already...