Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Mark David Dumlao]

On Mon, Aug 19, 2013 at 5:54 AM, pk <peterk2@××××××××.se> wrote:
> On 2013-08-18 23:08, Mick wrote:
>
>> I honestly cannot understand why we/Gentoo are allowing the RHL
>> monolithic development philosophy to break what we have.  Is
>> Poettering the only developer available to the Linux world?  Are
>> RHL dictating what path Debian and its cousin distros should
>> follow?
>
> Problem is that Linux is dependent on udev and udev is in the hands of
> Kay Sievers which also develops systemd together with Lennart
> Poettering which in turn used to be a Gnome developer... With that
> said, what I cannot understand is why people advocating systemd (and
> the kitchen-and-sink model) are using Gentoo in the first place. Are
> they just trying to make the rest of the Linux distro landscape as
> miserable as Fedora? Why don't they stay with Fedora instead of trying
> to turn Gentoo into Fedora?
>

This kind of response has been repeatedly grating on my nerves
on this mailing list. It's just so TECHNICALLY WRONG, but more than
that I feel that it hints at a deeper problem about user attitudes and the
need to act like a know-it-all that is so prevalent on this mailing list.

Systemd is _not_ a monolithic design. I don't know how anyone who
has taken even a casual glance at it, or its documentation, can say
otherwise. It's so reminiscent of qmail or postfix, where you have a
bunch of small programs each doing one thing well, but for init
systems rather than for mail, that it's just one step away from being
the kind of program you show to kids to teach them how to Unix.

Scroll up further on the random systemd rants on this mailing list and
you'll "learn" that systemd has a binary / xml configuration format
(it doesn't, it's plaintext INI, like samba) that requires binary code to
run daemons (um, no it doesn't), or that thanks to systemd, old,
perfectly working servers will just stop running...

You know what I think? You can't understand why some people
like or want to support systemd because you don't _want_ to
understand. It requires you to learn something new. There's an
old problem, _mostly_, but not entirely, solved, where we've swept
the ugly parts out of sight so that they don't bug you. The parts of
systemd that you don't understand why they should be there
are the parts that deal with those ugly things you don't want to learn.
I know that feeling, of being forced to learn something new and thinking
"do I really have to?" and I know I hate it. It's the same reason why
RTFM is considered rude. But it's basically the appropriate response
here. You wanna figure out why systemd does what it does? RTFM.

Yes, system initialization SHOULD be simple. Just like
mail or web SHOULD be. And heck, If you want to run some bash
script to do your web or mail or init, nobody's stopping you.

But somebody, somewhere, is going to want features, which is why
we have apache or postfix, and what-have-you. And if other projects want
to use those features, they're free to want to require those software
as they please. You don't like it? Don't use those projects. Or fork
them. But stop acting like a pompous know-it-all, quoting software
design witticisms as if you've actually looked at the problem domain
even half as seriously as the developers involved.

Oh but systemd is going to eat up all our software so that nothing
will run without it! Don't be ridiculous. They said that about Emacs,
Java, Lisp, GNOME, kdepim, The Browser(tm), etc etc etc. If you've
paid any attention at all to the history of software, it's obvious that it's
not happening. Why the hell would apache, which runs on windows,
require systemd? Or firefox? Or google chrome? Or qmail? Or postfix?
Or MySQL? Or samba? etc etc etc

If there's anything surprising, it's that you seriously thought a software
development house (cough cough Redhat) wouldn't try to dogfood their
own stuff into their other products (cough cough GNOME) _which
already have forks by the way_, so what are you worried about?
-- 
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none