Re: Init system deba{te|cle}
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?
Reply to: