Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

Making systemd more accessible to "normal" users

 

 

First page Previous page 1 2 3 4 5 6 7 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded


lxnay at gentoo

May 1, 2013, 3:04 AM

Post #1 of 166 (2012 views)
Permalink
Making systemd more accessible to "normal" users

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

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

It looks like there is some consensus on the effort of making systemd
more accessible, 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).

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)
- we give the users the right to choose without driving them nuts with
weird emerge-fu.
- we make possible to support new init systems in future, and even
specific init wrappers (bootchart anyone?)
- 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!)
- we put back some fun into Gentoo

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

Cheers,
--
Fabio Erculiani


pacho at gentoo

May 1, 2013, 3:50 AM

Post #2 of 166 (1941 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

El mié, 01-05-2013 a las 12:04 +0200, Fabio Erculiani escribió:
[...]
> - 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).
[...]

Can't them be stolen from other distros running systemd?

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

I am unable to find exact advantage of changing init system without
rebooting :/, what is the advantage of booting with an init.d and
shutting down with a different one?

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

Are udev and systemd-udev-part really equivalent? I mean, since they are
maintained by different people downstream, I am not sure if there would
be differences in how udev from udev ebuild and udev from systemd ebuild
will behave.

Best regards and thanks for your work!


lxnay at gentoo

May 1, 2013, 4:00 AM

Post #3 of 166 (1949 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

On Wed, May 1, 2013 at 12:50 PM, Pacho Ramos <pacho [at] gentoo> wrote:
> El mié, 01-05-2013 a las 12:04 +0200, Fabio Erculiani escribió:
> [...]
>> - 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).
> [...]
>
> Can't them be stolen from other distros running systemd?

Sure, Arch and Fedora repositories are a good source.

>
> [...]
>> 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.
>>
>
> I am unable to find exact advantage of changing init system without
> rebooting :/, what is the advantage of booting with an init.d and
> shutting down with a different one?

No, you don't boot with A and shutdown with B. B is loaded by the
kernel at the next boot.
Switching init system is the only way to roll out a migration path,
among other things I already wrote about on the eselect-sysvinit bug.

>
>> 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)
>
> Are udev and systemd-udev-part really equivalent? I mean, since they are
> maintained by different people downstream, I am not sure if there would
> be differences in how udev from udev ebuild and udev from systemd ebuild
> will behave.

This needs investigation.

>
> Best regards and thanks for your work!
>
>



--
Fabio Erculiani


pacho at gentoo

May 1, 2013, 6:13 AM

Post #4 of 166 (1932 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

El mié, 01-05-2013 a las 13:00 +0200, Fabio Erculiani escribió:
[...]
> >> 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.
> >>
> >
> > I am unable to find exact advantage of changing init system without
> > rebooting :/, what is the advantage of booting with an init.d and
> > shutting down with a different one?
>
> No, you don't boot with A and shutdown with B. B is loaded by the
> kernel at the next boot.
> Switching init system is the only way to roll out a migration path,
> among other things I already wrote about on the eselect-sysvinit bug.
>

Ah! OK, I misunderstood the "runtime" sense, in that case looks
interesting :D


mgorny at gentoo

May 1, 2013, 6:36 AM

Post #5 of 166 (1931 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

On Wed, 01 May 2013 12:50:42 +0200
Pacho Ramos <pacho [at] gentoo> wrote:

> El mi, 01-05-2013 a las 12:04 +0200, Fabio Erculiani escribi:
> [...]
> > - 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).
> [...]
>
> Can't them be stolen from other distros running systemd?

Yes and no. Fedora took the quick way of switching to systemd which
means some of the units are really poor quality. For example, they rely
on configs in /etc/sysconfig which we don't want to port to Gentoo.

I'd prefer if someone took the task really serious and worked hard to
get:

a) fixed config handling in upstream packages (thus allowing for better
unit files),

b) really good unit files,

c) bugs for upstreams to try to include those good files or fix
the existing ones.

> [...]
> > 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)
>
> Are udev and systemd-udev-part really equivalent? I mean, since they are
> maintained by different people downstream, I am not sure if there would
> be differences in how udev from udev ebuild and udev from systemd ebuild
> will behave.

There may be differences. For example, I'm not really interested
in patching systemd with patches from eudev which will never make it
upstream. Therefore, systemd-udevd won't work with old kernels systemd
does not support.

--
Best regards,
Micha Grny
Attachments: signature.asc (0.94 KB)


slong at rathaus

May 1, 2013, 6:54 AM

Post #6 of 166 (1933 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

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


lxnay at gentoo

