3 ms·
If the problems with sysvinit are all imaginary then why has every other UNIX replaced it? Mac OS X has launchd for 10 years now. Solaris 10 replaced sysvinit
by the_why_of_y 12y ago
If the problems with sysvinit are all imaginary then
why has every other UNIX replaced it?
Mac OS X has launchd for 10 years now.
Solaris 10 replaced sysvinit with SMF.
Don't have any experience with AIX but the documentation
says it has a "System Resource Controller" with a
"srcmstr" daemon to manage services;
though it looks like it runs on top of something sysvinit-like:
http://www-01.ibm.com/support/knowledgecenter/ssw_aix_61/com.ibm.aix.osdevice/sysrescon.htm?lang=en http://www-01.ibm.com/support/knowledgecenter/ssw_aix_61/com...
BSDs have generally never used sysvinit, although they do have shell-based service management.
So actually none of the particular examples you cite
use purely sysvinit to manage services.
And it's also quite obvious that there are use-cases where reliable and fast service management are very important on servers.
One is containers, where you may run 10000 of them on a single host, and you have to reboot the host some time too, so you don't want to delay the start up of all those containers by loads of slow and racy shell scripts. Or even better, you want to have socket activated containers that don't actually start until they are needed.
https://www.getpantheon.com/blog/pantheon-running-over-500000-systemd-units https://www.getpantheon.com/blog/pantheon-running-over-50000...
Another is hyperscale servers: There are now really small ARM and x86 based servers and you can put 4-500 of those in a single rack. That means a lot more individual servers to admin, and failure modes that are relatively rare in current server rooms will become an order of magnitude less rare, so more robust OS level service management is helpful.
- julie1 12y agoProblem 0: Yes sysinit has problems but systemd brings even more problems (journalctl, PID 1, dependancy Hell ++, undeterministic bootup process) Systemd is a broken silver bullet for handling the decrease in quality of packaging. There are problems with sysinit: the first one is the missing link between devs and syadmins in companies: people known as packagers. For a sysinit to work well shell scripts, permissions, where resources are located, the dependency management has to be done with art and expertise. It is a human job with human which are: 1) a very skilled rare resource, 2) not identified has needed by companies, 3) company's software QA is shitty (it has barely the level it works for me (tm) of quality Talking about debian, which is considered the distribution with the most talented packagers debian has 2 flows in this domain: * too rigid: projects goes for logical units of packaging that are consistent and organization of assets in packages that can ease maintaining. Debian has its guideline that makes them «fix» poorly packaged softwares like lateX, python, ruby: cutting language distro in at least runtime, dev, extra. Debian packagers are often debian experts, not upstream software package experts and they first break some stuffs (latex is so poorly packaged on debian it can be considered broken), AND it adds more works * too much features typical linux distro compared to BSD are pacakging fucking more packages in their core resulting in more work; less attentions to the details and conflicts of functionality/overlaps. This result in more resource drained from the packagers. Like we have 4 shells considered OK for writing shell related stuff, when they have only one: «sh». The problem of linux vs BSD is symbolized by the systemd vs sysinit: linux is an OS of devops that are super devops, poor coders and sysadmins, BSD is an OS of sysadmins and devs that are good sysadmins and devs, but no devops. And we still lack in 2014 of maintainer, sysadmins and coders of quality. Linux/Gnome ... FSF projects are not sustainable in these conditions. They think of free software has an infinite resource of benevolence. And they exponentially overblow the works required for maintaining, deploying ... thus they are mathematically doomed to die under their own weight. I see BSD as a calvinist boring protestant community turned towards humility doing what is right and linuces as catholic exhuberant rockstars over spending the good will of developers without thinking of the future. Being lutherian, I still dream of THE right OS that would less terse than BSD.