6 ms·

> This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without th

by exDM69 13y ago

> This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that tying, we already have (known, tested) tools that cover most of these features. This is the argument we've heard over and over again. The problem with traditional unix init scripts, together with cron, acpid, inetd, etc is that you need a big brittle mess of shell scripts to tie it all together to form a system that actually works. While the traditional approach may work alright for a static setup like a server that is booted once and stays on forever, it's not good enough for a desktop, laptop or mobile device. There may be changes in power (mains/battery/low power), network connectivity (ethernet, wifi, mobile) and connecting peripherals (including external disks) and lots of other things which need starting/stopping services or mounting/unmounting partitions. The amount of shell script glue to make these things work is unwieldy and doesn't really work that well. And distribution maintainers have to make a choice, supporting more than one init system is going to be a burden that will hurt end users in the long run. Finally, no one is forcing you to use a systemd based distribution. If OpenRC solves your problems, do go ahead and use Gentoo or another OpenRC based system.

synchronise 13y ago
You're forgetting the traction that OpenRC has gained in the past year, they have already implemented cgroup support and experimental process tracking and it's moving beyond simple shell scripts. It doesn't have feature parity with systemd, but it has portability and it's more permissively licensed, and factoring the speed of development I anticipate that it has a bright future ahead of it.
cynicalkane 13y ago
Not to devalue systemd, but I suspect that a lot of Unix problems could be solved if Unix offered a better general-purpose solution for gluing things together other than "big brittle masses of shell scripts". In particular, shell itself is an ugly mess of weird syntax, gotchas, and corner cases.
- CrLf 13y ago
  Granted, init-related scripts have become complex along the years, but we may argue that happened because of the same type of reasoning that's now justifying the move to systemd: the need to do everything in one place and automagically. You know, even if I would agree with you that "shell itself is an ugly mess of weird syntax, gotchas, and corner cases" that doesn't preclude init scripts from being redone in something other than shell. "People who don't understand unix are bound to reinvent it, badly." This has become the tag line for Linux, and unfortunately is starting to reach the previously sacred grounds of basic (server) infrastructure.
  - vidarh 13y ago
    The problem is not that they're shell scripts. The problem is that they are not constrained in a way that makes it possible to parse them easily and know what the state of the system is expected to be before and after processing. Instead you're forced to blindly execute them, and hope the script handles all the appropriate corner cases. In 20 years of maintaining Linux servers, it rarely goes more than days between situations where I come across init scripts that fails to account for some situation in ways that causes me aggravation. It's not uncommon to come across init scripts that regularly fails to stop a service because it has no proper way of determining which pid the process has, for example. Just the other day I had to deal with a server where the init scripts happily let 3 instances of a server process trying to operate on the same dataset; thankfully the app locked the files in questions and were just screeming bloody murder in its logs, but they were also all three competing for various resources. The init system of course had absolutely no way of telling that something had gone wrong. The only solution to have a sane server setup with SysV-init is to not use it for anything but the basic tasks and to start a proper process monitor. Then I'd rather just get rid of init entirely, since you're pulling in a bunch of other code that can do almost all of init's tasks anyway.
  - FooBarWidget 13y ago
    I argue that shell scripts became more complicated because of quite the opposite of what you're claiming. The original Bourne shell already supported, piping, control structures, etc. So people thought, hey, why design a new init system that does everything properly when we can just push all this logic to shell scripts and have them act as glue? It's the perfect example of "worse is better". They chose to keep the core init system simple, but as a result everything else became a complicated mess that doesn't handle corner cases properly. vidarh's comment is spot on.
