[gentoo-dev] Re: Making systemd more accessible to "normal" users

[Steven J. Long]

On Wed, May 01, 2013 at 12:04:00PM +0200, Fabio Erculiani wrote:
> PLEASE DO NOT START A FLAME WAR AND READ ON FIRST.
> THIS IS NOT A POST AGAINST OPENRC.
>
> With the release of Sabayon 13.04 [1] and thanks to the efforts I put
> into the systemd-love overlay [2], systemd has become much more
> accessible and easy to migrate to/from openrc. Both are able to
> happily coexist and logind/consolekit detection is now done at
> runtime.

That's great: well done :-)

Can I just check: what about people not using consolekit nor logind?

> It is sad to say that the "territoriality" in base-system (and
> toolchain) is not allowing any kind of progress [3] [4]. This is
> nothing new, by the way.

I don't think you help yourself by making that kind of remark: when I read
those bugs I see some valid concerns being raised, which you just ignore.
For instance, wrt "nonsensical blockers" I too would like to know some
examples, as was queried in comment 27 [3]. In fact it was the first thing
that came to mind when reading your post, as I thought where possible things
were just installed for systemd (such as unit files) even when the user
is not using it.

 > There are several components that need patching in order to work as
> expected with systemd:
> - polkit needs a patch that enables runtime detection of logind/consolekit
> - pambase needs to drop USE=systemd and always enable the optional
> module pam_systemd.so

Again, what about people not using consolekit, nor logind, with no intention
of ever installing systemd? I've got nothing against this so long as it
is guaranteed not to break my pam setup. As-is I feel *very* wary of a change
that unconditionally requires a 'pam_systemd.so'. Please note I am not hostile
to your aims: I am merely seeking reassurance.

> - genkernel needs to migrate to *udev (or as I did, provide a --udev
> genkernel option), mdev is unable to properly activate LVM volumes and
> LVM is actually working by miracle with openrc.

Why is that such a "miracle"? openrc has worked with lvm since the beginning
afair, and is both clean, portable C, and modular.

>  Alternatively, we should migrate to dracut.
> - networkmanager need not to install/remove files depending on
> USE=systemd but rather detect systemd at runtime, which is a 3 lines
> script.

Sounds reasonable; since I don't use it, that can't affect me in any case.

> - openrc-settingsd needs to support eselect-settingsd, which makes
> possible to switch the settingsd implementation at runtime, between
> openrc and systemd. This also removes the silly conflict between
> openrc-settingsd and systemd friends.
> - genkernel should at least support plymouth (work in progress my side)
> - other ~490 systemd units are missing at this time and writing them
> could also be a great GSoC project (don't look at me, I'm busy
> enough).
>
> All this would come with no cost for the current openrc state
> (actually, my initramfs speed improvements patches in genkernel.git
> also benefit openrc).
> If Gentoo is about choice, we should give our users the right to
> choose between the init system they like the most.

I must be missing something as I thought they already had that choice.

From reading the bug, the only pro of your approach is that the user
does not have to edit the kernel command-line to try out a new init.
Initially, you tried to sell this as "lowering the bar" which is actually
a con afaic: if someone is trying to run Gentoo and is incapable of
dealing with the kernel command-line, it's likely they won't be able to
install it; they certainly won't be able to maintain it, ime.

Later, we get the "some EFI bootloaders don't allow it." Could you elaborate
on how a system we install grub to, won't allow us to change anything?
I am not doubting you: I just think we need more explanation of the exact
context where we can install Gentoo, but not a bootloader.

> It looks like there is some consensus on the effort of making systemd
> more accessible,

Sure there is: there's also consensus that this approach is wrong for
Gentoo. And I have to concur, without further reasoning from you. Switching
init isn't done that often, and when it is a Gentoo user is expected to
deal with configuration. In this case, it's a doddle to set the command-line
to init=/sbin/fubar to try it, and then when it's running the user can
change the symlink, or just revert as they choose.

If they can't handle the above, they shouldn't be on Gentoo imo. And sabayon
already sets up systemd, so I don't see the use-case frankly. Apart from making
Gentoo base-system more suitable for direct usage in Sabayon, which is not our
problem.

What are the effects for other downstreams? Funtoo for instance, has been
swimming against the upstream udev/systemd mania, from glancing at their site
recently. Have you consulted with other downstreams about their needs and got
buy-in from them too? That would strengthen your case, tho imo it's weak
irrespective of what systemd-preferring downstreams want: after all, they're
distros, not Gentoo users, and are supposed to be expert at setting things up.

So I just don't see which Gentoo users this is helping. Making it even more
trivial to change init than it already is, is actually a bad thing in my eyes.
It gives the impression that it can be undertaken lightly which is simply bad
practice.

