On Sun, Nov 03, 2013 at 10:23:02AM +0100, Marko Randjelovic wrote: > I find shell scripts the most efficient way to automate system adin > tasks. It could be because I am a programmer, but at least init > scripts are already provided, and small modifications should not be a > problem even for non-programmers. For new scripts you have 'skeleton' > file that can be easily adjusted for a particular work.
Amongst other problems, how do you (or the package system) reconcile when you have made a local modification to an init script and the upstream package has made another in an update? > There is nothing more standard/portable in Unix-like systems then > POSIX shell. …which wasn't fully supported on Solaris 9 so you had to use a subset (e.g. no $(subshell) syntax). Writing truly portable shell scripts across multiple UNIX families was a terrible pain and one could not simply rely on the POSIX feature-set. I know this from bitter experience. I suspect C89 is/was more portable in practice, but the point OP is making here isn't the scripting language, for portability, it's the fact init scripts do little to abstract the differences between OSes, so portable init scripts are very hard to achieve. E.g. Debian uses /etc/default for overrides, Redhat-esque systems use various schemes under /etc/sysconfig; various init scripts are written with the assumption sh → bash which required a lot of fixing up when Debian and Ubuntu moved to a different default sh; and on and on. Such OS layout specifics being baked into init scripts also make it much harder to make changes, since you break a load of init scripts when the assumptions they rely on change. This is why it's not just systemd that is trying to replace shell scripts: nearly all the next-gen init systems do (launchd, upstart, openrc… even smf with its XML). > I do not see 'start daemons when they are first used' is quite an > important benefit and start in parallel is already supported by > sysvinit (startpar). Some people like socket activation a lot (which is why inetd was used to achieve this in the past) > I don't think UNIX philosophy is not so important. First of all, the > principle of all-might is by nature authoritarian. All-in-one > "solutions" are a characteristic of big companies that want to impress > their users, while not giving them enough real benefit. It's a principle near and dear to much of the rest of our F/OSS stack, however. The Linux kernel is monolithic (and enormous) rather than a microkernel. GLibc is enormous rather than a family of smaller libraries. And so on. > Systemd makes system startup more complicated and you need to know not > only shell scripts but also systemd syntax. This will make many people > unable to solve their system startup problems If you are considering the hypothetical novice user above (I think you are, correct me if I'm wrong), then in the systemd world such a user does not need to understand shell scripts to tweak or resolve system startup problems, only the systemd syntax. > and force them pay money to big companies, which is in essence what > big companies want. Debian should not put interests of big companies > above interests of its users. Which big company will accept my money to fix a startup problem for me? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131103143327.gb19...@bryant.redmars.org