Re: Systemd

On Sat, Apr 26, 2014 at 1:31 PM, Chris Angelico <rosuav@gmail.com> wrote:

On Sat, Apr 26, 2014 at 1:53 PM, Joel Rees <joel.rees@gmail.com> wrote:
> On Fri, Apr 25, 2014 at 10:59 PM, Chris Angelico <rosuav@gmail.com> wrote:

>> Please, can someone explain - without too much on the politics, if
>> that's possible - whether it's right for me to invest time into
>> learning systemd?
>
>
> This one is impossible to explain without bringing in stuff that the
> systemd/dbus/etc. crowd (using posts like the one that started this thread)
> have managed to paint over with the politics brush. (That's what I meant by
> poisoning the well.)
>
> So, no, it's impossible to explain without "politics".

Okay. Thank you for explaining. (Including the below.)

> On the other hand, you could learn to code, and then you could examine the
> code, and then you would understand why the acrimony goes all the way up to
> the top.

I know how to code, and spend significant portions of my day doing so.
I'm familiar with C, having been using it for the better part of two
decades. But I've never dug into the Linux kernel, simply because it's
a huge amount of code to grok; and opening up a few source files won't
tell me why people are unhappy. (Unless it's all in comments, in which
case it's no different from reading text files.)

Same here, but I'm either going to have to start digging in or just retire from the field, I'm afraid. (Three decades, for me.)

> Of course, understanding why XML configuration files don't belong in
> boot-time code does take a bit more learning to code than simply
> understanding the difference between a pointer and an array.

Uhh, XML config files don't belong ... pretty much anywhere. :)

Heh. You know, I had to learn the hard way about that. I think the idea of unbounded nesting was the siren song that took me in. Anyway, that's one of the sticking points, from what I hear.

>> [...]
> Unfortunately, they
> are also the tools that certain vested interests are using to subvert the
> entire open-source development process. (Apparently using? No. It's getting
> pretty obvious now.)

It was developed at Red Hat. Are you saying they're trying to subvert
open source, or someone else is? I'm lost.

Unfortunately, yes, Red Hat has become beholden to the vested interests. It started about the time the founder stepped down.

> [...] You should also start learning how to use the BSDs, especially

> openBSD.

As I said above, I can code. (Most of my need for Upstart/systemd
scripts is to get my stuff running on startup.) But maybe I should
start targeting a BSD, if only to get some experience with it.

It's worthwhile, although, with the state of Grub, I'm trying to set a spare machine aside for it.

You say there'll be a fork in the Linux kernel. But if the split is
over the use of systemd, why isn't there simply a fork of a
distribution, shipping some other init instead of systemd?

Because systemd et. al. are not system tools. They are political tools. They are a band-aid over the rougher spots in initialization, where people who aren't willing to learn to code shell scripts, and who aren't willing to learn different ways of organizing code, get hung up. They don't really solve the underlying problems, they just smooth the waters a bit. It's in the old tradition of the 80% solution that's really only a 20% solution being sold as an 80% solution.

Maybe I should just shut up and go be a user. :|

ChrisA

Maybe I'm being too negative about this. Believe me, you can help if you can spare even a little time.

The underlying problem, as I see it, is developing a way to encode the run-time dependencies into the package database and how to use that information in the configuration scripts.

I think it may require some virtual packages that are almost entirely configuration scripts, but the database needs to be able to be part of the various package systems.

(And no XML configuration files. :-/)

--
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.