CrLf 13y ago
"While the traditional approach may work alright for a static setup like a server that is booted once and stays on forever, it's not good enough for a desktop, laptop or mobile device." Sorry for sounding like a troll, but what you're saying is that the traditional approach works alright for setups where unix is actually good, and doesn't for setups where unix is actually crap. Lets exclude mobile devices from this picture (because those don't use general purpose Linux distributions and arguably don't use unix at all, but a unix-kernel with specialized - non-unix - userspace) and concentrate on servers and desktops/laptops... This systemd rage shows exactly why it's 2014 and while Linux is extensively used and trusted on the server side, it continues to limp along on peoples' desktops: it constantly reinvents the wheel (badly) with monolithic pieces of bloatware that are usually throw away tried-and-true solutions for unproven experiments. It throws away the old way of doing one thing and do it well in favor of components that do too much and become so complex that troubleshooting is a nightmare, exactly the kind of complaints we have about non-unix systems... Need an example? Where are the people that used to criticize the Windows registry now? I just recently almost(1) had to throw away my entire home dir on Ubuntu just to try and reset Kontact, because in this day and age the configuration structure of this stuff is far worse, and it's almost impossible to separate one component's configuration files and folders from everything else. And I'm not even going to start ranting about how in the name of $DEITY a mail/calendar application needs MySQL running in the background and about there is not a single decent mail client for Linux right now. Mail... a decades-old problem! I don't object to systemd itself, but I do object to systemd invading my servers that work just fine without it. (1) "Almost" because I just learned to live with the occasional crashes and misbehavior caused by some pieces of old configuration still lingering somewhere.
- hactually 13y ago
  > I don't object to systemd itself, but I do object to systemd invading my servers that work just fine without it. I think the Lennart and the Red Hat engineering team have more important things to do than covertly install systemd on your server. Please quit with the hyperbole.
  - theBlackDragon 13y ago
rodgerd 13y ago
> While the traditional approach may work alright for a static setup like a server that is booted once and stays on forever, Actually, it's not. Unless the server also has no dynamic resources and nothing in userland ever changes.
pdkl95 13y ago
I am not seeing any justification for why these tools HAVE to be a single, monolithic tool. > script glue That's what shell scripts[1] are FOR - they are the minimal glue that binds the large applications together. Besides, "big brittle mess" is a matter of opinion. Are you trying to tell me that this OpenRC script is a "mess" that needs to be replaced, taken from /etc/init.d/cupsd my current desktop: #!/sbin/runscript depend() { use net need dbus before nfs after logger } start() { ebegin "Starting cupsd" checkpath -q -d -m 0755 -o root:lp /run/cups checkpath -q -d -m 0511 -o lp:lpadmin /run/cups/certs start-stop-daemon --start --quiet --exec /usr/sbin/cupsd eend $? } stop() { ebegin "Stopping cupsd" start-stop-daemon --stop --quiet --exec /usr/sbin/cupsd eend $? } Yes, some scripts get much longer, because they have more complicated needs. Even in an alternate environment such as systemd, those will always be complicated. Things like changes in power or network addresses have been handled by OpenRC just fine (note: that was opinion, and systemd is better in some cases). More important,y those requirements do not suggest a need to bind tools together into one package, thoug; instead, they suggest a well-defined API* (or ABI) is needed. In OpenRC, that is simply another runlevel that you trigger on power-plug changes, etc. Your argument seems to be that the using many tools is too complex (even though each tool in isolation is much simpler, reduced in scope, and is likely to have fewer bugs), while tying that functionality together is faster to develop (despite makng the problems into a complex, interdependent mess). Despite being labeled an "april fools joke", RFC 1925 [2] has important wisdom. In particular, there seem to be a lot of people ignoring Truth #5: It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea. This is really a restatement of the UNIX design philosophy. Or maybe you're prefer this version, written by some old hackers you may have heard of[3] Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well. Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs, become general and useful tools. This idea about keeping problems separated was true when those guys wrote UNIX in the first place, it was true wen Dijkstra suggested structured programming instead of "goto", it was true when Alan Kay suggested sending Messages between Objects for yet more encapsulation, and countless other examples throughout the history of software. It is still true now. If you're having a hard time seeing this, I suggest you re-examine the problem and ask if an API could tie the pieces together, because it probably already exist in an unspecified form. > Finally, no one is forcing you to use a systemd based distribution. Of course not, but the monopolistic tactics being used to vertically integrate systemd IS forcing a problem - on purpose - with various other tools such as udev and gnome. I'm obviously going to stick to Gentoo for desktop use, but even there, the disruption caused by systemd has caused a significant mess by breaking previously-working software on purpose. -- 1: If this is merely a hatred of BourneShell/BASH, I would actually understand that as it certainly has its layers of cruft and gotcha/wtf behavior. A new Little Language[4] with special support so the standard "init script" support to make the scripts trivially small in general case could be really nice. 2: http://www.ietf.org/rfc/rfc3439.txt http://www.ietf.org/rfc/rfc3439.txt 3: Brian W. Kernighan, Rob Pike, "The UNIX Programming Environment" 4: http://c2.com/cgi/wiki?LittleLanguage http://c2.com/cgi/wiki?LittleLanguage

