5 ms·

Going against the "divide et impera" principle, "do just one thing, and do it well", "everything is a text file" (configurations and logs) and "pipes" which are

Going against the "divide et impera" principle, "do just one thing, and do it well", "everything is a text file" (configurations and logs) and "pipes" which are very natural idiom, in a UNIX-like system which has been built upon these principles, is just bad engineering, shallow understanding and, perhaps, too high ambitions of knowing better how to fix what isn't broken. The question why do we have this project and why there is such a buzz is more interesting. But the answers doesn't belong to realms of system design or engineering, they are in more obscure notions of "business strategies" and "sales techniques". It is a text-book example how to sell - "show them that they have a problem they didn't realize before, and give them the one and only fix". Fine. Except that the problem doesn't exist outside discussions of "why this product is good - it solves this and that". Another thing is that it is an excellent strategy to "create a niche for oneself". Look, we are the ones who give you a solution (to a problem which doesn't exist). We are "world leader" - look, we have lots of experts, web-presence, lines of code. There are so many examples in "parallel worlds", beginning with eco products or "fair-trade" coffee, you name it. But you see, lots of people don't need an eco or environmental-friendly daemon which does everything "the right way". No, thank you. Another thing, back to system design. If Windows has "registry" and there are millions copies of Windows everywhere, or Mac has that settings daemon (from which GNOME Gsettings has been copied) it doesn't mean that these design decisions are superior to plain old text configs. You could compile them and have an "intermediate storage" to gain a 5% more efficiency for application startup times, but this is, again, not a fundamental problem. Being able to use regular expressions on configuration and logs without any restriction are much more fundamental. And memorizig all the details of all these xxxxctl insted of saying something like $ grep -R ^sysctl /etc or whatever I need, is just an additional unnecessary burden. Most of the problems systemd is trying to "solve" does not exist. At least not BSD, AIX, Solaris, you name it. And, of course, there never been any problem with syslog, init or cron. They were *good-enough".

e12e 12y ago
I don't support a switch to systemd at this time (I use Debian, and I'd be happy to live with pretty much any other init system for at least one more release - the obvious choice would be to just stick to systemV init, and see what systemd looks like in a year or so. Down side is that if the distro were to move (for supporting all those people that want Gnome for some reason ;-) -- then we loose out on a year or two of testing systemd). Anyway: > Most of the problems systemd is trying to "solve" does not exist. At least not BSD, AIX, Solaris, you name it. Don't forget that (open) Solaris revamped the init system, not just the disk/filesystem-system. I think there are arguments to be made for integrated systems like the zones/zfs/SMF. I don't think systemd is a reasonable way to go about it, and I certainly don't think it is a good fit for "Linux in general". My impression is: Systemd is too big -- will fail. Wasn't it Gnome that at one time tried to mimic the windows registry for settings (because binary data on disk: really fast, lol) -- only to go back to ini-style files? (I might be misremembering that one). Different designs are fine (see: eg plan9) -- but moving away from fundamental design principles (everything is a (text) file) effectively means abandoning the old system, making a new system. If systemd was a bit more upfront about "making a new operating system sharing some code with Linux kernel and traditional userland" - rather than trying to sell systemd as "more of the same, just better" -- maybe they'd meet with more positive reception. That a new system is unstable is fine -- just don't expect people to use your new crap in production.
RubyPinch 12y ago
> Except that the problem doesn't exist outside discussions of except https://en.wikipedia.org/wiki/Init#Replacements_for_init https://en.wikipedia.org/wiki/Init#Replacements_for_init this problem was noticed and was trying to be fixed for a long time, by a lot of people
- dschiptsov 12y ago
  Traditionally, one of the major drawbacks of init is that it starts tasks serially, waiting for each to finish loading before moving on to the next. When startup processes end up I/O blocked, this can result in long delays during boot. For a server it doesn't matter, leave alone "broken". long delays during boot is grossly exaggerated, because delays are mostly due to network errors/timeouts or file-system checks, but you can do almost nothing "in parallel" without clean FS or configured network interface. Well, for some Ubuntu for mobile devices they could have adapt some "optimized" sysvinit-scripts (not /sbin/init) replacement, but, please, don't tell us that everyone needs this. Leave servers and home workstations alone.
  - RubyPinch 12y ago
    it matters with servers too, billing-per-hour/minute/second etc and my point was there has been a whole bunch of prior attempts at changing init, each one of those had issue with the pre-existing systems. I am not telling you that everyone needs it, or that its broken. I'm telling you that the issues didn't suddenly exist just because systemd
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 ago
  Problem 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.

e12e 12y ago

I don't support a switch to systemd at this time (I use Debian, and I'd be happy to live with pretty much any other init system for at least one more release - the obvious choice would be to just stick to systemV init, and see what systemd looks like in a year or so. Down side is that if the distro were to move (for supporting all those people that want Gnome for some reason ;-) -- then we loose out on a year or two of testing systemd). Anyway: > Most of the problems systemd is trying to "solve" does not exist. At least not BSD, AIX, Solaris, you name it. Don't forget that (open) Solaris revamped the init system, not just the disk/filesystem-system. I think there are arguments to be made for integrated systems like the zones/zfs/SMF. I don't think systemd is a reasonable way to go about it, and I certainly don't think it is a good fit for "Linux in general". My impression is: Systemd is too big -- will fail. Wasn't it Gnome that at one time tried to mimic the windows registry for settings (because binary data on disk: really fast, lol) -- only to go back to ini-style files? (I might be misremembering that one). Different designs are fine (see: eg plan9) -- but moving away from fundamental design principles (everything is a (text) file) effectively means abandoning the old system, making a new system. If systemd was a bit more upfront about "making a new operating system sharing some code with Linux kernel and traditional userland" - rather than trying to sell systemd as "more of the same, just better" -- maybe they'd meet with more positive reception. That a new system is unstable is fine -- just don't expect people to use your new crap in production.

RubyPinch 12y ago

> Except that the problem doesn't exist outside discussions of except https://en.wikipedia.org/wiki/Init#Replacements_for_init https://en.wikipedia.org/wiki/Init#Replacements_for_init this problem was noticed and was trying to be fixed for a long time, by a lot of people

dschiptsov 12y ago
Traditionally, one of the major drawbacks of init is that it starts tasks serially, waiting for each to finish loading before moving on to the next. When startup processes end up I/O blocked, this can result in long delays during boot. For a server it doesn't matter, leave alone "broken". long delays during boot is grossly exaggerated, because delays are mostly due to network errors/timeouts or file-system checks, but you can do almost nothing "in parallel" without clean FS or configured network interface. Well, for some Ubuntu for mobile devices they could have adapt some "optimized" sysvinit-scripts (not /sbin/init) replacement, but, please, don't tell us that everyone needs this. Leave servers and home workstations alone.
- RubyPinch 12y ago
  it matters with servers too, billing-per-hour/minute/second etc and my point was there has been a whole bunch of prior attempts at changing init, each one of those had issue with the pre-existing systems. I am not telling you that everyone needs it, or that its broken. I'm telling you that the issues didn't suddenly exist just because systemd

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 ago
Problem 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.