May 1, 2013, 7:14 AM

Post #7 of 166 (1942 views)
Permalink
Re: Re: Making systemd more accessible to "normal" users [In reply to]

On Wed, May 1, 2013 at 2:54 PM, Steven J. Long
<slong [at] rathaus> 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


prometheanfire at gentoo

May 1, 2013, 7:20 AM

Post #8 of 166 (1933 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

On 05/01/13 05:04, 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.
> 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.
>
> 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
> - 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. 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.
> - 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.
>
> It looks like there is some consensus on the effort of making systemd
> more accessible, 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).
>
> 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)
> - we give the users the right to choose without driving them nuts with
> weird emerge-fu.
> - we make possible to support new init systems in future, and even
> specific init wrappers (bootchart anyone?)
> - 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!)
> - we put back some fun into Gentoo
>
> 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
>
> Cheers,
>
Isn't there a tracker (and if not, why have you not created one yet :P )

--
-- Matthew Thode (prometheanfire)
Attachments: signature.asc (0.82 KB)


lxnay at gentoo

May 1, 2013, 7:22 AM

Post #9 of 166 (1936 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

There is no tracker yet. But it may be very well materialize at some point.

--
Fabio Erculiani


rich0 at gentoo

May 1, 2013, 7:52 AM

Post #10 of 166 (1934 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

On Wed, May 1, 2013 at 6:04 AM, Fabio Erculiani <lxnay [at] gentoo> wrote:
> - 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. Alternatively, we
> should migrate to dracut.

I'm not sure what "migrating to dracut" actually means. A gentoo
install doesn't include genkernel in the first place - it is installed
manually.

If you mean documenting how to use dracut in the handbook, then I
think that makes sense - we already document multiple alternatives
like genkernel, manual kernel builds, grub, lilo, etc.

I've been running dracut for almost a year now and it has been working
well, though I might note that I had to build a custom module to get
mdadm+LVM to work (not sure if current versions work out of the box,
and my use of old mdadm metadata versions due to previously having
followed the Gentoo mdadm+lvm guide might have something to do with
it).

Honestly, I'm not sure how important it is to be able to switch
back/forth at runtime. We should definitely support both options
reasonably well, but not to the point where people end up with a lot
of dependencies/complexity that a typical user doesn't actually have
need for.

Rich


slong at rathaus

May 1, 2013, 11:52 AM

Post #11 of 166 (1936 views)
Permalink
Re: Re: Making systemd more accessible to "normal" users [In reply to]

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 [at] rathaus> 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.


phajdan.jr at gentoo

May 1, 2013, 12:52 PM

Post #12 of 166 (1930 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

On 5/1/13 3:04 AM, Fabio Erculiani wrote:
> 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.
>
> [4] "useless crap": https://bugs.gentoo.org/show_bug.cgi?id=399615

As far as I read the bug, Mike (vapier) is doing the right thing.
Distros doing lots of custom changes can only add more chaos to the picture.

Have you reached out to relevant upstreams? If they refuse to make
changes, that's a different story. So far I think it's reasonable to go
to upstreams first.

Paweł
Attachments: signature.asc (0.20 KB)


mgorny at gentoo

May 1, 2013, 1:32 PM

Post #13 of 166 (1928 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

On Wed, 01 May 2013 12:52:09 -0700
""Pawe Hajdan, Jr."" <phajdan.jr [at] gentoo> wrote:

> On 5/1/13 3:04 AM, Fabio Erculiani wrote:
> > 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.
> >
> > [4] "useless crap": https://bugs.gentoo.org/show_bug.cgi?id=399615
>
> As far as I read the bug, Mike (vapier) is doing the right thing.
> Distros doing lots of custom changes can only add more chaos to the picture.
>
> Have you reached out to relevant upstreams? If they refuse to make
> changes, that's a different story. So far I think it's reasonable to go
> to upstreams first.

Well, the first thing to do would be making /sbin/init a symlink
and renaming sysvinit. Now, why would sysvinit upstream do such
a thing? I doubt it's a change that upstream should be willing to do
because of what downstream wants to do afterwards...

--
Best regards,
Micha Grny
Attachments: signature.asc (0.94 KB)


lxnay at gentoo

May 1, 2013, 2:14 PM

Post #14 of 166 (1937 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

On Wed, May 1, 2013 at 9:52 PM, "Paweł Hajdan, Jr."
<phajdan.jr [at] gentoo> wrote:
> On 5/1/13 3:04 AM, Fabio Erculiani wrote:
>
> As far as I read the bug, Mike (vapier) is doing the right thing.
> Distros doing lots of custom changes can only add more chaos to the picture.

