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

[Steven J. Long]

On Wed, May 01, 2013 at 03:14:07PM +0100, Fabio Erculiani wrote:
> 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.

Ah I see: sorry you're taking my email in the wrong spirit. I thought I made
it quite clear I'm not hostile to your intentions, but you appear to be hostile
to everything I've written.

FTR, as I said I was "just checking" that there would not be a hard dependency
introduced, since a) it would affect me and b) I wanted to know you're aware of
those use-cases, and that you already keep them in mind, going forward.

When someone says "just checking" or "can I just check.." it means they don't
expect there's any issue, but they'd like to be sure. Hence "just" a "check".
 
> >> 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.

OFC not, that's the point: it's why I'm asking you. The other person in the bug
clearly has some experience, and you refrained from answering him too. Oh well.
 
> >
> >  > 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?

Again, you're not helping yourself with this attitude. Just a friendly warning.

> Do you know what optional means in this context?

"Always enable the optional.." means "require the currently optional.." to me.
 
> >> - 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?

I have a fair idea of how lvm, udev and openrc interact, after making udev start
after localmount last August. But really, all your replies are along the lines
of questioning my competence instead of answering the point.

I still don't see why you think it's a miracle openrc works with lvm, unless you
mean it was an effort for you. I do recall a bug with lvm a couple of months ago
I had to patch the lvm initscript for; but I notified the openrc channel about it
and they fixed it pretty quickly. Again, more experience that clearly makes me
incompetent.

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

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

Hmm.. no. I'm afraid you haven't shown that Gentoo users don't currently have a
choice of init systems: so you're not some liberator endowing us with "rights"
we didn't otherwise enjoy til you came along with your magic impl, I'm afraid.

As for this topic being solely about improving the systemd experience, that's
a change. I could have sworn i read something about "improving the love between
openrc and systemd" and making *both* work better. But since you're now stating
this is just about systemd, I'll just point out that you're awfully territorial
yourself.

And your attitude of ignoring openrc people does not increase the love at all.

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

YAF non-answer.
 
> >> 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.

No the above is, and again you didn't answer it. There is no consensus as you claim.
 
> >
> > 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.

The thing you're ignoring is that your setup is more complex, and you clearly don't
give a damn about, and have not considered, the effect on other downstreams.

So we get more complexity and less choice overall, as is usual with idiot-box
approaches. And sorry, but a distro that doesn't hold your hand is a lot _easier_
to work with in the longer-term.

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

You mean the respect you've shown me in this email, in my "little world"? *swoon*
you hero. I give up trying to be polite in the face of such crap, it's more than
I can stomach.

> Implementing new stuff also means making things easier, especially in the systemd case.

LMAO. You go girl, strut that nonsense like it means something.
 
> >> 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.

So why are you complaining about maintainers who are not interested in systemd,
who ignore your bugs and don't add the unit files you want them to?

Maybe they know the policy too.

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

No way, sunshine. If you make what is effectively a marketing claim like "no
recompilation" then don't add the qualifications later on. Be precise upfront,
instead of typing so much noise. Or at very least be polite when someone queries
it.
 
> > 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.
> >
> Same as above. You're talking about something you haven't even managed
> to try. I'm sorry to tell you.

Yes that's real emerge-fu there.. only for "gurus" for sure. </sarcasm>

If you post to a wider mailing-list like this, you should bear in mind that the
audience is not simply Gentoo developers, by _design_. If you don't like that, too
bad. Further, if you're posting to get feedback and buy-in from other people,
you severely limit yourself when you suddenly state that only those who have
already done the openrc -> systemd migration are qualified to discuss it. Doubly
so when you're rude to someone who actually felt quite supportive of your effort,
if not the design.

Believe me, I don't now. I just think you're a loud-mouthed amateur who's caught
up in the current fad for idiot-box designs, or what is traditionally known as
being "clever" instead of "wise". Your perspective will change in a decade or so.
As for me, I don't ever want to interact with you again.

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

Right, so I can't switch init=/path/to/foo atm.
 
> >
> >> - 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.

Yay, a straight answer!
 
> >
> >> - 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.

And interacting with you is not fun at all. Don't worry, I won't respond again
so feel free to mouth off some more.

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

That's useless crap too. And in fact he told you all back in January last year, so
make that 13 months. Then bear in mind how users get treated, and how quickly so
many of us take things upstream. Then ask yourself how much respect your attitude
really merits.
 
> >
> > 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.

> Thanks for your feedback.

Yeah, right. Thanks for answering none^W one of my questions.

Your designs sucks afaic, most especially within the Gentoo context. You're wasting
your time imo, but it's yours to waste. Unfortunately you're also going to waste the
time of users and other developers. Still that's their concern, and none of my business.
That's what I keep telling myself, then we get more and more nonsense from one
"developer" or another, along with the mantra "the source is out there" like we have the
time.

Just so long as I can keep hard-masking your rubbish, that's fine by me. When you're
in base-system, or you're a portage developer, I'll prepare the ground to switch
distros, contingent on the output and whether you're in charge of anything.

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