Upstart Now Available In Debian Unstable

[LightBit]

You really should go read what the systemd commumity is doing. They are making boot so much simpler and tje truth is they are inspired by other unixy "friends" from Apple, not MS. The basic idea is spawnig as few processes as possible and do socket activation. Is is simple and clean, and as a side effect; damn fast! Thats for init.

Apple was inspired by MS, it even uses CamelCase. Unix-like OS-es never had problem spawning many processes and socket activation doesn't belong to init. If it's so simple, reimplement it in one month or even better make it POSIX.

[peppepz]

I'm probably speaking beyond my competence, here, but here goes:

I'm also incompetent, but nevertheless I've been successfully managing my own LFS installation since 1999, and I wholeheartedly agree to every word that you've said.

Upstart developers not having a messianic stance to have everyone in the world use their product is also a plus.

[funkSTAR]

Unix-like OS-es never had problem spawning many processes and socket activation doesn't belong to init. If it's so simple, reimplement it in one month or even better make it POSIX.

Wow. First systemd is bashed for being too complex, and now "UNIX" is immune to any complexity. This keeps getting better and better. What makes "UNIX" magic? Nothing. It is a now-dead 70s OS implementation(for a reason)!

One of the reasons Linux is getting its ass kicked is the abysmal kernel support for stuff that desktop user cares about; A kernel layer and init that just dont fuck up. The only way to keep it managable is keeping it fucking simple and enable a sane level of debugging. Systemd does that. There is no need to spawn shit about UNIX or POSIX compliance. users dont care.

[funkSTAR]

The only way to keep it managable is keeping it fucking simple and enable a sane level of debugging. Systemd does that.

And just to show how it is done. Canonicals skunkwork shit is nowhere near this level of achievement. Because they dont care unless it benefits Canonical. The same goes for the kernel.
https://plus.google.com/108087225644...ts/3AprGbCTfpS

Userland is stil uncharted land. Now Canonical starts blabbering about user session management in Upstart. Well maybe those guys should help fix the kernel layer first. THEY CHOSE NOT TO BECAUSE THEY DONT CARE. Now they want a piece of user land following their session stuff while the systemd guys have been holding back for at least 1 year because no hard systemd deps could be accepted by Canonical. Waiting one year on Canonical, and now they are on the verge to add user land deps on Upstart. How ridiculous!

[LightBit]

Wow. First systemd is bashed for being too complex, and now "UNIX" is immune to any complexity. This keeps getting better and better. What makes "UNIX" magic? Nothing. It is a now-dead 70s OS implementation(for a reason)!

So if you put everything into one process, like COMMAND.COM, it becomes simpler?
fork() is cheap and I said unix-like, not AT&T Bell Labs UNIX.

[LightBit]

And just to show how it is done. Canonicals skunkwork shit is nowhere near this level of achievement. Because they dont care unless it benefits Canonical. The same goes for the kernel.
https://plus.google.com/108087225644...ts/3AprGbCTfpS

Same as Red Hat's systemd.

Userland is stil uncharted land. Now Canonical starts blabbering about user session management in Upstart. Well maybe those guys should help fix the kernel layer first. THEY CHOSE NOT TO BECAUSE THEY DONT CARE.

Same as systemd does't care about POSIX.

Now they want a piece of user land following their session stuff while the systemd guys have been holding back for at least 1 year because no hard systemd deps could be accepted by Canonical. Waiting one year on Canonical, and now they are on the verge to add user land deps on Upstart. How ridiculous!

Great for sysvinit, because no one can add hard deps to userland.

[siban]

So if you put everything into one process, like COMMAND.COM, it becomes simpler?

systemd package contains the code for many different programs (including udev). The init daemon (/usr/lib/systemd/systemd) for version 196 is 888 kB size.

When everything is compiled you get these binaries:

hostnamectl
journalctl
localectl
loginctl
systemctl
systemd-analyze
systemd-ask-password
systemd-cat
systemd-cgls
systemd-cgtop
systemd-coredumpctl
systemd-delta
systemd-detect-virt
systemd-inhibit
systemd-machine-id-setup
systemd-notify
systemd-nspawn
systemd-stdio-bridge
systemd-tmpfiles
systemd-tty-ask-password-agent
timedatectl
udevadm
udevd

Which are normally located in the /usr/bin/ directory. So you see, systemd is not like COMMAND.COM

[siban]

Same as systemd does't care about POSIX.

systemd is a system and service manager for Linux, not for POSIX operating systems. If other UNIX-like operating systems want systemd, the need to port cgroups (which is in Linux since 2007).

If you don't like it... you know... don't use it.

[LightBit]

systemd package contains the code for many different programs (including udev).
The init daemon (/usr/lib/systemd/systemd) for version 196 is 888 kB size.

Is this supposed to be small?!
init should be less than 10kB statically linked to some bloat free library.

When everything is compiled you get these binaries:

hostnamectl
journalctl
localectl
loginctl
systemctl
systemd-analyze
systemd-ask-password
systemd-cat
systemd-cgls
systemd-cgtop
systemd-coredumpctl
systemd-delta
systemd-detect-virt
systemd-inhibit
systemd-machine-id-setup
systemd-notify
systemd-nspawn
systemd-stdio-bridge
systemd-tmpfiles
systemd-tty-ask-password-agent
timedatectl
udevadm
udevd

Which are normally located in the /usr/bin/ directory. So you see, systemd is not like COMMAND.COM

See what is inside core (pid 1): http://cgit.freedesktop.org/systemd/.../tree/src/core

[curaga]

systemd package contains the code for many different programs (including udev). The init daemon (/usr/lib/systemd/systemd) for version 196 is 888 kB size.
...
So you see, systemd is not like COMMAND.COM

888 kb !

You're making my, and his, point for us. That is _huge_. That's 850kb of code, all unnecessary, there to increase the chance of bugs disrupting the only task init should do.

My sysvinit is ~32kb, and that is a bit too big too.


So yes, that is exactly like command.com despite systemd having some commands split off.