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

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/09/2016 05:44 AM, Rich Freeman wrote:
> 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?

Isn't there a bit more to it than that? We can take any design idea,
apply it to an extreme, and see where it won't work. Plan9 is a 'more
proper UNIX' and somehow does a bunch of things exclusively through
the filesystem. I think that design can be great for some things. For
a lot of the above, even the disparate set of tools interfaces with
files. `crontab -e` edits a file, device nodes have been in the
filesystem for forever, mounts have historically been managed by fstab
and need a place in the filesystem to mount, etc.

The primary difference here is systemd throws it into one directory
tree instead of multiple. Systemd is great if you agree with the
design decisions made. That's the problem/benefit with both
approaches. If you go with systemd, you have to like or agree with
every change they make or every design decision on everything. With
multiple tools, you can pick and choose. If I don't like my cron
implementation, I can swap it out with another one. If I was with
systemd and didn't like it, I'd have to recompile systemd to remove
the feature (assuming it's not required like logind), and replace it
with a standalone cron service, managing it with systemd. I could be
lazy and leave systemd running and just add the cron service, but that
would needlessly complicate things and may end up doubling cronjobs.

Politics aside, the dichotomy caused by systemd comes down between
groups of people that either don't care about their lower level system
(or agree with its design) and people who either disagree with
systemd's design and/or want to be able to swap things out when they
get pissed at the way one component is acting. Systemd is an
all-or-nothing choice, and among a population that fiercely values
choices, that can understandably make them concerned. That said,
systemd still deserves to be treated as a choice.

>
>>
>> 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?

I see where you're coming from, but there are situations where you
really *do* want that server to stay down. What sort of data is on
that server? What purpose is it fulfilling? If it's a webserver, its
failure will be obvious, immediately apparent, and odds are someone is
on-call to manage it. If you're holding important data like a
government agency, you likely have someone on-call as well, but do you
want a compromised server rebooting continuously as a cracker or some
other entity is trying to take advantage of a kernel bug? The correct
course of action there is to let it fail, get your staff to the
machine, isolate it from the network, and start triaging.

There are still cases where I suppose you'd want auto-reboot, but I
can't imagine they'd be the correct answer for the problem at hand.
>
>>
>> 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.

It's more like "which would you like to use?" Using them in tandem is
asking for issues, but generally the sudoers file itself and a few
groups can handle that for you, or acls, or (maybe?) LDAP. There's
many ways to skin that cat.
>
>>>
>>>> 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.

And that's where something like eclasses (but for rc scripts) could be
used to consolidate all the redundancy. As far as I can tell we
already implement something similar with the built-in functions that
rc scripts are expected to have. The thing is, do we want to go in the
direction of declarative files and the limitations that come with
that? The complexity would then have to be migrated to the daemon
manager itself instead of the scripts. No matter how you look at it,
managing daemons is non-trivial and rather complex. Most people aren't
going to touch unit files *or* rc scripts unless they're developers,
and most developers will read documentation. If anything, a developer
will have more control over how their daemon is handled in the rc
script. They would have to read systemd's C code or its plethora of
unit options to set it up 'just right' to achieve the same.

Even that will have different tastes across the board. Some developers
want complete control, so they'll want to build their own script.
Others don't care or don't mind integrating with something and
providing a configuration file.
>
>>
>> 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.

That may be the case once it's covered in the handbook, but in the
future we already know the systemd team does not intend on maintaining
udev-sans-systemd forever.

>
>>>
>>> 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.

Do you consider OpenRC a project that's not useful anymore?
>
>> 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.

Would it, really? I think it's hard for us to say, which is why I
suggested getting a rough idea from our users, somehow. The people who
don't care won't notice anything, and the people who do care will know
how to mask eudev.

It's possible that eudev isn't the way to go. But we at least know
that there are no plans for it to be absorbed by a parent project.
That said...

>
> 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.
>

It's not really speculation. [1] [2] You're right, though. We could
keep sys-fs/udev around, at an older version, until it just stops
working. That would likely take months, since udev's core
functionality really hasn't changed in years. Rules you wrote 6 years
ago will probably still work.

I can get behind deferring the decision, but if we were to make it,
knowing the systemd team's plans for the future and the current state
of the virtual (depending on the systemd flag), it makes more sense to
default to eudev, since you have to have '-systemd' to trigger either
of them.

[1]:
https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
[2]:
https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html

Unfortunately I could not find more links. I recall seeing a ML
posting from Poettering where he indicated separate udev would not be
supported perpetually. I'm not the best at searching the Web so I
couldn't find it.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWuftQAAoJEAEkDpRQOeFwQooQAKyp6KmeyUCffTON9H+Hhw8g
swqddfxkBo+QVa2yhdGDqPe8NaHSMZ7KdcW/2f+V/4YOUntYkchs346czSPlYm1P
559+8jrVsHflLUO5hCB5SlFtdwNy4a+tWWObOej5yk+b+O6PuORlsTL+UZ4K3YUg
bDGF/CG6FLxH8iSocZFpBMxbjgxNioSzHjIBTfdvYf2kXK6bF5vdFaAGGu1bs8/g
Utaz/PJDG7XtkgKUZq87B3xl2Dy4tjDwRDHGsricGvHW0byaovrBJ/+N8gJ9JAL0
/WubGP20clOmDo6cq0CIXkx6DcqOa8MW44r0CPIxfkFhxI192+KznmfJjlO67kEL
Xuk+fLkNIBJB89Y09ZkTex9aM96ZJ/eXcU/VdJQ00Dteun/7iKBSto5stgXRi/po
Xu5LHJxsuL7XHsgo3sl0vkJwVcv87gQZZn4faeV/R9+pUawS034EzV5yg979IZUl
7CDJ69Ei0kS7sYY+oDv7wZcyLxTqD02btQ33W7LI3HlPwu7zoPziO99H3m9jtctN
+QPSX5lRt2jAMzhJbBLGHBgs0QIZbMjhQNLUGQNm4cO6JKqOvfYT4a8v5G1d8bO/
6YUUynVxNtTIWnf/h6ap1Znd7dSaveKM02tmPa04o37McOhyTybt8msvg+LhgYO9
XfnFlRggdBPxwvLeFBFg
=8Jxb
-----END PGP SIGNATURE-----