Please show a link to the Tomecat init script you are talking about, because I was unable to found a ready to use init script in the Tomecat source code repository. I confess that did't spend a long time searching it, but since you seem to known well Tomecat (unlike me) you should find it quickly.
Unfortunately the initscripts are mostly distribution specific and lack a good standardization. See the nginx example to illustrate the problem: http://wiki.nginx.org/InitScri...
The systemd infrastructure provides features that don't exists initscripts, so yes there have a bit more coupling than initscripts, but since the features list is not the same, the comparison is biased . If you have a better architecture to propose to provides the same set of features, please show your talent.
Debian package dependencies will show you that initscripts depend on sysv-rc (or file-rc) to boot the machine. Without sysv-rc, initscripts are just simple scripts that will not magically run at the boot of your machine.
If a kernel provides the features required by systemd, aside of a compatibility layer, what could technically prevent systemd to run on an other platform? Maybe the lack of motivation, ok, but from the technical point of view?
http://man7.org/linux/man-page... I let you the joy to click on each link and to read the "CONFORMING TO" section to count how many time you find the indication "Linux specific". Just a few of them as example: pivot_root, ppoll, remap_file_pages, removexattr, restart_syscall, timerfd_create, futex.
The fact that the initscripts package depend on sysv-rc package was true since squeeze and unfortunately for your claim, systemd is packaged into Debian only since wheezy, about two years later.
The cause was due to an other player: https://packages.debian.org/sq... Before upstart the order of the dependency was not important. The error in the order was only evident when the new player 'upstart' was able to replace sysvinit (unlike file-rc).
No, this is really initscripts that depend on something to make your machine boot. This other thing can be sysv-rc, file-rc or even systemd. sysv-rc, file-rc or event systemd without any unit file will not boot your machine to any useful state.
The point is that if you choose to use systemd units you depend on systemd to start them at boot, exactly the same way that if you choose to use initscripts you depend on sysv-rc or something like this to start the scripts at boot.
Take a look at the initscripts Debian package dependencies: https://packages.debian.org/si... Really, this is initscripts that depend on sysv-rc and not the other way around. This is pure logic.
Please, Ô master of the understanding, please explain to our poor brains your various reason why we are do dumb. Please, just plain verified facts that we can reproduce.
Given the number of security fixes that have affected the various venerable UNIX tools since do many decades, and the number of competitive UNIX projects with different architectures over the time, I am really not convinced that UNIX is so better at "writing good code". A big and motivated open source community is a way to help a project getting code with improved quality. But just UNIX, I don't think so.
Note that initscripts lovers can still wrote a simple systemd service file to lunch sysv-rc and all the initscripts it if there like doing that way after the removing of the sysvinit compatibility. There can even disable all the systemd services but the one that lunch sysv-rc to get back there precious initscripts.
There will simply be no more maintainers taking care of the initscripts coherency in the long term. I am curious to see how the initscrips fans will reach a consensus to replace them.
And what is precisely the point to have a initscript running outside sysv-rc + sysvinit? To have a simple script running? Whoow! Such a great feature.... Seriously, did you think that a machine running systemd is not able to run a simple script? The reality is that initscripts need sysv-rc to boot the machine.
By the way, systemd is compatible with sysv-rc so what are you complaining about ?
You can try to make your system as complex as you want and since systemd is sysvinit compatible, it will not even stop you doing so.
Outside of sysv-rc and initsctips mess, UNIX is to a vast majority a collection of binary executables, especially regarding the admin commands. Just do a "file/bin/*/sbin/*" to verify this fact.
The whole initscripts mess will not work outside the sysv-rc + sysvinit infrastructure too.
Others platforms only have to add the required syscalls to get systemd, or a why to get the same kind of functionality. Linux has added new specific syscalls since very long time, nothing new on this subject.
Transposed to sysvinit this question don't make any sense either: "And how many of sysvinit scripts are dependent on other sysvinit scripts or multiple others sysvinit scripts for functionality or require the init PID 1 ?"
The multiples systemd-* executables don't have direct dependencies outside the fact that the system need to arrive at some state to be able to start some applications that depend on that state, exactly like sysvint. The systemd allow you to choose exactly the services you want to execute or not.
Systemd is a collection of small executables each with a precise goal, in line with the UNIX philosophy. Do a "ls -alSrh/lib/systemd/systemd-*/usr/bin/systemd-*" if you want to verify this fact.
I remember that in 1996 the pilot of a FBW aircraft has say that one computer displayed an error, then there restarted the computer and the error was not displayed again, so all is nominal and we can go. He didn't detailed the error displayed. Maybe this was minor, maybe not. The 6 hours fly was without any problem.
I have read you, and I have not used the word "server" in the context of this "4 admins more" paragraph. I have perfectly understand that you are talking about your users that you fail to convince to use BSD as you fail to convince me to use BSD. Despite all your angry comments about Linux and systemd, at some point you should have to agree that actual Linux distribution bring a more usable system for for more users than BSD. Wherever you dislike this situation will change absolutely nothing.
You can use shell scripts to automate your work if you like and use systemd commands into your scripts without any problems. The point is that systemd don't require scripts to work and is not based on scripts, as for the large majority of commands used for basic administration. You can keep trying to avoid to recognize the reality of the facts by just saying that I an idiot or ignorant., this again and again does not change the facts.
Yes systemd provides benefits to the users. What I have say id that systemd don't remove power to the users.
No, you have not make clear what real and factual problem systemd might have for your. You have show a poor knowledge of what systemd really is actually and you react with far too much emotions to be able to generate a simple list of facts.
4 more admins to support the same workload on the BSD box compared to a Linux box? Not really efficient. I understand why Linux make you so angry...
If you like definition: http://en.wikipedia.org/wiki/A... Clearly restarting a services take less time than a reboot, and a crash that require a manual reset is the work case. If you reboot like you like to do, the fact that the machine is idle or full loaded will change nothing. You still fail to provides real facts that explain why you find Linux so inferior compared to BSD.
You have say many time that BSD is superior to Linux (by order of magnitude), but you allay failed to prove your claim. Now you are spanning the time and includes private use into the context. Just saying that something is crap is not going to convince anyone, especially if after so many messages you are still incapable to details a single factual example.
What prevent you to do the same security management on Linux as you do on BSD? This do not depend on the OS, nor on systemd / sysvinit. A libc security fix very rarely affect the security of all the processes in a system. Free to you to degrade the availability of the servers by rebooting them if you want, but again this has nothing to do with Linux or systemd. And for your knowledge: Debian and Ubuntu automatically restart systemd/sysvinit in case of libc upgrade (and the services listed as affected). It's not a mental challenge to verify this fact. The procedure you describes seem to imply that netBSD is not able to do the same.
Yes this is a success because multiples devices was tested across very different operating conditions transitions, and systemd not only did fully work as expected, but this was a pleasure to operate remotely since all the status and management are more simple and coherent than with sysvinit. I named all the custom applications with the same prefix, so a simple 'systemctl status prefix*' show everything at once.
You still show irrational stress about systemd. The reality is that all majors distributions have adopted it, so yes it will go into embedded systems, and yes it will go into aerospace environment over time but certainly not into critical grade application (nor sysvinit anyway).
The fact that a sysadmin use a shell command interpreter did not imply that the command he call are shell script. I think that I have show enough prove that shell scripts are not as essential outside of system V init as you used to claim. Now, this don't prevent anyone to use a shell to get a CLI and to write some scripts if he like to do so. You seem to forget that the maintainers decision to switch to systemd is not to remove power to the users, but to make the maintainers work more easy and reliable across multiples systems. I never stated that sysadmin should be forced to use GUI, and projects like systemd or NetworkManaged take care to provides very good CLI, so I don't understand how stressed you are about the systemd architecture.
About the comparison between Linux and BSD kernel, you still failed to explain why your BSD boxes can't do the work you are so angry to run on Linux boxes. At some point you have to admit that the Linux box do something that your BSD boxes can't do. You never explain the part of the Linux kernel that cause the supposed crash, and I am very curious about this because triggering a kernel crash is usually not so easy.
A reboot for a upgrade will not affect to much the availability because it only affect the users for a minute or so, contrary to a stability problem like crash that could affect the users as long as someone take to reset the machine. So I think we can at least agree that the upgrade on Linux is no affecting your operation more that your BSD boxes. It you really have a particular problem with your Linux boxes, than must be something as severe as a kernel crash, not because of upgrade. And if you can really crash a up-to-date Linux kernel so often, then you must see a clear pattern of the subsystem that cause the crash.
Restarting services take less time than rebooting (especially with systemd), this is less risky on a remote machine, and this affect the availability far less than a reboot because many services are capable to handle restart very fast, and others services are unaffected. In industrial systems there are situation where we just want to upgrade some part of the system while still let running others realtime parts unaffected. You might be in a context where you can just reboot, but there exists others contexts with more constrains than in your environment. You can ignore this fact, as you can continue to insult me, this will simply change nothing to the reality of the facts. And no, our company don't charge per hour.
I would be more than happy to design any futures systems with systemd into it. I delivered my first design with systemd last week and given the success I see no reason to go backward. A mission/life critical aerospace system with not use a Linux kernel anyway. But for less critical functions, even in aerospace, this could done. In fact there is already exists systems running Linux in aerospace environment, it's not hard to find on the internet.
And 17 of them are perl scripts. The rest are mostly not so used commands. So I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts.
I mentioned busybox to show that binary commands is enough to admin a box (outside of system V init), not about a supposed busybox GUI.
I have see a lot of Linux boxes with load like the one you describes on your BSD box, this is not impressive at all. Now, did your Linux kernel really crash ? I understand that you reboot for each libc or kernel update, this is your choice, but certainly not a stability problem.
About the libc update, you might find more simple to just reboot, but again this is your choice, not a stability problem. Now in case of libc upgrade, how did you do with your BSD boxes ? Or the BSD libc is so perfect that no upgrade is required ? Hint: https://www.freebsd.org/securi...
You call me ridicule, but I largely prefer restarting some services on a remote machine., and even more when the machine also act as a NFS server, or a router, or a firewall, or have virtual machines. It's a choice, and I will not call you ridicule for your own choice.
If you are so conservative to reboot each boxes as soon as a libc or kernel upgrade exists, then I wonder how your BSD boxes could have uptime a "few orders of magnitude less shitty".
I do tests on the system I deliver, and my customers do tests too, I just say that this is tests not usually done in the cycle of a kernel release [by the kernel maintainers] (last part added for you understanding).
You can't usually buy the systems we design as there are not for consumers. What I can tell you is that we have build systems where conformity to part of aerospace, or railway, or automotive, or civil engineering standards are required. Nothing highly critical, but still with a good chunk of audit and conformity tests. Customers are happy enough with our work to allow, to setup our own company 4 years ago.
But I would like to remain you the this discussion is about the fact hat Ubuntu has released his first version with systemd:-)
I understand that you find the GUI-only Linux ubuntu's goal pointless, but at the same time I read that you have many users asking for precisely this kind of systems. While your are doing the admin work instead of them within the company, it's logical that those peoples will select a distribution with GUI outside of the company related work. After all when those people use a smartphone, a router or a TV, all potentially running Linux, there don't expect to see anything other than GUI.
If we talk about the admin work, it's not fair to count/usr/*. On a typical Debian Jessie I have: file/bin/*/sbin/* | egrep ELF | wc -l 233 file/bin/*/sbin/* | egrep script | wc -l 36 And a majority of the scripts are just to make usual commands work on compressed files. So I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts. Far from that actually, and to push this to the limit, just look at the busybox project. I have not verified, but I suspect that a machine with systemd and busybox could be close the be usable for simple tasks without any shell interpreter. Actually I think there is still some binary that expect a shell evaluation at some point, but this is probably doable to work around them.
But as you have noticed, using command on a shell don't imply shell script. The NetworkManager project for example is split into different parts, essentially: 1) the daemon, 2) the CLI, 3) the GUI. This allow to make some clean implementation not related to the preference of the user/admin regarding the CLI or GUI. This also help to make the GUI a relatively simple project that only query data, display them, allow fill form and send them. With this kind of project, you can use CLI and script if you want, as you can use GUI if you want. The trend is to apply this design to more and more parts of the systems, and systemd is a way to go forward in that direction. Personally I would like to also see a Web and SQL interfaces for all of those parts as this is basically what my customers are asking for.
If I understand you correctly your BSD boxs don't run the same kind of applications as the Linux box, so it's not fair to compare the stability of a GUI application by the kernel or distribution where it is executed. You don't have to reboot to update the libc and you are free to decide if you like to update you kernel depending on the risk that apply to your situation. BSD kernel are released less often it seem, this don't make it less buggy as your RAID experience has show, but simply a consequence that his community of developers is smaller than Linux.. I really wonder what you can find so unstable in the Linux kernel because it's rock stable for me even on embedded systems where the workload and driver set is quite different to anything usually tested in the cycle of a kernel release.
I once watched a talk from a leading LibreOffice maintainer. I remember how happy it was with the progress of LibreOffice compared to OpenOffice. He explained that it was hard for external contributors to get patches accepted on OpenOffice. LibreOffice unlocked the situation.
Slashdot Mirror
Ô master of the understanding, please explain to our poor brains what rules listed in the link of your holly signatures are so blasphemed by systemd.
Please show a link to the Tomecat init script you are talking about, because I was unable to found a ready to use init script in the Tomecat source code repository. I confess that did't spend a long time searching it, but since you seem to known well Tomecat (unlike me) you should find it quickly.
Unfortunately the initscripts are mostly distribution specific and lack a good standardization. See the nginx example to illustrate the problem: http://wiki.nginx.org/InitScri...
The systemd infrastructure provides features that don't exists initscripts, so yes there have a bit more coupling than initscripts, but since the features list is not the same, the comparison is biased . If you have a better architecture to propose to provides the same set of features, please show your talent.
And now guess what project the script you're trying to make look like a separate project belongs to?
Tell me.
On what part did you need a prof ?
Debian package dependencies will show you that initscripts depend on sysv-rc (or file-rc) to boot the machine. Without sysv-rc, initscripts are just simple scripts that will not magically run at the boot of your machine.
If a kernel provides the features required by systemd, aside of a compatibility layer, what could technically prevent systemd to run on an other platform? Maybe the lack of motivation, ok, but from the technical point of view?
http://man7.org/linux/man-page...
I let you the joy to click on each link and to read the "CONFORMING TO" section to count how many time you find the indication "Linux specific". Just a few of them as example: pivot_root, ppoll, remap_file_pages, removexattr, restart_syscall, timerfd_create, futex.
The fact that the initscripts package depend on sysv-rc package was true since squeeze and unfortunately for your claim, systemd is packaged into Debian only since wheezy, about two years later.
https://packages.debian.org/sq...
https://packages.debian.org/wh...
The cause was due to an other player: https://packages.debian.org/sq... Before upstart the order of the dependency was not important. The error in the order was only evident when the new player 'upstart' was able to replace sysvinit (unlike file-rc).
No, this is really initscripts that depend on something to make your machine boot. This other thing can be sysv-rc, file-rc or even systemd. sysv-rc, file-rc or event systemd without any unit file will not boot your machine to any useful state.
The point is that if you choose to use systemd units you depend on systemd to start them at boot, exactly the same way that if you choose to use initscripts you depend on sysv-rc or something like this to start the scripts at boot.
Take a look at the initscripts Debian package dependencies:
https://packages.debian.org/si...
Really, this is initscripts that depend on sysv-rc and not the other way around. This is pure logic.
Please, Ô master of the understanding, please explain to our poor brains your various reason why we are do dumb. Please, just plain verified facts that we can reproduce.
Given the number of security fixes that have affected the various venerable UNIX tools since do many decades, and the number of competitive UNIX projects with different architectures over the time, I am really not convinced that UNIX is so better at "writing good code". A big and motivated open source community is a way to help a project getting code with improved quality. But just UNIX, I don't think so.
Note that initscripts lovers can still wrote a simple systemd service file to lunch sysv-rc and all the initscripts it if there like doing that way after the removing of the sysvinit compatibility. There can even disable all the systemd services but the one that lunch sysv-rc to get back there precious initscripts.
There will simply be no more maintainers taking care of the initscripts coherency in the long term. I am curious to see how the initscrips fans will reach a consensus to replace them.
(wtf is sytem V rc?)
LOL! I am certain to remember this joke even in a decade :-)
Without sysv-rc your machine will simply not execute any of your initscripts at boot! Try to remove it if you don't believe (and good bye by the way).
Can't stop laughing....
:-D
The idea is to push them to prove there claims, just to see where are there limits regarding real facts.
And yes you are right, the defense pattern is mostly the same each time.
What did I not read correctly ?
And what is precisely the point to have a initscript running outside sysv-rc + sysvinit? To have a simple script running? Whoow! Such a great feature.... Seriously, did you think that a machine running systemd is not able to run a simple script? The reality is that initscripts need sysv-rc to boot the machine.
By the way, systemd is compatible with sysv-rc so what are you complaining about ?
This is simply true:
https://packages.debian.org/si...
"dep: sysv-rc"
There a so dependent that there are from the same source package:
https://packages.debian.org/so...
You can try to make your system as complex as you want and since systemd is sysvinit compatible, it will not even stop you doing so.
Outside of sysv-rc and initsctips mess, UNIX is to a vast majority a collection of binary executables, especially regarding the admin commands. Just do a "file /bin/* /sbin/*" to verify this fact.
The whole initscripts mess will not work outside the sysv-rc + sysvinit infrastructure too.
Others platforms only have to add the required syscalls to get systemd, or a why to get the same kind of functionality. Linux has added new specific syscalls since very long time, nothing new on this subject.
"How many initscripts depend on sysv-rc ?"
- Try "all of them"
Strange question.
Transposed to sysvinit this question don't make any sense either:
"And how many of sysvinit scripts are dependent on other sysvinit scripts or multiple others sysvinit scripts for functionality or require the init PID 1 ?"
The multiples systemd-* executables don't have direct dependencies outside the fact that the system need to arrive at some state to be able to start some applications that depend on that state, exactly like sysvint. The systemd allow you to choose exactly the services you want to execute or not.
Systemd is a collection of small executables each with a precise goal, in line with the UNIX philosophy. /lib/systemd/systemd-* /usr/bin/systemd-*" if you want to verify this fact.
Do a "ls -alSrh
I remember that in 1996 the pilot of a FBW aircraft has say that one computer displayed an error, then there restarted the computer and the error was not displayed again, so all is nominal and we can go. He didn't detailed the error displayed. Maybe this was minor, maybe not. The 6 hours fly was without any problem.
I have read you, and I have not used the word "server" in the context of this "4 admins more" paragraph. I have perfectly understand that you are talking about your users that you fail to convince to use BSD as you fail to convince me to use BSD. Despite all your angry comments about Linux and systemd, at some point you should have to agree that actual Linux distribution bring a more usable system for for more users than BSD. Wherever you dislike this situation will change absolutely nothing.
Easy escape of all others point?
You can use shell scripts to automate your work if you like and use systemd commands into your scripts without any problems. The point is that systemd don't require scripts to work and is not based on scripts, as for the large majority of commands used for basic administration. You can keep trying to avoid to recognize the reality of the facts by just saying that I an idiot or ignorant., this again and again does not change the facts.
Yes systemd provides benefits to the users. What I have say id that systemd don't remove power to the users.
No, you have not make clear what real and factual problem systemd might have for your. You have show a poor knowledge of what systemd really is actually and you react with far too much emotions to be able to generate a simple list of facts.
4 more admins to support the same workload on the BSD box compared to a Linux box? Not really efficient. I understand why Linux make you so angry...
If you like definition: http://en.wikipedia.org/wiki/A... Clearly restarting a services take less time than a reboot, and a crash that require a manual reset is the work case. If you reboot like you like to do, the fact that the machine is idle or full loaded will change nothing. You still fail to provides real facts that explain why you find Linux so inferior compared to BSD.
You have say many time that BSD is superior to Linux (by order of magnitude), but you allay failed to prove your claim. Now you are spanning the time and includes private use into the context. Just saying that something is crap is not going to convince anyone, especially if after so many messages you are still incapable to details a single factual example.
What prevent you to do the same security management on Linux as you do on BSD? This do not depend on the OS, nor on systemd / sysvinit. A libc security fix very rarely affect the security of all the processes in a system. Free to you to degrade the availability of the servers by rebooting them if you want, but again this has nothing to do with Linux or systemd. And for your knowledge: Debian and Ubuntu automatically restart systemd/sysvinit in case of libc upgrade (and the services listed as affected). It's not a mental challenge to verify this fact. The procedure you describes seem to imply that netBSD is not able to do the same.
Yes this is a success because multiples devices was tested across very different operating conditions transitions, and systemd not only did fully work as expected, but this was a pleasure to operate remotely since all the status and management are more simple and coherent than with sysvinit. I named all the custom applications with the same prefix, so a simple 'systemctl status prefix*' show everything at once.
You still show irrational stress about systemd. The reality is that all majors distributions have adopted it, so yes it will go into embedded systems, and yes it will go into aerospace environment over time but certainly not into critical grade application (nor sysvinit anyway).
Bye,
The fact that a sysadmin use a shell command interpreter did not imply that the command he call are shell script. I think that I have show enough prove that shell scripts are not as essential outside of system V init as you used to claim. Now, this don't prevent anyone to use a shell to get a CLI and to write some scripts if he like to do so. You seem to forget that the maintainers decision to switch to systemd is not to remove power to the users, but to make the maintainers work more easy and reliable across multiples systems. I never stated that sysadmin should be forced to use GUI, and projects like systemd or NetworkManaged take care to provides very good CLI, so I don't understand how stressed you are about the systemd architecture.
About the comparison between Linux and BSD kernel, you still failed to explain why your BSD boxes can't do the work you are so angry to run on Linux boxes. At some point you have to admit that the Linux box do something that your BSD boxes can't do. You never explain the part of the Linux kernel that cause the supposed crash, and I am very curious about this because triggering a kernel crash is usually not so easy.
A reboot for a upgrade will not affect to much the availability because it only affect the users for a minute or so, contrary to a stability problem like crash that could affect the users as long as someone take to reset the machine. So I think we can at least agree that the upgrade on Linux is no affecting your operation more that your BSD boxes. It you really have a particular problem with your Linux boxes, than must be something as severe as a kernel crash, not because of upgrade. And if you can really crash a up-to-date Linux kernel so often, then you must see a clear pattern of the subsystem that cause the crash.
I suspect hat your BSD are in fact netBSD. If this is the case this apply to them: http://www.netbsd.org/support/...
Restarting services take less time than rebooting (especially with systemd), this is less risky on a remote machine, and this affect the availability far less than a reboot because many services are capable to handle restart very fast, and others services are unaffected. In industrial systems there are situation where we just want to upgrade some part of the system while still let running others realtime parts unaffected. You might be in a context where you can just reboot, but there exists others contexts with more constrains than in your environment. You can ignore this fact, as you can continue to insult me, this will simply change nothing to the reality of the facts. And no, our company don't charge per hour.
I would be more than happy to design any futures systems with systemd into it. I delivered my first design with systemd last week and given the success I see no reason to go backward. A mission/life critical aerospace system with not use a Linux kernel anyway. But for less critical functions, even in aerospace, this could done. In fact there is already exists systems running Linux in aerospace environment, it's not hard to find on the internet.
dpkg --get-selections | wc -l
3423
dpkg -L $(dpkg-query -Wf '${Architecture;-20}${Priority;-40}${Package}:${Architecture}\n' | egrep "all|amd64" | cut -b21- | egrep "required|important" | cut -b41-) | grep "/usr/s*bin/.*" | xargs file | egrep " script, " | wc -l
56
And 17 of them are perl scripts. The rest are mostly not so used commands. So I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts.
I mentioned busybox to show that binary commands is enough to admin a box (outside of system V init), not about a supposed busybox GUI.
I have see a lot of Linux boxes with load like the one you describes on your BSD box, this is not impressive at all. Now, did your Linux kernel really crash ? I understand that you reboot for each libc or kernel update, this is your choice, but certainly not a stability problem.
About the libc update, you might find more simple to just reboot, but again this is your choice, not a stability problem. Now in case of libc upgrade, how did you do with your BSD boxes ? Or the BSD libc is so perfect that no upgrade is required ? Hint: https://www.freebsd.org/securi...
You call me ridicule, but I largely prefer restarting some services on a remote machine., and even more when the machine also act as a NFS server, or a router, or a firewall, or have virtual machines. It's a choice, and I will not call you ridicule for your own choice.
If you are so conservative to reboot each boxes as soon as a libc or kernel upgrade exists, then I wonder how your BSD boxes could have uptime a "few orders of magnitude less shitty".
I do tests on the system I deliver, and my customers do tests too, I just say that this is tests not usually done in the cycle of a kernel release [by the kernel maintainers] (last part added for you understanding).
You can't usually buy the systems we design as there are not for consumers. What I can tell you is that we have build systems where conformity to part of aerospace, or railway, or automotive, or civil engineering standards are required. Nothing highly critical, but still with a good chunk of audit and conformity tests. Customers are happy enough with our work to allow, to setup our own company 4 years ago.
But I would like to remain you the this discussion is about the fact hat Ubuntu has released his first version with systemd :-)
I understand that you find the GUI-only Linux ubuntu's goal pointless, but at the same time I read that you have many users asking for precisely this kind of systems. While your are doing the admin work instead of them within the company, it's logical that those peoples will select a distribution with GUI outside of the company related work. After all when those people use a smartphone, a router or a TV, all potentially running Linux, there don't expect to see anything other than GUI.
If we talk about the admin work, it's not fair to count /usr/*. On a typical Debian Jessie I have: /bin/* /sbin/* | egrep ELF | wc -l /bin/* /sbin/* | egrep script | wc -l
file
233
file
36
And a majority of the scripts are just to make usual commands work on compressed files. So I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts. Far from that actually, and to push this to the limit, just look at the busybox project. I have not verified, but I suspect that a machine with systemd and busybox could be close the be usable for simple tasks without any shell interpreter. Actually I think there is still some binary that expect a shell evaluation at some point, but this is probably doable to work around them.
But as you have noticed, using command on a shell don't imply shell script. The NetworkManager project for example is split into different parts, essentially: 1) the daemon, 2) the CLI, 3) the GUI. This allow to make some clean implementation not related to the preference of the user/admin regarding the CLI or GUI. This also help to make the GUI a relatively simple project that only query data, display them, allow fill form and send them. With this kind of project, you can use CLI and script if you want, as you can use GUI if you want. The trend is to apply this design to more and more parts of the systems, and systemd is a way to go forward in that direction. Personally I would like to also see a Web and SQL interfaces for all of those parts as this is basically what my customers are asking for.
If I understand you correctly your BSD boxs don't run the same kind of applications as the Linux box, so it's not fair to compare the stability of a GUI application by the kernel or distribution where it is executed. You don't have to reboot to update the libc and you are free to decide if you like to update you kernel depending on the risk that apply to your situation. BSD kernel are released less often it seem, this don't make it less buggy as your RAID experience has show, but simply a consequence that his community of developers is smaller than Linux.. I really wonder what you can find so unstable in the Linux kernel because it's rock stable for me even on embedded systems where the workload and driver set is quite different to anything usually tested in the cycle of a kernel release.
I once watched a talk from a leading LibreOffice maintainer. I remember how happy it was with the progress of LibreOffice compared to OpenOffice. He explained that it was hard for external contributors to get patches accepted on OpenOffice. LibreOffice unlocked the situation.