We are a distribution, we have our own goals, thus we change the code
to better integrate with our ecosystem.
That's part of the game. If we don't want to do that, we shouldn't be
running a distro in the first place.

>
> Have you reached out to relevant upstreams? If they refuse to make
> changes, that's a different story. So far I think it's reasonable to go
> to upstreams first.

For just a symlink swap and some file moves? (re: sysvinit)
We don't need to bless upstream first for such small changes.

>
> Paweł
>
>



--
Fabio Erculiani


peter at stuge

May 1, 2013, 2:40 PM

Post #15 of 166 (1919 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

Fabio, I think you're doing awesome work!

Steven, I think you can behave a lot better on the internet. kthx.


Steven J. Long wrote:
> > 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.

In my world naysayers have no say and doers decide, as long as there
are no obvious negative consequences from doing.

In my world it is also an absolute no-brainer to try to make systemd
as accessible as possible in Gentoo.


> Switching init isn't done that often

That doesn't mean that it couldn't be, and it also doesn't mean that
it wouldn't be handy to use eselect to do so.


> and when it is a Gentoo user is expected to deal with configuration.

I don't know where such expectation could come from since, as you
write, switching init isn't done that often; so there can't be a lot
of user feedback from doing it, and it hasn't been discussed very
much by developers.

If you mean that *you* expect users to deal with configuration then
that's fine and valid, but I think that if we can find a neat way for
users *not* to have to deal with configuration when they want to
switch init then that would be really nice!


> In this case, it's a doddle to set the command-line to
> init=/sbin/fubar to try it

I think it's less about telling the kernel which binary will be
process 1 and more about what gets started by process 1 on next boot.


> If they can't handle the above, they shouldn't be on Gentoo imo.

You have all right to your opinion, but I for one don't share this
opinion. If we can make it easy to switch around I think that's
awesome.


> I don't see the use-case frankly.

I would say that it is to make migration easy.


> So I just don't see which Gentoo users this is helping.

Anyone who has a Gentoo system using OpenRC who would like to try out
systemd.


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

Sorry, I don't buy your argument. Consider how lightly I can
undertake deletion of all my data, which is also bad practise:

rm -rf ~


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

Yep, +1 for all of this. I think Fabio shouldn't let unresponsiveness
of others create very long wait states when doing benign changes.


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

Setting the USE flag doesn't lead to recompilation per se, but the
question is good - what will the USE flag actually mean when we
arrive at the final outcome? Will it do anything at all? Fabio?

In the end, maybe it would just control if baselayout DEPENDs on
openrc or systemd?


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

Consider that Fabio and I are not native english speakers. I would
recommend spending more time seeking to understand what was intended
to be transmitted, rather than merely interpreting the words received.

Communication becomes significantly more effectively that way, which
you probably don't need me to bring up, if you're used to talking to
users on forums. :)


> > - we put back some fun into Gentoo
>
> Eh, I've been having much more fun since ..
..
> 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 are implicitly communicating that systemd can not be fun because
it is not modular. Basic flaming. What's the point of that?


> Please note: I fully support your effort to make it easy to switch
> back and forth

I have no doubts that this was true in your original email, but you
should consider that the words you chose communicate something very
different.


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

I think the point is to investigate exactly to ensure that the module
*is not* fragile.


> Nor should someone change init on a whim, without being ready to
> handle configuration.

I think it would be awesome if we can allow changing init on a whim,
without having to handle configuration.


> In fact, dumbing down Gentoo is dangerous imo.

I think you misinterpret the intention. Creating powerful tools to
make complex tasks appear simpler doesn't fit my understanding of
"dumbing down." (My understanding is to artificially restrict what
tasks can be done.)


> Gentoo, like Unix, doesn't stop you from doing stupid things, as
> that would stop you doing clever things.

Switching init can be wise. (You later use "clever" in a derogatory
fashion.) I nearly replaced init with supervise on my systems before
I started using systemd. supervise is one of a few components I would
have written myself if I hadn't already found that someone else had
done it.


Steven J. Long wrote:
> Ah I see: sorry you're taking my email in the wrong spirit.

That is quite understandable to me, since you made liberal use of
flammable wording next to the explicit, but brief, expression of
support of the effort.


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

See above. I think you could have communicated your points a lot
better, so that they would not have been misunderstood.


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

I guess you realize that it isn't so useful to first educate peers
(answering you) before moving on to actual discussion. If you haven't
got experience from the details of this topic, perhaps your time is
better spent on another topic..


