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

[Fabio Erculiani]

On Wed, May 1, 2013 at 2:54 PM, Steven J. Long
<slong@××××××××××××××××××.uk> wrote:
> 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?

This has nothing to do with it. If you don't want consolekit nor
logind just USE="-consolekit -systemd".
It looks like you haven't clear what I'm writing about, though.

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

Have you ever tried to fully migrate to systemd from openrc? Clearly not.

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

Do you know how pam works? And did you understand the meaning of my
words? Do you know what optional means in this context?

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

Do you know how LVM and udev and systemd interact wrt volumes activation?

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

My goal wrt openrc is to keep the current level of support and just
make systemd users' life easier.

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

Please, write about something you actually manage to _know_. And also,
please do read my post title.
This is not a flamewar topic, I want to discuss about improving the
systemd experience.

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

Being Gentoo does not absolutely mean that we have to craft watches
and play VHS with the tongue every time we want to do something.
Making things easy is an orthogonal concept!

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

That's not absolutely the point, I am sorry. The topic here is to
improve the systemd experience, if you are an openrc user that doesn't
care about systemd and other stuff, you are off topic.

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

We should stop thinking about Gentoo like a guru-distro. Gentoo is
about choice, but choice != complexity. Making things easier is not
against our Manifesto.
Gentoo is about choice, which to me also means "embrace diversitiy".
If you want to keep living in your little world, fine, you can and
you're very welcome, but also people who want to have fun with new
stuff should get the same respect. Implementing new stuff also means
making things easier, especially in the systemd case.

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

Thanks for reminding me a policy I am supposed to already know about.

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

Because you enable it once and for all and still have a _WORKING_ openrc.
Please take more time reading about what's in my overlay before jumping the gun.

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

Same as above. You're talking about something you haven't even managed
to try. I'm sorry to tell you.

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

It is not.

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

This doesn't affect such users.

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

You're not the user I'm trying to work for. But yet nothing would
change for you.

>
>> 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 join Gentoo first.

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

Thanks for your feedback.

>
> 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 ;-)
>



-- 
Fabio Erculiani