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

[Tom Wijsman <TomWij@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3977 bytes --]

On Wed, 15 May 2013 13:25:11 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Wed, May 15, 2013 at 12:59 PM, Tom Wijsman <TomWij@gentoo.org>
> wrote:
> Don't take it personally or as an attack on systemd.  I think he was
> just pointing out that there are many use cases where systemd may not
> be appropriate.

In discussions, I try to not root for object X or Y but be constructive.

> I'm sure if you pulled a glibc from 10 years ago there would be a
> pretty good chance that systemd wouldn't work, but openrc is mainly
> based on shell (not even bash), so it would be pretty likely to work.

That is, if OpenRC is POSIX.1-2001 compatible; it doesn't use any APIs
or programs developed in the last 10 years, it doesn't depend on a
certain way a certain feature works that has changed in last 10 years.

Agreed though, shell changes less often than glibc; but that's merely
based on time, I can imagine in some point in the future there may be
no need for further changes in glibc the same way POSIX stopped
changing years ago; or in other words, it got standardized to be solid.

Going back from those details to OpenRC and systemd, one could say that
one tool depends on old and solid standards while the other depends on
new and developing technologies; there are reasons enough to choose for
either. Some things are better done by A, others by B.

That's not what I'm after, I want to know when either A or B doesn't
work; this is a matter of 1) trying to make it work for our users and 2)
documenting it to our users in which occasions it doesn't work.

Though, I went to take a look, if I were to trust the systemd ebuild it
seems that it doesn't work with glibc versions prior to May 2009 (2.10)
so I think we're in a quite good standing here; the amount of users
that don't upgrade for four years that need systemd is likely minor,
hence we don't need to document this and this doesn't form a problem.

> Likewise if you picked a kernel from a few years ago systemd with all
> its use of cgroups and such probably wouldn't work, while openrc is
> simpler.  Certainly if you picked a FreeBSD kernel systemd will not
> work.  (Keep in mind the set of systems not using a recent linux
> kernel includes all systems that don't run linux at all.)

I don't think the goal of making systemd more accessible has anything
to do with people that don't upgrade for a few years; it doesn't stand
in their way and given that it is out of the Portage tree we likely
don't support these kind of practices anymore. Support is a big word
and doesn't mean we don't try to help them if they have a solid case,
but I can't see someone with <2006 hardware wanting to run GNOME 3.8.

> In any case, there really isn't any "decision" to make here.

Then for what purpose is this discussion still going on?

> As long as devs want to support openrc it will be supported.
> Likewise with eudev.  As long as devs want to support systemd and
> udev those will be options as well. The beauty of Gentoo is that more
> than any distro it maximizes the options for our users.  The changes
> in Gnome may eliminate Gnome+openrc as a practical option, and when
> those teams stop supporting the combo then users will have to make a
> choice to not use one or the other.  Gentoo is about choice, but that
> doesn't mean that we have to offer EVERY possible choice.  If
> somebody wants to support my hp48 calculator as a Gentoo arch that
> would be great, but that doesn't mean that I can sta hassling teams
> to do the work for me.
> 
> Gentoo is about working TOGETHER to provide choices, not about telling
> others to make choices work for you.

That's what I'm after, I have send a very similar mail two months ago.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]