> > > Again, what about people not using consolekit, nor logind, with
> > > no intention of ever installing systemd?

They might change their mind at some point, and I think it would be
cool to make it as easy as possible to switch both ways.


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

Your words are far from friendly.

I for one did not understand the meaning of Fabio's words, it would
be cool if he can clarify the details about the pam_systemd.so file.


> > Do you know what optional means in this context?
>
> "Always enable the optional.." means "require the currently
> optional.." to me.

I think this is a misunderstanding, because it doesn't fit with the
general intention I receive in Fabio's mail. I can't explain what
Fabio meant exactly, I believe I also don't quite understand what
he meant. I hope he'll clarify a bit.


> I still don't see why you think it's a miracle openrc works with lvm,

I think it's valid to ask for more details about potential problems
with openrc+lvm, although such details are also not really on topic
for this thread. (Very good to do in another thread however, maybe
there is also some misunderstanding about how openrc+lvm is supposed
to work, which would allow a smoother user experience and perhaps
improved documentation.)


> unless you mean it was an effort for you.

I don't see the point of this ad hominem.


> > Please, write about something you actually manage to _know_.
> > I want to discuss about improving the systemd experience.
>
> Hmm.. no.

What no? No you will not write about matters where you have
experience, or no you do not agree that this discussion is
about improving the systemd experience?


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

I think you're behaving like an asshole, I don't see the point of that.

When studying systemd it becomes clear that there are potentially
interesting challenges in migration between process 1
implementations, and experience quickly confirms it. :)

I don't think Fabio has claimed to endow you with rights you didn't
have before, or enable new choice. I think he intends to make it
*easier* to effect one's choice. He points out several things which
would help accomplish this.


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

I think "focused" is a better word. Since systemd is a new
alternative, and since it works differently in various ways, other
parts need to change to fit together with it. I think everyone agrees
that such changes should not have negative effects on already well-
established openrc.


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

I for one don't see that attitude from Fabio. Can you be specific
about where openrc people (do you mean developers, users, or both?)
were ignored?


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

Do you intend to say that Fabio is being off-topic in a thread he
himself started just two emails earlier?


> There is no consensus as you claim.

I think there is, it's just more local than I think you interpreted
Fabio to mean.


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

Fabio makes excellent points here.


> The thing you're ignoring is that your setup is more complex,

Sorry, what do you mean? What setup is more complex than what alternative?


> and you clearly don't give a damn about, and have not considered,
> the effect on other downstreams.

That's not at all clear to me. What are some concrete negative
effects of Fabio's suggestions on "other downstreams," and which
downstreams do you have in mind?


> So we get more complexity and less choice overall,

I don't follow you. Please clarify? Tooling that simplifies switching
might end up complex, but only if the task itself actually requires
complexity. I don't understand the "less choice overall" part at all. :\


> as is usual with idiot-box approaches.

Another ad hominem, wheter against Fabio or Lennart this isn't a very
helpful comment in the discussion. It's clear that you aren't very
interested in making systemd work (easily) on Gentoo..


> And sorry, but a distro that doesn't hold your hand is a lot
> _easier_ to work with in the longer-term.

..from this comment and others. You could have saved us all a lot of
time if you had simply written a brief email saying something like

"I disagree with the goal of making it easier to switch from and to systemd."

along with some to-the-point qualification.


> I give up trying to be polite in the face of such crap, it's more
> than I can stomach.

If you can't compose yourself in the face of someone who doesn't seem
to understand you then please think twice before entering into
discussions. Misunderstandings are frequent on the internets.


> > Implementing new stuff also means making things easier, especially
> > in the systemd case.
>
> LMAO. You go girl, strut that nonsense like it means something.

Something is obviously meant, but you didn't receive it. I also
haven't received it. I don't know exactly what "new stuff" Fabio
refers to, but I can certainly think of things that he might have
intended to communicate, which allows his sentence above to have
wise meaning. Please try to think of such things you too.


> > >> 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
> > >
> > > AFAIK it's been policy
> >
> > 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.

Fabio is being polite to give a grace period and it would be polite
of maintainers to answer, even if only to point out that they are
fine with him making the changes immediately.

It would be polite of them because it would remove a lot of wait
states. If there would be critical mass then at some point no new
wait states would be created. It is quite clear from my rather brief
experience with Gentoo developers that no matter what policy you have
to back you up you can make someone upset enough to flame you by
doing something that they don't like.

The wait states introduced by Fabio giving a grace period is a
typical example of the chilling effect which is a quite natural
result from such attitude.

