Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Tue, Feb 9, 2016 at 8:06 AM, Daniel Campbell <zlg@g.o> wrote:
>
> Perhaps that's because each of those things should not actually be
> considered the same object type. That sort of design may be convenient
> to users, but is more akin to treating everything like a nail when you
> have a hammer.
>
> Also note that in the 'alternate' model, each of the above is handled
> by a different tool. It's obvious that using a combination of
> different tools will result in different conceptualizations of each of
> those parts in a system. I see little benefit in a single project
> pretending to understand everything about each of them.

I thought the whole beauty of unix was the everything-is-a-file design?

>
> If I didn't know any better I'd say this reads like shilling. Firstly,
> there's a real problem if you're depending on a daemon restarting
> itself. Why is it stopping in the first place? If it's stopping,
> something wrong is happening and restarting it *isn't* going to fix it.

Sure, but then why does the linux kernel have an option to auto-reboot
after a panic?  Surely it is better if there is a kernel panic to just
leave the server down for a few days until an admin shows up to debug
the kernel?

>
> Existing permission systems handle a lot of cases. *kit (logind, is
> more like it) has some extra things to make it a bit more granular.
> It's mostly unneeded complexity. The biggest benefit logind brings to
> a system is multi-seat capability.

Emphasis on "existing permission systemS" - again you're comparing a
patchwork of different solutions to a problem vs a harmonized
solution.

>>
>>> And a lot of Gentoo is surprisingly simple: Like our use of bash
>>> scripts for recipies to build things, like using rsync to
>>> deploy/relay not just those recipies, but security notices and
>>> news items, which are themselves reasonably simple formats.
>>
>> Well, one thing about Gentoo that certainly isn't simple is our
>> init.d scripts.
>>
>> Compare this: http://pastebin.com/sSDtpF4t
>>
>> With this: http://pastebin.com/Lfn8r7qP
>>
>> Systemd does the job in 10% of the code (and half of it is a
>> comment), and doesn't implement its own service polling and killer
>> script during shutdown independently for every service (not that
>> every init.d script even does this - most of them will just leave
>> orphans behind, and systemd will catch orphans that even the
>> lengthy init.d script for apache misses).
>
> This is a dishonest comparison. You're comparing a declarative
> configuration file with a Turing-complete scripting language.

That is how each solution implements its configuration.  It isn't my
fault that openrc forces everybody to write bash scripts just to
start/stop a single process.

The complexity of openrc is inherent in the design.

Sure, systemd has more lines of code internally, but the difference is
that instead of having a bazillion independent bash scripts maintained
by different people at different levels of QA, you have a single
codebase that almost all distros share that is maintained to a higher
level of QA.  Features are implemented once there instead of a million
times in various shell scripts.

>
> I can get behind that. This dodges all sorts of arguments regarding
> initial installations. There's still the issue of the virtual,
> however; would we add sys-fs/udev to p.mask in non-systemd profiles to
> clarify the decision, or make eudev the default choice in the virtual?
> I think we can all agree on making it an additional step in the
> handbook, but the default is still at hand.

I agree, but it becomes a less important default, like whether you
prefer vi/emacs to nano.

>>
>> If you want to talk about default providers, the most
>> straightforward one to use is systemd.  It is what people are going
>> to be used to coming from other distros, it is what every upstream
>> package expects to be running anyway, and it is the simpler tool
>> that does everything that most people want.
>>
>> For people who want a more exotic configuration, there are
>> alternatives, and Gentoo should certainly support using them as
>> long as people care to maintain them.
>
> This is the same argument other distros used before they switched
> completely to systemd. When has Gentoo ever been about marching to the
> beat of other distros? Are you advocating for following what others do
> simply because it's popular?

Gentoo has always been like other mainstream distros (until Arch came
along it was probably closest to Debian).  Its distinctiveness came
from offering choices to users and being source-based.  I think that
is what we're good at.

The only reason we had OpenRC is that EVERYBODY was rolling their own
service managers, and OpenRC was better than the alternatives.  I
think that was great, but everybody else has moved on.

> The e-mails I've seen from you in this thread seem out of the
> ordinary. Has the systemd team been talking with you, or people from
> other distributions urging for Gentoo to switch?

Not at all.

I'll admit this has been a bit of an emotional thread for me.  I think
my frustration comes from the fact that it seems like the whole reason
that eudev exists is because people really strongly believe that
systemd isn't the right way to go, and yet those same people don't
seem to realize that others might feel just as strongly that eudev
isn't the right way to go.

Surely anybody suggesting switching to eudev as the default
virtual/udev provider had to have realized that this would create a
huge controversy.

Even if standalone udev is a dead-end (something that is speculation
at this point), it isn't like the code that exists today will suddenly
stop working.  Worst case we just have to change the default at a
later point in time.

Even just kicking the can down the road has a lot of advantages:
1.  Everything works fine today.
2.  We don't know for sure that it will ever stop working.
3.  Deferring a decision means we don't have to wage a huge battle
over which way the decision ought to go.
4.  If we do have to make a decision in the future, we'll have more
information to act on.

-- 
Rich