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