It is what it is. Lots of software developers simply suck at dealing
with other people, and unfortunately this affects the software we all
work on, because most significant (open source) software development
is too much for any one person. Sad, but a fact.


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

Your query was not particularly polite either. I think it is
reasonable to ask for you to review Fabio's work before rejecting it.


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

Do you mean to say that because someone receives an email they don't
have a moral responsibility to consider if a reply will contribute
something to the topic, and a duty to optimize their reply for
efficiency for the sake of readers? I disagree with that.


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

Maybe you agree that it's a lot less useful to discuss solutions
with someone who hasn't experienced the problem? It's not impossible,
in particular it's already very useful to discuss based on experience
from using openrc and systemd independently, since that already
forces thinking about the problem in concrete terms.

It's possible to come to same conclusions through theory, but that
usually takes significantly more effort. Our time as contributors is
scarce, so we tend to prefer conclusions drawn efficiently.


> Doubly so when you're rude to someone who actually felt quite
> supportive of your effort, if not the design.

I think Fabio reacted quite composed to your words, which were
indistinguishable from verbal attacks in spite of your explicit
expression of support.


> Believe me, I don't now. I just think you're a loud-mouthed amateur

You're writing what you think about Fabio, when the topic is making
it easier to switch process 1 implementations in Gentoo. Please focus.


> I don't ever want to interact with you again.