by exDM69 13y ago

synchronise 13y ago

You're forgetting the traction that OpenRC has gained in the past year, they have already implemented cgroup support and experimental process tracking and it's moving beyond simple shell scripts. It doesn't have feature parity with systemd, but it has portability and it's more permissively licensed, and factoring the speed of development I anticipate that it has a bright future ahead of it.

cynicalkane 13y ago

Not to devalue systemd, but I suspect that a lot of Unix problems could be solved if Unix offered a better general-purpose solution for gluing things together other than "big brittle masses of shell scripts". In particular, shell itself is an ugly mess of weird syntax, gotchas, and corner cases.

CrLf 13y ago
Granted, init-related scripts have become complex along the years, but we may argue that happened because of the same type of reasoning that's now justifying the move to systemd: the need to do everything in one place and automagically. You know, even if I would agree with you that "shell itself is an ugly mess of weird syntax, gotchas, and corner cases" that doesn't preclude init scripts from being redone in something other than shell. "People who don't understand unix are bound to reinvent it, badly." This has become the tag line for Linux, and unfortunately is starting to reach the previously sacred grounds of basic (server) infrastructure.
- vidarh 13y ago
  The problem is not that they're shell scripts. The problem is that they are not constrained in a way that makes it possible to parse them easily and know what the state of the system is expected to be before and after processing. Instead you're forced to blindly execute them, and hope the script handles all the appropriate corner cases. In 20 years of maintaining Linux servers, it rarely goes more than days between situations where I come across init scripts that fails to account for some situation in ways that causes me aggravation. It's not uncommon to come across init scripts that regularly fails to stop a service because it has no proper way of determining which pid the process has, for example. Just the other day I had to deal with a server where the init scripts happily let 3 instances of a server process trying to operate on the same dataset; thankfully the app locked the files in questions and were just screeming bloody murder in its logs, but they were also all three competing for various resources. The init system of course had absolutely no way of telling that something had gone wrong. The only solution to have a sane server setup with SysV-init is to not use it for anything but the basic tasks and to start a proper process monitor. Then I'd rather just get rid of init entirely, since you're pulling in a bunch of other code that can do almost all of init's tasks anyway.
- FooBarWidget 13y ago
  I argue that shell scripts became more complicated because of quite the opposite of what you're claiming. The original Bourne shell already supported, piping, control structures, etc. So people thought, hey, why design a new init system that does everything properly when we can just push all this logic to shell scripts and have them act as glue? It's the perfect example of "worse is better". They chose to keep the core init system simple, but as a result everything else became a complicated mess that doesn't handle corner cases properly. vidarh's comment is spot on.

CrLf 13y ago

"While the traditional approach may work alright for a static setup like a server that is booted once and stays on forever, it's not good enough for a desktop, laptop or mobile device." Sorry for sounding like a troll, but what you're saying is that the traditional approach works alright for setups where unix is actually good, and doesn't for setups where unix is actually crap. Lets exclude mobile devices from this picture (because those don't use general purpose Linux distributions and arguably don't use unix at all, but a unix-kernel with specialized - non-unix - userspace) and concentrate on servers and desktops/laptops... This systemd rage shows exactly why it's 2014 and while Linux is extensively used and trusted on the server side, it continues to limp along on peoples' desktops: it constantly reinvents the wheel (badly) with monolithic pieces of bloatware that are usually throw away tried-and-true solutions for unproven experiments. It throws away the old way of doing one thing and do it well in favor of components that do too much and become so complex that troubleshooting is a nightmare, exactly the kind of complaints we have about non-unix systems... Need an example? Where are the people that used to criticize the Windows registry now? I just recently almost(1) had to throw away my entire home dir on Ubuntu just to try and reset Kontact, because in this day and age the configuration structure of this stuff is far worse, and it's almost impossible to separate one component's configuration files and folders from everything else. And I'm not even going to start ranting about how in the name of $DEITY a mail/calendar application needs MySQL running in the background and about there is not a single decent mail client for Linux right now. Mail... a decades-old problem! I don't object to systemd itself, but I do object to systemd invading my servers that work just fine without it. (1) "Almost" because I just learned to live with the occasional crashes and misbehavior caused by some pieces of old configuration still lingering somewhere.

