Entangled monolith? [was: Re: GR proposed re: choice of init systems]

[Joel Rees]

On Tue, Oct 21, 2014 at 5:56 PM, Andrei POPESCU
<andreimpopescu at gmail.com> wrote:
> On Ma, 21 oct 14, 16:55:08, Joel Rees wrote:
>>
>> Anyway, if you think about Ric's comment about the movie 2001, well, the
>> monolith is not subject to being taken apart and analyzed. Dave's
>> interaction with it is pretty much passive. 2001 is a great movie, very
>> thought provoking. But I think it encourages a passive attitude towards
>> things one doesn't understand.
>>
>> I'm not much in favor of that attitude.
>
> Me neither, but at least as far as I'm concerned:
>
> Sysvrc is anything but transparent to me. It consists of a bunch of
> shell scripts that are beyond my understanding.

Why?

> And don't tell me shell
> scripting is easy,

It takes getting used to, sure. I'm not all that used to it, but
writing a few scripts of my own tells me the strange conditional
syntax is not a barrier to recognizing conditionals as conditionals.
(Well, it was for a couple of years, early on. I'll grant that.)

> I've been following the "bash exorcism" thread on
> -devel

<sigh />

> and few other references provided on -user (Unix standards
> getting quoting wrong?)

Wrong?

In whose opinion? (This is the question you should be asking, and, no,
the answer is not POSIX, nor is it debian Policy, neither is it any
name at all. The correct answer is a bit longer than that.)

BTW, what languages do you program in?

perl got mentioned several times in that thread, do you understand the
reasons I would have been trolling if I had (as I was tempted) posted
a simple

    #! /usr/local/perl -T

as a response to one of the early posts?

> and just about anyone agrees that beyond a
> certain size it's much better to rewrite the thing in a real programming
> language.

Well, size is not the first criterion I'd use, but, yeah. I'm not sure
if your reasons are the same as mine, however. Not ceding your
assertion that *sh is not a real programming language, just that the
primary init processes are mostly not things you want being
interpreted by a large and not-well-defined shell language.

On the other hand, as I'm trying to point out here, I wouldn't want
Python, perl, Ruby, Haskell, etc. being the execution environment for
my pid 1, if I were going to have an interpreter executing init as a
script. Even bash would be preferable.

> Systemd unit configuration files are much more understandable for me.

You think they are. The primate looking at the monolith thought it was
understandable, no?

(Big. Black. Doesn't move. Ignore it. Oh. Nice bone.)

> I've found everything I needed in the manpages

So far.

> and if the behaviour is
> not as documented I know how to file bugs. In comparison initscripts are
> not documented at all except for code comments ("look at the source"?
> when was this ever considered good documentation).

There are still people around who think that "Code should be self
documenting." has little to do with being able to strip the comments
from before a function header and put them in a man page. (I am one of
those.)

> Systemd *is* FLOSS

In whose opinion?

Can you restrict the interpretation of free/libre/open-source software
to a single meaning and it still be either free or libre, or even
open?

> and I'm quite sure that being such a central piece in
> so many distributions has already attracted many eyeballs.

Have you looked at the code?

Do you understand it?

> Many more
> than your average initscript.

Your average initscript does significantly less than systemd.

Hmm. Are you implying that you are under the impression that
/sbin/init is a script?

> Is systemd (the project) tightly integrated?

And when you started jesting about how could something monolithic be
entangled with itself, I thought you were arguing that it couldn't be
tightly integrated with itself.

> Yes, nobody is disputing
> this. Is it *too* tightly integrated? Many have argued "yes" and that a
> loosely integrated design would have been better. I'm not even
> disagreeing with this view. However, so far there's no real contender
> for systemd:

Well, I'm just saying that, as a principle of engineering, if I were
presented with the option between systemd and not using computers, I'd
say, what option?

> Upstart has buried itself from the start (the weird upside-down
> dependency model, the CLA,

I'm not really familiar with the history of upstart. I know I had bad
experiences with it at some point.

> and the Debian Maintainer's insistence to
> replace sysvinit instead of allowing parallel installation and booting
> with some init= parameter).

Did upstart need sysvinit code to be present, or was that as a
safety-net? (Not that it seems relevant to me. It doesn't.)

> OpenRC seems interesting, but it's far from being ready for a
> distribution like Debian. Same with others, like daemontools, runit,
> etc. that are even present in the archive, yet not enough people have
> seriously considered switching to them.

I am aware that testing those would take time. I'm not particularly
enthusiastic about any of them, but some, at least, try to be more
circumspect about what they do than systemd.

> uselessd and nosh are still just starting and both look like one-man
> shows.

Not even that. Proofs of concept, really.

> It's too early to tell if they will be successful or will just
> fade away as most distros switch to systemd and are reasonably happy
> with it.

Two years ago, I was still under the impression that debian's
developers would have, in general, enough engineering background to
not take systemd seriously. I've had other things to do since joining
the community, and stayed away from debian-devel. Didn't want to get
entangled in fun threads like the thread you mentioned above.

Two or so years ago, Andrei, you helped me get started with debian.
Thanks. Even though I'm arguing these points with you, I do appreciate
your help.

-- 
Joel Rees

Be careful when you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Arm yourself with knowledge of yourself.