This is behaving like an asshole, which is harmful not only for Fabio
(which I guess you intend, but which I certainly don't find good) but
also for this mailing list and indeed the Gentoo project as a whole.

Please behave better than that.


> And interacting with you is not fun at all.

Volunteer contributor collaboration across nations, cultures and
languages using seven bit text is rarely fun - most of the time it's
damned hard work and requires boatloads of patience, to arrive at
even halfway good things.


> Your designs sucks afaic

I don't know about that. I think it sounds pretty good from a
usability perspective, and the way I understand Fabio's intentions
it also seems to make sense from a technical perspective.


> Just so long as I can keep hard-masking

What to mask is always your choice.

> your rubbish

I don't know about that, since again I didn't review Fabio's work.
But again, from what he describes it doesn't sound like rubbish to me.


> I'll .. switch distros

This statement creates a pretty bad atmosphere for little reason.


//Peter


mattst88 at gentoo

May 1, 2013, 3:32 PM

Post #16 of 166 (1917 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

On Wed, May 1, 2013 at 2:40 PM, Peter Stuge <peter [at] stuge> wrote:
> Steven, I think you can behave a lot better on the internet. kthx.

Amazing. I came to the exact opposite conclusion.


1i5t5.duncan at cox

May 1, 2013, 7:11 PM

Post #17 of 166 (1919 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

Steven J. Long posted on Wed, 01 May 2013 19:52:03 +0100 as excerpted:

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

> No way, sunshine. [...] Or at very least be polite when someone queries
> it.

Unfortunately, I believe the above demands a public post...

The above is taking it too far. Please take a bit of time to cool off if
you need it, then apologize, or if you choose not to do that, refrain
from further posts to the list.

(I don't necessarily agree with all he posted and in fact had some of the
same questions you did about optional being made non-optional, but
(despite the "little world" comment which I agree was going a bit far,
but just because he did, you didn't have to go one worse) he wasn't
getting personal to the degree you did above, and the elements of your
reply above simply have no place on this list. If indeed it is more than
you can stomach and you can't at least be polite and avoid going
personal, you really do need to consider getting off the list. The list
has been rather better lately as to their credit people /have/ been
keeping it civil despite obviously strong disagreements. There's no
place for this sort of personal name calling by analogy on this list now,
and despite past history to the contrary, never was or at least never
should have been. So if you insist on taking it to that level, do it
elsewhere.)

(Just to make clear I'm just a gentoo user and list participant too.
I've no authority to kick you from the list, but I can make clear that as
part of the gentoo community, /I/ don't like that behavior, and believe
it far enough out of bounds to ask for an apology. What others with said
authority do after that isn't up to me.)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman


alex_y_xu at yahoo

May 1, 2013, 7:41 PM

Post #18 of 166 (1914 views)
Permalink
Re: Re: Making systemd more accessible to "normal" users [In reply to]

On 01/05/13 10:11 PM, Duncan wrote as excerpted:
> Steven J. Long posted on Wed, 01 May 2013 19:52:03 +0100 as excerpted:
>
>>> 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.
>
>> No way, sunshine. [...] Or at very least be polite when someone queries
>> it.
>
> Unfortunately, I believe the above demands a public post...
>
> The above is taking it too far. Please take a bit of time to cool off if
> you need it, then apologize, or if you choose not to do that, refrain
> from further posts to the list.
>
Agreed in full. I was prepared to write a response, but this is far more
eloquent than anything I could have written.

I'll go one step further, and say that this is just an example of the
toxic behavior that's been shown in the Gentoo community, in particular
this mailing list. This complete lack of any semblance of empathy, even
in some *Gentoo developers* is entirely unacceptable.

Things like "a bunch of crybabies", "whinging threads", "Avoid spreading
FUD", "Really, please stop spreading FUD." (from different people),
"Good arguments! As usual I'd say." (sarcasm), "Just to annoy people who
have successfully used...", ad nauseam are, at best, not remotely
productive.

Please, just consider for a second how your words will, or even /might/
be perceived by others. Even better: although it might seem beneath you,
consider how you yourself might perceive them, were they to be said from
someone else.
Attachments: signature.asc (0.82 KB)


williamh at gentoo

May 1, 2013, 7:49 PM

Post #19 of 166 (1922 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

On Wed, May 01, 2013 at 03:13:54PM +0200, Pacho Ramos wrote:
> El mi, 01-05-2013 a las 13:00 +0200, Fabio Erculiani escribi:
> [...]
> > >> 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.
> > >>
> > >
> > > I am unable to find exact advantage of changing init system without
> > > rebooting :/, what is the advantage of booting with an init.d and
> > > shutting down with a different one?
> >
> > No, you don't boot with A and shutdown with B. B is loaded by the
> > kernel at the next boot.
> > Switching init system is the only way to roll out a migration path,
> > among other things I already wrote about on the eselect-sysvinit bug.
> >
>
> Ah! OK, I misunderstood the "runtime" sense, in that case looks
> interesting :D

I still don't see the advantage of eselect-sysvinit over editing your
boot loader configuration and changing the init= kcl option, as I said
on the bug.

William
Attachments: signature.asc (0.19 KB)


williamh at gentoo

May 1, 2013, 8:18 PM

Post #20 of 166 (1921 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

On Wed, May 01, 2013 at 11:14:28PM +0200, Fabio Erculiani wrote:
> On Wed, May 1, 2013 at 9:52 PM, "Paweł Hajdan, Jr."
> <phajdan.jr [at] gentoo> wrote:
> > On 5/1/13 3:04 AM, Fabio Erculiani wrote:
> >
> > As far as I read the bug, Mike (vapier) is doing the right thing.
> > Distros doing lots of custom changes can only add more chaos to the picture.
>
> We are a distribution, we have our own goals, thus we change the code
> to better integrate with our ecosystem.
> That's part of the game. If we don't want to do that, we shouldn't be
> running a distro in the first place.
>
> >
> > Have you reached out to relevant upstreams? If they refuse to make
> > changes, that's a different story. So far I think it's reasonable to go
> > to upstreams first.
>
> For just a symlink swap and some file moves? (re: sysvinit)
> We don't need to bless upstream first for such small changes.

Like I've already said too, I don't see that we need to do this change.

Systemd is called /usr/lib/systemd/systemd (it should be
/lib/systemd/systemd), and sysvinit is called /sbin/init,, so I don't
see the need for moving init around and creating all of these symlinks.

I guess I'm not completely opposed to it, I just want you to convince me
that doing it has value. Where I am now is I feel like it adds
complexity for almost no gain.

William
Attachments: signature.asc (0.19 KB)


kentfredric at gmail

May 1, 2013, 9:26 PM

Post #21 of 166 (1919 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

On 2 May 2013 15:18, William Hubbs <williamh [at] gentoo> wrote:

> Like I've already said too, I don't see that we need to do this change.
>
> Systemd is called /usr/lib/systemd/systemd (it should be
> /lib/systemd/systemd), and sysvinit is called /sbin/init,, so I don't
> see the need for moving init around and creating all of these symlinks.
>
> I guess I'm not completely opposed to it, I just want you to convince me
> that doing it has value. Where I am now is I feel like it adds
> complexity for almost no gain.
>
> William
>
>
The best arguments I have for the symlink approach, are:

- its a consistent approach that is bootloader agnostic
- it doesn't require you to understand your bootloaders scripting system to
add it to the init= line
- its "no brains required, and hard to mess up"

bootloader configuration under grub1 for instance, was quite
straight-forward. Now with grub-2, its quite convoluted, for me at least.

Its also sometimes a bit confusing if you need something other than
/sbin/init as your "init", because sometimes you need some pre-init stuff (
like genkernel does ), and you need some /other/ parameter other than init=
so that the pre-init still runs and then passes over to init

Having a symlink that will just do the right thing is helpful for these
cases.

Against, the symlink may introduce parts that are breakable, like if user
messes up and places the destination of the symlink on a different
partition ( shouldn't be a problem, but might be ), or if you're doing an
initird that has init baked into it, you'd have to regenerate that initrd
after changing the symlink ( I think, maybe not, its probably not even a
problem, its just something I'd have to check )

And also, if for whatever reason systemd becomes "unbootable" it might be
slightly hard to boot with the "right" init if you can't change kernel
parameters during boot time.

But noted, those last 2 "against" reasons are "edge cases", where the
arguments for it are "majority cases", so collectively I'm still in favour
of the eselect + symlinks approach.


--
Kent


lxnay at gentoo

May 1, 2013, 10:42 PM

Post #22 of 166 (1912 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

On Thu, May 2, 2013 at 5:26 AM, Kent Fredric <kentfredric [at] gmail> wrote:
>

[snip]

>
> Against, the symlink may introduce parts that are breakable, like if user
> messes up and places the destination of the symlink on a different partition
> ( shouldn't be a problem, but might be ), or if you're doing an initird that
> has init baked into it, you'd have to regenerate that initrd after changing
> the symlink ( I think, maybe not, its probably not even a problem, its just
> something I'd have to check )

eselect-sysvinit handles symlink swapping among files in /sbin/init.d.
So you cannot run into partitioning issues directly.

>
> And also, if for whatever reason systemd becomes "unbootable" it might be
> slightly hard to boot with the "right" init if you can't change kernel
> parameters during boot time.

The same happens if you change the boot arguments and reboot.
This is not something eselect-sysvinit is supposed to solve.

But anyway, eselect-sysvinit is a marginal thing and can be supported
by just providing a more experimental, perhaps masked, sysvinit
ebuild.
I am more concerned about the rest of the story.

>
> But noted, those last 2 "against" reasons are "edge cases", where the
> arguments for it are "majority cases", so collectively I'm still in favour
> of the eselect + symlinks approach.
>
>
> --
> Kent



--
Fabio Erculiani


williamh at gentoo

May 2, 2013, 11:05 AM

Post #23 of 166 (1903 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

On Thu, May 02, 2013 at 04:26:06PM +1200, Kent Fredric wrote:
> - its a consistent approach that is bootloader agnostic
> - it doesn't require you to understand your bootloaders scripting system to
> add it to the init= line

> - its "no brains required, and hard to mess up"

Why should we do something "boot loader agnostic" for the init
system when editing config files is something that all gentoo
users/sysadmins are expected to understand?

> bootloader configuration under grub1 for instance, was quite
> straight-forward. Now with grub-2, its quite convoluted, for me at least.

I haven't looked at grub2 yet, but I can't imagine it being convoluted
based on the documentation I have read.

> Its also sometimes a bit confusing if you need something other than
> /sbin/init as your "init", because sometimes you need some pre-init stuff (
> like genkernel does ), and you need some /other/ parameter other than init=
> so that the pre-init still runs and then passes over to init

Now you are talking about an initramfs, and no symlink is going to take
care of that.

You also still have to keep your boot loader configuration up to date
whenyou upgrade your kernel.

> Having a symlink that will just do the right thing is helpful for these
> cases.

I don't see how the symlink is going to help anything since it doesn't
preclude you editing your boot loader configuration.

> Against, the symlink may introduce parts that are breakable, like if user
> messes up and places the destination of the symlink on a different
> partition ( shouldn't be a problem, but might be ), or if you're doing an
> initird that has init baked into it, you'd have to regenerate that initrd
> after changing the symlink ( I think, maybe not, its probably not even a
> problem, its just something I'd have to check )
>
> And also, if for whatever reason systemd becomes "unbootable" it might be
> slightly hard to boot with the "right" init if you can't change kernel
> parameters during boot time.
>
> But noted, those last 2 "against" reasons are "edge cases", where the
> arguments for it are "majority cases", so collectively I'm still in favour
> of the eselect + symlinks approach.

If this does ever hit the tree, I think it should be defaulted to off
and users should be able to turn it on if they want.

William
Attachments: signature.asc (0.19 KB)


floppym at gentoo

May 2, 2013, 11:13 AM

Post #24 of 166 (1907 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

On Thu, May 2, 2013 at 2:05 PM, William Hubbs <williamh [at] gentoo> wrote:
> On Thu, May 02, 2013 at 04:26:06PM +1200, Kent Fredric wrote:
>> bootloader configuration under grub1 for instance, was quite
>> straight-forward. Now with grub-2, its quite convoluted, for me at least.
>
> I haven't looked at grub2 yet, but I can't imagine it being convoluted
> based on the documentation I have read.
>

If you manually write your own configuration for GRUB2, it is no more
convoluted than for GRUB Legacy.

If you use grub-mkconfig to generate a configuration file, you can
append the init option by setting
GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd" in
/etc/default/grub.

Either way, it's pretty simple.


lxnay at gentoo

May 2, 2013, 12:01 PM

Post #25 of 166 (1952 views)
Permalink
Re: Making systemd more accessible to "normal" users [In reply to]

On Thu, May 2, 2013 at 8:13 PM, Mike Gilbert <floppym [at] gentoo> wrote:
>
> If you manually write your own configuration for GRUB2, it is no more
> convoluted than for GRUB Legacy.
>
> If you use grub-mkconfig to generate a configuration file, you can
> append the init option by setting
> GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd" in
> /etc/default/grub.

Not all the Gentoo users are as skilled as you (a developer). Having a
programmatic, bootloader agnostic way to swap /sbin/init is useful for
the reasons I explained. Yet I haven't read any solid reason not to do
that.

>
> Either way, it's pretty simple.
>

If it's that simple, why on earth do we have all the eselect modules we have!?

Extra modules:
audicle Manage /usr/bin/audicle audio engine
bashcomp Manage contributed bash-completion scripts
binutils Manage installed versions of sys-devel/binutils
blas Manage installed BLAS implementations
bzimage Switch bzImage default kernel by updating
/boot/bzImage symlink
cblas Manage installed CBLAS implementations
cdparanoia Manage /usr/bin/cdparanoia implementation
chuck Manage /usr/bin/chuck audio engine
ctags Manage /usr/bin/ctags implementations
ecj Manage ECJ targets
editor Manage the EDITOR environment variable
emacs Manage /usr/bin/emacs version
env Manage environment variables set in /etc/env.d/
esd Select esound daemon or wrapper
etags Manage /usr/bin/etags implementations
fontconfig Manage fontconfig /etc/fonts/conf.d/ symlinks
gnat Manage the installed gnat compilers
gnome-shell-extensions Manage default settings for systemwide
GNOME Shell extensions
infinality Manage the /etc/fonts/infinality/conf.d symlink
java-nsplugin Manage the Java plugin for Netscape-like Browsers
java-vm Manage the Java system and user VM
kernel Manage the /usr/src/linux symlink
lapack Manage installed LAPACK implementations
lcdfilter Manage the /etc/env.d/99lcdfilter symlink
lightdm Switch between LightDM greeters
locale Manage the LANG environment variable
maven Manage Maven targets
mesa Manage the OpenGL driver architecture used
by media-libs/mesa
miniaudicle Manage /usr/bin/miniAudicle audio engine
modules Query eselect modules
mpg123 Manage /usr/bin/mpg123 implementation
mpost Manage /usr/bin/mpost implementations
news Read Gentoo ("GLEP 42") news items
notify-send Manage /usr/bin/notify-send implementation
nxserver Manages the configuration of NX servers
oodict Manage the configuration of dictionaries
for OpenOffice.Org.
opencl Manage the OpenCL implementation used by your system
opengl Manage the OpenGL implementation used by your system
package-manager Manage the PACKAGE_MANAGER environment variable
pager Manage the PAGER environment variable
pdftex Manage /usr/bin/pdftex implementations
php Manage php installations
pinentry Manage /usr/bin/pinentry implementation
postgresql Manage active PostgreSQL client
applications and libraries
profile Manage the make.profile symlink
python Manage Python symlinks
qtgraphicssystem Manage the system-wide active Qt Graphics System
rails Manage Ruby on Rails versions
rc Manage /etc/init.d scripts in runlevels
ruby Manage Ruby symlinks
settingsd Switch between settingsd implementations
sh Manage /bin/sh (POSIX shell) implementations
sndpeek Manage /usr/bin/sndpeek audio engine
sysvinit Switch between sysvinit implementations
timidity Select default system patchset for TiMidity++
unison Manage /usr/bin/unison versions
vdr-plugin Manage VDR plugins
vi Manage /usr/bin/vi implementations
visual Manage the VISUAL environment variable
wxwidgets Manage the system default wxWidgets profile.
xvmc Manage the XvMC implementation used by your system

Why aren't we telling people to just edit config files!?

--
Fabio Erculiani

First page Previous page 1 2 3 4 5 6 7 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.