> while there are problems with submitting bugs about
> new systemd units of the sort that maintainers just_dont_answer(tm).
> In this case, I am just giving 3 weeks grace period for maintainers to
> answer and then I usually go ahead adding units (I'm in systemd@ after
> all).

AFAIK it's been policy for a while that systemd unit files should be installed
by default, for all the reasons you've given. I can't see a maintainer being
bothered by the systemd herd adding them when they have no interest: after all
users can already set an INSTALL_MASK, and it makes binpkgs more useful.

> The only remaining problem is about eselect-sysvinit, for this reason,
> I am probably going to create a new separate pkg called
> _sysvinit-next_, that contains all the fun stuff many developers were
> not allowed to commit (besides my needs, there is also the need of
> splitting sysvinit due to the issues reported in [4]). I am sure that
> a masked alternative sysvinit ebuild won't hurt anybody and will make
> Gentoo a bit more fun to use.
>
> The final outcome will hopefully be:
> - easier to migrate from/to systemd, at runtime, with NO recompilation
> at all (just enable USE=systemd and switch the device manager from
> *udev to systemd -- unless somebody wants to drop the udev part from
> systemd, if at all possible)

How is adding USE=systemd to a system with it switched off (ie: enabling it),
*not* going to lead to recompilation?

> - we give the users the right to choose without driving them nuts with
> weird emerge-fu.

What weird "emerge-fu"? You haven't outlined any at all. Unless you mean
changing a USE flag and the standard emerge process, which isn't what anyone
here would think of as "emerge-fu": just normal usage.

Also, if you can't handle emerge, you really should be on another distro.

> - we make possible to support new init systems in future, and even
> specific init wrappers (bootchart anyone?)

Which is possible already, so this is null.

> - we prepare the path towards a painless migration from consolekit
> (deprecated for long time now) to logind (we probably need to fork it
> off the systemd pkg -- upstream projects are _dropping_ consolekit
> support right now!)

Some people don't use either. For good reason, but let's not get into a
flamewar: let's leave it as that "choice" thing you mentioned before. I
take it those users will not see any breakage beyond missing "features"?

> - we put back some fun into Gentoo

Eh, I've been having much more fun since I got rid of semantic-craptop,
switched to mutt[A], and turned off all nubkit-related flags. My KDE came
back to me, and runs smooth just like 3.5 used to :) Then I replaced my
/bin/sh with /bin/bb which sped up bootup by an order of perceived
magnitude, and also sped up the _rest_ of my system. Of course, the latter
is only possible because Unix is designed on a modular basis, and we can
still swap components in and out on Linux (for now.)

> If you want to see a working implementation of my systemd-love
> efforts, just go download [1] and see things working yourself.
>
> [1] http://www.sabayon.org/release/press-release-sabayon-1304
> [2] https://github.com/Sabayon/systemd-love
> [3] For instance: https://bugs.gentoo.org/show_bug.cgi?id=465236
> [4] "useless crap": https://bugs.gentoo.org/show_bug.cgi?id=399615

Again, I don't think you help your case with this remark. I expected the
"useless crap" to be a reference to lennart-ware. In fact, he was pointing
out that he told you all 8 months ago to raise it upstream: several commands
had already been migrated in upstream git according to another comment. So
the "useless crap" was in fact what he'd usually call whining ime, about the
lack of a "magic fix."

Please note: I fully support your effort to make it easy to switch back
and forth (I actually believe many people who try out openrc will stay with it.)
I just don't think that adding a fragile eselect module (along with "this needs
investigation" as things come up) is the way to do it. Nor does it solve
any real problem in the Gentoo context. Nor should someone change init on a whim,
without being ready to handle configuration.

In fact, dumbing down Gentoo is dangerous imo. It makes it far more likely
that user will mess up something else more significant, likely leading to data
loss. Gentoo, like Unix, doesn't stop you from doing stupid things, as that
would stop you doing clever things. If you're not ready for that (which the
install process beats into you) then you're better off not using it, afaic.

That last is actually the reason I haven't put our installer out to users on
the forum: I don't think it's a good idea to have an automated install unless
you've done at least 2 manual ones. And that would go out the window with
an easy installer. Perhaps that's why you feel Sabayon users need the Gentoo
bar lowered.

To my mind the answer to that is to educate them some more, and make it clear
that Gentoo is not Sabayon for that very reason. It's not meant to hold your
hand: it's far more likely to slap you on the wrist. Or indeed shoot your foot
off if, and only if, you tell it to.

Regards,
steveL.

[A] "kmail to mutt with maildir and procmail"
http://forums.gentoo.org/viewtopic-t-945868.html

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)