Originally posted by LightBit
View Post
Announcement
Collapse
No announcement yet.
Upstart Now Available In Debian Unstable
Collapse
X
-
Originally posted by kigurai View PostIf sysvinit is the only really good choice to couple with OpenRC, why would I want that instead of just running sysvinit directly? Genuine question, because I haven't used gentoo in a long time, and never heard of OpenRC. But to me, it sounds a bit hypocritical to bash systemd for "unused code" while championing an init system that sits on top of another init system...
Also, the "more code = more bugs" is a rule of thumb, not some kind of law. As you are probably aware there are some really stable pieces of hardware with milions of lines of code (Linux kernel, to take one relevant example), and lots of very small applications that are riddled with bugs.
If systemd crashed substantially more than sysvinit I suppose you could have a point. I have not seen anything that hints about that.
The main innovations of OpenRC are the creation of named runlevels and full dependency handling. The numbered runlevels of sysvinit were an attempt at handling dependencies, but they sequentialize the boot process and are unable to handle complex dependency chains. OpenRC's calculation of the dependency graph eliminates such limitations. It is also written in C, so there is not much overhead in the calculation.
Originally posted by funkSTAR View PostFSF is a non-commercial org caring deeply about software freedom.They want CA to maximize legal protection for the licensed code. Canonical is just a RH competitor seeking an advantage. They dont want CA to keep the code open and protect it. Canonical want the copyrigtht so they can do whatever skunkwork they need. This includes distrobuting closed source editions. And yes Canonical KNOWS the CAing will keep RH out of the loop. They are causing fragmentation without any regrets.
Upstart: CA, low canonical investment, no community.
Systemd: no CA, high RH investment, much larger community.
Systemd is already way ahead based on technical merits. Based on metrics like keeping the source code on free license and building communities systemd is your pick.
So in order to follow your PurgePoettering agenda you have to accept less features, less freedom and less community. Only a suffering hater can do something this stupid. I hope you will get well by time. God bless you.
Anyway, systemd is full of severe reliability regressions that I do not want on my system. I am currently fixing a regression that can cause udevd to enter d-state permanently. It will cripple the system boot process in certain situations. eudev inherited it from systemd. Anyone who asks me for details will be told to ask again after our first tag. I have adopted the Sun Microsystems approach to collaboration (i.e. code drops) for reliability bugs introduced by systemd in response to abuse from Lennart Poettering and Kay Sievers. You can thank them for that.Last edited by ryao; 01 December 2012, 07:09 PM.
Comment
-
Originally posted by funkSTAR View PostSo in order to follow your PurgePoettering agenda you have to accept less features, less freedom and less community.
Originally posted by ryao View PostBoth the FSF and Canonical require copyright assignment.
Comment
-
Originally posted by siban View Postsystemd package contains the code for many different programs (including udev).
hostnamectl journalctl localectl loginctl systemctl systemd systemd-ac-power systemd-analyze systemd-ask-password
systemd-binfmt systemd-cat systemd-cgls systemd-cgroups-agent systemd-cgtop systemd-coredump systemd-coredumpctl
systemd-delta systemd-detect-virt systemd-fsck systemd-hostnamed systemd-inhibit systemd-initctl systemd-journald
systemd-journal-gatewayd systemd-localed systemd-logind systemd-machine-id-setup systemd-modules-load systemd-multi-seat-x
systemd-notify systemd-nspawn systemd-quotacheck systemd-random-seed systemd-readahead systemd-remount-fs
systemd-reply-password systemd-shutdown systemd-shutdownd systemd-sleep systemd-stdio-bridge systemd-sysctl
systemd-timedated systemd-timestamp systemd-tmpfiles systemd-tty-ask-password-agent systemd-udevd systemd-update-utmp
systemd-user-sessions systemd-vconsole-setup timedatectl udevadm
halt init init-checkconf initctl initctl2dot poweroff reboot reload restart runlevel shutdown start status stop telinit
upstart-socket-bridge upstart-udev-bridge
And we're talking only about the binaries, not all stuff such as support libraries and configuration files. In total, the systemd installation image touches 621 files and 93 directories. Upstart touches 44 files and 18 directories.
Now in all honesty, looking at the complexity of the two packages, and supposing that I don't need systemd's additional features, because I'm fine with syslog and inetd, when managing my system, am I more likely to need external help when I'm using systemd, or when I'm using upstart?
Oh, and since people keep making silly comparisons such as counting the number of PIDs used,
Code:$ size init text data bss dec hex filename 221392 1948 136 223476 368f4 init
Code:$ size systemd text data bss dec hex filename 884496 54692 2424 941612 e5e2c systemd
Comment
-
Originally posted by peppepz View PostOh, and since people keep making silly comparisons such as counting the number of PIDs used,
Code:$ size init text data bss dec hex filename 221392 1948 136 223476 368f4 init
Code:$ size systemd text data bss dec hex filename 884496 54692 2424 941612 e5e2c systemd
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.
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?
Comment
-
Originally posted by Akka View PostAs 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.
Originally posted by Akka View PostAs 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?
Comment
-
Originally posted by LightBit View Postpeppepz compared size of init part only.
Yes, udev. It was separate package before, but systemd devs "stole" it.
.Last edited by Akka; 02 December 2012, 02:53 PM.
Comment
-
Originally posted by droste View PostHow did "the systemd devs" (who?) steal it? Do you have sources for such a claim?
Comment
-
Originally posted by LightBit View PostThey didn't actually stole it. Kay Sievers is systemd dev and he was also udev maintainer. http://lwn.net/Articles/490413/
Comment
Comment