[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.

[Nicolas Sebrecht]

The 25/07/12, Kevin Chadwick wrote:
> > If a service is not provided:
> > - with SysVinit you have to write the whole script usually relying on
> >   whatever library the distribution provides (which tend to be
> >   error-prone);
> > - with systemd, you just write a configuration file.
> >
> 
> Well arch has some includes to make it prettier.

Look:

> On OpenBSD you have

<...>

> or

<...>

> or

<...>

I don't find that pretty nor even smart at all.

> This also demonstrates how easy shell can be

Or not.

Come back to reality (and I won't talk about BSD systems which are not
the Linux world), shell scripts for init are a nightmare for plenty of
reasons:
- various API;
- API not always fully respected in all the scripts;
- no real journal;
- almost nothing in API for detailed logs;
- bad experience with parallelism;
- static dependencies;
- not events aware (except for TCP sockets);
- slower;
- almost no cgroup isolation support (and so goes for resource limits
  strategies);
- almost anything for IO class and priority;
- nothing well-defined to wait for availability of resources (remote fs,
  advanced authentication protocols, etc);
- tracking of jobs/daemons sucks;
- respawing absent;
- no D-BUS interface;
- no possibility to select which daemons to start from kernel command
  line (so multi-environments configuration for laptops often sucks);
- relying on large binaries (starting from the shells);
- etc, etc.

Nobody will convince me that the pretended easy, smart, robust,
hacking-friendly, etc world of init scripts is a wonderfull world which
just worked for ages. I've had too many glitches for years (often hard
to resolve) ― sometimes indirectly related from so unexpected pieces of
the system ― to believe such thing, sorry.

The ini style for configuration files of systemd or the rc.conf split
into 3 or 5 files looks to be nit-picking to me.


> One of the founding principles of UNIX is that small tools that do
> a single job well allow complete flexibility whereas large tools do
> what the devs foresee very well but will likely hinder users or the
> unforeseen uses (hacking).

Hackers know C. Admins don't hack and write scripts, too often poorly;
whatever my statement will hurt readers or not.

-- 
Nicolas Sebrecht