hactually 13y ago
> I don't object to systemd itself, but I do object to systemd invading my servers that work just fine without it. I think the Lennart and the Red Hat engineering team have more important things to do than covertly install systemd on your server. Please quit with the hyperbole.
- theBlackDragon 13y ago

rodgerd 13y ago

> While the traditional approach may work alright for a static setup like a server that is booted once and stays on forever, Actually, it's not. Unless the server also has no dynamic resources and nothing in userland ever changes.

pdkl95 13y ago

I am not seeing any justification for why these tools HAVE to be a single, monolithic tool. > script glue That's what shell scripts[1] are FOR - they are the minimal glue that binds the large applications together. Besides, "big brittle mess" is a matter of opinion. Are you trying to tell me that this OpenRC script is a "mess" that needs to be replaced, taken from /etc/init.d/cupsd my current desktop: #!/sbin/runscript depend() { use net need dbus before nfs after logger } start() { ebegin "Starting cupsd" checkpath -q -d -m 0755 -o root:lp /run/cups checkpath -q -d -m 0511 -o lp:lpadmin /run/cups/certs start-stop-daemon --start --quiet --exec /usr/sbin/cupsd eend $? } stop() { ebegin "Stopping cupsd" start-stop-daemon --stop --quiet --exec /usr/sbin/cupsd eend $? } Yes, some scripts get much longer, because they have more complicated needs. Even in an alternate environment such as systemd, those will always be complicated. Things like changes in power or network addresses have been handled by OpenRC just fine (note: that was opinion, and systemd is better in some cases). More important,y those requirements do not suggest a need to bind tools together into one package, thoug; instead, they suggest a well-defined API* (or ABI) is needed. In OpenRC, that is simply another runlevel that you trigger on power-plug changes, etc. Your argument seems to be that the using many tools is too complex (even though each tool in isolation is much simpler, reduced in scope, and is likely to have fewer bugs), while tying that functionality together is faster to develop (despite makng the problems into a complex, interdependent mess). Despite being labeled an "april fools joke", RFC 1925 [2] has important wisdom. In particular, there seem to be a lot of people ignoring Truth #5: It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea. This is really a restatement of the UNIX design philosophy. Or maybe you're prefer this version, written by some old hackers you may have heard of[3] Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well. Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs, become general and useful tools. This idea about keeping problems separated was true when those guys wrote UNIX in the first place, it was true wen Dijkstra suggested structured programming instead of "goto", it was true when Alan Kay suggested sending Messages between Objects for yet more encapsulation, and countless other examples throughout the history of software. It is still true now. If you're having a hard time seeing this, I suggest you re-examine the problem and ask if an API could tie the pieces together, because it probably already exist in an unspecified form. > Finally, no one is forcing you to use a systemd based distribution. Of course not, but the monopolistic tactics being used to vertically integrate systemd IS forcing a problem - on purpose - with various other tools such as udev and gnome. I'm obviously going to stick to Gentoo for desktop use, but even there, the disruption caused by systemd has caused a significant mess by breaking previously-working software on purpose. -- 1: If this is merely a hatred of BourneShell/BASH, I would actually understand that as it certainly has its layers of cruft and gotcha/wtf behavior. A new Little Language[4] with special support so the standard "init script" support to make the scripts trivially small in general case could be really nice. 2: http://www.ietf.org/rfc/rfc3439.txt http://www.ietf.org/rfc/rfc3439.txt 3: Brian W. Kernighan, Rob Pike, "The UNIX Programming Environment" 4: http://c2.com/cgi/wiki?LittleLanguage http://c2.com/cgi/wiki?LittleLanguage