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

[Daniel Campbell <zlg@gentoo.org>]

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

On 02/09/2016 04:17 AM, Rich Freeman wrote:
> On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric
> <kentfredric@gmail.com> wrote:
>> 
>> A pure udev system is in comparison, much simpler than a systemd
>> system.
> 
> I don't buy that at all.  In systemd you have a unified object
> model across device nodes, mountpoints, services, and cron jobs.
> In the alternate model you have completely different
> implementations of all of those, each with their own configurations
> and behaviors.

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.

> 
>> 
>> And that's much of the beauty of OpenRC. Its simple, it achieves
>> the same goals as Systemd and Upstart, etc, but does so with a
>> lot less mechanics under the hood, and doesn't clutter up systems
>> with features you don't need prematurely.
> 
> OpenRC doesn't achieve MANY of the goals of systemd.  Maybe you
> don't personally care about some of them, but you really can't
> compare the feature sets at this point.
> 
>> And there are great benefits from simplicity over complexity.
> 
> Absolutely.  It is great to create a text file and symlink it in a 
> directory named after a service to make that service auto-restart,
> or have a memory limit, or set an IO priority for that service.  It
> is great to not have to think about anything to have just about all
> your processes organized into a sensible cgroup hierarchy.  It is
> great to be able to tweak one config file to ensure that users who
> log out of a system can't leave any processes behind.
> 
> It is great to be able to tweak something in policykit and change 
> things like who can shut down the system, or who can restart a 
> service.
> 
> The simplicity of systemd comes from the fact that it has brought
> what used to be a collection of many independent tools under one
> roof, and created a converging set of interfaces for all of them.

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.

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.
> 
>> 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. If we're
going by SLOC, we would need to also consider all the C code that
systemd uses to *act* on said declarative file. One could argue that
rc scripts in this case are a lot of repetition, and that'd be
correct. There's nothing stopping rc scripts from becoming similar to
systemd's unit files. It'd be akin to our eclass system. But why is
this important? OpenRC supports cgroups, so if a daemon isn't reaping
its children correctly, a bug needs to be filed, either on the package
providing the script or on OpenRC itself.
> 
>> 
>> The only preference I see here is the preference to not have and 
>> install things your system has no use for, which I find an odd 
>> preference to be complaining about, and depending on your system 
>> requirements, that may also be not so much "preference".
>> 
> 
> And hence my suggestion that we simply get this stuff out of the 
> stage3s in the first place.  Then everybody can just pick the 
> implementation that best suits their requirements.

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

We have nothing to gain by making systemd the default init system, and
it would tick off a considerable portion of our userbase, even with it
being changeable. It's one thing to put it on the live media, or even
as part of (a flavor of) a stage4, but to push for it being a default
across the board on a standard install is a bit much.

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?

To clarify, there's nothing wrong with systemd as a choice. It's
special enough that it has its own set of profiles. I think that's
enough, and creates a workable path for both.

For this thread, it seems that we need to do something similar with
eudev. sys-fs/udev already comes with the systemd profile, and eudev
fulfills all the same needs. Maybe we should speak with our users and
find out just how many people are using systemd-udev intentionally
rather than going along with it as a default, and their reasoning for
doing so. The same could go for eudev. Not so much for numbers
(because unlike Debian, we have nothing comparable to popcon), but to
see where people are standing on 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

iQIcBAEBCAAGBQJWueRSAAoJEAEkDpRQOeFw7DYP/i4hqRWuhSVUZsAXE8DX9GAa
vapYjX43fb5S5BzgqS5KVbRWUdDUQNAghyy9kywPUFjjQRArzTF+xX3EmBhj5rUG
Agar+BB3fGh19NbvMtwoJ3C+eHBw7aNGkmlj65vpMOmOnZ/7lDZNU0PbZ4GtDdmp
FoQ2ooR5+TAV7xZaMRf5liwcptMcIPrOhksvUWtzRPhFjGyJLRtg60xO6hxC5Zc0
yF+hrO8/QNnqIvKn5u1sXAx3GyRE2UZtPX+Fad6Z376gH+8T7CtbqjLT1rxIZedd
CYLusg/AdENLsS6EVy6KN5exIH1oAeAqWwtiUS88VURzP7QY7TA3RbCPVVgCFe0M
kM2J5JZqlrdCxG935zEk3kiO9dtW4wBQNbjyLD7G3PCkWWnv2eZsP+lk+pFQlIvw
+Sfbb4nrtusSu8MYkeLnAQJ3oyt8qYUQN0Ip07Y/5h+3pKizMi/A2NVjLdoH35tx
KXnpy5LPYn7Hk7UrVGPdgNQC/GckRcIAgwjH90fvO2cOAV6pdcPAR/VYxaodQeWZ
AUZdT6ksmuZuhfBgZBEU2X2ilEVZsDI22egjz5/+FCDZjr2c56cURCP6+GXcW4ao
LaM/OoTmHkEQSG4PVTSNE6wXN9lrVx5v/TvH9vDjdViugdzOUHyt58gXiC+Bk8wA
XD8LH56ilZGFcoJWdmSR
=Ggkl
-----END PGP SIGNATURE-----