[gentoo-dev] Changing order of default virtual/udev provider

[gentoo-dev] Changing order of default virtual/udev provider

[Patrick Lauer]

Ohey,

I've opened a bug at:
https://bugs.gentoo.org/show_bug.cgi?id=573922

The idea here is to change the order of the providers of virtual/udev.
For existing installs this has zero impact.
For stage3 this would mean that eudev is pulled in instead of udev.

The rationale behind this is:

* eudev is an in-house fork, and there's more than a dozen distros
already using it by default that are not us. Which is a little bit weird ...

* Both udev and eudev have pretty much feature parity, so there won't be
any user-visible changes

* udev upstream strongly discourages standalone udev (without systemd)
since at least 2012

(see for example:
https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html
https://lkml.org/lkml/2012/10/3/618
)

So it'd be (1) following upstreams recommendations and (2) dogfooding
our own tools. I don't see any downsides to this :)

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Brian Dolbec]

On Mon, 8 Feb 2016 10:08:22 +0100
Patrick Lauer <patrick@gentoo.org> wrote:

> Ohey,
> 
> I've opened a bug at:
> https://bugs.gentoo.org/show_bug.cgi?id=573922
> 
> The idea here is to change the order of the providers of virtual/udev.
> For existing installs this has zero impact.
> For stage3 this would mean that eudev is pulled in instead of udev.
> 
> The rationale behind this is:
> 
> * eudev is an in-house fork, and there's more than a dozen distros
> already using it by default that are not us. Which is a little bit
> weird ...
> 
> * Both udev and eudev have pretty much feature parity, so there won't
> be any user-visible changes
> 
> * udev upstream strongly discourages standalone udev (without systemd)
> since at least 2012
> 
> (see for example:
> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html
> https://lkml.org/lkml/2012/10/3/618
> )
> 
> So it'd be (1) following upstreams recommendations and (2) dogfooding
> our own tools. I don't see any downsides to this :)
> 

+1

I switched to eudev a few years ago and glad I did.

The non-systemd profiles should have eudev as default.

-- 
Brian Dolbec <dolsen>

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Anthony G. Basile]

On 2/8/16 4:25 AM, Brian Dolbec wrote:
> On Mon, 8 Feb 2016 10:08:22 +0100
> Patrick Lauer <patrick@gentoo.org> wrote:
> 
>> Ohey,
>>
>> I've opened a bug at:
>> https://bugs.gentoo.org/show_bug.cgi?id=573922
>>
>> The idea here is to change the order of the providers of virtual/udev.
>> For existing installs this has zero impact.
>> For stage3 this would mean that eudev is pulled in instead of udev.
>>
>> The rationale behind this is:
>>
>> * eudev is an in-house fork, and there's more than a dozen distros
>> already using it by default that are not us. Which is a little bit
>> weird ...
>>
>> * Both udev and eudev have pretty much feature parity, so there won't
>> be any user-visible changes
>>
>> * udev upstream strongly discourages standalone udev (without systemd)
>> since at least 2012
>>
>> (see for example:
>> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html
>> https://lkml.org/lkml/2012/10/3/618
>> )
>>
>> So it'd be (1) following upstreams recommendations and (2) dogfooding
>> our own tools. I don't see any downsides to this :)
>>
> 
> +1
> 
> I switched to eudev a few years ago and glad I did.
> 
> The non-systemd profiles should have eudev as default.
> 

just pile the pressure on :)

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Andrew Savchenko]

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

On Mon, 8 Feb 2016 06:12:05 -0500 Anthony G. Basile wrote:
> On 2/8/16 4:25 AM, Brian Dolbec wrote:
> > On Mon, 8 Feb 2016 10:08:22 +0100
> > Patrick Lauer <patrick@gentoo.org> wrote:
> > 
> >> Ohey,
> >>
> >> I've opened a bug at:
> >> https://bugs.gentoo.org/show_bug.cgi?id=573922
> >>
> >> The idea here is to change the order of the providers of virtual/udev.
> >> For existing installs this has zero impact.
> >> For stage3 this would mean that eudev is pulled in instead of udev.
> >>
> >> The rationale behind this is:
> >>
> >> * eudev is an in-house fork, and there's more than a dozen distros
> >> already using it by default that are not us. Which is a little bit
> >> weird ...
> >>
> >> * Both udev and eudev have pretty much feature parity, so there won't
> >> be any user-visible changes
> >>
> >> * udev upstream strongly discourages standalone udev (without systemd)
> >> since at least 2012
> >>
> >> (see for example:
> >> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html
> >> https://lkml.org/lkml/2012/10/3/618
> >> )
> >>
> >> So it'd be (1) following upstreams recommendations and (2) dogfooding
> >> our own tools. I don't see any downsides to this :)
> >>
> > 
> > +1
> > 
> > I switched to eudev a few years ago and glad I did.
> > 
> > The non-systemd profiles should have eudev as default.
> > 
> 
> just pile the pressure on :)

+1
I use eudev on all setups (both home and work) for years now.
The experience is yummy.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/08/2016 01:08 AM, Patrick Lauer wrote:
> Ohey,
> 
> I've opened a bug at: 
> https://bugs.gentoo.org/show_bug.cgi?id=573922
> 
> The idea here is to change the order of the providers of
> virtual/udev. For existing installs this has zero impact. For
> stage3 this would mean that eudev is pulled in instead of udev.
> 
> The rationale behind this is:
> 
> * eudev is an in-house fork, and there's more than a dozen distros 
> already using it by default that are not us. Which is a little bit
> weird ...
> 
> * Both udev and eudev have pretty much feature parity, so there
> won't be any user-visible changes
> 
> * udev upstream strongly discourages standalone udev (without
> systemd) since at least 2012
> 
> (see for example: 
> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.
html
>
> 
https://lkml.org/lkml/2012/10/3/618
> )
> 
> So it'd be (1) following upstreams recommendations and (2)
> dogfooding our own tools. I don't see any downsides to this :)
> 

No complaints here. I've used eudev ever since I started using Gentoo
back in 2012, to escape systemd. I'm completely okay with us
defaulting to eudev. In fact, I wonder why it hasn't already happened.
Upstream is actively against Gentoo, after all [1].

Out of curiosity, which distros are shipping with eudev by default?

[1]:
https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.htm
l
- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWuIpDAAoJEAEkDpRQOeFwF0AP/3sRQzMUcdLLFyxYSBzjQW4e
mzV2xMXknqkkjnNHe/tygAMlB91usZ9m2HJtRMYjqIYj6OlGBOHHdNw01FKpYeSu
Ogg7avAge1/cXsFS/ZmxenImG2z6k8Nt+74S5d9QzvC/AyQ8BCBaUI4HVxxb3ULn
au7GDRaJ1+sX0A8EsQtKb6UxAO9juueabWu3CeddjLlMnR0FdtyOjAEN7SkPgLy9
oXTwn3eLjvBeY6t1unk3kJD4aOBfZzTupX19hiDr6W6K8mo/q9XwLOcltslerDBO
OTsq3HcW+IDgp91bnSEQJnUMUec2Awce1qlDX8Khsybu9qwcfbyICOY4l3uCYCN9
bc5Z5luWwrV5OA64apjdjCxUgJCVv0b92JcNcIJ9F9cMIn2Lxp5xXRNCNCL6PkSW
+kVt8w1HeQk1XQXedilThgDzSHBZVjPKJMqjpF6deVXrALR1ZoZ3i17TYkkj7mGx
+NHQq3PENUDho7VeujdVyroybaWlBO/B3/GgxCBiybI8R+0YyN14H1W86LlHn4ol
jgdPxs07/F/XaV64UEsKsD+2vBKJeRVsYCpinjgfTUciEUyxW2cETobUTd2LoJeq
b3SP+DEuAOD8qJwpk/isq6yYnQD9+JPbYGedz1D0vdpj5S82pHO4wZ+iuxnmHIHS
dMKUlMc5eb+ykgRLfQmy
=c1uf
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Patrick Lauer]

On 02/08/2016 01:30 PM, Daniel Campbell wrote:
>
> Out of curiosity, which distros are shipping with eudev by default?
>
From [1]:

"""
1. AUSTRUMI switched to eudev in March 2013 (see package list for the
2.6.8 release).

2. Parted Magic switched to eudev in August 2013.

3. Quirky (experimental version of Puppy Linux) switched to eudev in
December 2013.

4. 0linux switched to eudev in February 2014 (see base packages for the
eta release).

5. Linux From Scratch (standard version) switched to eudev in March 2014
(see this commit).

6. Vine Linux switched to eudev in June 2014.

7. Funtoo Linux switched to eudev in June 2014.

8. CRUX switched to eudev in July 2014.

9. Void Linux switched to eudev in July 2014 (see this commit).

10. Guix System Distribution switched to eudev in September 2014.

11. NuTyX switched to eudev in October 2014 (see system packages for the
Saravane release).

12. Puppy Linux (standard version) switched to eudev in October 2014
(see package list for the 6.0 tahrpup release).

13. Manjaro Linux (OpenRC edition) has used eudev since the initial
release in December 2014.

14. Calculate Linux switched to eudev in April 2015.

15. Alpine Linux (desktop edition) switched to eudev in July 2015.
"""

[1] https://forums.gentoo.org/viewtopic-t-1003230.html

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/08/2016 04:32 AM, Patrick Lauer wrote:
> On 02/08/2016 01:30 PM, Daniel Campbell wrote:
>> 
>> Out of curiosity, which distros are shipping with eudev by
>> default?
>> 
> From [1]:
> 
> """ 1. AUSTRUMI switched to eudev in March 2013 (see package list
> for the 2.6.8 release).
> 
> 2. Parted Magic switched to eudev in August 2013.
> 
> 3. Quirky (experimental version of Puppy Linux) switched to eudev
> in December 2013.
> 
> 4. 0linux switched to eudev in February 2014 (see base packages for
> the eta release).
> 
> 5. Linux From Scratch (standard version) switched to eudev in March
> 2014 (see this commit).
> 
> 6. Vine Linux switched to eudev in June 2014.
> 
> 7. Funtoo Linux switched to eudev in June 2014.
> 
> 8. CRUX switched to eudev in July 2014.
> 
> 9. Void Linux switched to eudev in July 2014 (see this commit).
> 
> 10. Guix System Distribution switched to eudev in September 2014.
> 
> 11. NuTyX switched to eudev in October 2014 (see system packages
> for the Saravane release).
> 
> 12. Puppy Linux (standard version) switched to eudev in October
> 2014 (see package list for the 6.0 tahrpup release).
> 
> 13. Manjaro Linux (OpenRC edition) has used eudev since the
> initial release in December 2014.
> 
> 14. Calculate Linux switched to eudev in April 2015.
> 
> 15. Alpine Linux (desktop edition) switched to eudev in July 2015. 
> """
> 
> [1] https://forums.gentoo.org/viewtopic-t-1003230.html
> 
> 
> 
Wow, that's actually pretty great news. That's enough 'momentum' to
maybe maintain a smaller ecosystem free of any particular init-system
preference! Thanks for sharing!

While I was going over some previous stuff I'd written, I noticed you
were actually part of some Debian mailing list discussions from a few
years ago. Kinda funny how things work out, huh? :)

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWuIwHAAoJEAEkDpRQOeFwDM8P/3jy7+sTp7iElztIcmpmNbE9
GkPNmhk1/tQh6gRn1Ho7lJl8FxF5DiY1o2HxjtITztGb0O4nm1ENbiBKx8JF/X0u
02KBD2WakTTK/sVOmTeN5EqnRFlQJ4PQfSAGsgzLbi/9Ky7IoNHalef2FM+ZSi6A
GrTHSgK8Elhnzblplz1SyAJ+iqE+AR9oNdwS6/7uraRi2t6gIGLBaWfhUwK3HVxn
h+mybPrbEuVxAC/Xen8iy4F1w75S1JI9I5FRwgh6farhDqMMjd920BbxePzA7j/h
VTnDSnjVQKE28un6RvdhWqWsxfVdmemSOpsQuuUOh3Mn3qjtYvK+wYQxxclmct4T
L7qjv6KwidGIA/EV1O7DmRf81xgpV0pTqdfMT7WONItgV+ltl9hz+eoHHx2aFekD
T4zCY0kEjt8hXK+4S04eVL6clspmHXp45MaA1JIaY/qxrRKJYu88+FalgQiDcm/X
38oyu3gJq0FZ9B3jLa/qEVn+Df6BA7cSbPufJOcr35DjaDBZnJbo+qLNb4GPo74P
SQ0iUBBfxIXOOMA14f2iByfXhtnCZaZVq3+CkC9FjQwXwkwKSxuLwi+hqf48EIPb
71ITD4N/Kjt50ajzgbfI0A09PDv//j3tWorU83ep0gIM02sGpjsxoGxPL+cWKOh4
+KhWxuCbPEXbpIq935hQ
=5rjF
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Michał Górny]

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

On Mon, 8 Feb 2016 10:08:22 +0100
Patrick Lauer <patrick@gentoo.org> wrote:

> Ohey,
> 
> I've opened a bug at:
> https://bugs.gentoo.org/show_bug.cgi?id=573922
> 
> The idea here is to change the order of the providers of virtual/udev.
> For existing installs this has zero impact.
> For stage3 this would mean that eudev is pulled in instead of udev.
> 
> The rationale behind this is:
> 
> * eudev is an in-house fork, and there's more than a dozen distros
> already using it by default that are not us. Which is a little bit weird ...

That's not an argument. I can also fork random system components. Would
you consider that a reason to replace the defaults with our 'in-house'
forks?

> * Both udev and eudev have pretty much feature parity, so there won't be
> any user-visible changes
> 
> * udev upstream strongly discourages standalone udev (without systemd)
> since at least 2012
> 
> (see for example:
> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html
> https://lkml.org/lkml/2012/10/3/618
> )
> 
> So it'd be (1) following upstreams recommendations and (2) dogfooding
> our own tools. I don't see any downsides to this :)

I'm strongly against this, because:

1. It is a conflict-induced fork. As such, it will never be merged
upstream and it will never be supported upstream. In fact, it is
continually forces to follow upstream changes and adapt to them. eudev
is more likely to break because of the Gentoo developer(s) working hard
to merge upstream changes to their incompatible code.

2. Many of Gentoo users are programmers who appreciate the 'vanilla'
API experience Gentoo often provides. Switching the defaults to a fork
that is known to intentionally diverge from upstream goes against that
principle. Programs written against eudev may not work correctly with
upstream udev.

3. eudev has fallen behind systemd/udev more than once in the past,
and caused visible breakage to users this way.

4. eudev is underdocumented, and the maintainer admits that 'he sucks
at documenting'. In fact, did anyone even bother to note how far eudev
diverges from upstream udev to this point?

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 02/08/2016 10:25 AM, Brian Dolbec wrote:
> On Mon, 8 Feb 2016 10:08:22 +0100 Patrick Lauer 
> <patrick@gentoo.org> wrote:
> 
>> Ohey,
>> 
>> I've opened a bug at: 
>> https://bugs.gentoo.org/show_bug.cgi?id=573922
>> 
>> The idea here is to change the order of the providers of 
>> virtual/udev. For existing installs this has zero impact. For 
>> stage3 this would mean that eudev is pulled in instead of udev.


> 
> +1
> 
> I switched to eudev a few years ago and glad I did.
> 
> The non-systemd profiles should have eudev as default.
> 

+1 from me on this change of default order.

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWuI+kAAoJECULev7WN52FAaYH/01R41pe88P+9mMOO403UwSH
X3m3uO+RisAFeDpfnlDieIuaalaR4zrZQYChgBa+UZ4/KO4Gw5I4UpKL5RJSsFGX
6ts3aYwVtpGOn1lehMl6p6U8m+l2vjwX11b6Cf7E01wDG01DGU8OMU8kpfoxPqkG
Bi+XCCgZRcgOmeBzxjtJ9WJK18GI0cpta7Z8+8mZfHoMPuR8tpDrzFUwRKpCuvU7
eC7DshBLEtSbFPSIBGy+vhYqsC5exZWAABk72XVmOKGbQA471zztejgEw1FQEHB9
zmvyiMNNWQ8rDSr7XOhQHAVbMhP+zliTEyg3WFMzeCsCL3nB8hk8KuLsEO33208=
=5Ato
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/08/2016 04:46 AM, Michał Górny wrote:
> On Mon, 8 Feb 2016 10:08:22 +0100 Patrick Lauer
> <patrick@gentoo.org> wrote:
> 
>> Ohey,
>> 
>> I've opened a bug at: 
>> https://bugs.gentoo.org/show_bug.cgi?id=573922
>> 
>> The idea here is to change the order of the providers of
>> virtual/udev. For existing installs this has zero impact. For
>> stage3 this would mean that eudev is pulled in instead of udev.
>> 
>> The rationale behind this is:
>> 
>> * eudev is an in-house fork, and there's more than a dozen
>> distros already using it by default that are not us. Which is a
>> little bit weird ...
> 
> That's not an argument. I can also fork random system components.
> Would you consider that a reason to replace the defaults with our
> 'in-house' forks?
> 
>> * Both udev and eudev have pretty much feature parity, so there
>> won't be any user-visible changes
>> 
>> * udev upstream strongly discourages standalone udev (without
>> systemd) since at least 2012
>> 
>> (see for example: 
>> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516
.html
>>
>> 
https://lkml.org/lkml/2012/10/3/618
>> )
>> 
>> So it'd be (1) following upstreams recommendations and (2)
>> dogfooding our own tools. I don't see any downsides to this :)
> 
> I'm strongly against this, because:
> 
> 1. It is a conflict-induced fork. As such, it will never be merged 
> upstream and it will never be supported upstream. In fact, it is 
> continually forces to follow upstream changes and adapt to them.
> eudev is more likely to break because of the Gentoo developer(s)
> working hard to merge upstream changes to their incompatible code.
> 
> 2. Many of Gentoo users are programmers who appreciate the
> 'vanilla' API experience Gentoo often provides. Switching the
> defaults to a fork that is known to intentionally diverge from
> upstream goes against that principle. Programs written against
> eudev may not work correctly with upstream udev.
> 
> 3. eudev has fallen behind systemd/udev more than once in the
> past, and caused visible breakage to users this way.
> 
> 4. eudev is underdocumented, and the maintainer admits that 'he
> sucks at documenting'. In fact, did anyone even bother to note how
> far eudev diverges from upstream udev to this point?
> 
May I ask which meaningful effects this has on systems that don't
already run systemd? As it stands, upstream udev is one step (kdbus)
away from full reliance on specific kernel and systemd versions. Which
features of eudev have fallen behind enough to create breakage for
users that use non-systemd init systems?

Given that eudev's purpose is to be init-agnostic, I would argue it's
more in line with Gentoo's general goals and upstream is hostile
enough to Gentoo's efforts to deliberately structure their software in
a fashion that makes life harder for us. There's certainly no harm in
considering them upstream and perhaps modeling eudev's updates/patches
after theirs, but given upstream's goals to coerce everyone into using
their init system, what workable long-term solution is there? A fork
was really the only pragmatic approach here.

This reminds me of the ffmpeg/libav issue. Thankfully since we've
gotten past that, eudev/udev should be a simpler matter because we
have prior experience to go off of.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWuJB9AAoJEAEkDpRQOeFwR74QAJ0a+uFI7E4Gmf6QGWe4t+lH
hWrmflClGOcDOiP6imVTU+yrtL/f/aHAQUG4whfDRzc3zR4uBtpjhIKgPEdAsyFh
aSvuOVjon6hEEvE2UA3SAOJErAD8bhGKDNArtLpLuWP9Ekjv7InL8EVFKfMbR/j2
tQMInjCip5BV9jf++9D/Nia46ilc/65eQz9k4jpqedVlZjGn/RIxpJXcKQAtdMPn
JZ3w2n2przirn9hVQn7MZc4tBIPARnC1G/s7BC2pvGvbVwHTKZrkKhdS8kTWHJzk
ME93G1HGRYJrSsHU0U0GSmbh+tC/1xAJFjcXG8+fi/dBjtYEyveMIQB66fVHkcvH
pYuHeZ+uiuCvhRkOETYC6A92FFSQe41ofHf0JQx1OW0Br/mric74z5rg5BDA4bx7
22TrnN2M+cP2CC5jQi61rQ22Xh6jZ3x6EHuMN55iebuR7TuUBYBmT/qX1hvyubHl
TPAKoxFnkhxcC9Ioe2lEpQxYdugQ0wxhUwQOvGsb/O1wU3WhX6ADWOavElhL7qHO
5vTiC6uq5ACz/qiwQ6QJU4ocSaJ1/qBTPFpp+WxeDryAEzmnjmiic/Uv0HGYWRaE
4GR0Kjv2AWuz4xEIbGKFadivUjTMVJHgW1CR2b8LId11UloEbjBBz48ar/fMS1xP
ve4SvOASasKCk1Cc3uxV
=LzE5
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Dale]

Andrew Savchenko wrote:
> On Mon, 8 Feb 2016 06:12:05 -0500 Anthony G. Basile wrote:
>> On 2/8/16 4:25 AM, Brian Dolbec wrote:
>>> On Mon, 8 Feb 2016 10:08:22 +0100
>>> Patrick Lauer <patrick@gentoo.org> wrote:
>>>
>>>> Ohey,
>>>>
>>>> I've opened a bug at:
>>>> https://bugs.gentoo.org/show_bug.cgi?id=573922
>>>>
>>>> The idea here is to change the order of the providers of virtual/udev.
>>>> For existing installs this has zero impact.
>>>> For stage3 this would mean that eudev is pulled in instead of udev.
>>>>
>>>> The rationale behind this is:
>>>>
>>>> * eudev is an in-house fork, and there's more than a dozen distros
>>>> already using it by default that are not us. Which is a little bit
>>>> weird ...
>>>>
>>>> * Both udev and eudev have pretty much feature parity, so there won't
>>>> be any user-visible changes
>>>>
>>>> * udev upstream strongly discourages standalone udev (without systemd)
>>>> since at least 2012
>>>>
>>>> (see for example:
>>>> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html
>>>> https://lkml.org/lkml/2012/10/3/618
>>>> )
>>>>
>>>> So it'd be (1) following upstreams recommendations and (2) dogfooding
>>>> our own tools. I don't see any downsides to this :)
>>>>
>>> +1
>>>
>>> I switched to eudev a few years ago and glad I did.
>>>
>>> The non-systemd profiles should have eudev as default.
>>>
>> just pile the pressure on :)
> +1
> I use eudev on all setups (both home and work) for years now.
> The experience is yummy.
>
> Best regards,
> Andrew Savchenko

+1 

As a lowly user, I switched very shortly after eudev was started.  I
think it was like the second or third release.  So far, I've not seen
any problems.  It just works. 

One thing about Gentoo, for those who don't want eudev, they can always
select another tool. 

Back to my hole.

Dale

:-)  :-)

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Kent Fredric]

On 9 February 2016 at 01:46, Michał Górny <mgorny@gentoo.org> wrote:
> 1. It is a conflict-induced fork. As such, it will never be merged
> upstream and it will never be supported upstream. In fact, it is
> continually forces to follow upstream changes and adapt to them. eudev
> is more likely to break because of the Gentoo developer(s) working hard
> to merge upstream changes to their incompatible code.
>
> 2. Many of Gentoo users are programmers who appreciate the 'vanilla'
> API experience Gentoo often provides. Switching the defaults to a fork
> that is known to intentionally diverge from upstream goes against that
> principle. Programs written against eudev may not work correctly with
> upstream udev.
>
> 3. eudev has fallen behind systemd/udev more than once in the past,
> and caused visible breakage to users this way.
>
> 4. eudev is underdocumented, and the maintainer admits that 'he sucks
> at documenting'. In fact, did anyone even bother to note how far eudev
> diverges from upstream udev to this point?


These problems can be resolved, but the resources involved with
resolving them are not trivial.

For instance, all it would take to change #1 and #2 would be for
`eudev` to become an external project, not an implied child of Gentoo,
and for our tools to consider it as such.

That is, instead of users being encouraged to see eudev as "Gentoos
Udev Fork", they'd have to see it as a stand-alone fork of udev with
the goals of retaining the axioms and values of Unix systems and
simplicity.

Then it would be resorted to the question of "Which external competing
udev implementation makes sense for our default value in conjunction
with our other default value of rc systems: OpenRC"

#3 and #4 are the more important criticisms IME, and we need eudev to
be the responsibility of more than one person and have a
survival,reliability and progression strategy that will continue in
the event upstream drop udev entirely to the point that Gentoo cannot
simply port their changes anymore.

Because if *that* happens, the fragmentation will become a much bigger
problem, and systemd getting bug fixes and updates while eudev gets no
love is not really much of a long term solution.

In short, for eudev to be a viable long term solution, we might need
to have a guarantee of investing a lot more resources in the project
than we presently can afford.

And until we have some kind of tacit assurance that we can do this,
making it the default might not be the best choice.

That said, if the upstream fragmentation is going to go in the "no
backports and udev goes away" direction, users currently taking the
"udev" choice are in for some bumpy waters eventually anyway.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/02/16 07:46 AM, Michał Górny wrote:
> On Mon, 8 Feb 2016 10:08:22 +0100 Patrick Lauer
> <patrick@gentoo.org> wrote:
> 
>> Ohey,
>> 
>> I've opened a bug at: 
>> https://bugs.gentoo.org/show_bug.cgi?id=573922
>> 
>> The idea here is to change the order of the providers of
>> virtual/udev. For existing installs this has zero impact. For
>> stage3 this would mean that eudev is pulled in instead of
>> udev.
>> 
>> The rationale behind this is:
>> 
>> * eudev is an in-house fork, and there's more than a dozen
>> distros already using it by default that are not us. Which is a
>> little bit weird ...
> 
> That's not an argument. I can also fork random system components.
> Would you consider that a reason to replace the defaults with our
> 'in-house' forks?
> 
>> * Both udev and eudev have pretty much feature parity, so there
>> won't be any user-visible changes
>> 
>> * udev upstream strongly discourages standalone udev (without
>> systemd) since at least 2012
>> 
>> (see for example: 
>> https://lists.freedesktop.org/archives/systemd-devel/2012-June/0055
16.html
>>
>> 
https://lkml.org/lkml/2012/10/3/618
>> )
>> 
>> So it'd be (1) following upstreams recommendations and (2)
>> dogfooding our own tools. I don't see any downsides to this :)
> 
> I'm strongly against this, because:
> 
> 1. It is a conflict-induced fork. As such, it will never be
> merged upstream and it will never be supported upstream. In fact,
> it is continually forces to follow upstream changes and adapt to
> them. eudev is more likely to break because of the Gentoo
> developer(s) working hard to merge upstream changes to their
> incompatible code.

Yes this is true -- however, this claim is based on sys-fs/udev
actually being an upstream package and it really isn't -- it's a
partial package of systemd that upstream really doesn't support as a
separate package anyhow (hence the size and complexity of the ebuild
to build it).

> 
> 2. Many of Gentoo users are programmers who appreciate the
> 'vanilla' API experience Gentoo often provides. Switching the
> defaults to a fork that is known to intentionally diverge from
> upstream goes against that principle. Programs written against
> eudev may not work correctly with upstream udev.

No.  Eudev ensures compatibility with systemd-udev as a principle,
we are not going to fork the API.  Unless upstream decides to do
something with udev that breaks it previous API in an incompatible
way that cannot be reproduced without the rest of systemd, eudev
will retain API compatibility with systemd-udev.  Eudev would not be
nearly as useful as it is, if it wasn't a drop-in replacement for
upstream udevd and libudev.

Besides, now that gudev is its own package there's really just
libudev (rarely changes now), rules.d syntax (afaik hasnt changed
since before the fork), and the support for the builtin's (which we
keep up with) that we need to maintain.


> 3. eudev has fallen behind systemd/udev more than once in the
> past, and caused visible breakage to users this way.


Similarly, in the last 6-12 months eudev's releases have been AHEAD
of sys-fs/udev more than once, too.


> 4. eudev is underdocumented, and the maintainer admits that 'he
> sucks at documenting'. In fact, did anyone even bother to note
> how far eudev diverges from upstream udev to this point?


At this point, WITHOUT the patch applied by USE="rule-generator",
divergence is fairly minimal -- the primary difference is that udev
and libudev contain the internal functions that have been migrated
upstream into the giant libsystemd-common.  Most of the various
improvement patches that we made in the early days have either been
integrated upstream or have been dropped as they are no longer
relevant.  Blueness knows more on this, as I haven't done a thorough
examination of upstream's code in quite a while.


Oh, eudev also doesn't handle network link setup given that external
tools already do this just fine.  That's another difference, though
not one that matters programmatically.  That said, the network-link
setup was added primarily to support systemd's use-case, and there's
very little need or point in having it done by udevd on an rc-based
system.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAla4u48ACgkQAJxUfCtlWe02JgD+KjY9zpYjh8JZf1gAu3QUahjN
EqtAkPbXZLsELPBuAHgA/Aq2sHQIFg2iKYKow29HXIb43JKUbV96t37m9tUIBBm4
=trQk
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On 2/8/16, Patrick Lauer <patrick@gentoo.org> wrote:
> The idea here is to change the order of the providers of virtual/udev.
> For existing installs this has zero impact.
> For stage3 this would mean that eudev is pulled in instead of udev.

Might I suggest a slightly different approach.  I don't really have a
strong preference on the order of providers in this virtual, though I
don't really care for a direction of promoting in-house tools over
standardized ones (genkernel is another one that comes to mind).
Gentoo's distinctiveness should come from being source-based and
offering choices, not from a large collection of internal forks (I
have nothing against people working on them, but they shouldn't be the
default experience).

However, I think we're actually missing the bigger issue here.  Why is
this virtual even in @system to begin with?  When I set up a chroot or
some kinds of containers I don't need udev, or sysvinit (or openssh -
but let's set that one aside for now).

We don't stick grub or genkernel or even gentoo-sources in our
stage3s.  Why stick (e)udev in there?

It seems like this should just be another step in the handbook - pick
your desired device manager.

Obviously if we produce a boot CD it will need a device manager (and
kernel and bootloader and network manager), and I don't care which one
it is.

This just seems more like the Gentoo way, and it completely sidesteps
all the controversy over defaults.  We're already working on fixing
the few remaining functions.sh references so that openrc can be
removed from the system set as well.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/02/16 11:18 AM, Rich Freeman wrote:
> However, I think we're actually missing the bigger issue here.
> Why is this virtual even in @system to begin with?  When I set up
> a chroot or some kinds of containers I don't need udev, or
> sysvinit (or openssh - but let's set that one aside for now).
> 
> We don't stick grub or genkernel or even gentoo-sources in our 
> stage3s.  Why stick (e)udev in there?
> 
> It seems like this should just be another step in the handbook -
> pick your desired device manager.
> 
> Obviously if we produce a boot CD it will need a device manager
> (and kernel and bootloader and network manager), and I don't care
> which one it is.
> 
> This just seems more like the Gentoo way, and it completely
> sidesteps all the controversy over defaults.  We're already
> working on fixing the few remaining functions.sh references so
> that openrc can be removed from the system set as well.
> 

I thought the point of this discussion had to do mostly with what
udev variant gets installed when a user doesn't specify one.  And
AFAIK, since there are still plenty of packages that *DEPEND on
virtual/udev , the discussion's still worth having isn't it?

Besides, if we just move the goal of this discussion from "order of
atoms in virtual/udev" to "order of items in this new Handbook
page", we still need to decide what the default is don't we?



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAla4ye0ACgkQAJxUfCtlWe0fQQEAhwlNL4UR7OCHwQrIspTJjan0
eRcokUvWl4VSq7BZtjoA/AszQTLuS3AXB4hTB7Vd/fndJ1y+YrbNw1Z+V/pF4tNa
=0G1K
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Brian Dolbec]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, 8 Feb 2016 12:01:33 -0500
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 08/02/16 11:18 AM, Rich Freeman wrote:
> > However, I think we're actually missing the bigger issue here.
> > Why is this virtual even in @system to begin with?  When I set up
> > a chroot or some kinds of containers I don't need udev, or
> > sysvinit (or openssh - but let's set that one aside for now).
> > 
> > We don't stick grub or genkernel or even gentoo-sources in our 
> > stage3s.  Why stick (e)udev in there?
> > 
> > It seems like this should just be another step in the handbook -
> > pick your desired device manager.
> > 
> > Obviously if we produce a boot CD it will need a device manager
> > (and kernel and bootloader and network manager), and I don't care
> > which one it is.
> > 
> > This just seems more like the Gentoo way, and it completely
> > sidesteps all the controversy over defaults.  We're already
> > working on fixing the few remaining functions.sh references so
> > that openrc can be removed from the system set as well.
> >   
> 
> I thought the point of this discussion had to do mostly with what
> udev variant gets installed when a user doesn't specify one.  And
> AFAIK, since there are still plenty of packages that *DEPEND on
> virtual/udev , the discussion's still worth having isn't it?
> 
> Besides, if we just move the goal of this discussion from "order of
> atoms in virtual/udev" to "order of items in this new Handbook
> page", we still need to decide what the default is don't we?


Yes, we do.

Also, it is releng's intention to change to a stage4 for normal new
install stages.  It will contain the most needed pkgs for new installs,
and allow the @system set to be trimmed down more.  It is entirely
possible, to at that point, then create smaller chroot/container images
without undue hardships and complexities for new installs.

But please let's not sidetrack this thread more with this tangent.
That's a different bikeshed to paint.



- -- 
Brian Dolbec <dolsen>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJWuNEMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG
QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7YTVQQAJhStpgaDT2pqMsVuTO3HZx6
XfaZoNtcN01nqOttBwQ4C+17n8Rv2/d52Zu6lc3YSrdPgHRGOVT0LU8CyzZlz8Rw
rnFeo5oZAZheqlA/4UzRMOkhXbOvT4FRDL1bF/q5t00h+pADoPDSC3ZIyS8enkvr
Evm3DYpDDT40pM5f7cwlAqRarJL604XDgFmU5Qhtmtnxw+TRIicGTwHoWe4fk77u
PNm3ZrU+ea7b2XAwKH+oDVM0UDMfFLi37APGd4R2VC0jJmp0msPnNfKRvpURcNo5
3iZMMDuM7vqJergB2yCfiqaGdHmaEPX1PLpQEuhgLWS0b6lCN4JKenYpRdNVLjZG
FqOEtSVUs9iNt++XmsZ6goLQAczePOxqR/aAJOMrXuhePiuXMRmm1MBQK2yRRo6q
6MU/lj+1YAzEWMyOZH9GNzQhCl1cBj+futm6mRTWYsNCaKOGi/ocnIHiQpXyKf/U
dp/hlvx2rhqMz6eqO60OaJHaKzbCV6EbGb3kv0AsC4VGGFS+DpoUen21aetBh82O
aE6c/hKNvsgARQl0mpwFDttSnB24oRr8E9pR5Rvf7iQJwL7h/5gHvs2YQRL9PxFR
vSN1R67Sge9JrAzQ/OmEBbl5exO2a1/0HShfdfvU6oA/lDShFHyttJXYxGi0tDym
A2Bo/b9FonL7aEmwilCH
=PiEj
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Changing order of default virtual/udev provider

[William Hubbs]

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

As one of the maintainers of sys-fs/udev, I am very conflicted about
this.

I tend to agree with Kent that we need to be absolutely sure before we
switch the default that eudev will maintain feature parity with udev,
now and in the future, e.g. when a new release of udev hits, a new
release of eudev must happen asap that supports all of the features of
the new udev.

I also think mgorny's arguments against doing this must be considered.

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Pacho Ramos]

El lun, 08-02-2016 a las 12:12 -0600, William Hubbs escribió:
> As one of the maintainers of sys-fs/udev, I am very conflicted about
> this.
> 
> I tend to agree with Kent that we need to be absolutely sure before
> we
> switch the default that eudev will maintain feature parity with udev,
> now and in the future, e.g. when a new release of udev hits, a new
> release of eudev must happen asap that supports all of the features
> of
> the new udev.
> 
> I also think mgorny's arguments against doing this must be
> considered.
> 
> Thanks,
> 
> William
> 

I agree with mgorny on this. 

Specially I wonder about how fast the fixes from udev will get merged
in eudev :/. That can be not a problem currently as most non-systemd
users are using the splitted udev (a bit like the setup other
distributions like ubuntu were using, using udev from systemd as if the
default provider for udev was sys-apps/systemd even for running with
openRC).

But this can be more problematic when most non-systemd users will be
using a forked udev based on an older version that, then, won't contain
all the available bugfixes. For example, currently, if I don't
misremember eudev-3.1.5 is like systemd-220 and, then, it won't include
most fixes since 220 to 228.

Please take care I am not blaming on eudev maintainers or something
like that, it's simply that I think it's safer from a user point of
view (that relies on the hardware being recognized and working properly
on a first install) to ensure they get a newer/fixed version than one
that can have problems to be kept on sync.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Mon, Feb 8, 2016 at 12:01 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
>
> On 08/02/16 11:18 AM, Rich Freeman wrote:
>>
>> It seems like this should just be another step in the handbook -
>> pick your desired device manager.
>>
>> This just seems more like the Gentoo way, and it completely
>> sidesteps all the controversy over defaults.  We're already
>> working on fixing the few remaining functions.sh references so
>> that openrc can be removed from the system set as well.
>>
> I thought the point of this discussion had to do mostly with what
> udev variant gets installed when a user doesn't specify one.  And
> AFAIK, since there are still plenty of packages that *DEPEND on
> virtual/udev , the discussion's still worth having isn't it?

Sure, but if you've already picked which one you want as your default
at install time, then you won't have one pulled in as a default.  If a
package does pull in the virtual and you didn't want it installed at
boot, chances are the package won't work anyway, or the dependency
probably shouldn't be there.

But, if we want to change the default it sounds like the main criteria are:
* lots of distros using it by default
* feature parity with udev
* encouraged by its upstream as installed

Sounds like systemd is the obvious default.  :)

Oh wait, I left one out:
* being an in-house fork

Well, I suppose I could just git clone systemd from a month ago and
occasionally cherry-pick commits from upstream and stick that in the
tree.  Maybe I'll rename systemd-nspawn back to nspawn to add some
distinctiveness.  Then we can say that we're eating our own dogfood.

And this is why I think it is better to sidestep these sorts of
debates and just stick the instructions in the handbook.  I don't
really care which is listed first - heck, we still don't have dracut
in there and I don't get why anybody would install a system without
that.  (Another weekend project to do, along with integrating and
simplifying the systemd install instructions...)

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/08/2016 08:18 AM, Rich Freeman wrote:
> On 2/8/16, Patrick Lauer <patrick@gentoo.org> wrote:
>> The idea here is to change the order of the providers of
>> virtual/udev. For existing installs this has zero impact. For
>> stage3 this would mean that eudev is pulled in instead of udev.
> 
> Might I suggest a slightly different approach.  I don't really have
> a strong preference on the order of providers in this virtual,
> though I don't really care for a direction of promoting in-house
> tools over standardized ones (genkernel is another one that comes
> to mind). Gentoo's distinctiveness should come from being
> source-based and offering choices, not from a large collection of
> internal forks (I have nothing against people working on them, but
> they shouldn't be the default experience).
> 
> However, I think we're actually missing the bigger issue here.  Why
> is this virtual even in @system to begin with?  When I set up a
> chroot or some kinds of containers I don't need udev, or sysvinit
> (or openssh - but let's set that one aside for now).
> 
> We don't stick grub or genkernel or even gentoo-sources in our 
> stage3s.  Why stick (e)udev in there?
> 
> It seems like this should just be another step in the handbook -
> pick your desired device manager.
> 
> Obviously if we produce a boot CD it will need a device manager
> (and kernel and bootloader and network manager), and I don't care
> which one it is.
> 
> This just seems more like the Gentoo way, and it completely
> sidesteps all the controversy over defaults.  We're already working
> on fixing the few remaining functions.sh references so that openrc
> can be removed from the system set as well.
> 

++ from me. I hadn't considered just considering it another option.
[e]udev isn't the only device manager out there, and currently
Gentooers must explore that *after* installation. If someone comes to
Gentoo knowing they want mdev and runit, for example, maybe we should
at least briefly mention them in the Handbook and point to their wiki
pages for more information. Defaults don't have to be blessed.

I'm also in favor of keeping @system small. If that means migration to
stage4s for the average user and stage3s remain a thing, I'm okay with
that. We just need solid means to maintain choice and be honest about
the options available when building a system, imo.
- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWuTbWAAoJEAEkDpRQOeFw9FYQAKz8BfptTmFwH6/fGJDZYuuI
xQIh9uLWnd5CpRt4KgXhJWzN3DQvAA5/9iupiEfqZOMP/Iissjdc02ZQ/EmDceB3
sze+sqKMKrvEm0IaMkTK7J451NkLLODBkw1zQdZmruhkzx46C+4B8lnnyN5eewKd
cHP77EuDtGpFkq62ZfTwnk7iz4omiRqHUEJLq3nagEtKby109VM5FhSUpdbCgXOl
tRRrElgxroDeoV/nRjCLpXetMP7IMyKKyyS/6IH5FVLV31oWwyfhG9TE3MKmCVFo
xQeH0rALr7RrPKaGCbD32rFLl1dTedHI0x1hROl4jtPxRNoWcVQ2096l2wVdCzo5
42fkRvwuhro/v+ABcCj4ysdkfLLeEAS0S89vc+w7QGviKDHjXDjKwIxpeDnACUeT
qvHucT8glTVbCZPseD9z5iRTtnS8JIi2T8qVtYT3ULo5YH8Xcfy0M2htfusAMONS
07UOhIrZzhLOI6mEwYOHHkOiWzWpBy6JtpVVHzmw38eB1szmGSFBHl5pV2mmaqw7
0kYQ9/OX74QcFwxUnyEbl7gAJRnu15J6Zzk2wl+uVrMMgoL8uZ7B4JLGLx4772AH
HFxwlzdCuXtBQxOc7dL1OfW/DZkFg8JnDLxBKeTH8F0L1gX/Fe/vnekPUlKRj+y9
xtg0rCeg3gel+wbN/fWk
=iWI6
-----END PGP SIGNATURE-----

[gentoo-dev] Re: Changing order of default virtual/udev provider

[Duncan]

Michał Górny posted on Mon, 08 Feb 2016 13:46:06 +0100 as excerpted:

> 4. eudev is underdocumented, and the maintainer admits that 'he sucks at
> documenting'. In fact, did anyone even bother to note how far eudev
> diverges from upstream udev to this point?

IMO that's the most important of the four issues.

While I switched to systemd some some time ago (I guess it's close to two 
years?), for those choosing openrc, given udev/systemd's upstream plans 
to go kdbus and hard-lockin to kdbus enabled kernels when that happens, 
plus the fact that they strongly discourage and don't really support 
separate udev already, it just doesn't make sense to me to default to 
systemd-udev on a non-systemd system.

But strong documentation is one of the things I appreciated about gentoo 
back in the day, it's one of the things I appreciate about systemd today, 
and it sounds like it's the biggest thing lacking in eudev, certainly so 
going forward from that kdbus thing coming to pass (*IF* it does, the 
jury, with Linus as the jury foreman, is still out on that one) in 
upstream systemd-udev and kernel and apps eventually being built assuming 
that, as at that point it's unlikely that eudev users will simply be able 
to use udev documentation any longer, as they can in general practice, 
today.

Of the first three issues, #1 (conflict-induced fork) and #2 (vanilla api) 
really don't apply so much to (e)udev as to systemd -- if you're a 
programmer targeting "vanilla", by definition, these days you're 
targeting systemd, and if you're *not* targeting systemd, by definition, 
you're no longer targeting vanilla and are thus dealing with all sorts of 
adaptations already, and both users and devs are already in a non-vanilla 
choice once they've chosen non-systemd.  Doing the same for eudev vs udev 
will add only trifling incrementally to that, like arguing whether taking 
a taxi or the city bus to your hotel will be faster, once you've chosen 
to go by cruise ship instead of airline.

#3 (eudev falling behind at times) could be a bit of a problem, but if it 
has been ahead at times as well, as already argued, without further 
information on specific instances, it's impossible to judge and thus is a 
wash.

Meanwhile, missing documentation affects all three of those as well as 
being its own, very critical, point.  If there's a reason to oppose the 
default switch, it'd be that, and that's where I believe some focus will 
need to be for eudev to be taken seriously, long-term, particularly given 
how well systemd is documented, making it easy for developers and users 
alike to simply settle on it as their standard, leaving support for other 
alternatives to those who might feel the need to develop and document 
them, and if they're not documented, well...

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

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Anthony G. Basile]

On 2/8/16 7:46 PM, Daniel Campbell wrote:
> On 02/08/2016 08:18 AM, Rich Freeman wrote:
>> On 2/8/16, Patrick Lauer <patrick@gentoo.org> wrote:
>>> The idea here is to change the order of the providers of 
>>> virtual/udev. For existing installs this has zero impact. For 
>>> stage3 this would mean that eudev is pulled in instead of
>>> udev.
> 
>> Might I suggest a slightly different approach.  I don't really
>> have a strong preference on the order of providers in this
>> virtual, though I don't really care for a direction of promoting
>> in-house

what does in-house tool mean?  i'm a gentoo developer but i also work
on an upstream project (eudev) that 14 distros use.

some of the criticism given here are my concerns as well and i've
spoken with the various distros --- slack, parted magic, puppy.  they
get what's going on and they still see eudev is the best way forward
for now.  it may not be in the future, but neither will a udev
extracted from a compiled full systemd codebase.

>> tools over standardized ones (genkernel is another one that
>> comes to mind). Gentoo's distinctiveness should come from being 
>> source-based and offering choices, not from a large collection
>> of internal forks (I have nothing against people working on them,
>> but they shouldn't be the default experience).
> 
>> However, I think we're actually missing the bigger issue here.
>> Why is this virtual even in @system to begin with?  When I set up
>> a chroot or some kinds of containers I don't need udev, or
>> sysvinit (or openssh - but let's set that one aside for now).

it needs to be in the new stage4s to make a bootable system.  imo a
stage4 should be bootable modulo a kernel.



-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

[Anthony G. Basile]

On 2/8/16 7:47 PM, Duncan wrote:
> Michał Górny posted on Mon, 08 Feb 2016 13:46:06 +0100 as excerpted:
> 
>> 4. eudev is underdocumented, and the maintainer admits that 'he sucks at
>> documenting'. In fact, did anyone even bother to note how far eudev
>> diverges from upstream udev to this point?
> 
> IMO that's the most important of the four issues.
> 

to clear the records, i don't really suck at documentation, i just
really don't like doing it.  you can read my documention on some of my
other projects.

btw, upstream is sooooo much better at documentation :P  shall i point
you to all the random changes in the api that users are supposed to
dowse with divining rods.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alex McWhirter]

On 02/08/2016 07:07 PM, Rich Freeman wrote:
>
> Sure, but if you've already picked which one you want as your default
> at install time, then you won't have one pulled in as a default.  If a
> package does pull in the virtual and you didn't want it installed at
> boot, chances are the package won't work anyway, or the dependency
> probably shouldn't be there.
>
> But, if we want to change the default it sounds like the main criteria are:
> * lots of distros using it by default
> * feature parity with udev
> * encouraged by its upstream as installed
>
> Sounds like systemd is the obvious default.  :)
>
> Oh wait, I left one out:
> * being an in-house fork
>
> Well, I suppose I could just git clone systemd from a month ago and
> occasionally cherry-pick commits from upstream and stick that in the
> tree.  Maybe I'll rename systemd-nspawn back to nspawn to add some
> distinctiveness.  Then we can say that we're eating our own dogfood.
>
> And this is why I think it is better to sidestep these sorts of
> debates and just stick the instructions in the handbook.  I don't
> really care which is listed first - heck, we still don't have dracut
> in there and I don't get why anybody would install a system without
> that.  (Another weekend project to do, along with integrating and
> simplifying the systemd install instructions...)
>

I think the real issue here is maintaining the "freedom of choice"
Gentoo typically strives to offer. If upstream makes udev something that
cannot be installed without the rest of systemd (which from the sound of
things is very likely) you suddenly have a large userbase who are going
to be forced to go full systemd or migrate to something like eudev. When
this happens we either need to make systemd default over openrc, or make
eudev default over udev. Either way i think we need a better way of
letting the user decide which path they want to chose at install time.

As far as upstream support for eudev goes, consider that we are
currently breaking out udev for use with openrc. There may still be
loose support for this now, but when udev is not longer able to be
separated from systemd it's guaranteed that support for this kind of
configuration will be dropped.

So with that being said, I'm all for making eudev default as the only
other option would be making systemd default which is a completely
different discussion. One or the other will likely have to happen at
some point.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Mon, Feb 8, 2016 at 7:58 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
>
> what does in-house tool mean?  i'm a gentoo developer but i also work
> on an upstream project (eudev) that 14 distros use.
>
> some of the criticism given here are my concerns as well and i've
> spoken with the various distros --- slack, parted magic, puppy.  they
> get what's going on and they still see eudev is the best way forward
> for now.  it may not be in the future, but neither will a udev
> extracted from a compiled full systemd codebase.

How many of those 14 distros have more than 14 users?

Look, I get it, some people don't like systemd.  That's fine.
However, you have to realize at this point that a non-systemd
configuration is anything but mainstream.  There will always be a
"poppyseed linux" whose purpose in life seems to be to preserve linux
without sysfs or some other obscure practice.  I just think that
Gentoo should offer the choice to do those things, but have a more
mainstream set of defaults.

>
> it needs to be in the new stage4s to make a bootable system.  imo a
> stage4 should be bootable modulo a kernel.
>

Sure, a stage4 based on systemd makes a lot of sense.  I don't really
see the point in leaving a kernel out though - I'd even stick a
precompiled one in /boot on top of having the sources installed.  Why
not make a stage4 install something that takes all of 5 minutes?

I think that offering an eudev-based distro as a default just doesn't
make sense in 2016.  I just think the better road to take is to start
treating virtual/udev as something that gets installed post-stage3.
We can't even get people to agree on vi vs emacs as a default.

When these sorts of debates come up it seems like:
1.  People express their preference.
2.  People get offended when others express a different preference.
3.  People say "it's just a default" as if that is a reason that
others shouldn't object to their own preference.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Anthony G. Basile]

On 2/8/16 10:09 PM, Rich Freeman wrote:
> On Mon, Feb 8, 2016 at 7:58 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
>>
>> what does in-house tool mean?  i'm a gentoo developer but i also work
>> on an upstream project (eudev) that 14 distros use.
>>
>> some of the criticism given here are my concerns as well and i've
>> spoken with the various distros --- slack, parted magic, puppy.  they
>> get what's going on and they still see eudev is the best way forward
>> for now.  it may not be in the future, but neither will a udev
>> extracted from a compiled full systemd codebase.
> 
> How many of those 14 distros have more than 14 users?

may i forward that to them? i'm sure they'll appreciate your comment.

anyhow, your rhetorical question has speculation as its basis. do you
have numbers of users? as i write this, gentoo is number 44 in
distrowatch.com below slackware at 22 and puppy at 15.  can you produce
reliable numbers?

gentoo is very unpopular as a distro.  however, it excels as a meta
distro.  if you marginalize its special features, you take away all its
charm.

> 
> Look, I get it, some people don't like systemd.  That's fine.
> However, you have to realize at this point that a non-systemd
> configuration is anything but mainstream. 

neither is a system based on musl or uclibc, but if you need an embedded
system, then these are "mainstream".

similarly hardened is not "mainstream" and yet there are many companies
that depend on it.

the notion of "mainstream" is relative and you're taking a particular
vantage point.

anyhow, the argument in the subject is the order of udev and eudev in
the virtual, not systemd vs eudev.

 There will always be a
> "poppyseed linux" whose purpose in life seems to be to preserve linux
> without sysfs or some other obscure practice. 

no, more like special uses. you're framing the issue based on your
notion of "mainstream"

 I just think that
> Gentoo should offer the choice to do those things, but have a more
> mainstream set of defaults.

i don't care about the order of the virtual, that was other people's
issues.  i'm responding to bad arguments.

> 
>>
>> it needs to be in the new stage4s to make a bootable system.  imo a
>> stage4 should be bootable modulo a kernel.
>>
> 
> Sure, a stage4 based on systemd makes a lot of sense. 

not for embedded and the things i work on.  these have users.

> 
> I think that offering an eudev-based distro as a default just doesn't
> make sense in 2016.

because you have a limited sense of usefulness

> 
> When these sorts of debates come up it seems like:
> 1.  People express their preference.

no, its not a preference.  its the right tool for the right job.  when
something needs systemd, you use that, when something needs eudev you
use that.

> 2.  People get offended when others express a different preference.

all the vitriolic attacks i get about eudev come from the gentoo
community.  outside of this community i get praise.

> 3.  People say "it's just a default" as if that is a reason that
> others shouldn't object to their own preference.

the arguments based on "preference" and "mainstream" are fallacious.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Changing order of default virtual/udev provider

[waltdnes]

On Mon, Feb 08, 2016 at 08:15:42PM -0500, Alex McWhirter wrote

> As far as upstream support for eudev goes, consider that we are
> currently breaking out udev for use with openrc. There may still be
> loose support for this now, but when udev is not longer able to be
> separated from systemd it's guaranteed that support for this kind of
> configuration will be dropped.

  I think the whole point of eudev is that Anthony here, rather than
Lennart at Redhat, is "upstream".  Stop looking at the Redhat people as
"upstream" for eudev.  They're doing their best to break it.  I don't
know how many of you are old enough to remember the dirty tricks that
Microsoft pulled when IBM was running Windows 3.1 inside OS/2.  One
minor tweak, and Windows 3.11 broke inside OS/2.  Lennart and company
are actively hostile to us, and Gentoo risks annihilation and/or
absorption into the systemd Borg, if we consider the systemd people as
our "udev upstream".

  eudev is an independant fork, and should stand on its own.  I
currently use Pale Moon web browser, which is an independant fork of
Firefox.  Look Ma, no Atrocious^H^H^H^H^H^H^H^H Austraulis GUI.  Because
it's an independant fork, Firefox can shut down altogether, and Pale
Moon will keep going.  That's the model I want eudev to follow.

> So with that being said, I'm all for making eudev default as the only
> other option would be making systemd default which is a completely
> different discussion. One or the other will likely have to happen at
> some point.

  How difficult would it be to make it an install-time choice, like the
bootloader?

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Kent Fredric]

On 9 February 2016 at 16:09, Rich Freeman <rich0@gentoo.org> wrote:
> There will always be a
> "poppyseed linux" whose purpose in life seems to be to preserve linux
> without sysfs or some other obscure practice.


This seems to be an attempt at painting the "stick with eudev" model
as an "old fogies who are afraid of change".

I think a better characterisation is that this is a battle of
simplicity vs complexity[1]

A pure udev system is in comparison, much simpler than a systemd system.

And that's much of the beauty of OpenRC. Its simple, it achieves the
same goals as Systemd and Upstart, etc, but does so with a lot less
mechanics under the hood, and doesn't clutter up systems with features
you don't need prematurely.

And there are great benefits from simplicity over complexity.

And a lot of Gentoo is surprisingly simple: Like our use of bash
scripts for recipies to build things, like using rsync to deploy/relay
not just those recipies, but security notices and  news items, which
are themselves reasonably simple formats.

LFS and Slackware also seem to be platforms that leverage a lot of
"Simplicity" in the way of offering you only the basics you need to
get things done. They're not *easy* to use if you're a novice, but the
systems themselves are simple.

Thus, its not /merely/ a preference if a tool does things you don't need to do.

Because "I don't need a login daemon" is not a "Preference", its an
objective analysis of the systems requirements.

The only preference I see here is the preference to not have and
install things your system has no use for, which I find an odd
preference to be complaining about, and depending on your system
requirements, that may also be not so much "preference".

1: Related Viewing: http://www.infoq.com/presentations/Simple-Made-Easy
-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Kent Fredric]

On 9 February 2016 at 18:27, Anthony G. Basile <blueness@gentoo.org> wrote:
> all the vitriolic attacks i get about eudev come from the gentoo
> community.  outside of this community i get praise.


In case my  earlier messages stating a desire to exercise much caution
gave the wrong impression, I just want to state for the record I think
its awesome eudev exists, and I think its awesome other distro's are
using it.

Just when it comes to "Change the defaults", I want to be certain
about the path we're setting ourselves up for on this very important
component, because here, a change of defaults paves a broader path for
eudev to be a potential leading competition to systemd.

Because if we do that, I feel we must be so sure of ourselves that
eudev can be a profitable choice for at least a moderately long term,
even in the event we get no more support from the systemd codebase.

Having it in tree and having users who know what they're doing being
able to choose their own risk factors and say "yeah, eudev is the
right choice for what I'm doing" is one thing.

But stating implicitly that "Hey, this is the default", this needs to
be the *best* recommendation we can make based on all the other
factors and other defaults Gentoo uses.

Because new users *will* be inclined to pick the default, and
*existing* users of the *current* default are likely to see the
default change, and reason "well, the default has changed, so the new
default is the new best thing", and will be inclined to switch.

And the worst thing we could have is a combination of bad defaults
that leads new users to have a poor first experience because they used
all the default recommendations, and their system made magic smoke
instead of booting.

In short, to change *this* default, it seems pertinent that we *know*
that the change we're making *is* better and a more reliable long-term
choice than the *current* default, and if there is *any reasonable
doubt*, we should delay changing until that reasonable doubt is
expunged.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Tue, Feb 9, 2016 at 12:27 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
> On 2/8/16 10:09 PM, Rich Freeman wrote:
>> How many of those 14 distros have more than 14 users?
>
> gentoo is very unpopular as a distro.  however, it excels as a meta
> distro.  if you marginalize its special features, you take away all its
> charm.

Gentoo's special feature is that it is source-based, not that it uses
a different udev implementation from everybody else by default.

>>
>> Look, I get it, some people don't like systemd.  That's fine.
>> However, you have to realize at this point that a non-systemd
>> configuration is anything but mainstream.
>
> neither is a system based on musl or uclibc, but if you need an embedded
> system, then these are "mainstream".

Sure, but they're also not defaults.

>
> anyhow, the argument in the subject is the order of udev and eudev in
> the virtual, not systemd vs eudev.

And that is about defaults.

>
>  There will always be a
>> "poppyseed linux" whose purpose in life seems to be to preserve linux
>> without sysfs or some other obscure practice.
>
> no, more like special uses. you're framing the issue based on your
> notion of "mainstream"

My notion of mainstream, and Fedora's, and Debian's, and RHEL's, and Arch's...

>>
>>>
>>> it needs to be in the new stage4s to make a bootable system.  imo a
>>> stage4 should be bootable modulo a kernel.
>>>
>>
>> Sure, a stage4 based on systemd makes a lot of sense.
>
> not for embedded and the things i work on.  these have users.
>

Systemd makes plenty of sense for many embedded solutions.  For the
kinds of solutions where it doesn't make sense, I'm not sure that
linux makes sense.

But, even if you accept that eudev makes more sense for some embedded
solutions, we're taking about the default here, not the default for
the embedded profile (which doesn't actually exist, though with
mix-ins it might some day).

>>
>> I think that offering an eudev-based distro as a default just doesn't
>> make sense in 2016.
>
> because you have a limited sense of usefulness

It doesn't make sense as a default in the context of the situations
where our default profile is intended.  Maybe you could convince
somebody that it makes sense as a choice for a very specialized use
case, but in that use case you're probably going to have a list of USE
flags a mile long and be overriding numerous default providers.  eudev
would just be one more in that case.

>
>> 2.  People get offended when others express a different preference.
>
> all the vitriolic attacks i get about eudev come from the gentoo
> community.  outside of this community i get praise.

Gentoo is a community focused on providing a source-based distro where
you have choices.  I doubt anybody in the Gentoo community is bothered
about your offering another choice.

The controversy comes in when you want to make it a default, and start
arguing that it is somehow better than the solution everybody else is
using.

Outside of Gentoo people either aren't concerned at all with eudev (it
probably isn't even in their distro repositories), or they're a tiny
distro whose main purpose in life seems to be to avoid installing
systemd.  Of course you're going to get praise from them.

I've always supported having eudev hosted by Gentoo.  I just don't
support it being the default udev provider.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Anthony G. Basile]

On 2/9/16 6:59 AM, Rich Freeman wrote:
> On Tue, Feb 9, 2016 at 12:27 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
>> On 2/8/16 10:09 PM, Rich Freeman wrote:
>>> How many of those 14 distros have more than 14 users?
>>
>> gentoo is very unpopular as a distro.  however, it excels as a meta
>> distro.  if you marginalize its special features, you take away all its
>> charm.
> 
> Gentoo's special feature is that it is source-based, not that it uses
> a different udev implementation from everybody else by default.

that's not what i said.

> 
>>>
>>> Look, I get it, some people don't like systemd.  That's fine.
>>> However, you have to realize at this point that a non-systemd
>>> configuration is anything but mainstream.
>>
>> neither is a system based on musl or uclibc, but if you need an embedded
>> system, then these are "mainstream".
> 
> Sure, but they're also not defaults.

this is circular argumentation.  they are not default where they are not
default.  and they are where they are.

you simply want to privilege a certain set of targeted systems
(desktop/server) over another set (embedded).

> 
>>
>> anyhow, the argument in the subject is the order of udev and eudev in
>> the virtual, not systemd vs eudev.
> 
> And that is about defaults.

nope.  currently stages come with sys-fs/udev as default.

> 
>>
>>  There will always be a
>>> "poppyseed linux" whose purpose in life seems to be to preserve linux
>>> without sysfs or some other obscure practice.
>>
>> no, more like special uses. you're framing the issue based on your
>> notion of "mainstream"
> 
> My notion of mainstream, and Fedora's, and Debian's, and RHEL's, and Arch's...

correct, that is your notion.  in the grand scheme of things windows is
mainstream and fedora, debian, etc are just marginal.

you're missing the point that the style of argumentation you're taking
is one of a particular view that you privilege.

> 
>>>
>>>>
>>>> it needs to be in the new stage4s to make a bootable system.  imo a
>>>> stage4 should be bootable modulo a kernel.
>>>>
>>>
>>> Sure, a stage4 based on systemd makes a lot of sense.
>>
>> not for embedded and the things i work on.  these have users.
>>
> 
> Systemd makes plenty of sense for many embedded solutions.  For the
> kinds of solutions where it doesn't make sense, I'm not sure that
> linux makes sense.

like?  embedded os has avoided systemd like the plague.  they opt for
busybox mdev.

> 
> But, even if you accept that eudev makes more sense for some embedded
> solutions, we're taking about the default here, not the default for
> the embedded profile (which doesn't actually exist, though with
> mix-ins it might some day).
> 
>>>
>>> I think that offering an eudev-based distro as a default just doesn't
>>> make sense in 2016.
>>
>> because you have a limited sense of usefulness
> 
> It doesn't make sense as a default in the context of the situations
> where our default profile is intended.  Maybe you could convince
> somebody that it makes sense as a choice for a very specialized use
> case, but in that use case you're probably going to have a list of USE
> flags a mile long and be overriding numerous default providers.  eudev
> would just be one more in that case.
> 
>>
>>> 2.  People get offended when others express a different preference.
>>
>> all the vitriolic attacks i get about eudev come from the gentoo
>> community.  outside of this community i get praise.
> 
> Gentoo is a community focused on providing a source-based distro where
> you have choices.  I doubt anybody in the Gentoo community is bothered
> about your offering another choice.

being a from source distro means a lot more than you give it ... see below.

> 
> The controversy comes in when you want to make it a default, and start
> arguing that it is somehow better than the solution everybody else is
> using.

i'm not arguing for the default.  i'm saying that your argumentation has
flaws.

> 
> Outside of Gentoo people either aren't concerned at all with eudev (it
> probably isn't even in their distro repositories), or they're a tiny
> distro whose main purpose in life seems to be to avoid installing
> systemd.  Of course you're going to get praise from them.

the assumption here is that Gentoo is a single distribution where its
from source nature makes it a meta distribution.  so you create a false
dichotomy between gentoo and "tiney distros whose main purpose"  Many of
those "tiny distros" are gentoo because gentoo is a set covering many
derivatives.

the reason i'm engaging in this is not because of the default.  the
reason i'm engaging in this dialogue is because of the repeated
reduction in vision as to what "from source" means.

> 
> I've always supported having eudev hosted by Gentoo.  I just don't
> support it being the default udev provider.
> 


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric <kentfredric@gmail.com> wrote:
>
> A pure udev system is in comparison, much simpler than a systemd system.

I don't buy that at all.  In systemd you have a unified object model
across device nodes, mountpoints, services, and cron jobs.  In the
alternate model you have completely different implementations of all
of those, each with their own configurations and behaviors.

>
> And that's much of the beauty of OpenRC. Its simple, it achieves the
> same goals as Systemd and Upstart, etc, but does so with a lot less
> mechanics under the hood, and doesn't clutter up systems with features
> you don't need prematurely.

OpenRC doesn't achieve MANY of the goals of systemd.  Maybe you don't
personally care about some of them, but you really can't compare the
feature sets at this point.

> And there are great benefits from simplicity over complexity.

Absolutely.  It is great to create a text file and symlink it in a
directory named after a service to make that service auto-restart, or
have a memory limit, or set an IO priority for that service.  It is
great to not have to think about anything to have just about all your
processes organized into a sensible cgroup hierarchy.  It is great to
be able to tweak one config file to ensure that users who log out of a
system can't leave any processes behind.

It is great to be able to tweak something in policykit and change
things like who can shut down the system, or who can restart a
service.

The simplicity of systemd comes from the fact that it has brought what
used to be a collection of many independent tools under one roof, and
created a converging set of interfaces for all of them.

> And a lot of Gentoo is surprisingly simple: Like our use of bash
> scripts for recipies to build things, like using rsync to deploy/relay
> not just those recipies, but security notices and  news items, which
> are themselves reasonably simple formats.

Well, one thing about Gentoo that certainly isn't simple is our init.d scripts.

Compare this:
http://pastebin.com/sSDtpF4t

With this:
http://pastebin.com/Lfn8r7qP

Systemd does the job in 10% of the code (and half of it is a comment),
and doesn't implement its own service polling and killer script during
shutdown independently for every service (not that every init.d script
even does this - most of them will just leave orphans behind, and
systemd will catch orphans that even the lengthy init.d script for
apache misses).

>
> The only preference I see here is the preference to not have and
> install things your system has no use for, which I find an odd
> preference to be complaining about, and depending on your system
> requirements, that may also be not so much "preference".
>

And hence my suggestion that we simply get this stuff out of the
stage3s in the first place.  Then everybody can just pick the
implementation that best suits their requirements.

If you want to talk about default providers, the most straightforward
one to use is systemd.  It is what people are going to be used to
coming from other distros, it is what every upstream package expects
to be running anyway, and it is the simpler tool that does everything
that most people want.

For people who want a more exotic configuration, there are
alternatives, and Gentoo should certainly support using them as long
as people care to maintain them.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/08/2016 11:43 PM, waltdnes@waltdnes.org wrote:
> How difficult would it be to make it an install-time choice, like
> the bootloader?

Not very. It would need proper documentation, however, and at least
indications on limitations or consequences of choices. If we were to
add a device manager step to the handbook, it would be poor form to
focus on just systemd-udev vs eudev. There's mdev and a few other
alternatives out there as well, and they deserve at least a
mention-in-passing, so people know what all is available in the tree.

Otherwise, I agree that when considering eudev, blueness is basically
our upstream. Him being a Gentoo dev is coincidental and just allows
him to support Gentoo better. As he mentioned, he's upstream to
multiple distros, so I see no reason why Gentoo can't be considered
downstream while he's working on eudev.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWudk9AAoJEAEkDpRQOeFwT4QP/iOlBrMlGzlr9PBhpqtqk/RK
DqOfeDs5Oxw5rhKt3WY1CuIZeoIzyXa7ribdfHdpTJ6nuEWYATcwFBLonsmPpo0v
9QvSIXaBOA4QKkVtt9dM3SL2X3JiEKIoPMKdDMfmH4kGYLDtzMLRQWwePx7ii8Gv
vTA7ooTaYTkNtPxYaCn5RUymVQM0mOPpK7CF+BmxiOKFo6RezkHSo2lwN3YPUOBb
xutm2JtQlKfr7efgWdJ1tb8XHbm1Q0UYP8myoFd3Fu20MBSk1F6KmAVlkniCbAZJ
DO9qrvv9Sgcp6XCB+Uy4Zx4OOUz5noZSC3COQ3XOwxw+bSHtjik9NBZU3k2fs5cI
Os2QJVNPNBpZHnNFvw4IA6iyLa2FFDIf/2FsqZyrNtt3GipqeR6YQqBHYD8KOXnf
55kQFphOlm5L2KkNe15TPwsNolMJq59RwSdJ0u+5qKX3TgABGvFMWYZZrdQYIZPH
/zK1s3wpeBudUPjgXQnok2Q6FD4mT5WHsgBnYxAYmYwd5WMjDz6uDYRVmgFV8RHi
qB2H2wjQ1fg/d9W0rFlII/Ml1n/sXjqjc53EGA5Ik3s2uy9WWMHSTxV59pAuplL2
pHIIUu96hJJ9BtkPzQFWSL2+/y6hT+VdZpPAbKJBai/vezax4mq1xJdEbGpeALlt
4emEaPNpHav1iAN/3Wwv
=X02j
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/09/2016 01:03 AM, Kent Fredric wrote:
> On 9 February 2016 at 18:27, Anthony G. Basile
> <blueness@gentoo.org> wrote:
>> all the vitriolic attacks i get about eudev come from the gentoo 
>> community.  outside of this community i get praise.
> 
> 
> In case my  earlier messages stating a desire to exercise much
> caution gave the wrong impression, I just want to state for the
> record I think its awesome eudev exists, and I think its awesome
> other distro's are using it.
> 
> Just when it comes to "Change the defaults", I want to be certain 
> about the path we're setting ourselves up for on this very
> important component, because here, a change of defaults paves a
> broader path for eudev to be a potential leading competition to
> systemd.
> 
> Because if we do that, I feel we must be so sure of ourselves that 
> eudev can be a profitable choice for at least a moderately long
> term, even in the event we get no more support from the systemd
> codebase.
> 
> Having it in tree and having users who know what they're doing
> being able to choose their own risk factors and say "yeah, eudev is
> the right choice for what I'm doing" is one thing.
> 
> But stating implicitly that "Hey, this is the default", this needs
> to be the *best* recommendation we can make based on all the other 
> factors and other defaults Gentoo uses.
> 
> Because new users *will* be inclined to pick the default, and 
> *existing* users of the *current* default are likely to see the 
> default change, and reason "well, the default has changed, so the
> new default is the new best thing", and will be inclined to
> switch.
> 
> And the worst thing we could have is a combination of bad defaults 
> that leads new users to have a poor first experience because they
> used all the default recommendations, and their system made magic
> smoke instead of booting.
> 
> In short, to change *this* default, it seems pertinent that we
> *know* that the change we're making *is* better and a more reliable
> long-term choice than the *current* default, and if there is *any
> reasonable doubt*, we should delay changing until that reasonable
> doubt is expunged.
> 

I can understand your concerns wrt defaults, but I don't know very
many Gentoo users that stick to defaults. Part of what draws people to
Gentoo is the very fact that you can customize every layer of the
stack, from kernel to user-facing GUI applications.

The default service manager is OpenRC, and it works great with eudev.
I've not had a single issue with eudev since I started using it. It
accepted any of the rules I had written for older udev before systemd
swallowed it, and I just don't have any issues. I can't think of any
reason eudev can't be a drop-in replacement, at least at the current tim
e.

sys-fs/udev is only for systems that aren't already running systemd,
as "!sys-apps/systemd" is in sys-fs/udev's ebuild. Given that
systemd+eudev is the only possible combination I can think of that may
cause problems, I don't think changing the default from sys-fs/udev to
sys-fs/eudev is a problem, at all. The default is currently
systemd-udev, and udev's been mostly unchanged since systemd swallowed
it, aside from the push for kdbus that the systemd team is pushing the
kernel guys to implement. Once *that* happens, eudev will need to
either use that interface to maintain "full" feature parity, or fork
off on its own.

Given that the push for kdbus is more a political API move than
anything, I can see eudev sticking to the current interface and
working just fine. The kdbus switch is completely internal and people
actually using udev won't notice much of anything except the necessity
for a new kernel version. If current users of udev end up being
required to switch to systemd in order to retain udev, then there will
most certainly be more interest in eudev and its development. I see
only positives for this.

I've used OpenRC and eudev since I started using Gentoo in 2012. I
don't predict switching from udev to eudev being difficult for anyone
running something like, say, runit, since it's really a drop-in
replacement. *after* kdbus is implemented in udev, *maybe*, but
unlikely since it's something really low level and there's no way the
systemd team would require big changes on the user/admin facing side
of things unless you aren't already running systemd. Their goal is to
make it so easy that people don't have to inspect the internals, which
gives them free reign to start conflicts with other distros and forks.

Have there been any real cases of issues switching between the two?
- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWud1gAAoJEAEkDpRQOeFwhXcP+gK9gMmk+CMQ8gRJbJcpHTot
nKAL4WotZc+st4TvyBSY1PklVT2s5GEQAfsHW4tvCYZAMQxaCceerWnCgJOhJynv
8fxxTaIkSivO0y6Q7PPEqFrnc3AhtQG8GWvDOUosVSX2xlTQ6kLXV/kjaS4vqd+i
K+G095gpn+tPKLsCuBS6+nHRYXJSEDJBL6b1cK0S37XNjBCaMAOo4kW3Qp6EEWAO
+oO1HH44gVQZdqDjdR/5J45zMeg7Y9KrzvZkD8QWbzAhui3X2Z/GsXpmnKw4vH2u
3dbXfFcPVZDJQ8PeJMTevglO8Weh6esoQTj83xjvY1luOwFn6Rvc2rPyulPHS+cJ
istKk1H1OvjgN8lK/3kAZ2fUAt2SFFvJIwFe0rNHzvVOv93sJcFhbCtrQIhqbvkf
kkBdSVHCDpxbYWtMvLIjbd73qsOjpvhTF+0MGMZlkAAinGoIFp/o4RqD4pqre0Nr
lmdGdmC/hufFTIf6ROEnCU7tkK6lWjzXN110E/Lekf8QEFZgjihFi0q+rkv7gi0c
B24fealTeqg1CFd2CrF5T/n6XG0FWovF6hOChg8OfN203pYRBSQgvFH6c9Kt4PP1
/CbVa0CGfuCNkDgQv10jwL9wQ+dNDKpwQC3r8CMPdeUYlqWZnRtz4/P8K0FjjUJs
8txys/VjkIqxdIuR9b10
=dov4
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Tue, Feb 9, 2016 at 7:14 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
> On 2/9/16 6:59 AM, Rich Freeman wrote:
>> On Tue, Feb 9, 2016 at 12:27 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
>>> On 2/8/16 10:09 PM, Rich Freeman wrote:
>>>> How many of those 14 distros have more than 14 users?
>>>
>>> gentoo is very unpopular as a distro.  however, it excels as a meta
>>> distro.  if you marginalize its special features, you take away all its
>>> charm.
>>
>> Gentoo's special feature is that it is source-based, not that it uses
>> a different udev implementation from everybody else by default.
>
> that's not what i said.

You implied that I'm marginalizing Gentoo's special features.  I don't
see how using a different udev implementation than 99% of the linux
install base is one of Gentoo's special features.

But, by all means clarify what you do mean if I'm misunderstanding
your point.  Or, if it

>
>>
>>>>
>>>> Look, I get it, some people don't like systemd.  That's fine.
>>>> However, you have to realize at this point that a non-systemd
>>>> configuration is anything but mainstream.
>>>
>>> neither is a system based on musl or uclibc, but if you need an embedded
>>> system, then these are "mainstream".
>>
>> Sure, but they're also not defaults.
>
> this is circular argumentation.  they are not default where they are not
> default.  and they are where they are.
>
> you simply want to privilege a certain set of targeted systems
> (desktop/server) over another set (embedded).

Gentoo's default virtual providers are almost universally focused on
desktop/server systems.

Even if you accept the argument that eudev is more suitable for
embedded, it would be just one more virtual in a sea of virtuals whose
defaults are not ideal in the embedded world.

If somebody wants to create an extension to profiles where you can
change the order of virtual defaults so that you can have an embedded
default that preferes uclibc over glibc more power to them.

However, in distro we're maintaining today everything is focused on
desktop/server.

>
>>
>>>
>>> anyhow, the argument in the subject is the order of udev and eudev in
>>> the virtual, not systemd vs eudev.
>>
>> And that is about defaults.
>
> nope.  currently stages come with sys-fs/udev as default.

The whole point of this thread is that somebody wants to change this.
Inevitably changing the defaults requires having a big slug-fest over
which new default is better.  And that is why I made the suggestion to
try to moot the decision by just making this part of the handbook.

Of course this is going to be a contentious discussion.  Of course
people are going to get upset about this.

I'm sorry if my suggestion to make the default less relevant seems
like a diversion to the original point of the thread, but I actually
see that as the only way to actually RESOLVE the thread.  Otherwise
this just turns into a which-implementation-is-better slugfest, which
is what we're having right now.

>>>
>>>  There will always be a
>>>> "poppyseed linux" whose purpose in life seems to be to preserve linux
>>>> without sysfs or some other obscure practice.
>>>
>>> no, more like special uses. you're framing the issue based on your
>>> notion of "mainstream"
>>
>> My notion of mainstream, and Fedora's, and Debian's, and RHEL's, and Arch's...
>
> correct, that is your notion.  in the grand scheme of things windows is
> mainstream and fedora, debian, etc are just marginal.
>
> you're missing the point that the style of argumentation you're taking
> is one of a particular view that you privilege.

No argument that different people use Gentoo for different reasons,
and they're going to weigh more heavily the arguments that emphasize
their own preferences.

The problem is that ultimately with the design of Gentoo there can
only be ONE default virtual/udev provider.

There are many ways to resolve this:
1.  Somebody just unilaterally changes the default.  (Not likely to
work - just leads to revert wars and nonsense in the repo.)
2.  Eventually the council is asked to pick a winner.  (The council
will likely not want to do this, and no matter what they pick a huge
portion of the distro will probably be upset about it).
3.  Make the default unimportant by making this part of the handbook.
(This is what we do with emacs vs vim, and it has the side benefit of
being more appropriate for installs that don't even need a udev
implementation.)

Historically Gentoo has tended to take the approach of #3.  This
avoids having to wage huge battles over stuff like this.  I think that
would be more productive than the two of us going back and forth about
whose baby is uglier.

>
>>
>>>>
>>>>>
>>>>> it needs to be in the new stage4s to make a bootable system.  imo a
>>>>> stage4 should be bootable modulo a kernel.
>>>>>
>>>>
>>>> Sure, a stage4 based on systemd makes a lot of sense.
>>>
>>> not for embedded and the things i work on.  these have users.
>>>
>>
>> Systemd makes plenty of sense for many embedded solutions.  For the
>> kinds of solutions where it doesn't make sense, I'm not sure that
>> linux makes sense.
>
> like?  embedded os has avoided systemd like the plague.  they opt for
> busybox mdev.

For a box where RAM is at a super-premium, even the Linux kernel may
be too much to ask for.

If RAM isn't at much of a premium (hundreds of MB), then systemd runs
just fine and it has a lot of features that support homeostatis which
I'd think would be an important feature in an embedded system.  Its
only real downside is its newness.

>
> the assumption here is that Gentoo is a single distribution where its
> from source nature makes it a meta distribution.  so you create a false
> dichotomy between gentoo and "tiney distros whose main purpose"  Many of
> those "tiny distros" are gentoo because gentoo is a set covering many
> derivatives.

And those distros can still exist no matter what the default udev
provider is.  I'm all for preserving choice.  I just don't think that
eudev is an appropriate default for the sorts of use cases where any
of our other default providers make sense.

>
> the reason i'm engaging in this is not because of the default.  the
> reason i'm engaging in this dialogue is because of the repeated
> reduction in vision as to what "from source" means.
>

Again, I'm not suggesting taking away choice at all.  In fact, my
suggestion was to move this into the handbook to give users more
choice than they have today.

There is already a thread on gentoo-user asking how to safely switch
from udev->eudev.  If that were just a part of the handbook that isn't
even a migration they'd have to make on a new install.  Nor would
udev->systemd.

To summarize my goals in this thread:
1.  Suggest that rather than picking a winner we instead just let the
user pick the winner.
2.  Demonstrate the futility of actually trying to pick a winner,
because we all have different values on this subject.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Tue, Feb 9, 2016 at 7:36 AM, Daniel Campbell <zlg@gentoo.org> wrote:
>
> Given that the push for kdbus is more a political API move than
> anything, I can see eudev sticking to the current interface and
> working just fine.

I doubt udev is going to make that switch until kdbus is merged into
the kernel.  I doubt that Linus will accept it simply over politics.

Once it is in the mainline kernel, why wouldn't the eudev maintainers
switch?  At that point just about anybody using dbus is going to be
making a switch to kdbus.

Not using kdbus will be like not using /proc.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/09/2016 04:17 AM, Rich Freeman wrote:
> On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric
> <kentfredric@gmail.com> wrote:
>> 
>> A pure udev system is in comparison, much simpler than a systemd
>> system.
> 
> I don't buy that at all.  In systemd you have a unified object
> model across device nodes, mountpoints, services, and cron jobs.
> In the alternate model you have completely different
> implementations of all of those, each with their own configurations
> and behaviors.

Perhaps that's because each of those things should not actually be
considered the same object type. That sort of design may be convenient
to users, but is more akin to treating everything like a nail when you
have a hammer.

Also note that in the 'alternate' model, each of the above is handled
by a different tool. It's obvious that using a combination of
different tools will result in different conceptualizations of each of
those parts in a system. I see little benefit in a single project
pretending to understand everything about each of them.

> 
>> 
>> And that's much of the beauty of OpenRC. Its simple, it achieves
>> the same goals as Systemd and Upstart, etc, but does so with a
>> lot less mechanics under the hood, and doesn't clutter up systems
>> with features you don't need prematurely.
> 
> OpenRC doesn't achieve MANY of the goals of systemd.  Maybe you
> don't personally care about some of them, but you really can't
> compare the feature sets at this point.
> 
>> And there are great benefits from simplicity over complexity.
> 
> Absolutely.  It is great to create a text file and symlink it in a 
> directory named after a service to make that service auto-restart,
> or have a memory limit, or set an IO priority for that service.  It
> is great to not have to think about anything to have just about all
> your processes organized into a sensible cgroup hierarchy.  It is
> great to be able to tweak one config file to ensure that users who
> log out of a system can't leave any processes behind.
> 
> It is great to be able to tweak something in policykit and change 
> things like who can shut down the system, or who can restart a 
> service.
> 
> The simplicity of systemd comes from the fact that it has brought
> what used to be a collection of many independent tools under one
> roof, and created a converging set of interfaces for all of them.

If I didn't know any better I'd say this reads like shilling. Firstly,
there's a real problem if you're depending on a daemon restarting
itself. Why is it stopping in the first place? If it's stopping,
something wrong is happening and restarting it *isn't* going to fix it.

Existing permission systems handle a lot of cases. *kit (logind, is
more like it) has some extra things to make it a bit more granular.
It's mostly unneeded complexity. The biggest benefit logind brings to
a system is multi-seat capability.
> 
>> And a lot of Gentoo is surprisingly simple: Like our use of bash 
>> scripts for recipies to build things, like using rsync to
>> deploy/relay not just those recipies, but security notices and
>> news items, which are themselves reasonably simple formats.
> 
> Well, one thing about Gentoo that certainly isn't simple is our
> init.d scripts.
> 
> Compare this: http://pastebin.com/sSDtpF4t
> 
> With this: http://pastebin.com/Lfn8r7qP
> 
> Systemd does the job in 10% of the code (and half of it is a
> comment), and doesn't implement its own service polling and killer
> script during shutdown independently for every service (not that
> every init.d script even does this - most of them will just leave
> orphans behind, and systemd will catch orphans that even the
> lengthy init.d script for apache misses).

This is a dishonest comparison. You're comparing a declarative
configuration file with a Turing-complete scripting language. If we're
going by SLOC, we would need to also consider all the C code that
systemd uses to *act* on said declarative file. One could argue that
rc scripts in this case are a lot of repetition, and that'd be
correct. There's nothing stopping rc scripts from becoming similar to
systemd's unit files. It'd be akin to our eclass system. But why is
this important? OpenRC supports cgroups, so if a daemon isn't reaping
its children correctly, a bug needs to be filed, either on the package
providing the script or on OpenRC itself.
> 
>> 
>> The only preference I see here is the preference to not have and 
>> install things your system has no use for, which I find an odd 
>> preference to be complaining about, and depending on your system 
>> requirements, that may also be not so much "preference".
>> 
> 
> And hence my suggestion that we simply get this stuff out of the 
> stage3s in the first place.  Then everybody can just pick the 
> implementation that best suits their requirements.

I can get behind that. This dodges all sorts of arguments regarding
initial installations. There's still the issue of the virtual,
however; would we add sys-fs/udev to p.mask in non-systemd profiles to
clarify the decision, or make eudev the default choice in the virtual?
I think we can all agree on making it an additional step in the
handbook, but the default is still at hand.
> 
> If you want to talk about default providers, the most
> straightforward one to use is systemd.  It is what people are going
> to be used to coming from other distros, it is what every upstream
> package expects to be running anyway, and it is the simpler tool
> that does everything that most people want.
> 
> For people who want a more exotic configuration, there are 
> alternatives, and Gentoo should certainly support using them as
> long as people care to maintain them.

This is the same argument other distros used before they switched
completely to systemd. When has Gentoo ever been about marching to the
beat of other distros? Are you advocating for following what others do
simply because it's popular?

We have nothing to gain by making systemd the default init system, and
it would tick off a considerable portion of our userbase, even with it
being changeable. It's one thing to put it on the live media, or even
as part of (a flavor of) a stage4, but to push for it being a default
across the board on a standard install is a bit much.

The e-mails I've seen from you in this thread seem out of the
ordinary. Has the systemd team been talking with you, or people from
other distributions urging for Gentoo to switch?

To clarify, there's nothing wrong with systemd as a choice. It's
special enough that it has its own set of profiles. I think that's
enough, and creates a workable path for both.

For this thread, it seems that we need to do something similar with
eudev. sys-fs/udev already comes with the systemd profile, and eudev
fulfills all the same needs. Maybe we should speak with our users and
find out just how many people are using systemd-udev intentionally
rather than going along with it as a default, and their reasoning for
doing so. The same could go for eudev. Not so much for numbers
(because unlike Debian, we have nothing comparable to popcon), but to
see where people are standing on it.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWueRSAAoJEAEkDpRQOeFw7DYP/i4hqRWuhSVUZsAXE8DX9GAa
vapYjX43fb5S5BzgqS5KVbRWUdDUQNAghyy9kywPUFjjQRArzTF+xX3EmBhj5rUG
Agar+BB3fGh19NbvMtwoJ3C+eHBw7aNGkmlj65vpMOmOnZ/7lDZNU0PbZ4GtDdmp
FoQ2ooR5+TAV7xZaMRf5liwcptMcIPrOhksvUWtzRPhFjGyJLRtg60xO6hxC5Zc0
yF+hrO8/QNnqIvKn5u1sXAx3GyRE2UZtPX+Fad6Z376gH+8T7CtbqjLT1rxIZedd
CYLusg/AdENLsS6EVy6KN5exIH1oAeAqWwtiUS88VURzP7QY7TA3RbCPVVgCFe0M
kM2J5JZqlrdCxG935zEk3kiO9dtW4wBQNbjyLD7G3PCkWWnv2eZsP+lk+pFQlIvw
+Sfbb4nrtusSu8MYkeLnAQJ3oyt8qYUQN0Ip07Y/5h+3pKizMi/A2NVjLdoH35tx
KXnpy5LPYn7Hk7UrVGPdgNQC/GckRcIAgwjH90fvO2cOAV6pdcPAR/VYxaodQeWZ
AUZdT6ksmuZuhfBgZBEU2X2ilEVZsDI22egjz5/+FCDZjr2c56cURCP6+GXcW4ao
LaM/OoTmHkEQSG4PVTSNE6wXN9lrVx5v/TvH9vDjdViugdzOUHyt58gXiC+Bk8wA
XD8LH56ilZGFcoJWdmSR
=Ggkl
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Francesco Riosa]

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

2016-02-09 13:17 GMT+01:00 Rich Freeman <rich0@gentoo.org>:

> On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric <kentfredric@gmail.com>
> wrote:
> >
> > A pure udev system is in comparison, much simpler than a systemd system.
>
> I don't buy that at all.  In systemd you have a unified object model
> across device nodes, mountpoints, services, and cron jobs.  In the
> alternate model you have completely different implementations of all
> of those, each with their own configurations and behaviors.
>
> >
> > And that's much of the beauty of OpenRC. Its simple, it achieves the
> > same goals as Systemd and Upstart, etc, but does so with a lot less
> > mechanics under the hood, and doesn't clutter up systems with features
> > you don't need prematurely.
>
> OpenRC doesn't achieve MANY of the goals of systemd.  Maybe you don't
> personally care about some of them, but you really can't compare the
> feature sets at this point.
>
> > And there are great benefits from simplicity over complexity.
>
> Absolutely.  It is great to create a text file and symlink it in a
> directory named after a service to make that service auto-restart, or
> have a memory limit, or set an IO priority for that service.  It is
> great to not have to think about anything to have just about all your
> processes organized into a sensible cgroup hierarchy.  It is great to
> be able to tweak one config file to ensure that users who log out of a
> system can't leave any processes behind.
>
> It is great to be able to tweak something in policykit and change
> things like who can shut down the system, or who can restart a
> service.
>
> The simplicity of systemd comes from the fact that it has brought what
> used to be a collection of many independent tools under one roof, and
> created a converging set of interfaces for all of them.
>
> > And a lot of Gentoo is surprisingly simple: Like our use of bash
> > scripts for recipies to build things, like using rsync to deploy/relay
> > not just those recipies, but security notices and  news items, which
> > are themselves reasonably simple formats.
>
> Well, one thing about Gentoo that certainly isn't simple is our init.d
> scripts.
>
> Compare this:
> http://pastebin.com/sSDtpF4t
>
> With this:
> http://pastebin.com/Lfn8r7qP
>
> Systemd does the job in 10% of the code (and half of it is a comment),
>

Actually that's incorrect, it does not implement "configdump" and
"fullstatus" is it possible for systemd to implement those?
Anyway we are hijaking another discussion to OpenRC versus Systemd or it's
only my impression?


> and doesn't implement its own service polling and killer script during
> shutdown independently for every service (not that every init.d script
> even does this - most of them will just leave orphans behind, and
> systemd will catch orphans that even the lengthy init.d script for
> apache misses).
>
> >
> > The only preference I see here is the preference to not have and
> > install things your system has no use for, which I find an odd
> > preference to be complaining about, and depending on your system
> > requirements, that may also be not so much "preference".
> >
>
> And hence my suggestion that we simply get this stuff out of the
> stage3s in the first place.  Then everybody can just pick the
> implementation that best suits their requirements.
>
> If you want to talk about default providers, the most straightforward
> one to use is systemd.  It is what people are going to be used to
> coming from other distros, it is what every upstream package expects
> to be running anyway, and it is the simpler tool that does everything
> that most people want.
>
> For people who want a more exotic configuration, there are
> alternatives, and Gentoo should certainly support using them as long
> as people care to maintain them.
>
> --
> Rich
>
>

[-- Attachment #2: Type: text/html, Size: 5978 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Ulrich Mueller]

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

[Replying to a more or less random posting of this thread.]

Maybe it helps to look at the actual dependency in virtual/udev-217:

RDEPEND="
	!systemd? ( || ( >=sys-fs/udev-217 >=sys-fs/eudev-2.1.1 ) )
	systemd? ( >=sys-apps/systemd-217:0 )"

IMHO, switching the order within the first (i.e. !systemd) USE
conditional would make a lot of sense. Why should we default to the
systemd udev for users that request USE=-systemd in their flags?

On a personal note, I'm using eudev on my systems and have never
experienced any problems with it. Keep on the good work!

Ulrich

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

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Tue, Feb 9, 2016 at 8:06 AM, Daniel Campbell <zlg@gentoo.org> wrote:
>
> Perhaps that's because each of those things should not actually be
> considered the same object type. That sort of design may be convenient
> to users, but is more akin to treating everything like a nail when you
> have a hammer.
>
> Also note that in the 'alternate' model, each of the above is handled
> by a different tool. It's obvious that using a combination of
> different tools will result in different conceptualizations of each of
> those parts in a system. I see little benefit in a single project
> pretending to understand everything about each of them.

I thought the whole beauty of unix was the everything-is-a-file design?

>
> If I didn't know any better I'd say this reads like shilling. Firstly,
> there's a real problem if you're depending on a daemon restarting
> itself. Why is it stopping in the first place? If it's stopping,
> something wrong is happening and restarting it *isn't* going to fix it.

Sure, but then why does the linux kernel have an option to auto-reboot
after a panic?  Surely it is better if there is a kernel panic to just
leave the server down for a few days until an admin shows up to debug
the kernel?

>
> Existing permission systems handle a lot of cases. *kit (logind, is
> more like it) has some extra things to make it a bit more granular.
> It's mostly unneeded complexity. The biggest benefit logind brings to
> a system is multi-seat capability.

Emphasis on "existing permission systemS" - again you're comparing a
patchwork of different solutions to a problem vs a harmonized
solution.

>>
>>> And a lot of Gentoo is surprisingly simple: Like our use of bash
>>> scripts for recipies to build things, like using rsync to
>>> deploy/relay not just those recipies, but security notices and
>>> news items, which are themselves reasonably simple formats.
>>
>> Well, one thing about Gentoo that certainly isn't simple is our
>> init.d scripts.
>>
>> Compare this: http://pastebin.com/sSDtpF4t
>>
>> With this: http://pastebin.com/Lfn8r7qP
>>
>> Systemd does the job in 10% of the code (and half of it is a
>> comment), and doesn't implement its own service polling and killer
>> script during shutdown independently for every service (not that
>> every init.d script even does this - most of them will just leave
>> orphans behind, and systemd will catch orphans that even the
>> lengthy init.d script for apache misses).
>
> This is a dishonest comparison. You're comparing a declarative
> configuration file with a Turing-complete scripting language.

That is how each solution implements its configuration.  It isn't my
fault that openrc forces everybody to write bash scripts just to
start/stop a single process.

The complexity of openrc is inherent in the design.

Sure, systemd has more lines of code internally, but the difference is
that instead of having a bazillion independent bash scripts maintained
by different people at different levels of QA, you have a single
codebase that almost all distros share that is maintained to a higher
level of QA.  Features are implemented once there instead of a million
times in various shell scripts.

>
> I can get behind that. This dodges all sorts of arguments regarding
> initial installations. There's still the issue of the virtual,
> however; would we add sys-fs/udev to p.mask in non-systemd profiles to
> clarify the decision, or make eudev the default choice in the virtual?
> I think we can all agree on making it an additional step in the
> handbook, but the default is still at hand.

I agree, but it becomes a less important default, like whether you
prefer vi/emacs to nano.

>>
>> If you want to talk about default providers, the most
>> straightforward one to use is systemd.  It is what people are going
>> to be used to coming from other distros, it is what every upstream
>> package expects to be running anyway, and it is the simpler tool
>> that does everything that most people want.
>>
>> For people who want a more exotic configuration, there are
>> alternatives, and Gentoo should certainly support using them as
>> long as people care to maintain them.
>
> This is the same argument other distros used before they switched
> completely to systemd. When has Gentoo ever been about marching to the
> beat of other distros? Are you advocating for following what others do
> simply because it's popular?

Gentoo has always been like other mainstream distros (until Arch came
along it was probably closest to Debian).  Its distinctiveness came
from offering choices to users and being source-based.  I think that
is what we're good at.

The only reason we had OpenRC is that EVERYBODY was rolling their own
service managers, and OpenRC was better than the alternatives.  I
think that was great, but everybody else has moved on.

> The e-mails I've seen from you in this thread seem out of the
> ordinary. Has the systemd team been talking with you, or people from
> other distributions urging for Gentoo to switch?

Not at all.

I'll admit this has been a bit of an emotional thread for me.  I think
my frustration comes from the fact that it seems like the whole reason
that eudev exists is because people really strongly believe that
systemd isn't the right way to go, and yet those same people don't
seem to realize that others might feel just as strongly that eudev
isn't the right way to go.

Surely anybody suggesting switching to eudev as the default
virtual/udev provider had to have realized that this would create a
huge controversy.

Even if standalone udev is a dead-end (something that is speculation
at this point), it isn't like the code that exists today will suddenly
stop working.  Worst case we just have to change the default at a
later point in time.

Even just kicking the can down the road has a lot of advantages:
1.  Everything works fine today.
2.  We don't know for sure that it will ever stop working.
3.  Deferring a decision means we don't have to wage a huge battle
over which way the decision ought to go.
4.  If we do have to make a decision in the future, we'll have more
information to act on.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Tue, Feb 9, 2016 at 8:39 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>
> IMHO, switching the order within the first (i.e. !systemd) USE
> conditional would make a lot of sense. Why should we default to the
> systemd udev for users that request USE=-systemd in their flags?
>

Well, if we're going to force it to be in the stage3, I guess this
boils down to whether eudev or udev is the better nano.

I think it makes far more sense to just remove some of the controversy
by taking it out of the system set first.  Then I doubt anybody would
notice the switch.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Ulrich Mueller]

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

>>>>> On Tue, 9 Feb 2016, Rich Freeman wrote:

> Well, if we're going to force it to be in the stage3, I guess this
> boils down to whether eudev or udev is the better nano.

"Nicht alles was hinkt ist ein Vergleich", as we say in German.
Emacs has a flexible extension language, whereas nano uses a
configuration file. Not sure in which direction this would map to
OpenRC and systemd.

> I think it makes far more sense to just remove some of the controversy
> by taking it out of the system set first.  Then I doubt anybody would
> notice the switch.

Take what out of the system set? virtual/udev isn't there, in the
first place, and virtual/dev-manager is needed for a working system.

Ulrich

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

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/09/2016 05:44 AM, Rich Freeman wrote:
> On Tue, Feb 9, 2016 at 8:06 AM, Daniel Campbell <zlg@gentoo.org>
> wrote:
>> 
>> Perhaps that's because each of those things should not actually
>> be considered the same object type. That sort of design may be
>> convenient to users, but is more akin to treating everything like
>> a nail when you have a hammer.
>> 
>> Also note that in the 'alternate' model, each of the above is
>> handled by a different tool. It's obvious that using a
>> combination of different tools will result in different
>> conceptualizations of each of those parts in a system. I see
>> little benefit in a single project pretending to understand
>> everything about each of them.
> 
> I thought the whole beauty of unix was the everything-is-a-file
> design?

Isn't there a bit more to it than that? We can take any design idea,
apply it to an extreme, and see where it won't work. Plan9 is a 'more
proper UNIX' and somehow does a bunch of things exclusively through
the filesystem. I think that design can be great for some things. For
a lot of the above, even the disparate set of tools interfaces with
files. `crontab -e` edits a file, device nodes have been in the
filesystem for forever, mounts have historically been managed by fstab
and need a place in the filesystem to mount, etc.

The primary difference here is systemd throws it into one directory
tree instead of multiple. Systemd is great if you agree with the
design decisions made. That's the problem/benefit with both
approaches. If you go with systemd, you have to like or agree with
every change they make or every design decision on everything. With
multiple tools, you can pick and choose. If I don't like my cron
implementation, I can swap it out with another one. If I was with
systemd and didn't like it, I'd have to recompile systemd to remove
the feature (assuming it's not required like logind), and replace it
with a standalone cron service, managing it with systemd. I could be
lazy and leave systemd running and just add the cron service, but that
would needlessly complicate things and may end up doubling cronjobs.

Politics aside, the dichotomy caused by systemd comes down between
groups of people that either don't care about their lower level system
(or agree with its design) and people who either disagree with
systemd's design and/or want to be able to swap things out when they
get pissed at the way one component is acting. Systemd is an
all-or-nothing choice, and among a population that fiercely values
choices, that can understandably make them concerned. That said,
systemd still deserves to be treated as a choice.

> 
>> 
>> If I didn't know any better I'd say this reads like shilling.
>> Firstly, there's a real problem if you're depending on a daemon
>> restarting itself. Why is it stopping in the first place? If it's
>> stopping, something wrong is happening and restarting it *isn't*
>> going to fix it.
> 
> Sure, but then why does the linux kernel have an option to
> auto-reboot after a panic?  Surely it is better if there is a
> kernel panic to just leave the server down for a few days until an
> admin shows up to debug the kernel?

I see where you're coming from, but there are situations where you
really *do* want that server to stay down. What sort of data is on
that server? What purpose is it fulfilling? If it's a webserver, its
failure will be obvious, immediately apparent, and odds are someone is
on-call to manage it. If you're holding important data like a
government agency, you likely have someone on-call as well, but do you
want a compromised server rebooting continuously as a cracker or some
other entity is trying to take advantage of a kernel bug? The correct
course of action there is to let it fail, get your staff to the
machine, isolate it from the network, and start triaging.

There are still cases where I suppose you'd want auto-reboot, but I
can't imagine they'd be the correct answer for the problem at hand.
> 
>> 
>> Existing permission systems handle a lot of cases. *kit (logind,
>> is more like it) has some extra things to make it a bit more
>> granular. It's mostly unneeded complexity. The biggest benefit
>> logind brings to a system is multi-seat capability.
> 
> Emphasis on "existing permission systemS" - again you're comparing
> a patchwork of different solutions to a problem vs a harmonized 
> solution.

It's more like "which would you like to use?" Using them in tandem is
asking for issues, but generally the sudoers file itself and a few
groups can handle that for you, or acls, or (maybe?) LDAP. There's
many ways to skin that cat.
> 
>>> 
>>>> And a lot of Gentoo is surprisingly simple: Like our use of
>>>> bash scripts for recipies to build things, like using rsync
>>>> to deploy/relay not just those recipies, but security notices
>>>> and news items, which are themselves reasonably simple
>>>> formats.
>>> 
>>> Well, one thing about Gentoo that certainly isn't simple is
>>> our init.d scripts.
>>> 
>>> Compare this: http://pastebin.com/sSDtpF4t
>>> 
>>> With this: http://pastebin.com/Lfn8r7qP
>>> 
>>> Systemd does the job in 10% of the code (and half of it is a 
>>> comment), and doesn't implement its own service polling and
>>> killer script during shutdown independently for every service
>>> (not that every init.d script even does this - most of them
>>> will just leave orphans behind, and systemd will catch orphans
>>> that even the lengthy init.d script for apache misses).
>> 
>> This is a dishonest comparison. You're comparing a declarative 
>> configuration file with a Turing-complete scripting language.
> 
> That is how each solution implements its configuration.  It isn't
> my fault that openrc forces everybody to write bash scripts just
> to start/stop a single process.
> 
> The complexity of openrc is inherent in the design.
> 
> Sure, systemd has more lines of code internally, but the difference
> is that instead of having a bazillion independent bash scripts
> maintained by different people at different levels of QA, you have
> a single codebase that almost all distros share that is maintained
> to a higher level of QA.  Features are implemented once there
> instead of a million times in various shell scripts.

And that's where something like eclasses (but for rc scripts) could be
used to consolidate all the redundancy. As far as I can tell we
already implement something similar with the built-in functions that
rc scripts are expected to have. The thing is, do we want to go in the
direction of declarative files and the limitations that come with
that? The complexity would then have to be migrated to the daemon
manager itself instead of the scripts. No matter how you look at it,
managing daemons is non-trivial and rather complex. Most people aren't
going to touch unit files *or* rc scripts unless they're developers,
and most developers will read documentation. If anything, a developer
will have more control over how their daemon is handled in the rc
script. They would have to read systemd's C code or its plethora of
unit options to set it up 'just right' to achieve the same.

Even that will have different tastes across the board. Some developers
want complete control, so they'll want to build their own script.
Others don't care or don't mind integrating with something and
providing a configuration file.
> 
>> 
>> I can get behind that. This dodges all sorts of arguments
>> regarding initial installations. There's still the issue of the
>> virtual, however; would we add sys-fs/udev to p.mask in
>> non-systemd profiles to clarify the decision, or make eudev the
>> default choice in the virtual? I think we can all agree on making
>> it an additional step in the handbook, but the default is still
>> at hand.
> 
> I agree, but it becomes a less important default, like whether you 
> prefer vi/emacs to nano.

That may be the case once it's covered in the handbook, but in the
future we already know the systemd team does not intend on maintaining
udev-sans-systemd forever.

> 
>>> 
>>> If you want to talk about default providers, the most 
>>> straightforward one to use is systemd.  It is what people are
>>> going to be used to coming from other distros, it is what every
>>> upstream package expects to be running anyway, and it is the
>>> simpler tool that does everything that most people want.
>>> 
>>> For people who want a more exotic configuration, there are 
>>> alternatives, and Gentoo should certainly support using them
>>> as long as people care to maintain them.
>> 
>> This is the same argument other distros used before they
>> switched completely to systemd. When has Gentoo ever been about
>> marching to the beat of other distros? Are you advocating for
>> following what others do simply because it's popular?
> 
> Gentoo has always been like other mainstream distros (until Arch
> came along it was probably closest to Debian).  Its distinctiveness
> came from offering choices to users and being source-based.  I
> think that is what we're good at.
> 
> The only reason we had OpenRC is that EVERYBODY was rolling their
> own service managers, and OpenRC was better than the alternatives.
> I think that was great, but everybody else has moved on.

Do you consider OpenRC a project that's not useful anymore?
> 
>> The e-mails I've seen from you in this thread seem out of the 
>> ordinary. Has the systemd team been talking with you, or people
>> from other distributions urging for Gentoo to switch?
> 
> Not at all.
> 
> I'll admit this has been a bit of an emotional thread for me.  I
> think my frustration comes from the fact that it seems like the
> whole reason that eudev exists is because people really strongly
> believe that systemd isn't the right way to go, and yet those same
> people don't seem to realize that others might feel just as
> strongly that eudev isn't the right way to go.
> 
> Surely anybody suggesting switching to eudev as the default 
> virtual/udev provider had to have realized that this would create
> a huge controversy.

Would it, really? I think it's hard for us to say, which is why I
suggested getting a rough idea from our users, somehow. The people who
don't care won't notice anything, and the people who do care will know
how to mask eudev.

It's possible that eudev isn't the way to go. But we at least know
that there are no plans for it to be absorbed by a parent project.
That said...

> 
> Even if standalone udev is a dead-end (something that is
> speculation at this point), it isn't like the code that exists
> today will suddenly stop working.  Worst case we just have to
> change the default at a later point in time.
> 
> Even just kicking the can down the road has a lot of advantages: 1.
> Everything works fine today. 2.  We don't know for sure that it
> will ever stop working. 3.  Deferring a decision means we don't
> have to wage a huge battle over which way the decision ought to
> go. 4.  If we do have to make a decision in the future, we'll have
> more information to act on.
> 

It's not really speculation. [1] [2] You're right, though. We could
keep sys-fs/udev around, at an older version, until it just stops
working. That would likely take months, since udev's core
functionality really hasn't changed in years. Rules you wrote 6 years
ago will probably still work.

I can get behind deferring the decision, but if we were to make it,
knowing the systemd team's plans for the future and the current state
of the virtual (depending on the systemd flag), it makes more sense to
default to eudev, since you have to have '-systemd' to trigger either
of them.

[1]:
https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
[2]:
https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html

Unfortunately I could not find more links. I recall seeing a ML
posting from Poettering where he indicated separate udev would not be
supported perpetually. I'm not the best at searching the Web so I
couldn't find it.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWuftQAAoJEAEkDpRQOeFwQooQAKyp6KmeyUCffTON9H+Hhw8g
swqddfxkBo+QVa2yhdGDqPe8NaHSMZ7KdcW/2f+V/4YOUntYkchs346czSPlYm1P
559+8jrVsHflLUO5hCB5SlFtdwNy4a+tWWObOej5yk+b+O6PuORlsTL+UZ4K3YUg
bDGF/CG6FLxH8iSocZFpBMxbjgxNioSzHjIBTfdvYf2kXK6bF5vdFaAGGu1bs8/g
Utaz/PJDG7XtkgKUZq87B3xl2Dy4tjDwRDHGsricGvHW0byaovrBJ/+N8gJ9JAL0
/WubGP20clOmDo6cq0CIXkx6DcqOa8MW44r0CPIxfkFhxI192+KznmfJjlO67kEL
Xuk+fLkNIBJB89Y09ZkTex9aM96ZJ/eXcU/VdJQ00Dteun/7iKBSto5stgXRi/po
Xu5LHJxsuL7XHsgo3sl0vkJwVcv87gQZZn4faeV/R9+pUawS034EzV5yg979IZUl
7CDJ69Ei0kS7sYY+oDv7wZcyLxTqD02btQ33W7LI3HlPwu7zoPziO99H3m9jtctN
+QPSX5lRt2jAMzhJbBLGHBgs0QIZbMjhQNLUGQNm4cO6JKqOvfYT4a8v5G1d8bO/
6YUUynVxNtTIWnf/h6ap1Znd7dSaveKM02tmPa04o37McOhyTybt8msvg+LhgYO9
XfnFlRggdBPxwvLeFBFg
=8Jxb
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Tue, Feb 9, 2016 at 9:44 AM, Daniel Campbell <zlg@gentoo.org> wrote:
>
> On 02/09/2016 05:44 AM, Rich Freeman wrote:
>
> If you go with systemd, you have to like or agree with
> every change they make or every design decision on everything.

There is a bit of irony in suggesting this in a discussion that
started with eudev, which is proof that you don't have to agree with
every decision they make on everything.

> I see where you're coming from, but there are situations where you
> really *do* want that server to stay down.

Of course, and auto-restarting a daemon is completely optional systemd behavior.

>>
>> Sure, systemd has more lines of code internally, but the difference
>> is that instead of having a bazillion independent bash scripts
>> maintained by different people at different levels of QA, you have
>> a single codebase that almost all distros share that is maintained
>> to a higher level of QA.  Features are implemented once there
>> instead of a million times in various shell scripts.
>
> And that's where something like eclasses (but for rc scripts) could be
> used to consolidate all the redundancy. As far as I can tell we
> already implement something similar with the built-in functions that
> rc scripts are expected to have. The thing is, do we want to go in the
> direction of declarative files and the limitations that come with
> that? The complexity would then have to be migrated to the daemon
> manager itself instead of the scripts.

No need to go down that road.  Somebody already wrote it for you.  :)

> No matter how you look at it,
> managing daemons is non-trivial and rather complex. Most people aren't
> going to touch unit files *or* rc scripts unless they're developers,
> and most developers will read documentation. If anything, a developer
> will have more control over how their daemon is handled in the rc
> script. They would have to read systemd's C code or its plethora of
> unit options to set it up 'just right' to achieve the same.

That sounds like suggesting that in order to edit my postfix
configuration I need to reverse engineer the software.

You just grep the manpage for whatever you're looking for.  I'll give
you two guesses as to what this option does:

       IOSchedulingClass=
           Sets the IO scheduling class for executed processes. Takes
an integer between 0 and 3 or one of
           the strings none, realtime, best-effort or idle. See
ioprio_set(2) for details.

>>
>> The only reason we had OpenRC is that EVERYBODY was rolling their
>> own service managers, and OpenRC was better than the alternatives.
>> I think that was great, but everybody else has moved on.
>
> Do you consider OpenRC a project that's not useful anymore?

I don't personally think it is useful, but I have no objections to
people who do find it useful maintaining it.

I think we're better off getting back onto common ground, which is choice.


-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Luca Barbato]

On 09/02/16 04:09, Rich Freeman wrote:
> On Mon, Feb 8, 2016 at 7:58 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
>>
>> what does in-house tool mean?  i'm a gentoo developer but i also work
>> on an upstream project (eudev) that 14 distros use.
>>
>> some of the criticism given here are my concerns as well and i've
>> spoken with the various distros --- slack, parted magic, puppy.  they
>> get what's going on and they still see eudev is the best way forward
>> for now.  it may not be in the future, but neither will a udev
>> extracted from a compiled full systemd codebase.
> 
> How many of those 14 distros have more than 14 users?
> 

Alpine is quite used as docker image base nowadays... I'd say that alone
makes it _quite_ widely used.

lu

Re: [gentoo-dev] Changing order of default virtual/udev provider

[William Hubbs]

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

On Tue, Feb 09, 2016 at 03:23:15PM +0100, Ulrich Mueller wrote:
> >>>>> On Tue, 9 Feb 2016, Rich Freeman wrote:
> 
> > Well, if we're going to force it to be in the stage3, I guess this
> > boils down to whether eudev or udev is the better nano.
> 
> "Nicht alles was hinkt ist ein Vergleich", as we say in German.
> Emacs has a flexible extension language, whereas nano uses a
> configuration file. Not sure in which direction this would map to
> OpenRC and systemd.
> 
> > I think it makes far more sense to just remove some of the controversy
> > by taking it out of the system set first.  Then I doubt anybody would
> > notice the switch.
> 
> Take what out of the system set? virtual/udev isn't there, in the
> first place, and virtual/dev-manager is needed for a working system.

A boot loader is also needed for a working system, but we do not have
one in @system. Instead, we direct the user to choose one.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Brian Dolbec]

On Tue, 9 Feb 2016 08:44:03 -0500
Rich Freeman <rich0@gentoo.org> wrote:
 
> I'll admit this has been a bit of an emotional thread for me.  I think
> my frustration comes from the fact that it seems like the whole reason
> that eudev exists is because people really strongly believe that
> systemd isn't the right way to go, and yet those same people don't
> seem to realize that others might feel just as strongly that eudev
> isn't the right way to go.
>

I started the replies with a simple +1, and that I had switched to
eudev...  No, "Down with the evil systemd.borg" comments

As one of the few huge threads that I have been reading.  It is you
that has been taking this thread more in the direction of something
akin to a preacher shouting we're all going to burn in hell for even
considering switching the default.  While you were obviously more
emotional, Anthony was very calmly, and clearly refuting many of your
statements.

 
> Surely anybody suggesting switching to eudev as the default
> virtual/udev provider had to have realized that this would create a
> huge controversy.
> 

BUT WHY DOES it have to be!!!!!

Why can't we as a group simply respond to something like this with a
simple +1, -1  and a few pros/cons

Why must it become yet another shouting match.  And I'm sorry to have to
tell you this, but you have been leading the charge in that direction.


> Even if standalone udev is a dead-end (something that is speculation
> at this point), it isn't like the code that exists today will suddenly
> stop working.  Worst case we just have to change the default at a
> later point in time.
> 
> Even just kicking the can down the road has a lot of advantages:
> 1.  Everything works fine today.

yes

> 2.  We don't know for sure that it will ever stop working.

no, we don't

> 3.  Deferring a decision means we don't have to wage a huge battle
> over which way the decision ought to go.

As I pointed out above, you seem to be leading the battle charge.

Why couldn't you have simply replied "-1 I use systemd like most other
distros" and "It works for me as is"  and leave it at that.

> 4.  If we do have to make a decision in the future, we'll have more
> information to act on.
> 

put off till tomorrow what you can avoid doing today...  tsk, tsk, tsk

IT IS A SIMPLE POLL of the possibility of switching the default VIRTUAL
we were suppose to be talking about/voting on!!!!



Sorry everyone for a little shouting of my own.
-- 
Brian Dolbec <dolsen>

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 02/09/2016 02:39 PM, Ulrich Mueller wrote:
> [Replying to a more or less random posting of this thread.]
> 
> Maybe it helps to look at the actual dependency in
> virtual/udev-217:
> 
> RDEPEND=" !systemd? ( || ( >=sys-fs/udev-217 >=sys-fs/eudev-2.1.1 )
> ) systemd? ( >=sys-apps/systemd-217:0 )"
> 
> IMHO, switching the order within the first (i.e. !systemd) USE 
> conditional would make a lot of sense. Why should we default to the
>  systemd udev for users that request USE=-systemd in their flags?
> 

Exactly, in particular since this isn't officially supported as
standalone to begin with it can only help with stability of systems to
change the default order.

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWuiCtAAoJECULev7WN52FVKIIALlJosgibmIYht6DcUf17mHI
Dez1iUcS/WxrAxBYvK5l0M1x5AqBHoCbtwRvG+vSCipaQx1hGAu+UAmE12KXHD6l
JP1Af0D/x4KeWGhuWYpjJF+CCrXW4H+1/RKiQ7Tgo+0zxkjjeq8lr92m3NslAc7l
cwoMz4jgaCfzmHHdrexDu1t/jBoM730yyrhi7x+/LVm7Go7O/H82dZs8JfNdaoJJ
O5T75WPxYcmWevuuZKfj31h71+A2eTzeKD8Tcq8v2HbTmqJPKT3pwG6F8ZJIZENJ
TWjWoFC9vDwaEKSQ8Z68+zi4calKjDXEPVYipBAnKJtltrQSlJCvUCri5U99MsM=
=btZm
-----END PGP SIGNATURE-----

boot loader in @system, was Re: [gentoo-dev] Changing order of default virtual/udev provider

[Chí-Thanh Christopher Nguyễn]

William Hubbs schrieb:
> A boot loader is also needed for a working system, but we do not > have one in @system. Instead, we direct the user to choose one.

Actually it is not strictly necessary to install a separate boot
loader. On EFI systems (arm and x86, not ia64 though), the kernel's
EFI stub will function as boot loader.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rubin]

+1, been using eudev since starting with gentoo, in fact, it was one of
the prime motivators of trying out gentoo [1].

[1]: using gentoo for about a year now and primary reason for me and
about 2 colleagues who switched with me was "a linux distro with enough
flexibility to completely avoid
systemd/logind/polkit/policykit/networkmanager/modemmanager at
./configure level". The resulting system is extremely simple
conceptually, with a low process count.


On 02/09/16 18:18, Brian Dolbec wrote:
> On Tue, 9 Feb 2016 08:44:03 -0500
> Rich Freeman <rich0@gentoo.org> wrote:
>  
>> I'll admit this has been a bit of an emotional thread for me.  I think
>> my frustration comes from the fact that it seems like the whole reason
>> that eudev exists is because people really strongly believe that
>> systemd isn't the right way to go, and yet those same people don't
>> seem to realize that others might feel just as strongly that eudev
>> isn't the right way to go.
>>
> 
> I started the replies with a simple +1, and that I had switched to
> eudev...  No, "Down with the evil systemd.borg" comments
> 
> As one of the few huge threads that I have been reading.  It is you
> that has been taking this thread more in the direction of something
> akin to a preacher shouting we're all going to burn in hell for even
> considering switching the default.  While you were obviously more
> emotional, Anthony was very calmly, and clearly refuting many of your
> statements.
> 
>  
>> Surely anybody suggesting switching to eudev as the default
>> virtual/udev provider had to have realized that this would create a
>> huge controversy.
>>
> 
> BUT WHY DOES it have to be!!!!!
> 
> Why can't we as a group simply respond to something like this with a
> simple +1, -1  and a few pros/cons
> 
> Why must it become yet another shouting match.  And I'm sorry to have to
> tell you this, but you have been leading the charge in that direction.
> 
> 
>> Even if standalone udev is a dead-end (something that is speculation
>> at this point), it isn't like the code that exists today will suddenly
>> stop working.  Worst case we just have to change the default at a
>> later point in time.
>>
>> Even just kicking the can down the road has a lot of advantages:
>> 1.  Everything works fine today.
> 
> yes
> 
>> 2.  We don't know for sure that it will ever stop working.
> 
> no, we don't
> 
>> 3.  Deferring a decision means we don't have to wage a huge battle
>> over which way the decision ought to go.
> 
> As I pointed out above, you seem to be leading the battle charge.
> 
> Why couldn't you have simply replied "-1 I use systemd like most other
> distros" and "It works for me as is"  and leave it at that.
> 
>> 4.  If we do have to make a decision in the future, we'll have more
>> information to act on.
>>
> 
> put off till tomorrow what you can avoid doing today...  tsk, tsk, tsk
> 
> IT IS A SIMPLE POLL of the possibility of switching the default VIRTUAL
> we were suppose to be talking about/voting on!!!!
> 
> 
> 
> Sorry everyone for a little shouting of my own.
> 

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alon Bar-Lev]

On 9 February 2016 at 13:59, Rich Freeman <rich0@gentoo.org> wrote:
>
> On Tue, Feb 9, 2016 at 12:27 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
> > On 2/8/16 10:09 PM, Rich Freeman wrote:
> >> How many of those 14 distros have more than 14 users?
> >
> > gentoo is very unpopular as a distro.  however, it excels as a meta
> > distro.  if you marginalize its special features, you take away all its
> > charm.
>

<snip>

> The controversy comes in when you want to make it a default, and start
> arguing that it is somehow better than the solution everybody else is
> using.
>
> Outside of Gentoo people either aren't concerned at all with eudev (it
> probably isn't even in their distro repositories), or they're a tiny
> distro whose main purpose in life seems to be to avoid installing
> systemd.  Of course you're going to get praise from them.
>
> I've always supported having eudev hosted by Gentoo.  I just don't
> support it being the default udev provider.
>

I too support eudev as default for openrc people, Gentoo is about
choice, and OpenRC eco-system should get rid of all systemd related
dependencies. This is a choice we provide. eudev should stand as its
own and provide a service for the non-systemd users, these users
actually care about what we provide, Gentoo is one of the last distros
that enables that. I use eudev since its first beta, and these guys
provides good service.

I also mask all systemd files that somehow find their way into my
system thanks to your past decisions as systemd supporter, instead of
installing these only when systemd USE flag is set and adding openrc
USE flag for the systemd users folks.

It may in future that udev will completely relay on systemd and we
left with eudev as the only choice for non systemd-eco system, it is
better to start building this eco-system now, make sure we have a
working solution at any given point in time.

Alon

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Tue, Feb 9, 2016 at 12:18 PM, Brian Dolbec <dolsen@gentoo.org> wrote:
>
> Why must it become yet another shouting match.  And I'm sorry to have to
> tell you this, but you have been leading the charge in that direction.
>

Fair enough.  I'll admit that this has been a lot of venting for me,
and an unnecessary distraction for everybody else.

Ulm's post and discussion with xiaomiao on #gentoo-dev have made me
reconsider my attitude towards this.

The reality is that this change really only impacts non-systemd users,
so the question really should be what provides the best experience for
these users.  I think there are legitimate arguments for either udev
or eudev from that standpoint, but I think we need to view them
through the lens of what is better for those who would prefer not to
use systemd (and that isn't limited to openrc, though I don't know
that this distinction matters).  For those who prefer to use systemd
it is a moot point.

To ulm's point virtual/dev-manager probably should be a part of
@system (even if the provider is only the minimal static device nodes)
- a posix system really isn't usable without anything in /dev.
Whichever provider is the default for that virtual might be a good
topic of discussion, but it is not a true dependency for this
decision, and I should not make it into one.

I still think we'd be well-served to get service managers out of
@system as well - another good topic of discussion, but again not a
true dependency for this decision.

Gentoo is and has always been about choice.  That is something I will
always support.

Personally this has been an area of frustration for me.  I get that
many have come to Gentoo as a refuge from systemd (as well as other
things).  I think it is a good thing that we can offer them that
choice, and I've always supported eudev having a home in Gentoo for
that reason.

However, I really do think that systemd largely represents the future
for linux distros.  It will of course evolve over time, and perhaps
some day it will be replaced, but I think that what it changes into is
going to look a lot more like systemd than the things that came
before.  I don't think we really do ourselves a service by clinging to
the old ways, and I don't think avoiding systemd as either a default
or a recommended configuration really improves our reputation or the
user experience.

And that is the frustration that caused me to lash out a bit on this
topic.  However, this really isn't appropriate.  This isn't holding
back systemd, and doesn't really have anything to do with systemd at
all.  This is about making Gentoo better for people who have made the
choice not to use systemd, and that isn't something any of us should
be holding back.  If I want to make things better for systemd users
there are plenty of areas that I could better invest this energy.

So, thanks for bearing with me.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Tue, Feb 9, 2016 at 1:25 PM, Alon Bar-Lev <alonbl@gentoo.org> wrote:
>
> I also mask all systemd files that somehow find their way into my
> system thanks to your past decisions as systemd supporter, instead of
> installing these only when systemd USE flag is set and adding openrc
> USE flag for the systemd users folks.
>

FWIW those decisions largely predate me, or at least my position on
the Council.  They're still decisions I support for a few reasons,
which I'll outline because I think they add value:

1.  Most of this concerns text files, such as systemd units or init.d
scripts.  Their installation doesn't have much practical impact on the
operation of a system which doesn't use them, and having them around
makes it easier for users to switch implementations either way without
reinstalling half of their system.  These are maskable in any case
fairly trivially.

2.  I've also seen concerns when upstream renames paths to systemd-*
for things that used to be stored someplace else.  While I know the
name tends to concern people, I think that it is beneficial to stick
to upstream paths because it doesn't add value to depart from them.
One of the things I like about Gentoo is that we follow upstream
closely, which means that if you use openrc you have init.d scripts
written for openrc and not LSB, and if you use systemd you have
systemd units and not wrappers around LSB.

I think these are both compelling reasons to maintain the current
policy, even if many don't like the direction upstream is going in the
case of systemd.  As is the case with eudev if upstream ticks off too
many people it can be forked.

> It may in future that udev will completely relay on systemd and we
> left with eudev as the only choice for non systemd-eco system, it is
> better to start building this eco-system now, make sure we have a
> working solution at any given point in time.

I think you'll find that the eudev maintainers have largely created
that eco-system already, though others can judge how well they did.
This is really just about changing a default, and will not on its own
make the eudev experience any better or worse, or more supported or
less supported.  Largely that is going to be the result of decisions
made by many upstream communities, and whether those who want to have
strong eudev support in Gentoo help deal with any issues that arise.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alexis Ballier]

On Mon, 8 Feb 2016 10:08:22 +0100
Patrick Lauer <patrick@gentoo.org> wrote:

> Ohey,
> 
> I've opened a bug at:
> https://bugs.gentoo.org/show_bug.cgi?id=573922
> 
> The idea here is to change the order of the providers of virtual/udev.
> For existing installs this has zero impact.
> For stage3 this would mean that eudev is pulled in instead of udev.
> 
> The rationale behind this is:
> 
> * eudev is an in-house fork, and there's more than a dozen distros
> already using it by default that are not us. Which is a little bit
> weird ...

IMHO the in-house fork thing is rather an argument to keep udev :)
the # of other distros using it is a rather motivating argument
and proves it is not in-house anymore though

> * Both udev and eudev have pretty much feature parity, so there won't
> be any user-visible changes

This is only a necessary condition.

> * udev upstream strongly discourages standalone udev (without systemd)
> since at least 2012


Here I think it'd be nice to have feedbacks from udev maintainers:
How much of a mess is it to support standalone udev? If maintaining
standalone udev means patching like mad, or having to build the
whole systemd just to dosbin udevd, then it is much less clean than a
proper fork and a good argument for eudev.


I'm still using udev because this is the kind of things I don't like
to change everyday and I initially didn't believe much in eudev's
sustainability. I've been proven wrong for the latter. IIRC one of eudev
goals was to be more portable and, e.g., not force very recent kernel
versions to be able to boot, which suits better Gentoo since kernel &
userland are decoupled. That'd be a +0.5 for eudev being default from
me.


Alexis.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Anthony G. Basile]

On 2/9/16 7:43 AM, Rich Freeman wrote:
> On Tue, Feb 9, 2016 at 7:36 AM, Daniel Campbell <zlg@gentoo.org> wrote:
>>
>> Given that the push for kdbus is more a political API move than
>> anything, I can see eudev sticking to the current interface and
>> working just fine.
> 
> I doubt udev is going to make that switch until kdbus is merged into
> the kernel.  I doubt that Linus will accept it simply over politics.
> 
> Once it is in the mainline kernel, why wouldn't the eudev maintainers
> switch?  At that point just about anybody using dbus is going to be
> making a switch to kdbus.

Yes.  I have a plan for a refactoring of the fork based on the direction
the kdbus stuff upstream is going.  So back last June they started some
major moving of code around.  I was hoping to follow them smoothly into
kdbus support, but that's not possible (or not easily possible).  So I
see where they're going and eudev-4 should have kdbus ready.

That's the plan but following Lennard is like following the rabbit down
the hole.

> 
> Not using kdbus will be like not using /proc.
> 


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

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

On 08 Feb 2016 13:46, Michał Górny wrote:
> I'm strongly against this, because:

agreed.  i also don't see any reasons in Patrick's e-mail to suggest
the current default is inadequate.  "i don't like upstream" isn't
relevant.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[gentoo-dev] Re: Changing order of default virtual/udev provider

[Duncan]

Mike Frysinger posted on Tue, 09 Feb 2016 14:26:52 -0500 as excerpted:

> On 08 Feb 2016 13:46, Michał Górny wrote:
>> I'm strongly against this, because:
> 
> agreed.  i also don't see any reasons in Patrick's e-mail to suggest the
> current default is inadequate.  "i don't like upstream" isn't relevant.

I'd agree, except that the way we're running udev is strongly discouraged 
and generally not supported by upstream, with a statement that it /will/ 
break in the future, it's simply a matter of time. 

Which makes a big difference when supporting that same specific use-case 
is the primary and arguably only reason the considered alternative exists.

IOW, it's not about not liking upstream.  It's about choosing a default 
that supports our default use-case.

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

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

[Alex McWhirter]

On 02/09/2016 05:39 PM, Duncan wrote:
> I'd agree, except that the way we're running udev is strongly discouraged 
> and generally not supported by upstream, with a statement that it /will/ 
> break in the future, it's simply a matter of time. 
>
> Which makes a big difference when supporting that same specific use-case 
> is the primary and arguably only reason the considered alternative exists.
>
> IOW, it's not about not liking upstream.  It's about choosing a default 
> that supports our default use-case.
>

My point exactly. When this happens we either make something like eudev
default or we have to make systemd default. I don't really care which as
long as i still have the option to change it.

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

[M. J. Everitt]

On 09/02/16 23:38, Alex McWhirter wrote:
> On 02/09/2016 05:39 PM, Duncan wrote:
>> I'd agree, except that the way we're running udev is strongly discouraged 
>> and generally not supported by upstream, with a statement that it /will/ 
>> break in the future, it's simply a matter of time. 
>>
>> Which makes a big difference when supporting that same specific use-case 
>> is the primary and arguably only reason the considered alternative exists.
>>
>> IOW, it's not about not liking upstream.  It's about choosing a default 
>> that supports our default use-case.
>>
> My point exactly. When this happens we either make something like eudev
> default or we have to make systemd default. I don't really care which as
> long as i still have the option to change it.
>
+1

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/09/2016 10:29 AM, Rich Freeman wrote:
> On Tue, Feb 9, 2016 at 12:18 PM, Brian Dolbec <dolsen@gentoo.org>
> wrote:
>> 
>> Why must it become yet another shouting match.  And I'm sorry to
>> have to tell you this, but you have been leading the charge in
>> that direction.
>> 
> 
> Fair enough.  I'll admit that this has been a lot of venting for
> me, and an unnecessary distraction for everybody else.

I don't mind accepting part of the responsibility on that front,
either. I made a few comments that were a bit knee-jerky. Now that
you've clarified your viewpoint I can understand where you come from.
> 
> Ulm's post and discussion with xiaomiao on #gentoo-dev have made
> me reconsider my attitude towards this.
> 
> The reality is that this change really only impacts non-systemd
> users, so the question really should be what provides the best
> experience for these users.  I think there are legitimate arguments
> for either udev or eudev from that standpoint, but I think we need
> to view them through the lens of what is better for those who would
> prefer not to use systemd (and that isn't limited to openrc, though
> I don't know that this distinction matters).  For those who prefer
> to use systemd it is a moot point.
> 
> To ulm's point virtual/dev-manager probably should be a part of 
> @system (even if the provider is only the minimal static device
> nodes) - a posix system really isn't usable without anything in
> /dev. Whichever provider is the default for that virtual might be a
> good topic of discussion, but it is not a true dependency for this 
> decision, and I should not make it into one.
> 
> I still think we'd be well-served to get service managers out of 
> @system as well - another good topic of discussion, but again not
> a true dependency for this decision.
> 
> Gentoo is and has always been about choice.  That is something I
> will always support.
> 
> Personally this has been an area of frustration for me.  I get
> that many have come to Gentoo as a refuge from systemd (as well as
> other things).  I think it is a good thing that we can offer them
> that choice, and I've always supported eudev having a home in
> Gentoo for that reason.
> 
> However, I really do think that systemd largely represents the
> future for linux distros.  It will of course evolve over time, and
> perhaps some day it will be replaced, but I think that what it
> changes into is going to look a lot more like systemd than the
> things that came before.  I don't think we really do ourselves a
> service by clinging to the old ways, and I don't think avoiding
> systemd as either a default or a recommended configuration really
> improves our reputation or the user experience.

I see systemd as the future of user-centric distros, and perhaps
dev-centric ones as well, as a way to get the internals out of the
equation and get people to focus on higher levels of the stack.
However, it being the future doesn't necessarily mean it'll be a
*good* future. I see it leading to less and less control over the
lower parts of the software stack, and that will slow the pace of
innovation and possible steps forward. Inertia will set in, and those
who've put themselves in the comfortable position as the leads of
these projects will have considerable influence over the experience of
GNU/Linux users. Despite our differences in preferences, I don't think
either of us wants a situation where a single project owns so much of
the problem space.

We shouldn't be throwing out old ways just because they're old, just
as we shouldn't be adopting the new shiny just because it's modern. I
may refuse to use systemd, but if someone actually needs to make use
of it, their company needs it to do X or Y, it's a highly multi-seat
environment, or whatever else, then use the right tool for the job.
The main issue I've always had with systemd and its followers is their
insistence that it's THE tool, right for ALL jobs, that anything else
is inferior. Such a statement is completely dependent on one's use
cases and software requirements. I'm not saying you've asserted this;
just clarifying a little bit of my own position.

Regarding our reputation, I'm not really sure where that's relevant.
To some degree it's important to retain and attract users, to make our
work more worthwhile and to help expose more bugs so we can fix them.
But who's actually going to complain that, say, Gentoo ships with
OpenRC and eudev, but can be changed to 'pure' systemd at install
time, complete with a profile that sets all the bells and whistles for
them? If anything, we support OpenRC and systemd and pretty much
ignore everything else. To my knowledge we don't even mention runit,
minit, or other options in the handbook. I think the only people who
can rightfully complain about lack of attention or coverage are those
who are using these lesser-known or lesser-used systems. Maybe we can
get some users to step up to the plate and contribute to the
documentation.
> 
> And that is the frustration that caused me to lash out a bit on
> this topic.  However, this really isn't appropriate.  This isn't
> holding back systemd, and doesn't really have anything to do with
> systemd at all.  This is about making Gentoo better for people who
> have made the choice not to use systemd, and that isn't something
> any of us should be holding back.  If I want to make things better
> for systemd users there are plenty of areas that I could better
> invest this energy.
> 
> So, thanks for bearing with me.
> 
Good points, I agree. Thanks for being willing to see the other side,
and dealing with my offhanded remarks. It seems we've reached a pretty
good understanding.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWunqRAAoJEAEkDpRQOeFwNtoQAMYBLO1l3DiXmemuWvQ6m04S
nHHMYiQNyW3o/Y421ScixKJKLaXrrLcE0OmRqC7jU2iOcm9JC1zcGQNNxdFPGI8o
nRl4be4qMEHxyU78NsQ9JWErf2RI1EezpT5gq5Gi2wA1go1rIa6fiI6UKc3WtYbL
RzwZK9ku9VJesXIPUBo7kTTQaciv8J6VLMMDpvunUORvfnHM2MlwW0/GRkfK9Iyl
nPso1Qj2X8kt3+PiBAoW3wkV9eFtEDlXAht51T18/1jSOuTmRBAGAZ9/XEHM7keY
6vLUSUUSVMrbE189WvSDX5Y1HMHeiYo7t5+ffL+gSDpqLu3eLKm0AUM2yYP3XuCn
EKENCUkzx9sa0lWSPYOi2CXPE79XPTqQguUzt+4Lyx+9Lurmuhvq+QswlRRtA41q
/hf6vZgC8VYas7e3Oky8tP0XWoYRIm3QeIAMsL7F00V/bNONh3rpQt9707FFmqeJ
tAGn4moufWID/SaWSh6w94mAO0wnVCUyB/Spnl1gchrt8kAKzvfISabVf7z8XCHi
az5rVl/JOubYZd1LS9iEjvjQTdwlO9YTkvZ3RfRIIjtNG4WCJ5fYto1v9dMRK1rC
qnGmm+gsuTG8phwmoChA7myMyC2fwYdKc9J293B+YXnDwK4e5FQzTS0uHsb3J9QX
BtUPq58Zw0BjOICrsIs8
=FYyN
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Dale]

Rich Freeman wrote:
> There is already a thread on gentoo-user asking how to safely switch
> from udev->eudev. If that were just a part of the handbook that isn't
> even a migration they'd have to make on a new install. Nor would
> udev->systemd. To summarize my goals in this thread: 1. Suggest that
> rather than picking a winner we instead just let the user pick the
> winner. 2. Demonstrate the futility of actually trying to pick a
> winner, because we all have different values on this subject. 

The reason for that thread was because the user had a entry that enabled
systemd for a package.  Once that was found and removed, the switch was
like it should be.  Unmerge udev and emerge eudev. 

Back to my hole.

Dale

:-)  :-) 

[gentoo-dev] Re: Changing order of default virtual/udev provider

[Duncan]

Daniel Campbell posted on Tue, 09 Feb 2016 06:44:34 -0800 as excerpted:

> If anything, a developer will have more control over how their daemon
> is handled in the rc script. They would have to read systemd's C code
> or its plethora of unit options to set it up 'just right' to achieve
> the same.

FWIW, that's an unfortunately common misconception.

It's just as easy to setup a shell script to do the work in systemd as it 
is in rc-based systems.  After all, at a high level it's simply another 
executable, and at an equally high level, setting up executables to run 
automatically at system start or other major system status change event 
is what init systems, regardless of the specifics, /do/.

And in fact, that's pretty much what I've done here for a variety of 
custom services, using native systemd options and functionality where it 
makes sense, scripting my own where I haven't found shipped functionality 
or services that do exactly what I want.

And I don't claim to be a C coder so I've certainly not had to read that 
to do it.  While I've used systemd unit options where they make sense 
because they're generally well documented and do what it says on the tin, 
if I'd considered rescripting that functionality easier than reading the 
friendly documentation, I certainly could have done so.

Meanwhile, arguably, "more control over how their daemon is handled" is 
incorrect as well, when with systemd it's trivial to setup cgroup control 
over anything cgroups control, and there's tools like nspawn if needed, 
that allow _way_ more control than chroot and the like, with similar 
levels of pre-configuration necessary.


But that's beside the point of the original thread.  I disagree with Rich 
here, because while (like him) I'm a systemd convert myself, I'm strongly 
in support of keeping it optional, and on profiles where systemd isn't 
the default, it simply makes no sense to me to default to a device 
manager that strongly discourages that sort of usage and has said that 
future breakage is a matter of when, not if, when there's a similarly 
functional and currently drop-in-replacement device manager that 
explicitly supports the use-case in question.

If it applied to systemd profiles, the question of an appropriate default 
and its resolution would arguably be far different, but the fact of the 
matter is it doesn't, we're talking about non-systemd profiles 
exclusively, and their default openrc use-case is strongly discouraged by 
udev's systemd upstream, so it simply makes sense to choose defaults 
where the upstreams aren't rabid enemies.

My major remaining concern is, as I've already said, documentation.  If 
that can be resolved, the case is clear enough, and even if not, it's 
simply a judgment call on which negative is less bad, lack of 
documentation, or an upstream that's actively opposing our use-case and 
has clearly stated that breakage is a matter of when, not if.
-- 
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

[gentoo-dev] Re: Changing order of default virtual/udev provider

[Duncan]

Rich Freeman posted on Tue, 09 Feb 2016 13:29:04 -0500 as excerpted:

> This isn't holding back systemd, and doesn't really have anything to do
> with systemd at all.

/Now/ you and I (both systemd users) are on the same page, here. =:^)

The outcome of this debate isn't going to affect systemd users like us, 
anyway.  It's primarily a debate about what's the better choice for users 
who have already chosen, for better or for worse, _not_ to use systemd, 
and only matters to systemd users to the degree that we continue to care 
about the experience of gentooers who have already made the non-systemd 
choice, which both you and I, as gentooers first and systemd users 
second, continue to strongly support _as_ a viable choice, or we'd 
arguably not be very good gentooers after all. =:^)

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

Re: [gentoo-dev] Changing order of default virtual/udev provider

[waltdnes]

On Tue, Feb 09, 2016 at 03:47:34PM -0800, Daniel Campbell wrote

> I think the only people who can rightfully complain about lack of
> attention or coverage are those who are using these lesser-known or
> lesser-used systems. Maybe we can get some users to step up to the
> plate and contribute to the documentation.

  See https://wiki.gentoo.org/wiki/Mdev and
https://wiki.gentoo.org/wiki/Mdev/Automount_USB

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

[Mike Frysinger]

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

On 09 Feb 2016 22:39, Duncan wrote:
> Mike Frysinger posted on Tue, 09 Feb 2016 14:26:52 -0500 as excerpted:
> > On 08 Feb 2016 13:46, Michał Górny wrote:
> >> I'm strongly against this, because:
> > 
> > agreed.  i also don't see any reasons in Patrick's e-mail to suggest the
> > current default is inadequate.  "i don't like upstream" isn't relevant.
> 
> I'd agree, except that the way we're running udev is strongly discouraged 
> and generally not supported by upstream, with a statement that it /will/ 
> break in the future, it's simply a matter of time. 

start a thread then when that actually happens
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

[waltdnes]

On Wed, Feb 10, 2016 at 12:09:58AM -0500, Mike Frysinger wrote
> On 09 Feb 2016 22:39, Duncan wrote:
> > Mike Frysinger posted on Tue, 09 Feb 2016 14:26:52 -0500 as excerpted:
> > > On 08 Feb 2016 13:46, Micha?? Górny wrote:
> > >> I'm strongly against this, because:
> > > 
> > > agreed.  i also don't see any reasons in Patrick's e-mail to suggest the
> > > current default is inadequate.  "i don't like upstream" isn't relevant.
> > 
> > I'd agree, except that the way we're running udev is strongly discouraged 
> > and generally not supported by upstream, with a statement that it /will/ 
> > break in the future, it's simply a matter of time. 
> 
> start a thread then when that actually happens

  The problem with that approach is that all at once the Gentoo forum
will be hit with questions by a whole bunch of people who will have to
migrate to either eudev or systemd on a short deadline.  As the old
saying goes, an ounce of prevention is worth a pound of cure.  I believe
that the best way to handle a crisis is to prevent it in the first
place.  That means getting into a lifeboat before standalone udev sinks.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

[Rich Freeman]

On Wed, Feb 10, 2016 at 9:27 AM,  <waltdnes@waltdnes.org> wrote:
> On Wed, Feb 10, 2016 at 12:09:58AM -0500, Mike Frysinger wrote
>> On 09 Feb 2016 22:39, Duncan wrote:
>> > Mike Frysinger posted on Tue, 09 Feb 2016 14:26:52 -0500 as excerpted:
>> > > On 08 Feb 2016 13:46, Micha?? Górny wrote:
>> > >> I'm strongly against this, because:
>> > >
>> > > agreed.  i also don't see any reasons in Patrick's e-mail to suggest the
>> > > current default is inadequate.  "i don't like upstream" isn't relevant.
>> >
>> > I'd agree, except that the way we're running udev is strongly discouraged
>> > and generally not supported by upstream, with a statement that it /will/
>> > break in the future, it's simply a matter of time.
>>
>> start a thread then when that actually happens
>
>   The problem with that approach is that all at once the Gentoo forum
> will be hit with questions by a whole bunch of people who will have to
> migrate to either eudev or systemd on a short deadline.  As the old
> saying goes, an ounce of prevention is worth a pound of cure.  I believe
> that the best way to handle a crisis is to prevent it in the first
> place.  That means getting into a lifeboat before standalone udev sinks.
>

What would force them to migrate all at once?  Even if udev-229
doesn't work standalone, udev-228 will work standalone forever, and
patches could always be backported if there were some security crisis.

By all means change the virtual if it is the right thing to do, but I
don't think that we should treat this as some kind of risk that could
cause problems for us without warning.  Most likely if a need to
abandon it comes up we'll have months of warning, with still-working
versions of udev not even marked stable yet in the pipeline.

As I said earlier, the advantage of procrastination is that you can
make a choice later when you have better information or perhaps even
more choices available.  Maybe by the time udev stops working
standalone everybody has seen the light and is now using libredev
anyway.

Often the decision to procrastinate is a decision that is rewarded.
That should be considered carefully.

-- 
Rich

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

[Michał Górny]

Dnia 10 lutego 2016 15:27:50 CET, waltdnes@waltdnes.org napisał(a):
>On Wed, Feb 10, 2016 at 12:09:58AM -0500, Mike Frysinger wrote
>> On 09 Feb 2016 22:39, Duncan wrote:
>> > Mike Frysinger posted on Tue, 09 Feb 2016 14:26:52 -0500 as
>excerpted:
>> > > On 08 Feb 2016 13:46, Micha?? Górny wrote:
>> > >> I'm strongly against this, because:
>> > > 
>> > > agreed.  i also don't see any reasons in Patrick's e-mail to
>suggest the
>> > > current default is inadequate.  "i don't like upstream" isn't
>relevant.
>> > 
>> > I'd agree, except that the way we're running udev is strongly
>discouraged 
>> > and generally not supported by upstream, with a statement that it
>/will/ 
>> > break in the future, it's simply a matter of time. 
>> 
>> start a thread then when that actually happens
>
>  The problem with that approach is that all at once the Gentoo forum
>will be hit with questions by a whole bunch of people who will have to
>migrate to either eudev or systemd on a short deadline.  As the old
>saying goes, an ounce of prevention is worth a pound of cure.  I
>believe
>that the best way to handle a crisis is to prevent it in the first
>place.  That means getting into a lifeboat before standalone udev
>sinks.

Wasn't the switch supported to be painless?


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

[William Hubbs]

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

On Wed, Feb 10, 2016 at 09:52:29AM -0500, Rich Freeman wrote:
> On Wed, Feb 10, 2016 at 9:27 AM,  <waltdnes@waltdnes.org> wrote:
> > On Wed, Feb 10, 2016 at 12:09:58AM -0500, Mike Frysinger wrote
> >> On 09 Feb 2016 22:39, Duncan wrote:
> >> > Mike Frysinger posted on Tue, 09 Feb 2016 14:26:52 -0500 as excerpted:
> >> > > On 08 Feb 2016 13:46, Micha?? Górny wrote:
> >> > >> I'm strongly against this, because:
> >> > >
> >> > > agreed.  i also don't see any reasons in Patrick's e-mail to suggest the
> >> > > current default is inadequate.  "i don't like upstream" isn't relevant.
> >> >
> >> > I'd agree, except that the way we're running udev is strongly discouraged
> >> > and generally not supported by upstream, with a statement that it /will/
> >> > break in the future, it's simply a matter of time.
> >>
> >> start a thread then when that actually happens
> >
> >   The problem with that approach is that all at once the Gentoo forum
> > will be hit with questions by a whole bunch of people who will have to
> > migrate to either eudev or systemd on a short deadline.  As the old
> > saying goes, an ounce of prevention is worth a pound of cure.  I believe
> > that the best way to handle a crisis is to prevent it in the first
> > place.  That means getting into a lifeboat before standalone udev sinks.
> >
> 
> What would force them to migrate all at once?  Even if udev-229
> doesn't work standalone, udev-228 will work standalone forever, and
> patches could always be backported if there were some security crisis.
> 
> By all means change the virtual if it is the right thing to do, but I
> don't think that we should treat this as some kind of risk that could
> cause problems for us without warning.  Most likely if a need to
> abandon it comes up we'll have months of warning, with still-working
> versions of udev not even marked stable yet in the pipeline.
> 
> As I said earlier, the advantage of procrastination is that you can
> make a choice later when you have better information or perhaps even
> more choices available.  Maybe by the time udev stops working
> standalone everybody has seen the light and is now using libredev
> anyway.
> 
> Often the decision to procrastinate is a decision that is rewarded.
> That should be considered carefully.

+ 10000.

I also saw another issue that made me shudder. If we change the default
to eudev, people who are running separate /usr are going to think they
can kill their initramfs's, because people in gentoo conflated the
separate /usr and initramfs issue with udev [1].

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=573760#C4

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

[Brian Dolbec]

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

On Wed, 10 Feb 2016 10:26:12 -0600
William Hubbs <williamh@gentoo.org> wrote:


> > Often the decision to procrastinate is a decision that is rewarded.
> > That should be considered carefully.  
> 
> + 10000.
> 
> I also saw another issue that made me shudder. If we change the
> default to eudev, people who are running separate /usr are going to
> think they can kill their initramfs's, because people in gentoo
> conflated the separate /usr and initramfs issue with udev [1].
> 
> William
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=573760#C4

That isn't a worthwhile reason to procrastinate.
IMO we're going to get those _ANYWAY_  no matter how long we
wait, within reason of course.

There will always be users that can't read/type/whatever and fail and
file bugs.

So if we have to wait for one (or more) users to forget about the
initramfs crud & confusion, we'll be waiting 20 years.  By then even
systemd will have been replaced by something else...
-- 
Brian Dolbec <dolsen>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

[gentoo-dev] The Beauty of Unix

[Paul Varner]

On 2/9/16 7:44 AM, Rich Freeman wrote:
> I thought the whole beauty of unix was the everything-is-a-file design?
No, the beauty of Unix has always been the architectural philosophy of 
loose-coupling of the components of the system.
The "everything is a file" is a result of that philosophy.  The end 
result of this is that you can switch out components of the system 
without redesigning other aspects of the system.  That is the philosophy 
that allows Gentoo to exist as meta-distribution and to provide choice 
for what you want.

On the other side you have Windows which tightly-couples everything in 
the system.  This does have the advantage of making everything have the 
same look and feel and "just work".  And I fully understand why 
Microsoft went that route, it made things easy for people who don't care 
and is what made them the huge company that they are today.

Sidebar, the reason you have to reboot a Windows box so much during 
updates is because of the tight-coupling.  With Unix, you typically only 
need to reboot if you update the kernel.

However, tight-coupling has big issues for people who do care or don't 
like the design that is being given to them.  I switched from Windows to 
Linux and OS X solely because I got very tired of fighting the design 
forced on to me and the fact that a bug in one piece of software would 
often kill the entire system.

And that is the reason that I don't care for systemd.  They are 
tightly-coupling everything together under their design approach. It is 
intended to be a one size fits all. While it will have the benefit of 
"just working", and does fit in with where Red Hat, etc, want to go with 
Linux. It will have the same disadvantages that Windows has.

Regards,
Paul

Re: [gentoo-dev] The Beauty of Unix

[Rich Freeman]

On Wed, Feb 10, 2016 at 12:36 PM, Paul Varner <fuzzyray@gentoo.org> wrote:
> On 2/9/16 7:44 AM, Rich Freeman wrote:
>>
>> I thought the whole beauty of unix was the everything-is-a-file design?
>
> No, the beauty of Unix has always been the architectural philosophy of
> loose-coupling of the components of the system.
> The "everything is a file" is a result of that philosophy.  The end result
> of this is that you can switch out components of the system without
> redesigning other aspects of the system.  That is the philosophy that allows
> Gentoo to exist as meta-distribution and to provide choice for what you
> want.

While I agree with much of that, keep in mind that strictly avoiding
loose coupling is a decision that actually denies some choices.

Strong coupling between my service manager and cron implementation
means that I can set one configuration option and have it apply to
everything, or have a common syntax across them.  Having it all tie
into kdbus means a simpler interface design for all of it.

I think this can be carried too far, and I don't use the full systemd
family for everything I do.  However, when I find that it makes sense
to use various systemd components together there are a lot of benefits
from the tight coupling.

And we already accept this in other parts of the system, the kernel
being the most obvious.  You can't use one implementation of /proc and
a different implementation of /sys, and use zfs from FreeBSD
seamlessly on the same system (I'm not saying you can't port all of
those into the same codebase - just as you could probably port eudev
into systemd if you wanted to fork them both).

My point was that providing common interfaces to system services was
actually a big part of the unix appeal.  It hasn't fully kept up, and
I think somebody already mentioned Plan 9 in the thread.  I'm not
really sure I want my window manager to be part of the kernel, even if
it is a microkernel, and there will always be another layer of
abstraction.  But, the goal is still a good one, and of course with
Gentoo you have the choice not to use it (though it may become a
harder one to sustain if some of the various upstreams wither away)

-- 
Rich

Re: [gentoo-dev] The Beauty of Unix

[Gregory Woodbury]

I agree with Paul Varner's comment.

There are places where a tight-coupling makes sense (the kernel) and places
where it doesn't (system admin and userspace development.)

My objections to the systemd plans is philosophical. There are some
folks who want to make Linux
into a Desktop System environment that works out of the box in the
manner of Windows. There are reasons to do this,
and there are reasons not to do this.  On the one hand, to compete
with MS Windows one must become MS Windows;
on the other hand. doing that cuts deeply into the things that make
Linux (and all the *NIX's) powerful and adaptable.

When SysVInit was developed (circa 1981) there were serious
limitations on the hardware it ran on in terms of speed
and memory. Additionally, there were missing software algorithms and
methods to solve some of the problems it
had to deal with.  A decision was made to punt some of the problems to
a capable human mind rather than to spend
precious time and resources trying to solve them computationally. This
is, of course, the need for the admins to look at
the services dependency graph and let them adjust the startup
sequencing by hand.

Hardware capabilities and software methods advanced quite fast and Sys
V Init (being standardized) did not keep
up with the times.  Various extensions and replacements for the
Init/startup methods were developed, and most
added dependency descriptions and automatic solving to the mix, while
trying to preserve the ease of using shell scripts
for getting things done.  OpenRC is one of the contenders and it is
highly adaptable as new technologies are
introduced (such as automatic device configuration a la eudev.)

Systemd's method, though, rips out huge chunks of many different
system components and replaced them with a
monolithic structure that takes control of everything between the
kernel's construction of the first process and the
startup of the selected desktop environment. It also imposes strict
interface requirements on the API of service
daemon startup and which desktop environments it wants to support.

The monolithic structure and resource requirements severely limit the
hardware that can be used (to fairly recent
amounts of memory and processor speed.)  This, like Microsoft's
methods, leaves a lot of not-so-old hardware
out in the cold in a forced obsolescence.

Additioinally, the development methods used, and the future plans for
systemd, make it clear that its objective
is to make a tighly integrated system that can compete with Microsoft
in its own arena. [And don't get me started
on the personalities involved!]

I use systemd when required, and I can even tweak the internals when
necessary. But for my own use, I much
prefer the freedom to customize and construct things on my own.
Perhaps I am and "old fogey" living in the past,
but I think some other folks would object to that characterization. I
have been involved in computing since 1958,
and have made (and continue to make) some significant contributions to
the field (even if my name is not publicly
associated with them.) I have been in the trenches of (F)OSS for a
long time and would love to see Linux+GNU
in a significant number of non-technical users' hand and homes.
However, I do not think that the only way to
accomplish that is by becoming another Microsoft.

This discussion should not be about which system is better or worse.
There should be room in the concept space
that preserves to ability to choose what a person wants on their
machine, rather than having the environment
dictated by some corporate entity looking to achieve market dominance.
The "average users" these days have
no concept of the magic behind the buttons on the screen and the
keyboard, and most are just willing to consider
the devices unrepairable when they fail and just go get another one.
The advertising driven consumer culture
really doesn't want the consumers' to know what is going on behind the
scenes. but it still requires that some
do know and can keep the infrastructure running and advancing.

That is enough ranting for now. Carry on.

-- 
G.Wolfe Woodbury
redwolfe@gmail.com

Re: [gentoo-dev] The Beauty of Unix

[brettrsears]

Pp
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Gregory Woodbury <redwolfe@gmail.com>
Date: Wed, 10 Feb 2016 14:30:56 
To: <gentoo-dev@lists.gentoo.org>
Reply-to: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] The Beauty of Unix

I agree with Paul Varner's comment.

There are places where a tight-coupling makes sense (the kernel) and places
where it doesn't (system admin and userspace development.)

My objections to the systemd plans is philosophical. There are some
folks who want to make Linux
into a Desktop System environment that works out of the box in the
manner of Windows. There are reasons to do this,
and there are reasons not to do this.  On the one hand, to compete
with MS Windows one must become MS Windows;
on the other hand. doing that cuts deeply into the things that make
Linux (and all the *NIX's) powerful and adaptable.

When SysVInit was developed (circa 1981) there were serious
limitations on the hardware it ran on in terms of speed
and memory. Additionally, there were missing software algorithms and
methods to solve some of the problems it
had to deal with.  A decision was made to punt some of the problems to
a capable human mind rather than to spend
precious time and resources trying to solve them computationally. This
is, of course, the need for the admins to look at
the services dependency graph and let them adjust the startup
sequencing by hand.

Hardware capabilities and software methods advanced quite fast and Sys
V Init (being standardized) did not keep
up with the times.  Various extensions and replacements for the
Init/startup methods were developed, and most
added dependency descriptions and automatic solving to the mix, while
trying to preserve the ease of using shell scripts
for getting things done.  OpenRC is one of the contenders and it is
highly adaptable as new technologies are
introduced (such as automatic device configuration a la eudev.)

Systemd's method, though, rips out huge chunks of many different
system components and replaced them with a
monolithic structure that takes control of everything between the
kernel's construction of the first process and the
startup of the selected desktop environment. It also imposes strict
interface requirements on the API of service
daemon startup and which desktop environments it wants to support.

The monolithic structure and resource requirements severely limit the
hardware that can be used (to fairly recent
amounts of memory and processor speed.)  This, like Microsoft's
methods, leaves a lot of not-so-old hardware
out in the cold in a forced obsolescence.

Additioinally, the development methods used, and the future plans for
systemd, make it clear that its objective
is to make a tighly integrated system that can compete with Microsoft
in its own arena. [And don't get me started
on the personalities involved!]

I use systemd when required, and I can even tweak the internals when
necessary. But for my own use, I much
prefer the freedom to customize and construct things on my own.
Perhaps I am and "old fogey" living in the past,
but I think some other folks would object to that characterization. I
have been involved in computing since 1958,
and have made (and continue to make) some significant contributions to
the field (even if my name is not publicly
associated with them.) I have been in the trenches of (F)OSS for a
long time and would love to see Linux+GNU
in a significant number of non-technical users' hand and homes.
However, I do not think that the only way to
accomplish that is by becoming another Microsoft.

This discussion should not be about which system is better or worse.
There should be room in the concept space
that preserves to ability to choose what a person wants on their
machine, rather than having the environment
dictated by some corporate entity looking to achieve market dominance.
The "average users" these days have
no concept of the magic behind the buttons on the screen and the
keyboard, and most are just willing to consider
the devices unrepairable when they fail and just go get another one.
The advertising driven consumer culture
really doesn't want the consumers' to know what is going on behind the
scenes. but it still requires that some
do know and can keep the infrastructure running and advancing.

That is enough ranting for now. Carry on.

-- 
G.Wolfe Woodbury
redwolfe@gmail.com

[gentoo-dev] Re: Changing order of default virtual/udev provider

[»Q«]

On Wed, 10 Feb 2016 09:27:50 -0500
waltdnes@waltdnes.org wrote:

> On Wed, Feb 10, 2016 at 12:09:58AM -0500, Mike Frysinger wrote
> > On 09 Feb 2016 22:39, Duncan wrote:  

> > > the way we're running udev is strongly
> > > discouraged and generally not supported by upstream, with a
> > > statement that it /will/ break in the future, it's simply a
> > > matter of time.   
> > 
> > start a thread then when that actually happens  
> 
>   The problem with that approach is that all at once the Gentoo forum
> will be hit with questions by a whole bunch of people who will have to
> migrate to either eudev or systemd on a short deadline.

That will happen anyway, assuming upstream is right that standalone
udev will break someday;  changing the default to openrc/eudev or to
systemd would prompt a few people to look at change their existing
systems, but most would just leave things alone and carry on.  

> As the old saying goes, an ounce of prevention is worth a pound of
> cure.  I believe that the best way to handle a crisis is to prevent
> it in the first place.  That means getting into a lifeboat before
> standalone udev sinks.

IMO, the lifeboats are already in place.  Never having looked into it
before yesterday, I went to <https://wiki.gentoo.org/wiki/Eudev> and
within a couple of minutes I had switched from udev to eudev, including
rebooting.  (I was lucky enough -- eudev was just a drop-in replacement
for me.)

All that said, ISTM sticking with standalone udev as default when
upstream does not support that seems strange, not that strangeness ever
ruled anything out in Gentoo. ;)

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/02/16 12:09 PM, Brian Dolbec wrote:
> On Wed, 10 Feb 2016 10:26:12 -0600 William Hubbs
> <williamh@gentoo.org> wrote:
> 
> 
>>> Often the decision to procrastinate is a decision that is
>>> rewarded. That should be considered carefully.
>> 
>> + 10000.
>> 
>> I also saw another issue that made me shudder. If we change
>> the default to eudev, people who are running separate /usr are
>> going to think they can kill their initramfs's, because people
>> in gentoo conflated the separate /usr and initramfs issue with
>> udev [1].
>> 
>> William
>> 
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=573760#C4
> 
> That isn't a worthwhile reason to procrastinate. IMO we're going
> to get those _ANYWAY_  no matter how long we wait, within reason
> of course.
> 
> There will always be users that can't read/type/whatever and fail
> and file bugs.
> 
> So if we have to wait for one (or more) users to forget about
> the initramfs crud & confusion, we'll be waiting 20 years.  By
> then even systemd will have been replaced by something else...
> 


Yeah I second this -- it was decided officially by council (what, 2
years ago now?) that separate-/usr-without-initramfs doesn't need to
be officially supported anymore, and so if things break that it is
up to end-users to ensure they pick up the pieces.

Although it is likely that eudev *will* keep installation onto / and
out of /usr to help with this not-officially-supported situation in
Gentoo, that doesn't mean the other projects have to stay out of
/usr, and "it worked before the upgrade but doesn't now" certainly
doesn't mean it's a valid bug.  If a user or sysadmin drops their
initramfs when they have a separate-/usr system, any resulting
breakage is on them.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAla74KkACgkQAJxUfCtlWe1cVgD/YCgpgZ9QwN1KXl8G9gPjF3my
dW6YnrV9xzISSYpHQkMA/jDNV5epu4bzWDEmIs0g2hx8qNI3lRHMNvcORRD0lNMi
=nADF
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/10/2016 05:15 PM, Ian Stakenvicius wrote:
> On 10/02/16 12:09 PM, Brian Dolbec wrote:
>> On Wed, 10 Feb 2016 10:26:12 -0600 William Hubbs 
>> <williamh@gentoo.org> wrote:
> 
> 
>>>> Often the decision to procrastinate is a decision that is 
>>>> rewarded. That should be considered carefully.
>>> 
>>> + 10000.
>>> 
>>> I also saw another issue that made me shudder. If we change the
>>> default to eudev, people who are running separate /usr are 
>>> going to think they can kill their initramfs's, because people 
>>> in gentoo conflated the separate /usr and initramfs issue with 
>>> udev [1].
>>> 
>>> William
>>> 
>>> [1] https://bugs.gentoo.org/show_bug.cgi?id=573760#C4
> 
>> That isn't a worthwhile reason to procrastinate. IMO we're going 
>> to get those _ANYWAY_  no matter how long we wait, within reason 
>> of course.
> 
>> There will always be users that can't read/type/whatever and
>> fail and file bugs.
> 
>> So if we have to wait for one (or more) users to forget about the
>> initramfs crud & confusion, we'll be waiting 20 years.  By then
>> even systemd will have been replaced by something else...
> 
> 
> 
> Yeah I second this -- it was decided officially by council (what,
> 2 years ago now?) that separate-/usr-without-initramfs doesn't need
> to be officially supported anymore, and so if things break that it
> is up to end-users to ensure they pick up the pieces.
> 
> Although it is likely that eudev *will* keep installation onto /
> and out of /usr to help with this not-officially-supported
> situation in Gentoo, that doesn't mean the other projects have to
> stay out of /usr, and "it worked before the upgrade but doesn't
> now" certainly doesn't mean it's a valid bug.  If a user or
> sysadmin drops their initramfs when they have a separate-/usr
> system, any resulting breakage is on them.
> 

+1

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWu+NnAAoJEAEkDpRQOeFw/YsQAMFID91JxR9xNYhZ3o6yDb3B
nha3mIgYbkFuQ4LtBQGFZo5r4NzW7tlre6Jc+Rw3nErej59HmasuQQrpZI0alBYA
SMhtlTlfz5B3fWZ2lWTBAQZcPp3mBUVHRFGOAqWNxYIHbRkqiBjLhR98xzrsJLOb
JOfDuHRWaXi8XELebEVhH99UgAezQOtwMQyKi79jkTSkVlSdw+rLfJn4e56QzVdU
UTRgbVmxTgVlHw2y0GLgSCWGS7UxXaXGp5Bds8sM1nDq/YtEZBnd5M8ApMRPneLo
CjIdtwueTgDkZsVH/KBNJMXz0u6383nN7I96Hsp19046M9AEHpvvitQH7Sxv7Dye
agr1YMqSar/uYQltW94qjKG9bR6HzN9YEBtwUxpbUM4FcibcgXlfdW8eBAhwAXaX
xVC3KD4XJzZbRa65kouiYLBNDm6uY7af8ehF7r0ZEn2iZTzDi2UH4GAbczM+y1om
jDWq7q5H4Mfiq17bz/n8f3Q7qW+SBY4WY1fTQefYYTLNoK2OPTABNYxg6Oko+M8/
dUJNWSV3+henEsaeRUo/sM6G+zw6pQSJubbwPc65756U6r2nYtDjEO6ebPknD504
qhywzdVLMNZh6C14gxQjgI8SkDY5Rl5eexbUDDzOjZI5eM1CxNO3gSTic6+LjiOi
SmUwjZD6f618Xg2MQjPR
=d5dN
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Nicolas Sebrecht]

On Mon, Feb 08, 2016 at 11:00:15AM -0500, Ian Stakenvicius wrote:

> Oh, eudev also doesn't handle network link setup given that external
> tools already do this just fine.  That's another difference, though
> not one that matters programmatically.  That said, the network-link
> setup was added primarily to support systemd's use-case, and there's
> very little need or point in having it done by udevd on an rc-based
> system.

Unless I'm mistaken, you're saying that eudev doesn't handle network
link but it doesn't matter because rc-based systems don't requires it.

And at the same time, I read in this thread that eudev is in-place
replacement for udev without any harm. What will happen to the users
wanting systemd AND expect the network link setup?

-- 
Nicolas Sebrecht

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Nicolas Sebrecht]

On Mon, Feb 08, 2016 at 04:37:28AM -0800, Daniel Campbell wrote:

> Wow, that's actually pretty great news. That's enough 'momentum' to
> maybe maintain a smaller ecosystem free of any particular init-system
> preference! Thanks for sharing!

I wouldn't call that much "momentum" since it's about adoption, not
contributions.

Also, to get things right for this thread, I think it would be best to
compare contributions like bug reports and pull requests between udev
and evdev.

Since most major distributions are running udev at that time, I tend to
think that udev is still more viable and stable for the long term. So
goes as the default. I expect udev to have much more momentum than
eudev, for now at least.

-- 
Nicolas Sebrecht

[gentoo-dev] Re: Changing order of default virtual/udev provider

[Duncan]

Nicolas Sebrecht posted on Thu, 11 Feb 2016 02:46:33 +0100 as excerpted:

> On Mon, Feb 08, 2016 at 11:00:15AM -0500, Ian Stakenvicius wrote:
> 
>> Oh, eudev also doesn't handle network link setup given that external
>> tools already do this just fine.  That's another difference, though not
>> one that matters programmatically.  That said, the network-link setup
>> was added primarily to support systemd's use-case, and there's very
>> little need or point in having it done by udevd on an rc-based system.
> 
> Unless I'm mistaken, you're saying that eudev doesn't handle network
> link but it doesn't matter because rc-based systems don't requires it.
> 
> And at the same time, I read in this thread that eudev is in-place
> replacement for udev without any harm. What will happen to the users
> wanting systemd AND expect the network link setup?

This whole debate doesn't apply to systemd users at all, only those not 
using systemd, because...

Systemd users get the systemd-integrated udev, with systemd blocking
(effectively, I've not looked at where the specific blocks are) both the 
stand-alone udev and eudev, as systemd is its own device-manager 
provider.  Thus, systemd users have the systemd-based network link 
solution if they want it, via the systemd-integrated udev.

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

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/02/16 08:46 PM, Nicolas Sebrecht wrote:
> On Mon, Feb 08, 2016 at 11:00:15AM -0500, Ian Stakenvicius
> wrote:
> 
>> Oh, eudev also doesn't handle network link setup given that
>> external tools already do this just fine.  That's another
>> difference, though not one that matters programmatically.  That
>> said, the network-link setup was added primarily to support
>> systemd's use-case, and there's very little need or point in
>> having it done by udevd on an rc-based system.
> 
> Unless I'm mistaken, you're saying that eudev doesn't handle
> network link but it doesn't matter because rc-based systems don't
> requires it.
> 
> And at the same time, I read in this thread that eudev is
> in-place replacement for udev without any harm. What will happen
> to the users wanting systemd AND expect the network link setup?
> 

Systemd requires system configuration differently compared to
openrc and other rc systems.  One cannot expect eudev (or sys-fs/udev)
to be drop-in replacements for systemd and for them to read systemd
configuration.  See
https://www.freedesktop.org/software/systemd/man/systemd.link.html
for more information on network linking, especially the very
systemd-specific config locations.

If someone whats to use both openrc and systemd on the same system,
then they can't have EITHER sys-fs/udev OR sys-fs/eudev installed,
so the point to this particular discussion is rather moot.
Systemd-udev from the systemd package could theoretically read the
network-link config files, assuming that systemd doesn't need to be
PID1 for this to occur; it could very well be, however, that even
when systemd is installed, booting openrc the network link setup
will still need to be configured appropriately outside of these
systemd configs.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAla8uewACgkQAJxUfCtlWe2nBgEAoelTVLQLwhqrrqNFGUncmW3M
iSrWyWSMlKTgeltsNQIBAOjewM3i0enEzhYacRijzmdNkrJdzs5KrYca3Ze1dftw
=1nVy
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

[Joshua Kinard]

On 02/10/2016 20:15, Ian Stakenvicius wrote:
> On 10/02/16 12:09 PM, Brian Dolbec wrote:
>> On Wed, 10 Feb 2016 10:26:12 -0600 William Hubbs
>> <williamh@gentoo.org> wrote:
> 
> 
>>>> Often the decision to procrastinate is a decision that is
>>>> rewarded. That should be considered carefully.
>>>
>>> + 10000.
>>>
>>> I also saw another issue that made me shudder. If we change
>>> the default to eudev, people who are running separate /usr are
>>> going to think they can kill their initramfs's, because people
>>> in gentoo conflated the separate /usr and initramfs issue with
>>> udev [1].
>>>
>>> William
>>>
>>> [1] https://bugs.gentoo.org/show_bug.cgi?id=573760#C4
> 

[snip]

> 
> Yeah I second this -- it was decided officially by council (what, 2
> years ago now?) that separate-/usr-without-initramfs doesn't need to
> be officially supported anymore, and so if things break that it is
> up to end-users to ensure they pick up the pieces.
> 
> Although it is likely that eudev *will* keep installation onto / and
> out of /usr to help with this not-officially-supported situation in
> Gentoo, that doesn't mean the other projects have to stay out of
> /usr, and "it worked before the upgrade but doesn't now" certainly
> doesn't mean it's a valid bug.  If a user or sysadmin drops their
> initramfs when they have a separate-/usr system, any resulting
> breakage is on them.
> 

FWIW, I have separate /usr on several systems, and haven't needed an initramfs
thus far.  I thought we had some trick active in busybox or even eudev that
handles separate /usr for *simple* filesystem configurations (i.e., just basic
partitions, no LVM, evms, encryption, etc).

So I don't there would be immediate breakage in this scenario.  It's going to
depend on how a given system was configured.  Simple setups appear to
JustWork(), AFAICT.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Patrick Lauer]

On 02/09/2016 01:17 PM, Rich Freeman wrote:
> On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric <kentfredric@gmail.com> wrote:
>
>> And a lot of Gentoo is surprisingly simple: Like our use of bash
>> scripts for recipies to build things, like using rsync to deploy/relay
>> not just those recipies, but security notices and  news items, which
>> are themselves reasonably simple formats.
> Well, one thing about Gentoo that certainly isn't simple is our init.d scripts.
>
> Compare this:
> http://pastebin.com/sSDtpF4t
More stable link:
https://gitweb.gentoo.org/proj/apache.git/tree/2.4/init/apache2.initd
>
> With this:
> http://pastebin.com/Lfn8r7qP
More stable link:
https://gitweb.gentoo.org/repo/gentoo.git/tree/www-servers/apache/files/apache2.2.service
> Systemd does the job in 10% of the code (and half of it is a comment),
> and doesn't implement its own service polling and killer script during
> shutdown independently for every service (not that every init.d script
> even does this - most of them will just leave orphans behind, and
> systemd will catch orphans that even the lengthy init.d script for
> apache misses).
>
Right, that's a bad comparison.

The equivalent OpenRC init script is:

```
#!/sbin/runscript
command="/usr/sbin/apache2"
command_args="${APACHE2_OPTS}"
description_reload="A graceful restart advises the children to exit
after the current request and reloads the configuration."

stop() {
    $command $APACHE2_OPTS -k graceful-stop
}
reload() {
    $command $APACHE2_OPTS -k graceful
}
```
So that's almost exactly the same (modulo braces and newlines). There's
no equivalent for PrivateTmp, and we ignore the extra data in
/etc/tmpfiles.d (for creating runtime dirs). Which is bad, but that's
another rant ;)

Just that the current initscript does a lot more, and ... uhm ... why is
the systemd unit sourcing /etc/conf.d/apache2 ?
(Oh, and dependencies, but those just slow down startup <trollface/>)

So if you compile the equivalent naive init script there's not much
difference, and the initial argument falls on its face and disappears.

I'm getting tired of having this argument :)

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Patrick Lauer]

On 02/09/2016 10:03 AM, Kent Fredric wrote:
> On 9 February 2016 at 18:27, Anthony G. Basile <blueness@gentoo.org> wrote:
>> all the vitriolic attacks i get about eudev come from the gentoo
>> community.  outside of this community i get praise.
>
> In case my  earlier messages stating a desire to exercise much caution
> gave the wrong impression, I just want to state for the record I think
> its awesome eudev exists, and I think its awesome other distro's are
> using it.
>
> Just when it comes to "Change the defaults", I want to be certain
> about the path we're setting ourselves up for on this very important
> component, because here, a change of defaults paves a broader path for
> eudev to be a potential leading competition to systemd.
If, for any reason, eudev should be abandoned - we can just change the
virtual back. One-line change.
>
> Because if we do that, I feel we must be so sure of ourselves that
> eudev can be a profitable choice for at least a moderately long term,
> even in the event we get no more support from the systemd codebase.
>
> Having it in tree and having users who know what they're doing being
> able to choose their own risk factors and say "yeah, eudev is the
> right choice for what I'm doing" is one thing.
>
> But stating implicitly that "Hey, this is the default", this needs to
> be the *best* recommendation we can make based on all the other
> factors and other defaults Gentoo uses.
Given the options of {systemd, systemd-udevd standalone, eudev} -
Those that choose systemd are not in this discussion.
Systemd-udevd standalone is unsupported, with upstream suggesting that
they want to remove support for it.
Leaves eudev as the only 'sane' option, since we even have an upstream.

And it's the 'mainstream' choice.

And it wins the popular vote:
https://forums.gentoo.org/viewtopic-t-1038696-postdays-0-postorder-asc-highlight-eudev-start-0.html

>
> Because new users *will* be inclined to pick the default, and
> *existing* users of the *current* default are likely to see the
> default change, and reason "well, the default has changed, so the new
> default is the new best thing", and will be inclined to switch.
Existing installs won't have a visible change. Since a provider of
virtual/udev is installed nothing changes, even if we shuffle the
virtual providers around.
>
> And the worst thing we could have is a combination of bad defaults
> that leads new users to have a poor first experience because they used
> all the default recommendations, and their system made magic smoke
> instead of booting.
>
> In short, to change *this* default, it seems pertinent that we *know*
> that the change we're making *is* better and a more reliable long-term
> choice than the *current* default, and if there is *any reasonable
> doubt*, we should delay changing until that reasonable doubt is
> expunged.
>
Since eudev is a drop-in replacement that uses a good part of the
original udev codebase - if you notice any deviation it's either a bug
(which we should fix) or udev misbehaves (e.g. persistent network
naming, which is a wonderful way to make people with more than zero
network cards angry)

And again: It would only affect what gets installed if you do "emerge -C
udev eudev; emerge virtual/udev"
(and, as a positive side-effect, changes the udev implementation of
stage3, which again only affects the default on *new* installs)

I don't see any serious doubts, apart from "we're deviating from
upstream" - but that's exactly what I want to fix! Yes, we deviate
*now*, we should not do that. And there's reasonable doubt that we can
keep sys-fs/udev going.


I like it when people violently agree with me :)

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> If, for any reason, eudev should be abandoned - we can just change the
> virtual back. One-line change.

Which is precisely the corresponding argument for not switching the
default to eudev in the first place.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Patrick Lauer]

On 02/14/2016 05:00 PM, Rich Freeman wrote:
> On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>> If, for any reason, eudev should be abandoned - we can just change the
>> virtual back. One-line change.
> Which is precisely the corresponding argument for not switching the
> default to eudev in the first place.
>
That no sense :)

Since we're, right now, already using an unsupported version ...
Can't get worse.

And since you argued for mainstream earlier you'd have to agree that
eudev is the mainstream solution and Gentoo is lagging behind the others ...

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Brian Dolbec]

On Sun, 14 Feb 2016 11:00:30 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer <patrick@gentoo.org>
> wrote:
> > If, for any reason, eudev should be abandoned - we can just change
> > the virtual back. One-line change.  
> 
> Which is precisely the corresponding argument for not switching the
> default to eudev in the first place.
> 

OH, my, this is looking more like you are being paid by systemd peeps...

THIS IS OPEN SOURCE, there is not a single project out there that might
not become abandoned at some point in the future.

Even Microsoft may eventually abandon their crappy windows, Apple
abandon it's current platform, (wait they did that once or twice
already)...


You are just refusing to acknowledge these simple facts.

systemd.................:  irrelevant to this decision

standalone systemd-udev.:  Vehemently unsupported, support for its
                           capability to exist is planned to be punted
                           in the future.

eudev...................:  fully functional, actively developed,
                           and fully supported, mature project, been
                           around for years.


Oh and here is one final piece that should blow your reason away

https://github.com/gentoo/eudev   <== NOTICE that it's upstream is
within our gentoo domain.  That means if Anthony (god forbid) were to
be hit by that proverbial bus.  The project can be easily assigned new
developers.  Not to mention the fact that with 14 downstream
distributions using it as their udev implementation.  That I am sure
some downstream developers would step up and continue its development
too.

Need I go on to list examples of other current projects that have
continued when their main developer had gone for one reason or another.

HINT: they are current Gentoo defaults too.

So PLEASE show us you are capable of seeing and acknoledging the above
simple facts and give up these BS arguments.  This whole BS over a
simple decision is giving me flashbacks of jury duty I did.  But at
least then, it was over something serious.  It was a murder trial.
This is about a simple virtual and the default order of its
providers!!!!!!! 

-- 
Brian Dolbec <dolsen>

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Sun, Feb 14, 2016 at 2:41 PM, Brian Dolbec <dolsen@gentoo.org> wrote:
> On Sun, 14 Feb 2016 11:00:30 -0500
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer <patrick@gentoo.org>
>> wrote:
>> > If, for any reason, eudev should be abandoned - we can just change
>> > the virtual back. One-line change.
>>
>> Which is precisely the corresponding argument for not switching the
>> default to eudev in the first place.
>>
>
> OH, my, this is looking more like you are being paid by systemd peeps...

Nobody has ever paid me to do anything involving open-source software,
systemd or otherwise.

My point is just that there is no need to change today, because:
1.  udev works just fine today
2.  If udev doesn't work just fine in the future, we can just change
the virtual.  One-line change.

That's all.  I'm not saying that there might not be other reasons to
change the virtual.

I'm just saying that the possibility that udev might break in the
future isn't any more a reason to change the virtual than the
possibility that eudev might be abandoned in the future.

I love it when Patrick violently agrees with me.  :)

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

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

On 14 Feb 2016 11:41, Brian Dolbec wrote:
> On Sun, 14 Feb 2016 11:00:30 -0500 Rich Freeman wrote:
> > On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer wrote:
> > > If, for any reason, eudev should be abandoned - we can just change
> > > the virtual back. One-line change.  
> > 
> > Which is precisely the corresponding argument for not switching the
> > default to eudev in the first place.
> 
> OH, my, this is looking more like you are being paid by systemd peeps...

honestly ?  cut the crap man.

> You are just refusing to acknowledge these simple facts.
> 
> systemd.................:  irrelevant to this decision
> 
> standalone systemd-udev.:  Vehemently unsupported, support for its
>                            capability to exist is planned to be punted
>                            in the future.
> 
> eudev...................:  fully functional, actively developed,
>                            and fully supported, mature project, been
>                            around for years.

udev: it's the default in every major distro that everyone tests and
develops against.

eudev: no one of any relevance outside of Gentoo runs it.

> Oh and here is one final piece that should blow your reason away
> 
> https://github.com/gentoo/eudev   <== NOTICE that it's upstream is
> within our gentoo domain.

irrelevant.  any Gentoo dev can create any repo in that namespace even
when they shouldn't.  the fact that eudev is in there does *not* mean
the whole Gentoo project has signed on to it, or that it's some sort
of "banner" project.  it means at least one Gentoo dev decided to do X
and our project system doesn't require project consensus before X can
proceed.  do not conflate these.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Patrick Lauer]

On 02/14/2016 09:17 PM, Rich Freeman wrote:
> On Sun, Feb 14, 2016 at 2:41 PM, Brian Dolbec <dolsen@gentoo.org> wrote:
>> On Sun, 14 Feb 2016 11:00:30 -0500
>> Rich Freeman <rich0@gentoo.org> wrote:
>>
>>> On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer <patrick@gentoo.org>
>>> wrote:
>>>> If, for any reason, eudev should be abandoned - we can just change
>>>> the virtual back. One-line change.
>>> Which is precisely the corresponding argument for not switching the
>>> default to eudev in the first place.
>>>
>> OH, my, this is looking more like you are being paid by systemd peeps...
> Nobody has ever paid me to do anything involving open-source software,
> systemd or otherwise.
>
> My point is just that there is no need to change today, because:
> 1.  udev works just fine today
> 2.  If udev doesn't work just fine in the future, we can just change
> the virtual.  One-line change.
>
> That's all.  I'm not saying that there might not be other reasons to
> change the virtual.
>
> I'm just saying that the possibility that udev might break in the
> future isn't any more a reason to change the virtual than the
> possibility that eudev might be abandoned in the future.
>
> I love it when Patrick violently agrees with me.  :)
>
Eh yes. If we can avoid a problem we better wait until there is visible
breakage so we can heroically run around like headless chickens and
people see that we do something.

You're definitely of the "Fireman Sysadmin" type that doesn't want to do
preventative maintenance :)


Why are you so insistent on controlling something that doesn't even
affect you?  I mean ... the only difference for you would be that from a
default stage3 you do "emerge -C eudev" instead of "emerge -C udev" and
then you're on your way.

As far as users are concerned, most don't care and won't see a
difference, and those that care seem to be strongly in support of having
eudev ...

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alon Bar-Lev]

On 14 February 2016 at 22:23, Mike Frysinger <vapier@gentoo.org> wrote:
> udev: it's the default in every major distro that everyone tests and
> develops against.
>
> eudev: no one of any relevance outside of Gentoo runs it.

I honestly don't understand this argument that pops over and over.

No "major distro" using udev without systemd, so OpenRC people are
already using udev in unsupported setup.

Better to use a tool that is tested and supported in this setup.

Or maybe I do not understand and mission is for us to switch to systemd?

Systemd users/developers should not mind what the default is as they
are forced to use one variant anyway, these users/developers should
not force their opinion upon others.

Thanks,
Alon

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Patrick Lauer]

On 02/14/2016 09:23 PM, Mike Frysinger wrote:
> On 14 Feb 2016 11:41, Brian Dolbec wrote:
>> On Sun, 14 Feb 2016 11:00:30 -0500 Rich Freeman wrote:
>>> On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer wrote:
>>>> If, for any reason, eudev should be abandoned - we can just change
>>>> the virtual back. One-line change.  
>>> Which is precisely the corresponding argument for not switching the
>>> default to eudev in the first place.
>> OH, my, this is looking more like you are being paid by systemd peeps...
> honestly ?  cut the crap man.
>
>> You are just refusing to acknowledge these simple facts.
>>
>> systemd.................:  irrelevant to this decision
>>
>> standalone systemd-udev.:  Vehemently unsupported, support for its
>>                            capability to exist is planned to be punted
>>                            in the future.
>>
>> eudev...................:  fully functional, actively developed,
>>                            and fully supported, mature project, been
>>                            around for years.
> udev: it's the default in every major distro that everyone tests and
> develops against.
Not the standalone config we're using, so if you remove all
systemd-using distros which are irrelevant to this discussion you end up
with gentoo, and ~15 distros that use eudev. And of course other
irrelevant weirdos that use mdev, vdev etc.
>
> eudev: no one of any relevance outside of Gentoo runs it.
No one runs udev either. So that's a non-argument


So given the context of this discussion, and your ignorant contribution
... maybe you should cut the crap, man. Being a bit more polite wouldn't
be wrong either.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Sun, Feb 14, 2016 at 3:27 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 02/14/2016 09:17 PM, Rich Freeman wrote:
>> On Sun, Feb 14, 2016 at 2:41 PM, Brian Dolbec <dolsen@gentoo.org> wrote:
>>> On Sun, 14 Feb 2016 11:00:30 -0500
>>> Rich Freeman <rich0@gentoo.org> wrote:
>>>
>>>> On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer <patrick@gentoo.org>
>>>> wrote:
>>>>> If, for any reason, eudev should be abandoned - we can just change
>>>>> the virtual back. One-line change.
>>>> Which is precisely the corresponding argument for not switching the
>>>> default to eudev in the first place.
>>>>
>>> OH, my, this is looking more like you are being paid by systemd peeps...
>> Nobody has ever paid me to do anything involving open-source software,
>> systemd or otherwise.
>>
>> My point is just that there is no need to change today, because:
>> 1.  udev works just fine today
>> 2.  If udev doesn't work just fine in the future, we can just change
>> the virtual.  One-line change.
>>
>> That's all.  I'm not saying that there might not be other reasons to
>> change the virtual.
>>
>> I'm just saying that the possibility that udev might break in the
>> future isn't any more a reason to change the virtual than the
>> possibility that eudev might be abandoned in the future.
>>
>> I love it when Patrick violently agrees with me.  :)
>>
> Eh yes. If we can avoid a problem we better wait until there is visible
> breakage so we can heroically run around like headless chickens and
> people see that we do something.

I think you were the first to suggest that if eudev gets abandoned it
isn't a big deal.  I just pointed out that same is true if udev gets
abandoned.

> Why are you so insistent on controlling something that doesn't even
> affect you?

I'm not controlling anything.  I'm just offering my opinion.  Nobody
is bound by it.

> As far as users are concerned, most don't care and won't see a
> difference, and those that care seem to be strongly in support of having
> eudev ...

And that would be a valid reason to default to eudev, as opposed to
fear that udev might just stop working some day.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Sun, Feb 14, 2016 at 3:31 PM, Alon Bar-Lev <alonbl@gentoo.org> wrote:
> Systemd users/developers should not mind what the default is as they
> are forced to use one variant anyway, these users/developers should
> not force their opinion upon others.

Posting an opinion on a list isn't forcing anything on anybody.
You're more than welcome to disagree with it.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

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

On 14 Feb 2016 22:31, Alon Bar-Lev wrote:
> On 14 February 2016 at 22:23, Mike Frysinger wrote:
> > udev: it's the default in every major distro that everyone tests and
> > develops against.
> >
> > eudev: no one of any relevance outside of Gentoo runs it.
> 
> I honestly don't understand this argument that pops over and over.
> 
> No "major distro" using udev without systemd, so OpenRC people are
> already using udev in unsupported setup.
> 
> Better to use a tool that is tested and supported in this setup.

the bring up of the daemon itself is not nearly as important as the
runtime interaction of people using libudev or rules being executed.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

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

On 14 Feb 2016 21:31, Patrick Lauer wrote:
> On 02/14/2016 09:23 PM, Mike Frysinger wrote:
> > On 14 Feb 2016 11:41, Brian Dolbec wrote:
> >> On Sun, 14 Feb 2016 11:00:30 -0500 Rich Freeman wrote:
> >>> On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer wrote:
> >>>> If, for any reason, eudev should be abandoned - we can just change
> >>>> the virtual back. One-line change.  
> >>> Which is precisely the corresponding argument for not switching the
> >>> default to eudev in the first place.
> >> OH, my, this is looking more like you are being paid by systemd peeps...
> > honestly ?  cut the crap man.
> >
> >> You are just refusing to acknowledge these simple facts.
> >>
> >> systemd.................:  irrelevant to this decision
> >>
> >> standalone systemd-udev.:  Vehemently unsupported, support for its
> >>                            capability to exist is planned to be punted
> >>                            in the future.
> >>
> >> eudev...................:  fully functional, actively developed,
> >>                            and fully supported, mature project, been
> >>                            around for years.
> > udev: it's the default in every major distro that everyone tests and
> > develops against.
> Not the standalone config we're using, so if you remove all
> systemd-using distros which are irrelevant to this discussion you end up
> with gentoo, and ~15 distros that use eudev. And of course other
> irrelevant weirdos that use mdev, vdev etc.
> >
> > eudev: no one of any relevance outside of Gentoo runs it.
> No one runs udev either. So that's a non-argument
> 
> 
> So given the context of this discussion, and your ignorant contribution
> ... maybe you should cut the crap, man. Being a bit more polite wouldn't
> be wrong either.

yes, your e-mails in this thread are a shining example of how to
collobarate and make cogent arguments.  attacking people directly
is definitely how you "win".  it's too bad i haven't actually done
any of what you're attempting to slander me with here.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Anthony G. Basile]

On 2/14/16 3:23 PM, Mike Frysinger wrote:
> 
> eudev: no one of any relevance outside of Gentoo runs it.
> 

that's not true, nor is it the central criticism, imo.  the problem is
the project only has one pair of eyes.  people have said all sorts of
stuff but really, there's only one relevant issue.  its a project
limited to my skill and my time.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Anthony G. Basile]

On 2/14/16 3:34 PM, Mike Frysinger wrote:

> 
> the bring up of the daemon itself is not nearly as important as the
> runtime interaction of people using libudev or rules being executed.
> -mike
> 

correct and i've been careful with libudev.

anyhow, can we divert this away from udev/eudev.  mike what do you
recommend as the future of openrc once systemd-udev can no longer be
extracted.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

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

On 14 Feb 2016 15:42, Anthony G. Basile wrote:
> On 2/14/16 3:23 PM, Mike Frysinger wrote:
> > eudev: no one of any relevance outside of Gentoo runs it.
> 
> that's not true, nor is it the central criticism, imo.

can you list the projects that utilize eudev ?  the repo doesn't that
i can see.  it is the central criticism imo when correct interaction
with other projects is key.  people rely on rules being parsed & run
correctly, as well as information provided by udev matching what they
are running/testing everyday.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

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

On 14 Feb 2016 15:47, Anthony G. Basile wrote:
> On 2/14/16 3:34 PM, Mike Frysinger wrote:
> > the bring up of the daemon itself is not nearly as important as the
> > runtime interaction of people using libudev or rules being executed.
> 
> correct and i've been careful with libudev.
> 
> anyhow, can we divert this away from udev/eudev.  mike what do you
> recommend as the future of openrc once systemd-udev can no longer be
> extracted.

if/when systemd-udev can't be extract anymore, then sys-fs/udev is dead,
and this whole thread is fairly moot.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Anthony G. Basile]

On 2/14/16 3:47 PM, Mike Frysinger wrote:
> On 14 Feb 2016 15:42, Anthony G. Basile wrote:
>> On 2/14/16 3:23 PM, Mike Frysinger wrote:
>>> eudev: no one of any relevance outside of Gentoo runs it.
>> 
>> that's not true, nor is it the central criticism, imo.
> 
> can you list the projects that utilize eudev ?  the repo doesn't
> that i can see.  it is the central criticism imo when correct
> interaction with other projects is key.  people rely on rules being
> parsed & run correctly, as well as information provided by udev
> matching what they are running/testing everyday. -mike
> 

until patrick brought up the list of distros, i was only aware of
alpine which is a musl based distro.  then puppy and slack came
forward.  they build their entire system using eudev as the libudev
provider.  if there were issues, they would bring forward bug reports
like any other project.

so when you say "people rely on rules being parsed ..." i don't know
why those user bases are dismissed.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alex McWhirter]

Why does any discussion revolving around systemd always turn out like this?

For the record, I'm an OpenRC user and intend on keeping it that way for
as long as i can. In that case i need udev to keep things working the
way i want them to. So in the case that the systemd team makes udev
inseparable from systemd, I will then consider using eudev or something
else. The point here is that i will change udev "if and when" that happens.

If that change occurs it's not like all OpenRC users are going to have
dead boxes. We will still have older versions of udev in the tree for
quite a while as we figure out the best approach. The best approach may
very well be to make systemd the default over OpenRC. I'm perfectly fine
with that as long as i can still opt to choose OpenRC / "whateverdev" at
install time.

Now eudev looks good to me and will probably work fine for my use case,
but that may not apply to everyone. In fact, the case may be that the
majority of users are using systemd. If the majority of users use
systemd and udev is pulled out from under our feet then maybe we should
go full on systemd. However, maybe the majority of users are not using
systemd and in that case maybe eudev would be a better option. There may
even be other solutions. Of course, there are other things we will need
to consider as well, but not until we have to make those decisions in
response to an upstream change.

The point is that udev works now, and it probably will for a while
longer. There's no point in changing something that not only works, but
works well. When it does break we can then figure out the rest of the
details. It could be a completely different situation tomorrow compared
to what it is today. Again, i don't really care as long as i can choose
the system i want should i want something different than the default.

This discussion shouldn't be about systemd fanboys forcing systemd down
others throats and conversely it shouldn't be about non-systemd bigots
forcing something else down their throats either. It should be about
which default best reflects the needs of the community should udev be no
longer accessible as a stand alone thing. It's almost a pointless
discussion right now considering people are arguing over trivial
preferences / ideologies and the fact that the situation may be very
different when it actually becomes a problem.

In short...

If it isn't broke, don't fix it.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[William Hubbs]

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

On Sun, Feb 14, 2016 at 03:50:38PM -0500, Mike Frysinger wrote:
> On 14 Feb 2016 15:47, Anthony G. Basile wrote:
> > On 2/14/16 3:34 PM, Mike Frysinger wrote:
> > > the bring up of the daemon itself is not nearly as important as the
> > > runtime interaction of people using libudev or rules being executed.
> > 
> > correct and i've been careful with libudev.
> > 
> > anyhow, can we divert this away from udev/eudev.  mike what do you
> > recommend as the future of openrc once systemd-udev can no longer be
> > extracted.
> 
> if/when systemd-udev can't be extract anymore, then sys-fs/udev is dead,
> and this whole thread is fairly moot.
> -mike

+1.

And, as for right now, udev-229 is in the tree, so udev can still be
extracted and run standalone from systemd.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

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

On 14 Feb 2016 15:56, Anthony G. Basile wrote:
> On 2/14/16 3:47 PM, Mike Frysinger wrote:
> > On 14 Feb 2016 15:42, Anthony G. Basile wrote:
> >> On 2/14/16 3:23 PM, Mike Frysinger wrote:
> >>> eudev: no one of any relevance outside of Gentoo runs it.
> >> 
> >> that's not true, nor is it the central criticism, imo.
> > 
> > can you list the projects that utilize eudev ?  the repo doesn't
> > that i can see.  it is the central criticism imo when correct
> > interaction with other projects is key.  people rely on rules being
> > parsed & run correctly, as well as information provided by udev
> > matching what they are running/testing everyday.
> 
> until patrick brought up the list of distros, i was only aware of
> alpine which is a musl based distro.  then puppy and slack came
> forward.  they build their entire system using eudev as the libudev
> provider.  if there were issues, they would bring forward bug reports
> like any other project.
> 
> so when you say "people rely on rules being parsed ..." i don't know
> why those user bases are dismissed.

i'm not dismissing them per-se.  i'm being practical here: i think you
can agree that the combined developer base of alpine/puppy/slack(ware?)
is significantly smaller as compared to the distros using udev.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[M. J. Everitt]

On 15/02/16 02:16, Mike Frysinger wrote:
> On 14 Feb 2016 15:56, Anthony G. Basile wrote:
>> On 2/14/16 3:47 PM, Mike Frysinger wrote:
>>> On 14 Feb 2016 15:42, Anthony G. Basile wrote:
>>>> On 2/14/16 3:23 PM, Mike Frysinger wrote:
>>>>> eudev: no one of any relevance outside of Gentoo runs it.
>>>> that's not true, nor is it the central criticism, imo.
>>> can you list the projects that utilize eudev ?  the repo doesn't
>>> that i can see.  it is the central criticism imo when correct
>>> interaction with other projects is key.  people rely on rules being
>>> parsed & run correctly, as well as information provided by udev
>>> matching what they are running/testing everyday.
>> until patrick brought up the list of distros, i was only aware of
>> alpine which is a musl based distro.  then puppy and slack came
>> forward.  they build their entire system using eudev as the libudev
>> provider.  if there were issues, they would bring forward bug reports
>> like any other project.
>>
>> so when you say "people rely on rules being parsed ..." i don't know
>> why those user bases are dismissed.
> i'm not dismissing them per-se.  i'm being practical here: i think you
> can agree that the combined developer base of alpine/puppy/slack(ware?)
> is significantly smaller as compared to the distros using udev.
> -mike
by "udev" do you mean systemd (as they are losely one-and-the-same) or
the unsupported udev-severed-from-systemd ...
Of course there is no comparison between Anthony's work on eudev and the
systemd 'crowd' it's just a non-question.

I think people are confusing the fact that there IS no separate 'udev'
.. it is the work of a gentoo maintainer to make it work without
systemd. To this end, does it really matter that OpenRC users are
reliant on a gentoo developer applying heavy patching of 'upstream'
udev-for-systemd .. or another gentoo developer working on an
alternative that's roughly API-compatible. The discussion is how you
jump the inevitable shark, and perhaps by switching the default and
having a bit of time ahead to deal with issues, is surely better than
facing a large breakage ahead, when there remains an option to switch
back to the current udev if there are problems with eudev. It also gives
Anthony a chance to have a greater user-base to test and evaluate eudev
so that improvements can be made in a timely fashion before
udev-without-systemd becomes unavailable (for whatever set of reasons).

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

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

On 15 Feb 2016 02:31, M. J. Everitt wrote:
> I think people are confusing the fact that there IS no separate 'udev'

i'm fully aware of this fact and have been since it happened.
i don't think it changes my point.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[M. J. Everitt]

On 15/02/16 05:28, Mike Frysinger wrote:
> On 15 Feb 2016 02:31, M. J. Everitt wrote:
>> I think people are confusing the fact that there IS no separate
>> 'udev'
> 
> i'm fully aware of this fact and have been since it happened. i
> don't think it changes my point. -mike
> 
It wasn't necessarily aimed at you .. just clarifying the point that
for others the point may not have completely sunk in :)

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alexis Ballier]

On Sun, 14 Feb 2016 19:34:52 -0600
William Hubbs <williamh@gentoo.org> wrote:

> On Sun, Feb 14, 2016 at 03:50:38PM -0500, Mike Frysinger wrote:
> > On 14 Feb 2016 15:47, Anthony G. Basile wrote:  
> > > On 2/14/16 3:34 PM, Mike Frysinger wrote:  
> > > > the bring up of the daemon itself is not nearly as important as
> > > > the runtime interaction of people using libudev or rules being
> > > > executed.  
> > > 
> > > correct and i've been careful with libudev.
> > > 
> > > anyhow, can we divert this away from udev/eudev.  mike what do you
> > > recommend as the future of openrc once systemd-udev can no longer
> > > be extracted.  
> > 
> > if/when systemd-udev can't be extract anymore, then sys-fs/udev is
> > dead, and this whole thread is fairly moot.
> > -mike  
> 
> +1.
> 
> And, as for right now, udev-229 is in the tree, so udev can still be
> extracted and run standalone from systemd.

and even with that, I don't think there is anything preventing using
systemd-udev from an openrc boot, is it ? (ie, have systemd installed
but booting with openrc)

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/15/2016 01:29 AM, Alexis Ballier wrote:
> On Sun, 14 Feb 2016 19:34:52 -0600 William Hubbs
> <williamh@gentoo.org> wrote:
> 
>> On Sun, Feb 14, 2016 at 03:50:38PM -0500, Mike Frysinger wrote:
>>> On 14 Feb 2016 15:47, Anthony G. Basile wrote:
>>>> On 2/14/16 3:34 PM, Mike Frysinger wrote:
>>>>> the bring up of the daemon itself is not nearly as
>>>>> important as the runtime interaction of people using
>>>>> libudev or rules being executed.
>>>> 
>>>> correct and i've been careful with libudev.
>>>> 
>>>> anyhow, can we divert this away from udev/eudev.  mike what
>>>> do you recommend as the future of openrc once systemd-udev
>>>> can no longer be extracted.
>>> 
>>> if/when systemd-udev can't be extract anymore, then sys-fs/udev
>>> is dead, and this whole thread is fairly moot. -mike
>> 
>> +1.
>> 
>> And, as for right now, udev-229 is in the tree, so udev can still
>> be extracted and run standalone from systemd.
> 
> and even with that, I don't think there is anything preventing
> using systemd-udev from an openrc boot, is it ? (ie, have systemd
> installed but booting with openrc)
> 
systemd blocks both udev and eudev, since it includes systemd-udev. I
don't know enough to tell you if the udev that ships with systemd is
separated enough to act as a daemon with OpenRC, but package-wise it's
a blocker.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWwaIEAAoJEAEkDpRQOeFwDskP/0nwCQh71phL6Nc6F3EkTnzU
JLIP3QOpqKXdtDYXJ/jG9+w746CKC3K/lR7IHuqvrWMVETXblwERbF9XGwUWMvmO
nzFZ/K9pbNSQ+CiCqBGbs0HrXcXXjeosCf/sgl3FX3JIBgFordCS4t/WQMtmUbwF
i2unx4BzAp+H0lJ8CuhmQj4cqTu3jaZkM+eRoXxniBM1ELZ3TZIYWu4T4OdjrCyb
f77CNdm9sQTHFFhkYHf4unIdfwcfcin+x6vWYLmuQrBbuoqh9On4qAuQLjoZjjDk
JlhUhHgVX5OzGCd8vW6aD7FJNmMLLONKmhpv8aZZrhUda3QPzMuzjZFtYFwxrn1N
81YOROGyWL5TK/cVzpUjU7qmYIkGv/NXMrv42zOxmUINQnX7h0ny2SWnJ1jboJZb
isq2INnolrTTEV158eI1ij4usrxdLiDjKwCRoAVZP6eHWlKb/g2bFX5TjKrwiLfI
exS8r+aWLVj2ytEZIm6Uf0UNdGjTC5MQSHCxz5d0zx0/KHsz6COIiPZHdcvXfPME
dXuYVsmkdE/+4nFSvUPZ7w+eV0jFZB2C1X+at3l4I6a4itLxK/Sp/ydDXmAvlItQ
zTdQORHbu3BW+dvbuTwafZVCVsiZQKUtWZexGGkgeyKjxm3svGyT4UVPE5euk5M4
yUH3T+1z6Z3LYGM/We4M
=EuL7
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Lars Wendler]

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

On Sun, 14 Feb 2016 13:10:07 +0100 Patrick Lauer wrote:

>On 02/09/2016 01:17 PM, Rich Freeman wrote:
>> On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric <kentfredric@gmail.com>
>> wrote: 
>>> And a lot of Gentoo is surprisingly simple: Like our use of bash
>>> scripts for recipies to build things, like using rsync to
>>> deploy/relay not just those recipies, but security notices and
>>> news items, which are themselves reasonably simple formats.  
>> Well, one thing about Gentoo that certainly isn't simple is our
>> init.d scripts.
>>
>> Compare this:
>> http://pastebin.com/sSDtpF4t  
>More stable link:
>https://gitweb.gentoo.org/proj/apache.git/tree/2.4/init/apache2.initd
>>
>> With this:
>> http://pastebin.com/Lfn8r7qP  
>More stable link:
>https://gitweb.gentoo.org/repo/gentoo.git/tree/www-servers/apache/files/apache2.2.service
>> Systemd does the job in 10% of the code (and half of it is a
>> comment), and doesn't implement its own service polling and killer
>> script during shutdown independently for every service (not that
>> every init.d script even does this - most of them will just leave
>> orphans behind, and systemd will catch orphans that even the lengthy
>> init.d script for apache misses).
>>  
>Right, that's a bad comparison.
>
>The equivalent OpenRC init script is:
>
>```
>#!/sbin/runscript
>command="/usr/sbin/apache2"
>command_args="${APACHE2_OPTS}"
>description_reload="A graceful restart advises the children to exit
>after the current request and reloads the configuration."
>
>stop() {
>    $command $APACHE2_OPTS -k graceful-stop
>}
>reload() {
>    $command $APACHE2_OPTS -k graceful
>}
>```
>So that's almost exactly the same (modulo braces and newlines). There's
>no equivalent for PrivateTmp, and we ignore the extra data in
>/etc/tmpfiles.d (for creating runtime dirs). Which is bad, but that's
>another rant ;)
>
>Just that the current initscript does a lot more, and ... uhm ... why
>is the systemd unit sourcing /etc/conf.d/apache2 ?

Becasue I don't give a damn about systemd and nobody cared to send
patches yet.

>(Oh, and dependencies, but those just slow down startup <trollface/>)
>
>So if you compile the equivalent naive init script there's not much
>difference, and the initial argument falls on its face and disappears.
>
>I'm getting tired of having this argument :)
>

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Mon, Feb 15, 2016 at 4:29 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Sun, 14 Feb 2016 19:34:52 -0600
> William Hubbs <williamh@gentoo.org> wrote:
>
>> And, as for right now, udev-229 is in the tree, so udev can still be
>> extracted and run standalone from systemd.
>
> and even with that, I don't think there is anything preventing using
> systemd-udev from an openrc boot, is it ? (ie, have systemd installed
> but booting with openrc)
>

Correct, you can uninstall sys-fs/(e)udev and install
sys-apps/systemd, then boot with openrc, and udev will work just fine.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Francesco Riosa]

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

2016-02-14 21:23 GMT+01:00 Mike Frysinger <vapier@gentoo.org>:

> On 14 Feb 2016 11:41, Brian Dolbec wrote:
> > On Sun, 14 Feb 2016 11:00:30 -0500 Rich Freeman wrote:
> > > On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer wrote:
> > > > If, for any reason, eudev should be abandoned - we can just change
> > > > the virtual back. One-line change.
> > >
> > > Which is precisely the corresponding argument for not switching the
> > > default to eudev in the first place.
> >
> > OH, my, this is looking more like you are being paid by systemd peeps...
>
> honestly ?  cut the crap man.
>
> > You are just refusing to acknowledge these simple facts.
> >
> > systemd.................:  irrelevant to this decision
> >
> > standalone systemd-udev.:  Vehemently unsupported, support for its
> >                            capability to exist is planned to be punted
> >                            in the future.
> >
> > eudev...................:  fully functional, actively developed,
> >                            and fully supported, mature project, been
> >                            around for years.
>
> udev: it's the default in every major distro that everyone tests and
> develops against.
>

This is NOT true, major distro use systemd, NOT udev as we use it.


>
> eudev: no one of any relevance outside of Gentoo runs it.
>

Neither this is totally true, or put another way, everybody which is NOT
using systemd is using eudev (or some form of static /dev).
So obviously this is totally relevant for people that don't use systemd.

Also, why, why people using systemd ARE interested in this thread?
You should not be interested at all.


>
> > Oh and here is one final piece that should blow your reason away
> >
> > https://github.com/gentoo/eudev   <== NOTICE that it's upstream is
> > within our gentoo domain.
>
> irrelevant.  any Gentoo dev can create any repo in that namespace even
> when they shouldn't.  the fact that eudev is in there does *not* mean
> the whole Gentoo project has signed on to it, or that it's some sort
> of "banner" project.  it means at least one Gentoo dev decided to do X
> and our project system doesn't require project consensus before X can
> proceed.  do not conflate these.
> -mike
>

[-- Attachment #2: Type: text/html, Size: 3379 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

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

On 15 Feb 2016 13:13, Francesco Riosa wrote:
> Also, why, why people using systemd ARE interested in this thread?
> You should not be interested at all.

in case you're directing at me, i do not use systemd anywhere
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[gentoo-dev] Re: Changing order of default virtual/udev provider

[Duncan]

Francesco Riosa posted on Mon, 15 Feb 2016 13:13:37 +0100 as excerpted:

> Neither this is totally true, or put another way, everybody which is NOT
> using systemd is using eudev (or some form of static /dev).
> So obviously this is totally relevant for people that don't use systemd.

Not really true either, as there remain various distros using busybox's 
mdev, etc.  However, it's /possibly/ true that most/all distros using 
udev-devmgr-dropin functionality, but not systemd, are switching to 
eudev.  I'm not in a position to know on that, beyond the enumerated list 
of those using eudev that was posted earlier in the thread.

> Also, why, why people using systemd ARE interested in this thread?
> You should not be interested at all.

Because many of those who are using systemd, including me, are never-the-
less interested in preserving an alternative init system, both for those 
who choose to use something other than systemd, and because we value an 
environment where the choice remains available, believing that choice is 
healthy and ultimately strengthens most players including the dominant 
player, systemd in this case.

In my particular case, I was one of the few users actually running and 
testing the openrc-9999 live package for many years, and that testing 
resulted in a number of bugs being reported and fixed before they hit 
actual ~arch release users.  I stand on that openrc gentoo-bugs record, 
and while I'm now a systemd user, I still care about a viable and healthy 
openrc project and ecosystem, including stand-alone udev, because while I 
am *currently* a systemd user, I know well how time and real-life 
occasionally throw unpredictable curveballs, and for all I know, I may 
well end up back on openrc in a few years, myself.  And if not me, than 
someone else I'm trying to help on some mailing list or whatever.  As 
such, it's very much in my own interest to make sure openrc and its 
ecosystem (including standalone udev-replacements) remains as viable and 
healthy as possible.

As it happens, that was actually one of my big worries about switching to 
systemd, myself, since I /was/ one of the only openrc-live testers for 
some time, and I was a bit concerned about the possibility of nobody else 
actually running it and catching/filing those early pre-release bugs.  
But I did a bugsy search on openrc-9999, and it turned out in the last 
year or two before I switched to systemd, others had begun filing 
openrc-9999 bugs as well, and I was no longer the only filer popping up 
in the bug searches.  So it was that a big worry about the effects of my 
switch on others still using openrc was put to rest, and I could 
personally switch secure in the knowledge that others had filled my role 
as openrc-live tester and bug-filer. =:^)

And it's with all that in mind that I've participated in this thread, 
seriously believing that eudev is in fact the most logical and viable 
default for stand-alone udev-drop-in functionality, tho I'd definitely 
rest a bit easier if the documentation were better and if it wasn't so 
much a primarily one-man project.

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

Re: [gentoo-dev] Changing order of default virtual/udev provider

[William Hubbs]

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

On Mon, Feb 15, 2016 at 07:11:26AM -0500, Rich Freeman wrote:
> On Mon, Feb 15, 2016 at 4:29 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> > On Sun, 14 Feb 2016 19:34:52 -0600
> > William Hubbs <williamh@gentoo.org> wrote:
> >
> >> And, as for right now, udev-229 is in the tree, so udev can still be
> >> extracted and run standalone from systemd.
> >
> > and even with that, I don't think there is anything preventing using
> > systemd-udev from an openrc boot, is it ? (ie, have systemd installed
> > but booting with openrc)
> >
> 
> Correct, you can uninstall sys-fs/(e)udev and install
> sys-apps/systemd, then boot with openrc, and udev will work just fine.

This is correct. udev does not require systemd in order to run; the only
thing it needs is the systemd build environment since there is common
source code.

The primary reason we have sys-fs/udev in the tree these days is so
people can have upstream udev without installing systemd.

In theory, we could lastrites sys-fs/udev and make sys-apps/systemd the default
udev provider, but I'm sure that change would be even more controversial
than what we are discussing. ;-)

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alexis Ballier]

On Tue, 16 Feb 2016 11:45:41 -0600
William Hubbs <williamh@gentoo.org> wrote:

> On Mon, Feb 15, 2016 at 07:11:26AM -0500, Rich Freeman wrote:
> > On Mon, Feb 15, 2016 at 4:29 AM, Alexis Ballier
> > <aballier@gentoo.org> wrote:  
> > > On Sun, 14 Feb 2016 19:34:52 -0600
> > > William Hubbs <williamh@gentoo.org> wrote:
> > >  
> > >> And, as for right now, udev-229 is in the tree, so udev can
> > >> still be extracted and run standalone from systemd.  
> > >
> > > and even with that, I don't think there is anything preventing
> > > using systemd-udev from an openrc boot, is it ? (ie, have systemd
> > > installed but booting with openrc)
> > >  
> > 
> > Correct, you can uninstall sys-fs/(e)udev and install
> > sys-apps/systemd, then boot with openrc, and udev will work just
> > fine.  
> 
> This is correct. udev does not require systemd in order to run; the
> only thing it needs is the systemd build environment since there is
> common source code.
> 
> The primary reason we have sys-fs/udev in the tree these days is so
> people can have upstream udev without installing systemd.
> 
> In theory, we could lastrites sys-fs/udev and make sys-apps/systemd
> the default udev provider, but I'm sure that change would be even
> more controversial than what we are discussing. ;-)

It would probably generate controversy indeed, but my comment was more
to understand what is the root of the f34R of udev being absorbed by
systemd: "it is supposedly unsupported upstream and might not work at
some point".

Well, as far as I can see, you are maintaining sys-fs/udev standalone
and don't intend to drop it. Even if you did, we could still pkgmove it
to systemd. My conclusion is that this claim of udev being a dead end
is pure FUD.

Alexis.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Chí-Thanh Christopher Nguyễn]

Alexis Ballier schrieb:
> It would probably generate controversy indeed, but my comment was more
> to understand what is the root of the f34R of udev being absorbed by
> systemd: "it is supposedly unsupported upstream and might not work at
> some point".
> Well, as far as I can see, you are maintaining sys-fs/udev standalone
> and don't intend to drop it. Even if you did, we could still pkgmove it
> to systemd. My conclusion is that this claim of udev being a dead end
> is pure FUD.

This claim was made by upstream, no less. And it refers to *running* 
udev without systemd as opposed to building (which upstream already made 
impossible).

Here is the exact wording:
"Unless the systemd-haters prepare another
kdbus userspace until then this will effectively also mean that we will
not support non-systemd systems with udev anymore starting at that
point. Gentoo folks, this is your wakeup call."
https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html

Not sure what about this is FUD.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Changing order of default virtual/udev provider

[William Hubbs]

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

On Tue, Feb 16, 2016 at 07:34:20PM +0100, Chí-Thanh Christopher Nguyễn wrote:
> Alexis Ballier schrieb:
> > It would probably generate controversy indeed, but my comment was more
> > to understand what is the root of the f34R of udev being absorbed by
> > systemd: "it is supposedly unsupported upstream and might not work at
> > some point".
> > Well, as far as I can see, you are maintaining sys-fs/udev standalone
> > and don't intend to drop it. Even if you did, we could still pkgmove it
> > to systemd. My conclusion is that this claim of udev being a dead end
> > is pure FUD.
> 
> This claim was made by upstream, no less. And it refers to *running* 
> udev without systemd as opposed to building (which upstream already made 
> impossible).
> 
> Here is the exact wording:
> "Unless the systemd-haters prepare another
> kdbus userspace until then this will effectively also mean that we will
> not support non-systemd systems with udev anymore starting at that
> point. Gentoo folks, this is your wakeup call."
> https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
> 
> Not sure what about this is FUD.

Maybe FUD is the incorrect way to put it, but I think us doing something
about it at this point is definitely premature since KDBUS is no where
near ready to go -- they were forced to retract it a while back because
they had to re-think the design.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Chí-Thanh Christopher Nguyễn]

William Hubbs schrieb:
> Maybe FUD is the incorrect way to put it, but I think us doing  > something about it at this point is definitely premature since > 
KDBUS is no where near ready to go -- they were forced to retract > it a 
while back because they had to re-think the design.

kdbus got sent for inclusion in the kernel, and they were sure ready to 
pull off their plan back then if kdbus had been accepted.

Whether switching to eudev now is premature is actually the central 
issue of this whole discussion. Given that dropping support for udev on 
non-systemd systems was narrowly avoided once, and upstream leaves no 
doubt that they are ready to do so once their redesigned kernel message 
bus goes upstream, I say describing such a move as "definitely 
premature" is not warranted.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Chí-Thanh Christopher Nguyễn]

Sorry about the messed up quoting, somehow enigmail and format=flowed do 
not work well together.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alexis Ballier]

On Tue, 16 Feb 2016 19:34:20 +0100
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> Alexis Ballier schrieb:
> > It would probably generate controversy indeed, but my comment was
> > more to understand what is the root of the f34R of udev being
> > absorbed by systemd: "it is supposedly unsupported upstream and
> > might not work at some point".
> > Well, as far as I can see, you are maintaining sys-fs/udev
> > standalone and don't intend to drop it. Even if you did, we could
> > still pkgmove it to systemd. My conclusion is that this claim of
> > udev being a dead end is pure FUD.  
> 
> This claim was made by upstream, no less. And it refers to *running* 
> udev without systemd as opposed to building (which upstream already
> made impossible).
> 
> Here is the exact wording:
> "Unless the systemd-haters prepare another
> kdbus userspace until then this will effectively also mean that we
> will not support non-systemd systems with udev anymore starting at
> that point. Gentoo folks, this is your wakeup call."
> https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
> 
> Not sure what about this is FUD.

If it is kdbus, this has changed quite a bit in the past months: it's
now dropped and replaced by bus1, and afaik, there is no plan to make a
systemd only lib for easying usage:
https://github.com/bus1/libbus1

I also fail to see how udev using a new linux ipc would make it require
systemd. Quoting Lennart:
"You need the userspace code to set up the bus and its policy and handle
activation. That's not a trivial task. For us, that's what sytemd does
in PID 1. You'd need to come up with an alternative for that."

If it's just that, it's not limited to udev, but anything using
kdbus/bus1, and would mean openrc/${favorite init system} will have to
do the same thing anyway. But again, almost 2 years is extremely
old considering all the flux that has been around kbus.

Alexis.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Chí-Thanh Christopher Nguyễn]

Alexis Ballier schrieb:
> I also fail to see how udev using a new linux ipc would make it require
> systemd. Quoting Lennart:
> "You need the userspace code to set up the bus and its policy and handle
> activation. That's not a trivial task. For us, that's what sytemd does
> in PID 1. You'd need to come up with an alternative for that."
>
> If it's just that, it's not limited to udev, but anything using
> kdbus/bus1, and would mean openrc/${favorite init system} will have to
> do the same thing anyway. But again, almost 2 years is extremely
> old considering all the flux that has been around kbus.

OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel 
IPC system comes next. But if upstream udev makes use of the systemd 
userspace interface to the kernel IPC system, then OpenRC would have to 
implement the same interface in order to have working udev.

Also given the close relationship between systemd and udev, there is no 
guarantee that supporting other users of kdbus/bus1 will make udev 
automagically work. As these two are released together, there is no 
reason to have a stable, public API between them.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Brian Dolbec]

On Tue, 16 Feb 2016 19:53:48 +0100
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> William Hubbs schrieb:
> > Maybe FUD is the incorrect way to put it, but I think us doing
> > something about it at this point is definitely premature since   
> > KDBUS is no where near ready to go -- they were forced to retract
> > it a while back because they had to re-think the design.
> 
> kdbus got sent for inclusion in the kernel, and they were sure ready
> to pull off their plan back then if kdbus had been accepted.
> 
> Whether switching to eudev now is premature is actually the central 
> issue of this whole discussion. Given that dropping support for udev
> on non-systemd systems was narrowly avoided once, and upstream leaves
> no doubt that they are ready to do so once their redesigned kernel
> message bus goes upstream, I say describing such a move as
> "definitely premature" is not warranted.
> 
> 
> Best regards,
> Chí-Thanh Christopher Nguyễn

Thank you for bringing this information to the forefront of this debate.

So, is it not better for us Gentoo-er's that wish to not install
systemd, to set the default non-systemd udev to eudev.  In that way,
maybe eudev will get more contributed support and Anthony more eyes on
things.  It seems that unless kdbus is perpetually rejected by the
kernel team... it is only a matter of time.


So, I say, we've all had enough bickering about the subject.

 Time for a final vote!

If we had all spent our time working on real problems as
we've spent reading this never ending debate mail...

but alas, this will be yet another item that must be decided by the
council.
-- 
Brian Dolbec <dolsen>

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Michał Górny]

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

On Tue, 16 Feb 2016 20:14:03 +0100
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> Alexis Ballier schrieb:
> > I also fail to see how udev using a new linux ipc would make it require
> > systemd. Quoting Lennart:
> > "You need the userspace code to set up the bus and its policy and handle
> > activation. That's not a trivial task. For us, that's what sytemd does
> > in PID 1. You'd need to come up with an alternative for that."
> >
> > If it's just that, it's not limited to udev, but anything using
> > kdbus/bus1, and would mean openrc/${favorite init system} will have to
> > do the same thing anyway. But again, almost 2 years is extremely
> > old considering all the flux that has been around kbus.  
> 
> OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel 
> IPC system comes next. But if upstream udev makes use of the systemd 
> userspace interface to the kernel IPC system, then OpenRC would have to 
> implement the same interface in order to have working udev.
> 
> Also given the close relationship between systemd and udev, there is no 
> guarantee that supporting other users of kdbus/bus1 will make udev 
> automagically work. As these two are released together, there is no 
> reason to have a stable, public API between them.

This all is going into some bickering nonsense and noise made by
systemd haters just to feed their troll, FUD and whatever else they
made around here.

So, yes, we should definitely switch to semi-maintained,
semi-documented fork made plainly of systemd hate. Because certainly
project that is created plainly for political reasons is better.
Because it will certainly be technically better if people have to focus
on copying regular udev maintainers and reworking their changes to keep
them working on forked codebase.

And after all, as someone said, this will give eudev proper testing.
Because why default to something tested and working when you can throw
your random fork on our users. After all, if we force them to use it,
they will eventually start co-maintaining it, and it will no longer be
semi-maintained!

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Patrick Lauer]

On 02/16/2016 08:33 PM, Michał Górny wrote:
> On Tue, 16 Feb 2016 20:14:03 +0100
> Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
>
>> Alexis Ballier schrieb:
>>> I also fail to see how udev using a new linux ipc would make it require
>>> systemd. Quoting Lennart:
>>> "You need the userspace code to set up the bus and its policy and handle
>>> activation. That's not a trivial task. For us, that's what sytemd does
>>> in PID 1. You'd need to come up with an alternative for that."
>>>
>>> If it's just that, it's not limited to udev, but anything using
>>> kdbus/bus1, and would mean openrc/${favorite init system} will have to
>>> do the same thing anyway. But again, almost 2 years is extremely
>>> old considering all the flux that has been around kbus.  
>> OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel 
>> IPC system comes next. But if upstream udev makes use of the systemd 
>> userspace interface to the kernel IPC system, then OpenRC would have to 
>> implement the same interface in order to have working udev.
>>
>> Also given the close relationship between systemd and udev, there is no 
>> guarantee that supporting other users of kdbus/bus1 will make udev 
>> automagically work. As these two are released together, there is no 
>> reason to have a stable, public API between them.
> This all is going into some bickering nonsense and noise made by
> systemd haters just to feed their troll, FUD and whatever else they
> made around here.
You call it hate, I call it having a choice.
If I didn't want a choice I'd be using MacOS anyway, so please don't
claim to understand my motivations (and why they are obviously wrong,
since you know The Truth)

>
> So, yes, we should definitely switch to semi-maintained,
> semi-documented fork made plainly of systemd hate.
You mean sys-fs/udev ? I'd say unsupported instead of semi-maintained ;)

>  Because certainly
> project that is created plainly for political reasons is better.
> Because it will certainly be technically better if people have to focus
> on copying regular udev maintainers and reworking their changes to keep
> them working on forked codebase.
>
> And after all, as someone said, this will give eudev proper testing.
(1) It's already used by lots of people
(2) 'proper' testing? As opposed to be the default in more than a dozen
distros that have usecases you and I rarely think of?
> Because why default to something tested and working when you can throw
> your random fork on our users. After all, if we force them to use it,
> they will eventually start co-maintaining it, and it will no longer be
> semi-maintained!
>
I have no idea why you think eudev is so horrible, but you're entitled
to having opinions.

And we don't throw it on our users more than we do now: If you don't
like it just remove it. emerge -C is easy!
You make it sound like we're removing choice, which is just ... how the
... what are you?!?

The whole discussion, which seems to turn everyone into a raging
squirrel, is about changing the default provider of a virtual. All other
providers will continue being listed and available. The change affects
none of the current userbase (who seem to have a preference for eudev if
forums polls have any meaning).

The change will only affect the default selected when no udev provider
is already installed. This would finally allow releng to have eudev on
stage3, which so far they were unable to do without manually overriding
defaults.

^^ That is pretty much all that changes. Seriously.


I have no idea why this topic that doesn't even affect the most vocal
neigh-sayers in this discussion seems to be so insanely difficult ...

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alexis Ballier]

On Tue, 16 Feb 2016 20:14:03 +0100
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> Alexis Ballier schrieb:
> > I also fail to see how udev using a new linux ipc would make it
> > require systemd. Quoting Lennart:
> > "You need the userspace code to set up the bus and its policy and
> > handle activation. That's not a trivial task. For us, that's what
> > sytemd does in PID 1. You'd need to come up with an alternative for
> > that."
> >
> > If it's just that, it's not limited to udev, but anything using
> > kdbus/bus1, and would mean openrc/${favorite init system} will have
> > to do the same thing anyway. But again, almost 2 years is extremely
> > old considering all the flux that has been around kbus.  
> 
> OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel 
> IPC system comes next.

Well, as Lennart wrote it, kbus would have needed some initialisation.
Just like we have a dbus init script, openrc would have a kdbus one.

> But if upstream udev makes use of the systemd 
> userspace interface to the kernel IPC system, then OpenRC would have
> to implement the same interface in order to have working udev.

As I understand it, a kernel IPC doesn't need systemd to work. udev
might use wrappers from libsystemd, or libbus1, just like we have
programs using libv4l or libbluetooth currently.

> Also given the close relationship between systemd and udev, there is
> no guarantee that supporting other users of kdbus/bus1 will make udev 
> automagically work. As these two are released together, there is no 
> reason to have a stable, public API between them.

Yes, which would mean systemd requires matching udev, not the other way
around. I'm a bit clueless here: Do you have any pointers on the recent
trends on this side ?

Alexis.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Tue, Feb 16, 2016 at 2:57 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> The whole discussion, which seems to turn everyone into a raging
> squirrel, is about changing the default provider of a virtual. All other
> providers will continue being listed and available. The change affects
> none of the current userbase (who seem to have a preference for eudev if
> forums polls have any meaning).

Why is it that anytime there is a great debate over something somebody
says something like the following:

This decision is completely trivial and won't really change anything.
That is why it is so critical that we make this decision right now!

Either it matters or it doesn't...

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alexis Ballier]

On Tue, 16 Feb 2016 20:33:55 +0100
Michał Górny <mgorny@gentoo.org> wrote:
[...]
> This all is going into some bickering nonsense and noise made by
> systemd haters just to feed their troll, FUD and whatever else they
> made around here.
> 
> So, yes, we should definitely switch to semi-maintained,
> semi-documented fork made plainly of systemd hate. Because certainly
> project that is created plainly for political reasons is better.
> Because it will certainly be technically better if people have to
> focus on copying regular udev maintainers and reworking their changes
> to keep them working on forked codebase.
> 
> And after all, as someone said, this will give eudev proper testing.
> Because why default to something tested and working when you can throw
> your random fork on our users. After all, if we force them to use it,
> they will eventually start co-maintaining it, and it will no longer be
> semi-maintained!

keep cool; eudev has its merits, I'm just trying to figure out what is
a real one and what is a pure guess on the future. For me, the main
advantage for eudev is the loose coupling with the kernel, which we
have no way to control/force in gentoo, and in some worlds (embedded)
it is often, unfortunately, not even an option to use a recent kernel.

Alexis.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Tue, Feb 16, 2016 at 1:34 PM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
>
> This claim was made by upstream, no less. And it refers to *running* udev
> without systemd as opposed to building (which upstream already made
> impossible).
>
> Here is the exact wording:
> "Unless the systemd-haters prepare another
> kdbus userspace until then this will effectively also mean that we will
> not support non-systemd systems with udev anymore starting at that
> point. Gentoo folks, this is your wakeup call."
> https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
>
> Not sure what about this is FUD.
>

The fact that it came from Lennart doesn't make it any less FUD.

I don't think that the eudev folks plan to completely go off in a
separate direction, so most likely whatever changes occur to systemd
to keep udev running will probably end up getting made to openrc to
keep (e)udev running.

If the argument was that we should be running eudev by default because
it is better I could buy that.  However, this seems to be an argument
based on a fear of what some other project might do in the future.

Even the great Lennart doesn't know with certainty what the future
holds for udev/systemd/etc.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Anthony G. Basile]

On 2/16/16 3:05 PM, Rich Freeman wrote:
> On Tue, Feb 16, 2016 at 2:57 PM, Patrick Lauer <patrick@gentoo.org> wrote:
>> The whole discussion, which seems to turn everyone into a raging
>> squirrel, is about changing the default provider of a virtual. All other
>> providers will continue being listed and available. The change affects
>> none of the current userbase (who seem to have a preference for eudev if
>> forums polls have any meaning).
> 
> Why is it that anytime there is a great debate over something somebody
> says something like the following:

https://www.youtube.com/watch?v=6rI8mDpnv7c

> 
> This decision is completely trivial and won't really change anything.
> That is why it is so critical that we make this decision right now!
> 
> Either it matters or it doesn't...
> 


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alexis Ballier]

On Tue, 16 Feb 2016 15:09:23 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> On Tue, Feb 16, 2016 at 1:34 PM, Chí-Thanh Christopher Nguyễn
> <chithanh@gentoo.org> wrote:
> >
> > This claim was made by upstream, no less. And it refers to
> > *running* udev without systemd as opposed to building (which
> > upstream already made impossible).
> >
> > Here is the exact wording:
> > "Unless the systemd-haters prepare another
> > kdbus userspace until then this will effectively also mean that we
> > will not support non-systemd systems with udev anymore starting at
> > that point. Gentoo folks, this is your wakeup call."
> > https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
> >
> > Not sure what about this is FUD.
> >  
> 
> The fact that it came from Lennart doesn't make it any less FUD.

IMHO this makes a good argument for the wait&see (aka keep sys-fs/udev
default) position:
- May 2014: Lennart writes the world will fall apart and udev will
  somewhat require systemd with kdbus.
- May/June 2015: kdbus is first sent for review/merge for the linux 4.1
  merge window (I think).
- Feb. 2016: kdbus has been included then removed from fedora kernels,
  it is being reworked and is not even proposed for the linux 4.5 merge
  window.

I'd say we still have some time to see how things will evolve :)

Alexis.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Brian Dolbec]

On Tue, 16 Feb 2016 15:26:46 -0500
"Anthony G. Basile" <blueness@gentoo.org> wrote:

> On 2/16/16 3:05 PM, Rich Freeman wrote:
> > On Tue, Feb 16, 2016 at 2:57 PM, Patrick Lauer <patrick@gentoo.org>
> > wrote:  
> >> The whole discussion, which seems to turn everyone into a raging
> >> squirrel, is about changing the default provider of a virtual. All
> >> other providers will continue being listed and available. The
> >> change affects none of the current userbase (who seem to have a
> >> preference for eudev if forums polls have any meaning).  
> > 
> > Why is it that anytime there is a great debate over something
> > somebody says something like the following:  
> 
> https://www.youtube.com/watch?v=6rI8mDpnv7c
> 
> > 
> > This decision is completely trivial and won't really change
> > anything. That is why it is so critical that we make this decision
> > right now!
> > 
> > Either it matters or it doesn't...
> >   
> 
> 

And I had resisted several times now of pasting in youtube links... :)

time for some humor injection...

OK, in this first link, the eudev people think the systemd people are
the one migrating and the systemd people think the reverse...

https://www.youtube.com/watch?v=AOOs8MaR1YM

And from some people's comments in this thread...

https://www.youtube.com/watch?v=dndAXxqJbc0



-- 
Brian Dolbec <dolsen>

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Chí-Thanh Christopher Nguyễn]

Brian Dolbec schrieb:
> Thank you for bringing this information to the forefront of this debate.
>
> So, is it not better for us Gentoo-er's that wish to not install
> systemd, to set the default non-systemd udev to eudev.

Note that I am not advocating for or against this move. I was just pointing 
out what I consider bad arguments.

This includes labeling valid concerns as "pure FUD", and calling a move 
"definitely premature" when it was only circumstances beyond udev upstream's 
control which prevented it from becoming a necessity.

I do feel that the eudev critics are correct in pointing out that both the 
real-world exposure of eudev so far and the size of its development team are 
too small. Whether it is a good idea to attempt to increase them by making 
eudev the Gentoo default I don't think I am qualified to answer.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Chí-Thanh Christopher Nguyễn]

Michał Górny schrieb:
> This all is going into some bickering nonsense and noise made by
> systemd haters just to feed their troll, FUD and whatever else they
> made around here.

As you directed this reply at me: If you think that calling out someone for 
labeling valid concerns as "pure FUD" is itself bickering and FUD then I am 
sorry, but that is not a way we can have an argument.

I explained why the concerns are valid given upstream's past behaviour and 
public announcements. Whether they carry more weight than the other side's 
concerns is a different matter, but they can certainly not be dismissed as FUD.

> So, yes, we should definitely switch to semi-maintained,
> semi-documented fork made plainly of systemd hate.

That is a false dichotomy. Apparently in this world there exist only systemd 
love and systemd hate.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Michał Górny]

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

On Tue, 16 Feb 2016 20:57:31 +0100
Patrick Lauer <patrick@gentoo.org> wrote:

> On 02/16/2016 08:33 PM, Michał Górny wrote:
> > This all is going into some bickering nonsense and noise made by
> > systemd haters just to feed their troll, FUD and whatever else they
> > made around here.  
> You call it hate, I call it having a choice.

You have a choice. This is trying to force your choice on everyone else
just because you hate the other option and don't want anybody to be
using it.

> >  Because certainly
> > project that is created plainly for political reasons is better.
> > Because it will certainly be technically better if people have to focus
> > on copying regular udev maintainers and reworking their changes to keep
> > them working on forked codebase.
> >
> > And after all, as someone said, this will give eudev proper testing.  
> (1) It's already used by lots of people
> (2) 'proper' testing? As opposed to be the default in more than a dozen
> distros that have usecases you and I rarely think of?

Are you really serious with those fringe distros? How many of them have
a dozen users that do not happen to be developers of the distro? How
many of them are actually used in production? How many of them have
diverse enough userbase to prove that eudev works in different
environments?

> The whole discussion, which seems to turn everyone into a raging
> squirrel, is about changing the default provider of a virtual. All other
> providers will continue being listed and available. The change affects
> none of the current userbase (who seem to have a preference for eudev if
> forums polls have any meaning).
> 
> The change will only affect the default selected when no udev provider
> is already installed. This would finally allow releng to have eudev on
> stage3, which so far they were unable to do without manually overriding
> defaults.
> 
> ^^ That is pretty much all that changes. Seriously.
> 
> 
> I have no idea why this topic that doesn't even affect the most vocal
> neigh-sayers in this discussion seems to be so insanely difficult ...

The reason for that is simple: because it quickly turned away from
merits to politics, FUD and nonsense. And spammed the mailing list to
incredible level. So after next mail about the bad Templars silently
planning to take over the world by integrating udev in systemd codebase
and renaming it to systemd-udevd... I mean, people have their limits,
and there are amounts of nonsense that set us off.

Please don't forget to ban all *BSDs for keeping their sources
in a single repository. They took over the whole base-system already,
and you have to fork the whole system just to have the choice!

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Chí-Thanh Christopher Nguyễn]

Alexis Ballier schrieb:
>>> If it's just that, it's not limited to udev, but anything using
>>> kdbus/bus1, and would mean openrc/${favorite init system} will have
>>> to do the same thing anyway. But again, almost 2 years is extremely
>>> old considering all the flux that has been around kbus.
>>
>> OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel
>> IPC system comes next.
>
> Well, as Lennart wrote it, kbus would have needed some initialisation.
> Just like we have a dbus init script, openrc would have a kdbus one.
>
>> But if upstream udev makes use of the systemd
>> userspace interface to the kernel IPC system, then OpenRC would have
>> to implement the same interface in order to have working udev.
>
> As I understand it, a kernel IPC doesn't need systemd to work. udev
> might use wrappers from libsystemd, or libbus1, just like we have
> programs using libv4l or libbluetooth currently.

In a follow-up, upstream wrote about how you should only run udev together 
with systemd, and if you don't want to do that (spelling as in original):

"we will not support the udev-on-netlink case anymore. I see three options:
a) fork things, b) live with systemd, c) if hate systemd that much, but
love udev so much, then implement an alternative userspace for kdbus to
do initialiuzation/policy/activation."
https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html

So it seems a bit more than only initialization is needed.

>> Also given the close relationship between systemd and udev, there is
>> no guarantee that supporting other users of kdbus/bus1 will make udev
>> automagically work. As these two are released together, there is no
>> reason to have a stable, public API between them.
>
> Yes, which would mean systemd requires matching udev, not the other way
> around. I'm a bit clueless here: Do you have any pointers on the recent
> trends on this side ?

I have only upstream's statements from 2014. They talk about a kdbus 
userspace that systemd will provide to udev, which will be necessary for udev 
to function.
If and when upstream comes forward with statements about whether udev will 
only use public and stable API, these concerns could be either dispelled or 
confirmed.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alexis Ballier]

On Tue, 16 Feb 2016 23:16:41 +0100
Michał Górny <mgorny@gentoo.org> wrote:
> > >  Because certainly
> > > project that is created plainly for political reasons is better.
> > > Because it will certainly be technically better if people have to
> > > focus on copying regular udev maintainers and reworking their
> > > changes to keep them working on forked codebase.
> > >
> > > And after all, as someone said, this will give eudev proper
> > > testing.    
> > (1) It's already used by lots of people
> > (2) 'proper' testing? As opposed to be the default in more than a
> > dozen distros that have usecases you and I rarely think of?  
> 
> Are you really serious with those fringe distros? How many of them
> have a dozen users that do not happen to be developers of the distro?
> How many of them are actually used in production? How many of them
> have diverse enough userbase to prove that eudev works in different
> environments?


by that type of argument, we should really all be using android :)

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Brian Dolbec]

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

On Tue, 16 Feb 2016 23:16:41 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> On Tue, 16 Feb 2016 20:57:31 +0100
> Patrick Lauer <patrick@gentoo.org> wrote:
> 
> > On 02/16/2016 08:33 PM, Michał Górny wrote:  
> > > This all is going into some bickering nonsense and noise made by
> > > systemd haters just to feed their troll, FUD and whatever else
> > > they made around here.    
> > You call it hate, I call it having a choice.  
> 
> You have a choice. This is trying to force your choice on everyone
> else just because you hate the other option and don't want anybody to
> be using it.
>

NOT EVERYONE, just make it the non-systemd default, htere is still
choice to change to to whatever...

> > >  Because certainly
> > > project that is created plainly for political reasons is better.
> > > Because it will certainly be technically better if people have to
> > > focus on copying regular udev maintainers and reworking their
> > > changes to keep them working on forked codebase.
> > >
> > > And after all, as someone said, this will give eudev proper
> > > testing.    
> > (1) It's already used by lots of people
> > (2) 'proper' testing? As opposed to be the default in more than a
> > dozen distros that have usecases you and I rarely think of?  
> 
> Are you really serious with those fringe distros? How many of them
> have a dozen users that do not happen to be developers of the distro?
> How many of them are actually used in production? How many of them
> have diverse enough userbase to prove that eudev works in different
> environments?


Now you are starting to spout incomplete truths from being riled up,
not thinking things through.

Since you consider them to be just a dozen or so...

In the 8 months where I am working now, they use eudev for all their
installs.  This includes more than 50 different server profiles and
resulting images.  Those are multiplied out into multiple instances in
each rack and server clusters distributed in many places around the
world.

So a real world example puts it over a 1000 units (guesstimate) in daily
production. Plus several hundred more on the development and
testing clusters. Plus several hundred (minimum) workstation and
developer vms.

In that 8 months in the release engineering team, I've not seen one
email or bug report that has been due to a problem with eudev.  If
there were I did not see it pass thru the group communications channels.


So, there are lots more eudev users out there than the few dozen you
seem to intimate to.


Can we please put an end to this thread!!!!!  ONE WAY OR THE OTHER!!!
-- 
Brian Dolbec <dolsen>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Richard Yao]

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

On 02/08/2016 04:08 AM, Patrick Lauer wrote:
> Ohey,
> 
> I've opened a bug at:
> https://bugs.gentoo.org/show_bug.cgi?id=573922
> 
> The idea here is to change the order of the providers of virtual/udev.
> For existing installs this has zero impact.
> For stage3 this would mean that eudev is pulled in instead of udev.
> 
> The rationale behind this is:
> 
> * eudev is an in-house fork, and there's more than a dozen distros
> already using it by default that are not us. Which is a little bit weird ...
> 
> * Both udev and eudev have pretty much feature parity, so there won't be
> any user-visible changes
> 
> * udev upstream strongly discourages standalone udev (without systemd)
> since at least 2012
> 
> (see for example:
> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html
> https://lkml.org/lkml/2012/10/3/618
> )
> 
> So it'd be (1) following upstreams recommendations and (2) dogfooding
> our own tools. I don't see any downsides to this :)
> 

+1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Richard Yao]

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

On 02/08/2016 07:46 AM, Michał Górny wrote:
> On Mon, 8 Feb 2016 10:08:22 +0100
> Patrick Lauer <patrick@gentoo.org> wrote:
> 
>> Ohey,
>>
>> I've opened a bug at:
>> https://bugs.gentoo.org/show_bug.cgi?id=573922
>>
>> The idea here is to change the order of the providers of virtual/udev.
>> For existing installs this has zero impact.
>> For stage3 this would mean that eudev is pulled in instead of udev.
>>
>> The rationale behind this is:
>>
>> * eudev is an in-house fork, and there's more than a dozen distros
>> already using it by default that are not us. Which is a little bit weird ...
> 
> That's not an argument. I can also fork random system components. Would
> you consider that a reason to replace the defaults with our 'in-house'
> forks?
> 
>> * Both udev and eudev have pretty much feature parity, so there won't be
>> any user-visible changes
>>
>> * udev upstream strongly discourages standalone udev (without systemd)
>> since at least 2012
>>
>> (see for example:
>> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html
>> https://lkml.org/lkml/2012/10/3/618
>> )
>>
>> So it'd be (1) following upstreams recommendations and (2) dogfooding
>> our own tools. I don't see any downsides to this :)
> 
> I'm strongly against this, because:
> 
> 1. It is a conflict-induced fork. As such, it will never be merged
> upstream and it will never be supported upstream. In fact, it is
> continually forces to follow upstream changes and adapt to them. eudev
> is more likely to break because of the Gentoo developer(s) working hard
> to merge upstream changes to their incompatible code.

That was the entire point of the project. Upstream rejected any attempts
to do things that we actually needed and broke things claiming the
distributions were responsible for handling the breakage, so eudev was
started on the basis that we needed a project that would ensure that
changes in udev occur in a way that makes sense.

> 2. Many of Gentoo users are programmers who appreciate the 'vanilla'
> API experience Gentoo often provides. Switching the defaults to a fork
> that is known to intentionally diverge from upstream goes against that
> principle. Programs written against eudev may not work correctly with
> upstream udev.

If upstream udev were stable, that would be one thing, but it
intentionally diverges from itself continuously. The only experience
that could be reliably provided with upstream udev is one of continual
breakage.

> 3. eudev has fallen behind systemd/udev more than once in the past,
> and caused visible breakage to users this way.

When?

Can we also consider all of the times udev broke the boot process
because upstream just didn't care about doing changes in a sane way and
the people interested in providing the upstream experience delivered on
that goal?

> 4. eudev is underdocumented, and the maintainer admits that 'he sucks
> at documenting'. In fact, did anyone even bother to note how far eudev
> diverges from upstream udev to this point?

The FreeBSD developers were complaining about how poorly documented udev
was well before eudev existed. This is not a regression unless systemd's
innovations in replacing documented things with undocumented things made
them worse.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Richard Yao]

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

On 02/08/2016 10:09 PM, Rich Freeman wrote:
> On Mon, Feb 8, 2016 at 7:58 PM, Anthony G. Basile
<blueness@gentoo.org> wrote:
>>
>> what does in-house tool mean?  i'm a gentoo developer but i also work
>> on an upstream project (eudev) that 14 distros use.
>>
>> some of the criticism given here are my concerns as well and i've
>> spoken with the various distros --- slack, parted magic, puppy.  they
>> get what's going on and they still see eudev is the best way forward
>> for now.  it may not be in the future, but neither will a udev
>> extracted from a compiled full systemd codebase.
>
> How many of those 14 distros have more than 14 users?
>
> Look, I get it, some people don't like systemd.  That's fine.
> However, you have to realize at this point that a non-systemd
> configuration is anything but mainstream.  There will always be a
> "poppyseed linux" whose purpose in life seems to be to preserve linux
> without sysfs or some other obscure practice.  I just think that
> Gentoo should offer the choice to do those things, but have a more
> mainstream set of defaults.

The new mainstream is docker. Docker recently switched to Alpine Linux,
which uses OpenRC+eudev:

https://www.brianchristner.io/docker-is-moving-to-alpine-linux/

That dwarfs whatever marketshare systemd has in the same way that
Android+iOS dwarfed whatever marketshare Windows has.

If userbase is what matters to you, then OpenRC+eudev won. It is the
logical choice for those concerned about userbase because that is what
the Linux ecosystem will be using going forward.

I do not think userbase should be the sole means by which we make
decisions, but those that think otherwise should now join the
eudev+OpenRC camp. It has the bigger userbase share going forward.

To put it another way, the war is over. Welcome abroad. :)

>>
>> it needs to be in the new stage4s to make a bootable system.  imo a
>> stage4 should be bootable modulo a kernel.
>>
>
> Sure, a stage4 based on systemd makes a lot of sense.  I don't really
> see the point in leaving a kernel out though - I'd even stick a
> precompiled one in /boot on top of having the sources installed.  Why
> not make a stage4 install something that takes all of 5 minutes?
>
> I think that offering an eudev-based distro as a default just doesn't
> make sense in 2016.  I just think the better road to take is to start
> treating virtual/udev as something that gets installed post-stage3.
> We can't even get people to agree on vi vs emacs as a default.

We can leave virtual/udev out of stage3, but that doesn't diminish the
need to select sensible default for the virtual/udev provider.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[gentoo-dev] Re: Changing order of default virtual/udev provider

[Duncan]

Michał Górny posted on Tue, 16 Feb 2016 23:16:41 +0100 as excerpted:

> On Tue, 16 Feb 2016 20:57:31 +0100 Patrick Lauer <patrick@gentoo.org>
> wrote:
> 
>> On 02/16/2016 08:33 PM, Michał Górny wrote:
>> > This all is going into some bickering nonsense and noise made by
>> > systemd haters just to feed their troll, FUD and whatever else they
>> > made around here.
>> You call it hate, I call it having a choice.
> 
> You have a choice. This is trying to force your choice on everyone else
> just because you hate the other option and don't want anybody to be
> using it.

Who's forcing who's choice?  It's a virtual default, where virtuals are 
/designed/ to allow choice.

And as a systemd user myself, the only one I see trying to force a 
particular choice is systemd and its devs, which as they've made very 
clear, would prefer to be the only possibility on Linux, no choice 
available but to switch to some other non-Linux (or at least non-Gnu/
Linux) platform.

Meanwhile, systemd users already don't have a choice and thus aren't 
affected by the virtual default except at installation, and switching 
from udev or eudev to systemd, six of one, a half dozen of the other.

So what's the problem if non-systemd users decide to set a designed-to-be-
stand-alone package as the default device-manager, instead of an 
explicitly intended to be systemd-only package as a device-manager, using 
it apart from systemd in a way not intended and actively discouraged by 
its developers.  For non-systemd users, that would seem to be only 
logical, and systemd users have had that choice taken from them by 
systemd and thus don't have a choice to make, so what's the problem?

Again, that's as a systemd user myself.  You can't, at least not 
correctly, claim systemd hate here.  I'm simply a realist, using what 
seems to me to be the best tool for the job, which happens to be systemd 
currently, but I would sure like to keep the choice around as insurance 
against a dramatic turn for the worse, as unfortunately, I've seen happen 
too many times in my computer experience, Linux and otherwise.  (No need 
to enumerate details here.)

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

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Michał Górny]

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

On Tue, 16 Feb 2016 21:54:31 -0500
Richard Yao <ryao@gentoo.org> wrote:

> On 02/08/2016 07:46 AM, Michał Górny wrote:
> > On Mon, 8 Feb 2016 10:08:22 +0100
> > Patrick Lauer <patrick@gentoo.org> wrote:
> >   
> >> Ohey,
> >>
> >> I've opened a bug at:
> >> https://bugs.gentoo.org/show_bug.cgi?id=573922
> >>
> >> The idea here is to change the order of the providers of virtual/udev.
> >> For existing installs this has zero impact.
> >> For stage3 this would mean that eudev is pulled in instead of udev.
> >>
> >> The rationale behind this is:
> >>
> >> * eudev is an in-house fork, and there's more than a dozen distros
> >> already using it by default that are not us. Which is a little bit weird ...  
> > 
> > That's not an argument. I can also fork random system components. Would
> > you consider that a reason to replace the defaults with our 'in-house'
> > forks?
> >   
> >> * Both udev and eudev have pretty much feature parity, so there won't be
> >> any user-visible changes
> >>
> >> * udev upstream strongly discourages standalone udev (without systemd)
> >> since at least 2012
> >>
> >> (see for example:
> >> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html
> >> https://lkml.org/lkml/2012/10/3/618
> >> )
> >>
> >> So it'd be (1) following upstreams recommendations and (2) dogfooding
> >> our own tools. I don't see any downsides to this :)  
> > 
> > I'm strongly against this, because:
> > 
> > 1. It is a conflict-induced fork. As such, it will never be merged
> > upstream and it will never be supported upstream. In fact, it is
> > continually forces to follow upstream changes and adapt to them. eudev
> > is more likely to break because of the Gentoo developer(s) working hard
> > to merge upstream changes to their incompatible code.  
> 
> That was the entire point of the project. Upstream rejected any attempts
> to do things that we actually needed and broke things claiming the
> distributions were responsible for handling the breakage, so eudev was
> started on the basis that we needed a project that would ensure that
> changes in udev occur in a way that makes sense.

What things? Things like 'let's try to spawn this script third time in
case someone mounted something so that it happens to work this time'?
Yes, that old behavior really made sense.

> > 2. Many of Gentoo users are programmers who appreciate the 'vanilla'
> > API experience Gentoo often provides. Switching the defaults to a fork
> > that is known to intentionally diverge from upstream goes against that
> > principle. Programs written against eudev may not work correctly with
> > upstream udev.  
> 
> If upstream udev were stable, that would be one thing, but it
> intentionally diverges from itself continuously. The only experience
> that could be reliably provided with upstream udev is one of continual
> breakage.

This is FUD, without any proof.

> 
> > 3. eudev has fallen behind systemd/udev more than once in the past,
> > and caused visible breakage to users this way.  
> 
> When?

Whenever we installed new systemd and udev versions, and needed to bump
the dependency in virtual, and eudev maintainers were nowhere to be
found.

> Can we also consider all of the times udev broke the boot process
> because upstream just didn't care about doing changes in a sane way and
> the people interested in providing the upstream experience delivered on
> that goal?

Proof needed.

> > 4. eudev is underdocumented, and the maintainer admits that 'he sucks
> > at documenting'. In fact, did anyone even bother to note how far eudev
> > diverges from upstream udev to this point?  
> 
> The FreeBSD developers were complaining about how poorly documented udev
> was well before eudev existed. This is not a regression unless systemd's
> innovations in replacing documented things with undocumented things made
> them worse.

So... replacing thing that has some docs with a thing that has no docs
and links to docs of udev that aren't exact match for eudev is good?
Good to know.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Patrick Lauer]

On 02/17/2016 07:37 AM, Michał Górny wrote:
>
>>>> * Both udev and eudev have pretty much feature parity, so there won't be
>>>> any user-visible changes
>>>>
>>>> * udev upstream strongly discourages standalone udev (without systemd)
>>>> since at least 2012
>>>>
>>>> (see for example:
>>>> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html
>>>> https://lkml.org/lkml/2012/10/3/618
>>>> )
>>>>
>>>> So it'd be (1) following upstreams recommendations and (2) dogfooding
>>>> our own tools. I don't see any downsides to this :)  
>>> I'm strongly against this, because:
>>>
>>> 1. It is a conflict-induced fork. As such, it will never be merged
>>> upstream and it will never be supported upstream. In fact, it is
>>> continually forces to follow upstream changes and adapt to them. eudev
>>> is more likely to break because of the Gentoo developer(s) working hard
>>> to merge upstream changes to their incompatible code.  
>> That was the entire point of the project. Upstream rejected any attempts
>> to do things that we actually needed and broke things claiming the
>> distributions were responsible for handling the breakage, so eudev was
>> started on the basis that we needed a project that would ensure that
>> changes in udev occur in a way that makes sense.
> What things? Things like 'let's try to spawn this script third time in
> case someone mounted something so that it happens to work this time'?
> Yes, that old behavior really made sense.
It did. Not having it made booting a lot more exciting, and exciting is bad.

Now you need to boot before you boot (mount all relevant filesystems
before starting PID1?), which is fragile and suddenly makes the
initramfs complex enough to require, err, a dhcp client, different fsck
implementations, and pretty much all that would have been in /bin or
/sbin before the /usr movearounding started. And firmware and kernel
modules, like this it's easy to go >150MB for a compressed initramfs if
you need firmware and a dhcp client to bring up the NFS share with /boot
(hey, with ceph it's even more exciting ...)

"initramfs is the new rootfs" - yeah, that sounds like a good idea,
until you figure out that the initramfs doesn't fit in /boot anymore
(kernels are ~3-4MB each, so 25MB is plenty, eh?) and you need to either
repartition or boot from USB.

And since there was no visible failure mode for us before, of course
some of us are very confused why a reasonable and effective feature got
pruned without replacement. Just because somewhere else it didn't work
100% - that's no reason to remove features for everyone!
>
>>> 2. Many of Gentoo users are programmers who appreciate the 'vanilla'
>>> API experience Gentoo often provides. Switching the defaults to a fork
>>> that is known to intentionally diverge from upstream goes against that
>>> principle. Programs written against eudev may not work correctly with
>>> upstream udev.  
>> If upstream udev were stable, that would be one thing, but it
>> intentionally diverges from itself continuously. The only experience
>> that could be reliably provided with upstream udev is one of continual
>> breakage.
> This is FUD, without any proof.
See your reply to (3) - you disagree with yourself!
>>> 3. eudev has fallen behind systemd/udev more than once in the past,
>>> and caused visible breakage to users this way.  
>> When?
> Whenever we installed new systemd and udev versions, and needed to bump
> the dependency in virtual, and eudev maintainers were nowhere to be
> found.
Which was only needed due to API changes and/or feature removal. Which
is exactly what you claimed didn't happen, so go FUD yourself :)
>
>> Can we also consider all of the times udev broke the boot process
>> because upstream just didn't care about doing changes in a sane way and
>> the people interested in providing the upstream experience delivered on
>> that goal?
> Proof needed.
"Persistent network naming" caused me at least three independent boot
failures -

(1) network device got renamed away from eth0 by default. That's
horrible, why would you change the default like this?!
(If it were an option that I had to consciously turn on it'd be great)

(2) persistent naming only triggers when net link status is up. Thus if
the switch takes more time than the server (which it did) the renaming
did *not* happen, init script looks for en3p7 or whatever but now it's
eth0 again. This means I can't automatically power on systems after
power failure ...

(3) race condition in persistent naming renames on average 2 out of 4 of
the interfaces on bnx2 / bnx2x quad ethernet cards. So you may have
en3p0, eth1, eth2, en3p4 ... or eth0, en3p1, eth3, eth2.

The only available fixes for this are *not* using the persistently buggy
renamer thingy and instead use either MAC-based naming or pass
'net.ifnames=0' on the kernel command line to keep the stable kernel names.

At my current workplace we're stapling it to the MAC address - that way
whenever a NIC fails we need to also change udev config, but at least we
can guarantee which interface is which. Quite useful for server machines
that have between two and six interfaces.

And that's independent of the movearounding - see udev init script:

bins="/sbin/udevd /lib/systemd/systemd-udevd /usr/lib/systemd/systemd-udevd"

I'm not even going to ask why a binary is in /lib when it used to live
in /sbin.

(And I will not point out the wrongness of config in /lib, because
apparently people get upset when the madness is pointed out ... )
>
>>> 4. eudev is underdocumented, and the maintainer admits that 'he sucks
>>> at documenting'. In fact, did anyone even bother to note how far eudev
>>> diverges from upstream udev to this point?  
>> The FreeBSD developers were complaining about how poorly documented udev
>> was well before eudev existed. This is not a regression unless systemd's
>> innovations in replacing documented things with undocumented things made
>> them worse.
> So... replacing thing that has some docs with a thing that has no docs
> and links to docs of udev that aren't exact match for eudev is good?
> Good to know.
>
Having tried to use the systemd 'documentation' -

that's actually progress, having no documentation is better than a
random pile of braindumps. "Read the source", as usual ...

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Michał Górny]

Dnia 17 lutego 2016 09:17:37 CET, Patrick Lauer <patrick@gentoo.org> napisał(a):
>On 02/17/2016 07:37 AM, Michał Górny wrote:
>>
>>>>> * Both udev and eudev have pretty much feature parity, so there
>won't be
>>>>> any user-visible changes
>>>>>
>>>>> * udev upstream strongly discourages standalone udev (without
>systemd)
>>>>> since at least 2012
>>>>>
>>>>> (see for example:
>>>>>
>https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html
>>>>> https://lkml.org/lkml/2012/10/3/618
>>>>> )
>>>>>
>>>>> So it'd be (1) following upstreams recommendations and (2)
>dogfooding
>>>>> our own tools. I don't see any downsides to this :)  
>>>> I'm strongly against this, because:
>>>>
>>>> 1. It is a conflict-induced fork. As such, it will never be merged
>>>> upstream and it will never be supported upstream. In fact, it is
>>>> continually forces to follow upstream changes and adapt to them.
>eudev
>>>> is more likely to break because of the Gentoo developer(s) working
>hard
>>>> to merge upstream changes to their incompatible code.  
>>> That was the entire point of the project. Upstream rejected any
>attempts
>>> to do things that we actually needed and broke things claiming the
>>> distributions were responsible for handling the breakage, so eudev
>was
>>> started on the basis that we needed a project that would ensure that
>>> changes in udev occur in a way that makes sense.
>> What things? Things like 'let's try to spawn this script third time
>in
>> case someone mounted something so that it happens to work this time'?
>> Yes, that old behavior really made sense.
>It did. Not having it made booting a lot more exciting, and exciting is
>bad.

So, to summarize. Random non-repeatable behavior is good. Having repeatable boots is bad and exciting. Because then you can't claim your bugs are not bugs, right?

>
>Now you need to boot before you boot (mount all relevant filesystems
>before starting PID1?), which is fragile and suddenly makes the
>initramfs complex enough to require, err, a dhcp client, different fsck
>implementations, and pretty much all that would have been in /bin or
>/sbin before the /usr movearounding started. And firmware and kernel
>modules, like this it's easy to go >150MB for a compressed initramfs if
>you need firmware and a dhcp client to bring up the NFS share with
>/boot
>(hey, with ceph it's even more exciting ...)
>
>"initramfs is the new rootfs" - yeah, that sounds like a good idea,
>until you figure out that the initramfs doesn't fit in /boot anymore
>(kernels are ~3-4MB each, so 25MB is plenty, eh?) and you need to
>either
>repartition or boot from USB.
>
>And since there was no visible failure mode for us before, of course
>some of us are very confused why a reasonable and effective feature got
>pruned without replacement. Just because somewhere else it didn't work
>100% - that's no reason to remove features for everyone!
>>
>>>> 2. Many of Gentoo users are programmers who appreciate the
>'vanilla'
>>>> API experience Gentoo often provides. Switching the defaults to a
>fork
>>>> that is known to intentionally diverge from upstream goes against
>that
>>>> principle. Programs written against eudev may not work correctly
>with
>>>> upstream udev.  
>>> If upstream udev were stable, that would be one thing, but it
>>> intentionally diverges from itself continuously. The only experience
>>> that could be reliably provided with upstream udev is one of
>continual
>>> breakage.
>> This is FUD, without any proof.
>See your reply to (3) - you disagree with yourself!
>>>> 3. eudev has fallen behind systemd/udev more than once in the past,
>>>> and caused visible breakage to users this way.  
>>> When?
>> Whenever we installed new systemd and udev versions, and needed to
>bump
>> the dependency in virtual, and eudev maintainers were nowhere to be
>> found.
>Which was only needed due to API changes and/or feature removal. Which
>is exactly what you claimed didn't happen, so go FUD yourself :)
>>
>>> Can we also consider all of the times udev broke the boot process
>>> because upstream just didn't care about doing changes in a sane way
>and
>>> the people interested in providing the upstream experience delivered
>on
>>> that goal?
>> Proof needed.
>"Persistent network naming" caused me at least three independent boot
>failures -
>
>(1) network device got renamed away from eth0 by default. That's
>horrible, why would you change the default like this?!
>(If it were an option that I had to consciously turn on it'd be great)
>
>(2) persistent naming only triggers when net link status is up. Thus if
>the switch takes more time than the server (which it did) the renaming
>did *not* happen, init script looks for en3p7 or whatever but now it's
>eth0 again. This means I can't automatically power on systems after
>power failure ...
>
>(3) race condition in persistent naming renames on average 2 out of 4
>of
>the interfaces on bnx2 / bnx2x quad ethernet cards. So you may have
>en3p0, eth1, eth2, en3p4 ... or eth0, en3p1, eth3, eth2.
>
>The only available fixes for this are *not* using the persistently
>buggy
>renamer thingy and instead use either MAC-based naming or pass
>'net.ifnames=0' on the kernel command line to keep the stable kernel
>names.
>
>At my current workplace we're stapling it to the MAC address - that way
>whenever a NIC fails we need to also change udev config, but at least
>we
>can guarantee which interface is which. Quite useful for server
>machines
>that have between two and six interfaces.
>
>And that's independent of the movearounding - see udev init script:
>
>bins="/sbin/udevd /lib/systemd/systemd-udevd
>/usr/lib/systemd/systemd-udevd"
>
>I'm not even going to ask why a binary is in /lib when it used to live
>in /sbin.
>
>(And I will not point out the wrongness of config in /lib, because
>apparently people get upset when the madness is pointed out ... )

The wrongness is relying on any particular location of a daemon. The init system setup needs to know where it is, and that should go along with a package that installs it. Of course, it falls apart if you split scripts apart, then force movearounding to suit your fancy love to the past.

>>
>>>> 4. eudev is underdocumented, and the maintainer admits that 'he
>sucks
>>>> at documenting'. In fact, did anyone even bother to note how far
>eudev
>>>> diverges from upstream udev to this point?  
>>> The FreeBSD developers were complaining about how poorly documented
>udev
>>> was well before eudev existed. This is not a regression unless
>systemd's
>>> innovations in replacing documented things with undocumented things
>made
>>> them worse.
>> So... replacing thing that has some docs with a thing that has no
>docs
>> and links to docs of udev that aren't exact match for eudev is good?
>> Good to know.
>>
>Having tried to use the systemd 'documentation' -
>
>that's actually progress, having no documentation is better than a
>random pile of braindumps. "Read the source", as usual ...


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Michał Górny]

Dnia 17 lutego 2016 05:00:27 CET, Richard Yao <ryao@gentoo.org> napisał(a):
>On 02/08/2016 10:09 PM, Rich Freeman wrote:
>> On Mon, Feb 8, 2016 at 7:58 PM, Anthony G. Basile
><blueness@gentoo.org> wrote:
>>>
>>> what does in-house tool mean?  i'm a gentoo developer but i also
>work
>>> on an upstream project (eudev) that 14 distros use.
>>>
>>> some of the criticism given here are my concerns as well and i've
>>> spoken with the various distros --- slack, parted magic, puppy. 
>they
>>> get what's going on and they still see eudev is the best way forward
>>> for now.  it may not be in the future, but neither will a udev
>>> extracted from a compiled full systemd codebase.
>>
>> How many of those 14 distros have more than 14 users?
>>
>> Look, I get it, some people don't like systemd.  That's fine.
>> However, you have to realize at this point that a non-systemd
>> configuration is anything but mainstream.  There will always be a
>> "poppyseed linux" whose purpose in life seems to be to preserve linux
>> without sysfs or some other obscure practice.  I just think that
>> Gentoo should offer the choice to do those things, but have a more
>> mainstream set of defaults.
>
>The new mainstream is docker. Docker recently switched to Alpine Linux,
>which uses OpenRC+eudev:
>
>https://www.brianchristner.io/docker-is-moving-to-alpine-linux/
>
>That dwarfs whatever marketshare systemd has in the same way that
>Android+iOS dwarfed whatever marketshare Windows has.
>
>If userbase is what matters to you, then OpenRC+eudev won. It is the
>logical choice for those concerned about userbase because that is what
>the Linux ecosystem will be using going forward.
>
>I do not think userbase should be the sole means by which we make
>decisions, but those that think otherwise should now join the
>eudev+OpenRC camp. It has the bigger userbase share going forward.
>
>To put it another way, the war is over. Welcome abroad. :)

Oh, the new thing every cool kid users these days. I have only one question in return: for how long?

Today Alpine uses eudev. But people change, distributions change. One year from now, it may be using systemd.

Today docker uses Alpine. Tomorrow it may use something else. Or even require systemd by design.

Today docker is the cool thing. One year from now, nobody may remember about it. Didn't things like this happen before?

Now, let's extend this to a perspective of few years. What is more likely to be extinct: userbase of eudev or systemd?

>
>>>
>>> it needs to be in the new stage4s to make a bootable system.  imo a
>>> stage4 should be bootable modulo a kernel.
>>>
>>
>> Sure, a stage4 based on systemd makes a lot of sense.  I don't really
>> see the point in leaving a kernel out though - I'd even stick a
>> precompiled one in /boot on top of having the sources installed.  Why
>> not make a stage4 install something that takes all of 5 minutes?
>>
>> I think that offering an eudev-based distro as a default just doesn't
>> make sense in 2016.  I just think the better road to take is to start
>> treating virtual/udev as something that gets installed post-stage3.
>> We can't even get people to agree on vi vs emacs as a default.
>
>We can leave virtual/udev out of stage3, but that doesn't diminish the
>need to select sensible default for the virtual/udev provider.


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alexis Ballier]

On Tue, 16 Feb 2016 23:00:27 -0500
Richard Yao <ryao@gentoo.org> wrote:

> On 02/08/2016 10:09 PM, Rich Freeman wrote:
> > On Mon, Feb 8, 2016 at 7:58 PM, Anthony G. Basile  
> <blueness@gentoo.org> wrote:
> >>
> >> what does in-house tool mean?  i'm a gentoo developer but i also
> >> work on an upstream project (eudev) that 14 distros use.
> >>
> >> some of the criticism given here are my concerns as well and i've
> >> spoken with the various distros --- slack, parted magic, puppy.
> >> they get what's going on and they still see eudev is the best way
> >> forward for now.  it may not be in the future, but neither will a
> >> udev extracted from a compiled full systemd codebase.  
> >
> > How many of those 14 distros have more than 14 users?
> >
> > Look, I get it, some people don't like systemd.  That's fine.
> > However, you have to realize at this point that a non-systemd
> > configuration is anything but mainstream.  There will always be a
> > "poppyseed linux" whose purpose in life seems to be to preserve
> > linux without sysfs or some other obscure practice.  I just think
> > that Gentoo should offer the choice to do those things, but have a
> > more mainstream set of defaults.  
> 
> The new mainstream is docker. Docker recently switched to Alpine
> Linux, which uses OpenRC+eudev:
> 
> https://www.brianchristner.io/docker-is-moving-to-alpine-linux/
> 
> That dwarfs whatever marketshare systemd has in the same way that
> Android+iOS dwarfed whatever marketshare Windows has.
> 
> If userbase is what matters to you, then OpenRC+eudev won. It is the
> logical choice for those concerned about userbase because that is what
> the Linux ecosystem will be using going forward.
> 
> I do not think userbase should be the sole means by which we make
> decisions, but those that think otherwise should now join the
> eudev+OpenRC camp. It has the bigger userbase share going forward.
> 
> To put it another way, the war is over. Welcome abroad. :)

I don't know docker well enough, but an lxc container definitely doesn't
use udev inside the container.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Tue, Feb 16, 2016 at 11:00 PM, Richard Yao <ryao@gentoo.org> wrote:
>
> If userbase is what matters to you, then OpenRC+eudev won. It is the
> logical choice for those concerned about userbase because that is what
> the Linux ecosystem will be using going forward.
>

Uh, if we cared solely about userbase we'd be using upstart.  I'm
pretty sure that there are more chromebooks out there than Docker
containers running Alpine linux.

Do people actually use docker images created by docker?  That seems a
bit like asking the Apache Foundation to build you a website.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Michał Górny]

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

On Tue, 16 Feb 2016 23:41:33 +0100
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> Alexis Ballier schrieb:
> >>> If it's just that, it's not limited to udev, but anything using
> >>> kdbus/bus1, and would mean openrc/${favorite init system} will have
> >>> to do the same thing anyway. But again, almost 2 years is extremely
> >>> old considering all the flux that has been around kbus.  
> >>
> >> OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel
> >> IPC system comes next.  
> >
> > Well, as Lennart wrote it, kbus would have needed some initialisation.
> > Just like we have a dbus init script, openrc would have a kdbus one.
> >  
> >> But if upstream udev makes use of the systemd
> >> userspace interface to the kernel IPC system, then OpenRC would have
> >> to implement the same interface in order to have working udev.  
> >
> > As I understand it, a kernel IPC doesn't need systemd to work. udev
> > might use wrappers from libsystemd, or libbus1, just like we have
> > programs using libv4l or libbluetooth currently.  
> 
> In a follow-up, upstream wrote about how you should only run udev together 
> with systemd, and if you don't want to do that (spelling as in original):
> 
> "we will not support the udev-on-netlink case anymore. I see three options:
> a) fork things, b) live with systemd, c) if hate systemd that much, but
> love udev so much, then implement an alternative userspace for kdbus to
> do initialiuzation/policy/activation."
> https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html
> 
> So it seems a bit more than only initialization is needed.

You're missing the third option which is a sane option, and jump
straight to pitchforks.

As I see it, *if* this becomes a necessity, we're quite like are going
to provide KDBUS parts of systemd the way we provide udev parts right
now. After all, libsystemd-bus will be useful to more applications.

Of course, someone may want to fork that into libebus just for the sake
of renaming.

And after all, as it has already been noted, there are people
interested in maintaining non-systemd userspace for KDBUS. Which is
kinda the obvious choice, unlike forking something.

> >> Also given the close relationship between systemd and udev, there is
> >> no guarantee that supporting other users of kdbus/bus1 will make udev
> >> automagically work. As these two are released together, there is no
> >> reason to have a stable, public API between them.  
> >
> > Yes, which would mean systemd requires matching udev, not the other way
> > around. I'm a bit clueless here: Do you have any pointers on the recent
> > trends on this side ?  
> 
> I have only upstream's statements from 2014. They talk about a kdbus 
> userspace that systemd will provide to udev, which will be necessary for udev 
> to function.
> If and when upstream comes forward with statements about whether udev will 
> only use public and stable API, these concerns could be either dispelled or 
> confirmed.

And here you have my statement, from today:

  I declare that eudev will be discontinued. You should either move to
  systemd, to alternative device manager or fork it. This is your last
  call, Gentoo users!

Now please copy it to slashdot, reddit or whatever cool kids use these
days, and make sure to request at least half of existing eudev users
switch to something else because of the above statement.

Does it matter that I haven't contributed a single line to eudev code?
eudev upstream is Gentoo, and I'm a Gentoo developer. So I'm part of
upstream. Even if I don't touch eudev, I'm part of the upstream.
In fact, I think I even have commit access there!

If Lennart's single statement from 2014 is a reason to use eudev
instead of systemd-udevd, my statement from today is a more important
reason not to use eudev.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Richard Yao]

> On Feb 17, 2016, at 7:43 AM, Michał Górny <mgorny@gentoo.org> wrote:
> 
> On Tue, 16 Feb 2016 23:41:33 +0100
> Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
> 
>> Alexis Ballier schrieb:
>>>>> If it's just that, it's not limited to udev, but anything using
>>>>> kdbus/bus1, and would mean openrc/${favorite init system} will have
>>>>> to do the same thing anyway. But again, almost 2 years is extremely
>>>>> old considering all the flux that has been around kbus.  
>>>> 
>>>> OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel
>>>> IPC system comes next.  
>>> 
>>> Well, as Lennart wrote it, kbus would have needed some initialisation.
>>> Just like we have a dbus init script, openrc would have a kdbus one.
>>> 
>>>> But if upstream udev makes use of the systemd
>>>> userspace interface to the kernel IPC system, then OpenRC would have
>>>> to implement the same interface in order to have working udev.  
>>> 
>>> As I understand it, a kernel IPC doesn't need systemd to work. udev
>>> might use wrappers from libsystemd, or libbus1, just like we have
>>> programs using libv4l or libbluetooth currently.  
>> 
>> In a follow-up, upstream wrote about how you should only run udev together 
>> with systemd, and if you don't want to do that (spelling as in original):
>> 
>> "we will not support the udev-on-netlink case anymore. I see three options:
>> a) fork things, b) live with systemd, c) if hate systemd that much, but
>> love udev so much, then implement an alternative userspace for kdbus to
>> do initialiuzation/policy/activation."
>> https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html
>> 
>> So it seems a bit more than only initialization is needed.
> 
> You're missing the third option which is a sane option, and jump
> straight to pitchforks.
> 
> As I see it, *if* this becomes a necessity, we're quite like are going
> to provide KDBUS parts of systemd the way we provide udev parts right
> now. After all, libsystemd-bus will be useful to more applications.
> 
> Of course, someone may want to fork that into libebus just for the sake
> of renaming.
> 
> And after all, as it has already been noted, there are people
> interested in maintaining non-systemd userspace for KDBUS. Which is
> kinda the obvious choice, unlike forking something.

kdbus is dead. It is fatally flawed and Greg is no longer trying to get it merged as he is not updating his branch for newer kernel versions. If I recall correctly, kdbus was also removed from Fedora and has no distribution backing it anymore.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Michał Górny]

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

On Wed, 17 Feb 2016 07:53:22 -0500
Richard Yao <ryao@gentoo.org> wrote:

> > On Feb 17, 2016, at 7:43 AM, Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > On Tue, 16 Feb 2016 23:41:33 +0100
> > Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
> >   
> >> Alexis Ballier schrieb:  
> >>>>> If it's just that, it's not limited to udev, but anything using
> >>>>> kdbus/bus1, and would mean openrc/${favorite init system} will have
> >>>>> to do the same thing anyway. But again, almost 2 years is extremely
> >>>>> old considering all the flux that has been around kbus.    
> >>>> 
> >>>> OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel
> >>>> IPC system comes next.    
> >>> 
> >>> Well, as Lennart wrote it, kbus would have needed some initialisation.
> >>> Just like we have a dbus init script, openrc would have a kdbus one.
> >>>   
> >>>> But if upstream udev makes use of the systemd
> >>>> userspace interface to the kernel IPC system, then OpenRC would have
> >>>> to implement the same interface in order to have working udev.    
> >>> 
> >>> As I understand it, a kernel IPC doesn't need systemd to work. udev
> >>> might use wrappers from libsystemd, or libbus1, just like we have
> >>> programs using libv4l or libbluetooth currently.    
> >> 
> >> In a follow-up, upstream wrote about how you should only run udev together 
> >> with systemd, and if you don't want to do that (spelling as in original):
> >> 
> >> "we will not support the udev-on-netlink case anymore. I see three options:
> >> a) fork things, b) live with systemd, c) if hate systemd that much, but
> >> love udev so much, then implement an alternative userspace for kdbus to
> >> do initialiuzation/policy/activation."
> >> https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html
> >> 
> >> So it seems a bit more than only initialization is needed.  
> > 
> > You're missing the third option which is a sane option, and jump
> > straight to pitchforks.
> > 
> > As I see it, *if* this becomes a necessity, we're quite like are going
> > to provide KDBUS parts of systemd the way we provide udev parts right
> > now. After all, libsystemd-bus will be useful to more applications.
> > 
> > Of course, someone may want to fork that into libebus just for the sake
> > of renaming.
> > 
> > And after all, as it has already been noted, there are people
> > interested in maintaining non-systemd userspace for KDBUS. Which is
> > kinda the obvious choice, unlike forking something.  
> 
> kdbus is dead. It is fatally flawed and Greg is no longer trying to get it merged as he is not updating his branch for newer kernel versions. If I recall correctly, kdbus was also removed from Fedora and has no distribution backing it anymore.

Then... why are we even discussing this?

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Richard Yao]

> On Feb 17, 2016, at 7:25 AM, Rich Freeman <rich0@gentoo.org> wrote:
> 
>> On Tue, Feb 16, 2016 at 11:00 PM, Richard Yao <ryao@gentoo.org> wrote:
>> 
>> If userbase is what matters to you, then OpenRC+eudev won. It is the
>> logical choice for those concerned about userbase because that is what
>> the Linux ecosystem will be using going forward.
> 
> Uh, if we cared solely about userbase we'd be using upstart.  I'm
> pretty sure that there are more chromebooks out there than Docker
> containers running Alpine linux.
> 
> Do people actually use docker images created by docker?

They do. Docker is popular because it enables developers to start microservices from prebuilt images. Those images by default are Alpine Linux, which means anything using udev in them is using eudev.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alexis Ballier]

On Wed, 17 Feb 2016 13:58:51 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> On Wed, 17 Feb 2016 07:53:22 -0500
> Richard Yao <ryao@gentoo.org> wrote:
> 
> > > On Feb 17, 2016, at 7:43 AM, Michał Górny <mgorny@gentoo.org>
> > > wrote:
> > > 
> > > On Tue, 16 Feb 2016 23:41:33 +0100
> > > Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
> > >     
> > >> Alexis Ballier schrieb:    
> > >>>>> If it's just that, it's not limited to udev, but anything
> > >>>>> using kdbus/bus1, and would mean openrc/${favorite init
> > >>>>> system} will have to do the same thing anyway. But again,
> > >>>>> almost 2 years is extremely old considering all the flux that
> > >>>>> has been around kbus.      
> > >>>> 
> > >>>> OpenRC itself can for now just ignore kdbus, bus1, or whatever
> > >>>> kernel IPC system comes next.      
> > >>> 
> > >>> Well, as Lennart wrote it, kbus would have needed some
> > >>> initialisation. Just like we have a dbus init script, openrc
> > >>> would have a kdbus one. 
> > >>>> But if upstream udev makes use of the systemd
> > >>>> userspace interface to the kernel IPC system, then OpenRC
> > >>>> would have to implement the same interface in order to have
> > >>>> working udev.      
> > >>> 
> > >>> As I understand it, a kernel IPC doesn't need systemd to work.
> > >>> udev might use wrappers from libsystemd, or libbus1, just like
> > >>> we have programs using libv4l or libbluetooth currently.      
> > >> 
> > >> In a follow-up, upstream wrote about how you should only run
> > >> udev together with systemd, and if you don't want to do that
> > >> (spelling as in original):
> > >> 
> > >> "we will not support the udev-on-netlink case anymore. I see
> > >> three options: a) fork things, b) live with systemd, c) if hate
> > >> systemd that much, but love udev so much, then implement an
> > >> alternative userspace for kdbus to do
> > >> initialiuzation/policy/activation."
> > >> https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html
> > >> 
> > >> So it seems a bit more than only initialization is needed.    
> > > 
> > > You're missing the third option which is a sane option, and jump
> > > straight to pitchforks.
> > > 
> > > As I see it, *if* this becomes a necessity, we're quite like are
> > > going to provide KDBUS parts of systemd the way we provide udev
> > > parts right now. After all, libsystemd-bus will be useful to more
> > > applications.
> > > 
> > > Of course, someone may want to fork that into libebus just for
> > > the sake of renaming.
> > > 
> > > And after all, as it has already been noted, there are people
> > > interested in maintaining non-systemd userspace for KDBUS. Which
> > > is kinda the obvious choice, unlike forking something.    
> > 
> > kdbus is dead. It is fatally flawed and Greg is no longer trying to
> > get it merged as he is not updating his branch for newer kernel
> > versions. If I recall correctly, kdbus was also removed from Fedora
> > and has no distribution backing it anymore.  
> 
> Then... why are we even discussing this?
> 

because s/kdbus/bus1/

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Chí-Thanh Christopher Nguyễn]

Michał Górny schrieb:
>> In a follow-up, upstream wrote about how you should only run udev together
>> with systemd, and if you don't want to do that (spelling as in original):
>>
>> "we will not support the udev-on-netlink case anymore. I see three options:
>> a) fork things, b) live with systemd, c) if hate systemd that much, but
>> love udev so much, then implement an alternative userspace for kdbus to
>> do initialiuzation/policy/activation."
>> https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html
>>
>> So it seems a bit more than only initialization is needed.
> You're missing the third option which is a sane option, and jump
> straight to pitchforks.

Are you serious? The quoted line directly above your comment shows 
clearly that I have read and understood the third option.

> If Lennart's single statement from 2014 is a reason to use eudev
> instead of systemd-udevd, my statement from today is a more important
> reason not to use eudev.

With the exception that Lennart Poettering is the lead developer of 
systemd/udev, while such a thing cannot be said about you and eudev.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Richard Yao]

> On Feb 17, 2016, at 5:34 AM, Michał Górny <mgorny@gentoo.org> wrote:
> 
> Dnia 17 lutego 2016 05:00:27 CET, Richard Yao <ryao@gentoo.org> napisał(a):
>>> On 02/08/2016 10:09 PM, Rich Freeman wrote:
>>> On Mon, Feb 8, 2016 at 7:58 PM, Anthony G. Basile
>> <blueness@gentoo.org> wrote:
>>>> 
>>>> what does in-house tool mean?  i'm a gentoo developer but i also
>> work
>>>> on an upstream project (eudev) that 14 distros use.
>>>> 
>>>> some of the criticism given here are my concerns as well and i've
>>>> spoken with the various distros --- slack, parted magic, puppy.
>> they
>>>> get what's going on and they still see eudev is the best way forward
>>>> for now.  it may not be in the future, but neither will a udev
>>>> extracted from a compiled full systemd codebase.
>>> 
>>> How many of those 14 distros have more than 14 users?
>>> 
>>> Look, I get it, some people don't like systemd.  That's fine.
>>> However, you have to realize at this point that a non-systemd
>>> configuration is anything but mainstream.  There will always be a
>>> "poppyseed linux" whose purpose in life seems to be to preserve linux
>>> without sysfs or some other obscure practice.  I just think that
>>> Gentoo should offer the choice to do those things, but have a more
>>> mainstream set of defaults.
>> 
>> The new mainstream is docker. Docker recently switched to Alpine Linux,
>> which uses OpenRC+eudev:
>> 
>> https://www.brianchristner.io/docker-is-moving-to-alpine-linux/
>> 
>> That dwarfs whatever marketshare systemd has in the same way that
>> Android+iOS dwarfed whatever marketshare Windows has.
>> 
>> If userbase is what matters to you, then OpenRC+eudev won. It is the
>> logical choice for those concerned about userbase because that is what
>> the Linux ecosystem will be using going forward.
>> 
>> I do not think userbase should be the sole means by which we make
>> decisions, but those that think otherwise should now join the
>> eudev+OpenRC camp. It has the bigger userbase share going forward.
>> 
>> To put it another way, the war is over. Welcome abroad. :)
> 
> Oh, the new thing every cool kid users these days. I have only one question in return: for how long?
> 
> Today Alpine uses eudev. But people change, distributions change. One year from now, it may be using systemd.
> 
> Today docker uses Alpine. Tomorrow it may use something else. Or even require systemd by design.

The Alpine Linux developers use eudev where mdev is a pain to use and prefer mdev to it. They also prefer busybox init to just about everything else. The only way Alpine Linux would use systemd is if it were merged into busybox, but the busybox developers dropped systemd support last year because the systemd developers were not great at collaborating. The "busybox is a joke" remarks that I got from them before that happen means that they have been actively sabotaging that relationship for a long time.

I think it is safe to assume that Redhat will drop Linux for Windows before Alpine Linux uses systemd.

> Today docker is the cool thing. One year from now, nobody may remember about it. Didn't things like this happen before?

The iPhone did the same thing to Windows. Then Android came along. Neither contribute to Windows hemomgeny, which is dead. The same is true for systemd. Coincidentally, neither Android nor iOS use systemd.

> Now, let's extend this to a perspective of few years. What is more likely to be extinct: userbase of eudev or systemd?

systemd will always have its niche. The same is true for eudev. The latter will always exist as long the the former exists though as there are too many people who have been alienated by systemd development for them to accept a system running it.

That is unlikely that will change unless developers who the systemd developers alienate were to all die at once.

>>>> 
>>>> it needs to be in the new stage4s to make a bootable system.  imo a
>>>> stage4 should be bootable modulo a kernel.
>>> 
>>> Sure, a stage4 based on systemd makes a lot of sense.  I don't really
>>> see the point in leaving a kernel out though - I'd even stick a
>>> precompiled one in /boot on top of having the sources installed.  Why
>>> not make a stage4 install something that takes all of 5 minutes?
>>> 
>>> I think that offering an eudev-based distro as a default just doesn't
>>> make sense in 2016.  I just think the better road to take is to start
>>> treating virtual/udev as something that gets installed post-stage3.
>>> We can't even get people to agree on vi vs emacs as a default.
>> 
>> We can leave virtual/udev out of stage3, but that doesn't diminish the
>> need to select sensible default for the virtual/udev provider.
> 
> 
> -- 
> Best regards,
> Michał Górny (by phone)
> 

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Richard Yao]

> On Feb 17, 2016, at 1:37 AM, Michał Górny <mgorny@gentoo.org> wrote:
> 
> On Tue, 16 Feb 2016 21:54:31 -0500
> Richard Yao <ryao@gentoo.org> wrote:
> 
>>> On 02/08/2016 07:46 AM, Michał Górny wrote:
>>> On Mon, 8 Feb 2016 10:08:22 +0100
>>> Patrick Lauer <patrick@gentoo.org> wrote:
>>> 
>>>> Ohey,
>>>> 
>>>> I've opened a bug at:
>>>> https://bugs.gentoo.org/show_bug.cgi?id=573922
>>>> 
>>>> The idea here is to change the order of the providers of virtual/udev.
>>>> For existing installs this has zero impact.
>>>> For stage3 this would mean that eudev is pulled in instead of udev.
>>>> 
>>>> The rationale behind this is:
>>>> 
>>>> * eudev is an in-house fork, and there's more than a dozen distros
>>>> already using it by default that are not us. Which is a little bit weird ...  
>>> 
>>> That's not an argument. I can also fork random system components. Would
>>> you consider that a reason to replace the defaults with our 'in-house'
>>> forks?
>>> 
>>>> * Both udev and eudev have pretty much feature parity, so there won't be
>>>> any user-visible changes
>>>> 
>>>> * udev upstream strongly discourages standalone udev (without systemd)
>>>> since at least 2012
>>>> 
>>>> (see for example:
>>>> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html
>>>> https://lkml.org/lkml/2012/10/3/618
>>>> )
>>>> 
>>>> So it'd be (1) following upstreams recommendations and (2) dogfooding
>>>> our own tools. I don't see any downsides to this :)  
>>> 
>>> I'm strongly against this, because:
>>> 
>>> 1. It is a conflict-induced fork. As such, it will never be merged
>>> upstream and it will never be supported upstream. In fact, it is
>>> continually forces to follow upstream changes and adapt to them. eudev
>>> is more likely to break because of the Gentoo developer(s) working hard
>>> to merge upstream changes to their incompatible code.  
>> 
>> That was the entire point of the project. Upstream rejected any attempts
>> to do things that we actually needed and broke things claiming the
>> distributions were responsible for handling the breakage, so eudev was
>> started on the basis that we needed a project that would ensure that
>> changes in udev occur in a way that makes sense.
> 
> What things? Things like 'let's try to spawn this script third time in
> case someone mounted something so that it happens to work this time'?
> Yes, that old behavior really made sense.
> 
>>> 2. Many of Gentoo users are programmers who appreciate the 'vanilla'
>>> API experience Gentoo often provides. Switching the defaults to a fork
>>> that is known to intentionally diverge from upstream goes against that
>>> principle. Programs written against eudev may not work correctly with
>>> upstream udev.  
>> 
>> If upstream udev were stable, that would be one thing, but it
>> intentionally diverges from itself continuously. The only experience
>> that could be reliably provided with upstream udev is one of continual
>> breakage.
> 
> This is FUD, without any proof.

That kind of breakage is the reason eudev exists. If it did not occur, I would have not organized people to start eudev a few years ago. Part of the motivation was inflicted by the sys-fs/udev maintainers at the time, but systemd upstream did it's fair share by rejecting compatibility patches on the basis that only downstream should handle those. eudev was founded to be that downstream and also be upstream as sys-fs/udev refused to take patches that systemd would not take.
> 
>> 
>>> 3. eudev has fallen behind systemd/udev more than once in the past,
>>> and caused visible breakage to users this way.  
>> 
>> When?
> 
> Whenever we installed new systemd and udev versions, and needed to bump
> the dependency in virtual, and eudev maintainers were nowhere to be
> found.
> 
>> Can we also consider all of the times udev broke the boot process
>> because upstream just didn't care about doing changes in a sane way and
>> the people interested in providing the upstream experience delivered on
>> that goal?
> 
> Proof needed.

Go back and look at logs of me talking to WilliamH and talking in #systemd in the year before eudev was founded. There were problems with separate user among others. By the time, eudev was started, it was a wonder why it was not started earlier.
> 
>>> 4. eudev is underdocumented, and the maintainer admits that 'he sucks
>>> at documenting'. In fact, did anyone even bother to note how far eudev
>>> diverges from upstream udev to this point?  
>> 
>> The FreeBSD developers were complaining about how poorly documented udev
>> was well before eudev existed. This is not a regression unless systemd's
>> innovations in replacing documented things with undocumented things made
>> them worse.
> 
> So... replacing thing that has some docs with a thing that has no docs
> and links to docs of udev that aren't exact match for eudev is good?
> Good to know.

What documentation do you mean? As far as I know, udev documentation had always been nearly non-existent. Just ask the FreeBSD developers who have been looking for documentation so that they could reimplement it in a clean room manner for years.

If you would like to see that change, you could start writing documentation.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Michał Górny]

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

On Wed, 17 Feb 2016 14:09:57 +0100
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> Michał Górny schrieb:
> >> In a follow-up, upstream wrote about how you should only run udev together
> >> with systemd, and if you don't want to do that (spelling as in original):
> >>
> >> "we will not support the udev-on-netlink case anymore. I see three options:
> >> a) fork things, b) live with systemd, c) if hate systemd that much, but
> >> love udev so much, then implement an alternative userspace for kdbus to
> >> do initialiuzation/policy/activation."
> >> https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html
> >>
> >> So it seems a bit more than only initialization is needed.  
> > You're missing the third option which is a sane option, and jump
> > straight to pitchforks.  
> 
> Are you serious? The quoted line directly above your comment shows 
> clearly that I have read and understood the third option.
> 
> > If Lennart's single statement from 2014 is a reason to use eudev
> > instead of systemd-udevd, my statement from today is a more important
> > reason not to use eudev.  
> 
> With the exception that Lennart Poettering is the lead developer of 
> systemd/udev, while such a thing cannot be said about you and eudev.

He's lead developer of *systemd*. udev is a split part of systemd
codebase which has specific maintainers.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Chí-Thanh Christopher Nguyễn]

Michał Górny schrieb:
>> With the exception that Lennart Poettering is the lead developer of
>> systemd/udev, while such a thing cannot be said about you and eudev.
> He's lead developer of *systemd*. udev is a split part of systemd
> codebase which has specific maintainers.

systemd and udev share the same codebase. You can no longer build udev 
without systemd. udev is only a sub-project of systemd now, hence the 
name "systemd-udevd".


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Richard Yao]

> On Feb 17, 2016, at 7:58 AM, Michał Górny <mgorny@gentoo.org> wrote:
> 
> On Wed, 17 Feb 2016 07:53:22 -0500
> Richard Yao <ryao@gentoo.org> wrote:
> 
>>> On Feb 17, 2016, at 7:43 AM, Michał Górny <mgorny@gentoo.org> wrote:
>>> 
>>> On Tue, 16 Feb 2016 23:41:33 +0100
>>> Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
>>> 
>>>> Alexis Ballier schrieb:  
>>>>>>> If it's just that, it's not limited to udev, but anything using
>>>>>>> kdbus/bus1, and would mean openrc/${favorite init system} will have
>>>>>>> to do the same thing anyway. But again, almost 2 years is extremely
>>>>>>> old considering all the flux that has been around kbus.    
>>>>>> 
>>>>>> OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel
>>>>>> IPC system comes next.    
>>>>> 
>>>>> Well, as Lennart wrote it, kbus would have needed some initialisation.
>>>>> Just like we have a dbus init script, openrc would have a kdbus one.
>>>>> 
>>>>>> But if upstream udev makes use of the systemd
>>>>>> userspace interface to the kernel IPC system, then OpenRC would have
>>>>>> to implement the same interface in order to have working udev.    
>>>>> 
>>>>> As I understand it, a kernel IPC doesn't need systemd to work. udev
>>>>> might use wrappers from libsystemd, or libbus1, just like we have
>>>>> programs using libv4l or libbluetooth currently.    
>>>> 
>>>> In a follow-up, upstream wrote about how you should only run udev together 
>>>> with systemd, and if you don't want to do that (spelling as in original):
>>>> 
>>>> "we will not support the udev-on-netlink case anymore. I see three options:
>>>> a) fork things, b) live with systemd, c) if hate systemd that much, but
>>>> love udev so much, then implement an alternative userspace for kdbus to
>>>> do initialiuzation/policy/activation."
>>>> https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html
>>>> 
>>>> So it seems a bit more than only initialization is needed.  
>>> 
>>> You're missing the third option which is a sane option, and jump
>>> straight to pitchforks.
>>> 
>>> As I see it, *if* this becomes a necessity, we're quite like are going
>>> to provide KDBUS parts of systemd the way we provide udev parts right
>>> now. After all, libsystemd-bus will be useful to more applications.
>>> 
>>> Of course, someone may want to fork that into libebus just for the sake
>>> of renaming.
>>> 
>>> And after all, as it has already been noted, there are people
>>> interested in maintaining non-systemd userspace for KDBUS. Which is
>>> kinda the obvious choice, unlike forking something.  
>> 
>> kdbus is dead. It is fatally flawed and Greg is no longer trying to get it merged as he is not updating his branch for newer kernel versions. If I recall correctly, kdbus was also removed from Fedora and has no distribution backing it anymore.
> 
> Then... why are we even discussing this?

I have no idea why we are even discussing the choice of default for virtual/udev to have subdiscussions about kdbus. Practically everyone on the list thinks eudev is the best choice. From the perspective of the Linux community going forward through docker, eudev is the only sensible choice for a udev-based system for those that want to use the same code everyone else uses.

All arguments about systemd are akin to arguments about how Windows 10 is the next thing in desktops in a world dominated by POSIX through iOS and Android. Coincidentally, neither use systemd.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[M. J. Everitt]

On 17/02/16 13:38, Chí-Thanh Christopher Nguyễn wrote:
> Michał Górny schrieb:
>>> With the exception that Lennart Poettering is the lead developer of
>>> systemd/udev, while such a thing cannot be said about you and eudev.
>> He's lead developer of *systemd*. udev is a split part of systemd
>> codebase which has specific maintainers.
>
> systemd and udev share the same codebase. You can no longer build udev
> without systemd. udev is only a sub-project of systemd now, hence the
> name "systemd-udevd".
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
>
How hard is it to understand that there really is no longer a standalone
udev .. it's part of another project .. therefore no longer separate.
One of the developers already works for systemd. The other is clearly
busy with kernel coding.

My two cents for today:

https://en.wikipedia.org/wiki/Udev
http://without-systemd.org/wiki/index.php/Main_Page

+5 for Chi-Thanh for keeping it factual and objective.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Richard Yao]

> On Feb 17, 2016, at 5:52 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> 
> On Tue, 16 Feb 2016 23:00:27 -0500
> Richard Yao <ryao@gentoo.org> wrote:
> 
>>> On 02/08/2016 10:09 PM, Rich Freeman wrote:
>>> On Mon, Feb 8, 2016 at 7:58 PM, Anthony G. Basile  
>> <blueness@gentoo.org> wrote:
>>>> 
>>>> what does in-house tool mean?  i'm a gentoo developer but i also
>>>> work on an upstream project (eudev) that 14 distros use.
>>>> 
>>>> some of the criticism given here are my concerns as well and i've
>>>> spoken with the various distros --- slack, parted magic, puppy.
>>>> they get what's going on and they still see eudev is the best way
>>>> forward for now.  it may not be in the future, but neither will a
>>>> udev extracted from a compiled full systemd codebase.  
>>> 
>>> How many of those 14 distros have more than 14 users?
>>> 
>>> Look, I get it, some people don't like systemd.  That's fine.
>>> However, you have to realize at this point that a non-systemd
>>> configuration is anything but mainstream.  There will always be a
>>> "poppyseed linux" whose purpose in life seems to be to preserve
>>> linux without sysfs or some other obscure practice.  I just think
>>> that Gentoo should offer the choice to do those things, but have a
>>> more mainstream set of defaults.  
>> 
>> The new mainstream is docker. Docker recently switched to Alpine
>> Linux, which uses OpenRC+eudev:
>> 
>> https://www.brianchristner.io/docker-is-moving-to-alpine-linux/
>> 
>> That dwarfs whatever marketshare systemd has in the same way that
>> Android+iOS dwarfed whatever marketshare Windows has.
>> 
>> If userbase is what matters to you, then OpenRC+eudev won. It is the
>> logical choice for those concerned about userbase because that is what
>> the Linux ecosystem will be using going forward.
>> 
>> I do not think userbase should be the sole means by which we make
>> decisions, but those that think otherwise should now join the
>> eudev+OpenRC camp. It has the bigger userbase share going forward.
>> 
>> To put it another way, the war is over. Welcome abroad. :)
> 
> I don't know docker well enough, but an lxc container definitely doesn't
> use udev inside the container.

There really is no point to running udev inside the container, but if you do run udev in an Alpine Linux docker container, you get eudev.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Ben Kohler]

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

On Wed, Feb 17, 2016 at 7:39 AM, Richard Yao <ryao@gentoo.org> wrote:
>
>
> I have no idea why we are even discussing the choice of default for
> virtual/udev to have subdiscussions about kdbus. Practically everyone on
> the list thinks eudev is the best choice.
>

I think a lot of us appreciate that eudev exists as a lifeboat or backup
plan, but want to wait until there's a real, obvious, technical reason to
switch.  MOST of the reasons given have just been vague predictions of
future doom and gloom.  And if we dare ask for more technical reasons, we
get berated for being a "systemd lover".

"Let's wait until udev becomes unusable" doesn't seem that unreasonable to
me, and it has nothing to do with being pro or anti systemd.

-Ben

[-- Attachment #2: Type: text/html, Size: 1188 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Richard Yao]

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


> On Feb 17, 2016, at 8:47 AM, Ben Kohler <bkohler@gmail.com> wrote:
> 
> 
> 
>> On Wed, Feb 17, 2016 at 7:39 AM, Richard Yao <ryao@gentoo.org> wrote:
>> 
>> I have no idea why we are even discussing the choice of default for virtual/udev to have subdiscussions about kdbus. Practically everyone on the list thinks eudev is the best choice.
> 
> I think a lot of us appreciate that eudev exists as a lifeboat or backup plan, but want to wait until there's a real, obvious, technical reason to switch.  MOST of the reasons given have just been vague predictions of future doom and gloom.  And if we dare ask for more technical reasons, we get berated for being a "systemd lover".
> 
> "Let's wait until udev becomes unusable" doesn't seem that unreasonable to me, and it has nothing to do with being pro or anti systemd.

eudev has every commit scrutinized by people who care about using it on Gentoo. systemd-udev does not. Consequently, eudev has avoided the system boot breaking regressions that prompted its creation. That is a good reason to make it the new default. If it fails to fulfill its duties, then this could be revisited, but that should be unlikely.

> 
> -Ben
> 

[-- Attachment #2: Type: text/html, Size: 2000 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Ben Kohler]

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

On Wed, Feb 17, 2016 at 7:55 AM, Richard Yao <ryao@gentoo.org> wrote:

>
>
> eudev has every commit scrutinized by people who care about using it on
> Gentoo. systemd-udev does not. Consequently, eudev has avoided the system
> boot breaking regressions that prompted its creation. That is a good reason
> to make it the new default. If it fails to fulfill its duties, then this
> could be revisited, but that should be unlikely.
>
> I think if someone could enumerate those specific breakages and present it
as evidence, that could get more people on board for this change.  Moreso
than just "upstream doesn't care about us" or "eventually split udev will
be impossible".

-Ben

[-- Attachment #2: Type: text/html, Size: 1110 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Richard Yao]

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


> On Feb 17, 2016, at 9:01 AM, Ben Kohler <bkohler@gmail.com> wrote:
> 
> 
> 
>> On Wed, Feb 17, 2016 at 7:55 AM, Richard Yao <ryao@gentoo.org> wrote:
>> 
>> 
>> eudev has every commit scrutinized by people who care about using it on Gentoo. systemd-udev does not. Consequently, eudev has avoided the system boot breaking regressions that prompted its creation. That is a good reason to make it the new default. If it fails to fulfill its duties, then this could be revisited, but that should be unlikely.
> I think if someone could enumerate those specific breakages and present it as evidence, that could get more people on board for this change.  Moreso than just "upstream doesn't care about us" or "eventually split udev will be impossible".

That would require more time than I have to give right now. Hopefully someone else could go through the old bug reports and IRC logs to find those records.

> -Ben

[-- Attachment #2: Type: text/html, Size: 1712 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Richard Yao]

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



> On Feb 17, 2016, at 9:41 AM, Richard Yao <ryao@gentoo.org> wrote:
> 
> 
>> On Feb 17, 2016, at 9:01 AM, Ben Kohler <bkohler@gmail.com> wrote:
>> 
>> 
>> 
>>> On Wed, Feb 17, 2016 at 7:55 AM, Richard Yao <ryao@gentoo.org> wrote:
>>> 
>>> 
>>> eudev has every commit scrutinized by people who care about using it on Gentoo. systemd-udev does not. Consequently, eudev has avoided the system boot breaking regressions that prompted its creation. That is a good reason to make it the new default. If it fails to fulfill its duties, then this could be revisited, but that should be unlikely.
>> I think if someone could enumerate those specific breakages and present it as evidence, that could get more people on board for this change.  Moreso than just "upstream doesn't care about us" or "eventually split udev will be impossible".
> 
> That would require more time than I have to give right now. Hopefully someone else could go through the old bug reports and IRC logs to find those records.

I forgot to mention commit histories. The change log on CVS for sys-fs/udev should provide information on things that were broken for long spans of time if the causes of the fixes are scrutinized while commits to eudev fixing things that were broken (and likely still are) would also document things. At least some of the early ones under my name were rejected by systemd. They went into eudev when it was created.
> 
>> -Ben

[-- Attachment #2: Type: text/html, Size: 2465 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[brettrsears]

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

 
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Ben Kohler <bkohler@gmail.com>
Date: Wed, 17 Feb 2016 08:01:32 
To: <gentoo-dev@lists.gentoo.org>
Reply-to: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Changing order of default virtual/udev provider

On Wed, Feb 17, 2016 at 7:55 AM, Richard Yao <ryao@gentoo.org> wrote:

>
>
> eudev has every commit scrutinized by people who care about using it on
> Gentoo. systemd-udev does not. Consequently, eudev has avoided the system
> boot breaking regressions that prompted its creation. That is a good reason
> to make it the new default. If it fails to fulfill its duties, then this
> could be revisited, but that should be unlikely.
>
> I think if someone could enumerate those specific breakages and present it
as evidence, that could get more people on board for this change.  Moreso
than just "upstream doesn't care about us" or "eventually split udev will
be impossible".

-Ben


[-- Attachment #2: Type: text/html, Size: 1676 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Richard Yao]

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

On 02/17/2016 09:54 AM, brettrsears@gmail.com wrote:
>  
> Sent from my Verizon Wireless BlackBerry
> 
> -----Original Message-----
> From: Ben Kohler <bkohler@gmail.com>
> Date: Wed, 17 Feb 2016 08:01:32 
> To: <gentoo-dev@lists.gentoo.org>
> Reply-to: gentoo-dev@lists.gentoo.org
> Subject: Re: [gentoo-dev] Changing order of default virtual/udev provider
> 
> On Wed, Feb 17, 2016 at 7:55 AM, Richard Yao <ryao@gentoo.org> wrote:
> 
>>
>>
>> eudev has every commit scrutinized by people who care about using it on
>> Gentoo. systemd-udev does not. Consequently, eudev has avoided the system
>> boot breaking regressions that prompted its creation. That is a good reason
>> to make it the new default. If it fails to fulfill its duties, then this
>> could be revisited, but that should be unlikely.
>>
>> I think if someone could enumerate those specific breakages and present it
> as evidence, that could get more people on board for this change.  Moreso
> than just "upstream doesn't care about us" or "eventually split udev will
> be impossible".
> 
> -Ben
> 

This is something that I think many of us who had systems broken by
sys-fs/udev multiple times before sys-fs/eudev was an option thought was
obvious.

If a complete list of the breakages that lead to the creation of
sys-fs/eudev were produced, I imagine that the list would have at least
3 to 5 items from the ~18 months before sys-fs/eudev with half of them
were probably self inflicted by sys-fs/udev maintenance.

I recall one incident involving whether udev should be in /sbin or
/usr/sbin being resolved after 6 months of debate between then future
eudev founders and sys-fs/udev maintainers only because the systemd
developers told the sys-fs/udev maintainers it should be in /sbin like
others had told them.

Another broke support for older kernels for no apparent benefit (and
this sort of regression naturally enters sys-fs/udev):

https://github.com/gentoo/eudev/commit/eeb8d70a6b38f736febaa4c3b03e39b4c1193a6c

There were other issues too, but I am unable to volunteer the time
required to go through history to figure out what was broken, when and
for how long.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Michał Górny]

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

On Wed, 17 Feb 2016 14:38:05 +0100
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> Michał Górny schrieb:
> >> With the exception that Lennart Poettering is the lead developer of
> >> systemd/udev, while such a thing cannot be said about you and eudev.  
> > He's lead developer of *systemd*. udev is a split part of systemd
> > codebase which has specific maintainers.  
> 
> systemd and udev share the same codebase. You can no longer build udev 
> without systemd. udev is only a sub-project of systemd now, hence the 
> name "systemd-udevd".

Of course, sure. But since you seem not to be able to understand
basics: this *does not* mean Lennart is the only person having
influence on how udev progresses. Sharing the same repository
and utility libraries is not the same as being the same thing.

Much like the Council does not strictly force the development of eudev.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Richard Yao]

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

On 02/17/2016 11:16 AM, Michał Górny wrote:
> On Wed, 17 Feb 2016 14:38:05 +0100
> Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
> 
>> Michał Górny schrieb:
>>>> With the exception that Lennart Poettering is the lead developer of
>>>> systemd/udev, while such a thing cannot be said about you and eudev.  
>>> He's lead developer of *systemd*. udev is a split part of systemd
>>> codebase which has specific maintainers.  
>>
>> systemd and udev share the same codebase. You can no longer build udev 
>> without systemd. udev is only a sub-project of systemd now, hence the 
>> name "systemd-udevd".
> 
> Of course, sure. But since you seem not to be able to understand
> basics: this *does not* mean Lennart is the only person having
> influence on how udev progresses. Sharing the same repository
> and utility libraries is not the same as being the same thing.
> 
> Much like the Council does not strictly force the development of eudev.
> 

According to _AxS_, there are very few differences between systemd-udev
and eudev at the present time:

16:14 <@_AxS_> At this point there really aren't much in terms of
differences -- most of the code is the same as upstream, but the file
structure is different and obviously the build system is proper and
standalone.  There's the rule-generator patchset but otherwise
               things are pretty well the same iirc.
16:14 <@_AxS_> We *did* have a bunch of other things in eudev that
improved matters for older kernels or just general code/memory
improvements, but those have since been integrated upstream iirc
16:15 <@ryao> _AxS_: I recall hearing that eudev regressed with respect
to 2.6.32. If the older versions were not good enough and I had time, I
would try fixing that.
16:16 <@ryao> _AxS_: It is interesting to hear that patches to support
older kernels are now being merged by them. Kay told me that such
patches would not be merged.
16:18 <@_AxS_> ryao: eudev-3.x doesn't support the older kernels, true.
 However we determined that was ok because (1) the older kernels like
openvz have had the appropriate functionality backported into them, and
(2) we're keeping the older eudev versions around.

The main differences at this time seem to be the rule-generator patchset
for users who like that, a better build system (what IcedTea is to
OpenJDK) and a stricter process for getting newer code. Specifically,
instead of just doing a revision bump with the implicit assumption that
it was tested, every change is reviewed and committed to a repository
that is tagged independently of systemd-udev.

If there are regressions because of something upstream did, which has
occurred in the past, and they made it into eudev, there is someone who
accepted the commit that is responsible for it. They should not only
have caught it, but they also should have put a plan in place for
dealing with it like was done with the regressed kernel version support.
If they did not, then the eudev project can revise its QA strategies to
ensure that it does not happen again. That is something that can only be
rigorously done with a separate project that imports code from a vendor
like FreeBSD does, which is precisely what eudev is.

That is clearly better than what we have with sys-fs/udev. Given that
the two are almost identical with sys-fs/eudev being better suited for
systems where PID 1 is not systemd, there really is no point in having
sys-fs/udev be the first provider for virtual/udev. There is also no
point in having sys-fs/udev become a separate package from systemd,
unless we decide to break every component of systemd from the part meant
to be PID 1 too, but that is contrary to what systemd upstream recommends.

If making sys-fs/eudev the default virtual/udev provider turns out to be
a bad decision, we can always revisit it, but it seems better than the
status quo that we have now. Having less review of new code is bad and
having systemd-udev split from the systemd package on systems that use
systemd makes no sense. If we continue having the split, systemd would
depend on sys-fs/udev and consequently the systemd profiles with systemd
in @system would be unaffected by whatever the provider order happens to be.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Wed, Feb 17, 2016 at 11:04 AM, Richard Yao <ryao@gentoo.org> wrote:
>
> This is something that I think many of us who had systems broken by
> sys-fs/udev multiple times before sys-fs/eudev was an option thought was
> obvious.

About the only "system-breaking" change I'm aware of in udev over the
years was the change in default network interface names.  That was
preceded by news on how to avoid the change, or how to adapt to the
change.

There certainly wasn't some change introduced without warning that
just broke systems in random ways.

> If a complete list of the breakages that lead to the creation of
> sys-fs/eudev were produced, I imagine that the list would have at least
> 3 to 5 items from the ~18 months before sys-fs/eudev with half of them
> were probably self inflicted by sys-fs/udev maintenance.

Anytime upstream changes something it is up to package maintainers to
evaluate the change and adapt to it as needed, especially for critical
packages like udev.  For the most part I think this is happening.
Whether it is the udev maintainers doing the QA or the eudev
maintainers doing the QA, somebody has to do the QA (and in Gentoo it
sounds like we do it twice, which is fine).

> I recall one incident involving whether udev should be in /sbin or
> /usr/sbin being resolved after 6 months of debate between then future
> eudev founders and sys-fs/udev maintainers only because the systemd
> developers told the sys-fs/udev maintainers it should be in /sbin like
> others had told them.

So, this sounds like a disagreement between the future eudev founders
and the udev maintainers in Gentoo.  It really has nothing to do with
udev itself.

And that is OK - we're allowed to have the same package maintained
under two different names by two sets of maintainers.  Obviously it
isn't ideal, and it would be better if everybody could agree.

> Another broke support for older kernels for no apparent benefit (and
> this sort of regression naturally enters sys-fs/udev):

That isn't really the same as "breaking Gentoo."  And as was pointed
out they did accept patches to provide support back.

I think it is a bit unfair to characterize the udev maintainers as
breaking things left and right.  They apparently differ with you in
how they prefer to set their defaults, and what their dependencies
are.  They apparently also accept patches when you provide them for
older kernels, which is what upstreams are supposed to do.

It really seems like the main reasons for eudev's existence right now
are (based on this thread):
1.  The eudev maintainers don't trust the udev maintainer's QA and
want to do their own layer of QA before introducing changes to the
tree.
2.  The eudev maintainers prefer a different default network interface
naming scheme (my understanding is that eudev can be configured to
behave as udev does by default, and vice-versa - for example, on the
box I'm typing this on my packets are going out over eth0 just fine on
systemd).
3.  The eudev tarballs are smaller lacking the systemd components, and
the udev build system doesn't have to build the systemd components (I
don't think the same is true of udev but I could be wrong).

I'm not saying that eudev should go away, or that these concerns are
completely inappropriate.  If somebody wanted to fork their own kernel
stable series and carefully curate patches they could choose to do so
and package it in Gentoo, and give it different default configuration
options, and so on.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Chí-Thanh Christopher Nguyễn]

Michał Górny schrieb:
>> systemd and udev share the same codebase. You can no longer build udev
>> without systemd. udev is only a sub-project of systemd now, hence the
>> name "systemd-udevd".
>
> Of course, sure. But since you seem not to be able to understand
> basics: this *does not* mean Lennart is the only person having
> influence on how udev progresses. Sharing the same repository
> and utility libraries is not the same as being the same thing.

Ok, apparently I am too dense to understand that the someone who is the lead 
developer and visionary of a project naturally has the same say as someone 
who is only bickering from the sidelines. Maybe if you had pointed out a 
systemd developer who disagreed with Lennart's words I could have seen the 
light earlier.

Also I am obviously unable to understand that when the kernel folks 
complained about the "new maintainers" of udev breaking things, they would of 
course never suspect that these "new maintainers" have anything to do with 
systemd at all.

http://thread.gmane.org/gmane.linux.kernel/1368617

Seriously. You gave good reasons why udev should remain the default over 
eudev, I acknowledged as much already. But do not continue the path of 
labelling your opponents as stupid and their arguments as FUD, because this 
is clearly not the case. It really doesn't help your argument, it just makes 
you look bad.



Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/17/2016 04:43 AM, Michał Górny wrote:
> 
> [snip]
> 
> If Lennart's single statement from 2014 is a reason to use eudev 
> instead of systemd-udevd, my statement from today is a more
> important reason not to use eudev.
> 

That's kind of a false equivalence. Unlike Lennart, you are not the
primary developer or maintainer of what your (sarcastic) claim
indicates. Lennart's "single statement" has been backed up with every
large change made to systemd or udev. With each change, it becomes
more strongly coupled and that much harder to separate. Regardless of
my or others' feelings on Lennart, he *has* acted on things he's said
in that regard, and it's foolish to assume udev without systemd will
remain an option.

If Anthony had said that instead, I and many others would have reason
for concern and likely respond by migrating, again, to something else.
While you and I are part of Gentoo and thus somewhat 'upstream' to
eudev users, we aren't active on the project (to my knowledge; from
what I gather you're a systemd user and have no interest in eudev; I
have interest but no relevant experience/skill). I hope I was able to
explain the difference.

Rich made a good point that maybe we shouldn't act until udev simply
stops working. I'd prefer a more proactive approach, but I see the
merit in waiting.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWxQ4cAAoJEAEkDpRQOeFwGwIP/Rdw0Y6E+94bZNMCw+CfIveX
bb32aqkIDiXIsJjYAdYnglwhWff4DpUy8hW6VJchV6O1avU3m7FL3FZ1y3Z0GQOy
lkMprvahBqTwpcjCObtyWjAizJsdRyB4YcU1rUli4x30WG9exmQI2xTY2c2hz1fW
BKfjq7HGn/gPT8FPlHEhRVwB52HQDC0u5dHM7PKr1mrwBTMwc+1we16i0G+zNT4e
E/HcPjo7z6MbGHQNJ596GEm9PUXM/WDK85xYAeH1T3ILT1df+bBaq11v8c37Su5f
QkUqFsmCQuPNKbY99IwHEreiq0UeqwBoJmjIsVcn+sIs9ZhjXy71+3drUVC7iE5u
4lgPyaDLBWNP3+4stj4bsqwGGU7i2mei21Sk3kK19PcOyaCPsj2Oo/ohr6+yTN6C
yESh0vkQMZf5+5PSABDiczRIRtD8U0e5HrfBDs1gLxXblUTPk9PnOhlwDUipdN0y
pBcQ++BrOcQjDosnyQP4jRJjqodKuPZow+oqgW+SaQ5RVAlTz8K16Dm17KNfIc6k
Dm8dbmtaCNO6cZZUPuTHT8jSihlB2gclFR1ALZvfDjb3ghYmwy8uGxiec4x5abvj
0gVlXCP41jblNSXM+Q9EWCj+ICTVc0DbGPshPZ96p7XtetttKk6gdf+PcQ1UDzaa
UJFt2emel44zfnlQKY+f
=D8/l
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Richard Yao]

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

On 02/17/2016 01:47 PM, Rich Freeman wrote:
> On Wed, Feb 17, 2016 at 11:04 AM, Richard Yao <ryao@gentoo.org> wrote:
>>
>> This is something that I think many of us who had systems broken by
>> sys-fs/udev multiple times before sys-fs/eudev was an option thought was
>> obvious.
> 
> About the only "system-breaking" change I'm aware of in udev over the
> years was the change in default network interface names.  That was
> preceded by news on how to avoid the change, or how to adapt to the
> change.
> 
> There certainly wasn't some change introduced without warning that
> just broke systems in random ways.
> 
>> If a complete list of the breakages that lead to the creation of
>> sys-fs/eudev were produced, I imagine that the list would have at least
>> 3 to 5 items from the ~18 months before sys-fs/eudev with half of them
>> were probably self inflicted by sys-fs/udev maintenance.
> 
> Anytime upstream changes something it is up to package maintainers to
> evaluate the change and adapt to it as needed, especially for critical
> packages like udev.  For the most part I think this is happening.
> Whether it is the udev maintainers doing the QA or the eudev
> maintainers doing the QA, somebody has to do the QA (and in Gentoo it
> sounds like we do it twice, which is fine).
> 
>> I recall one incident involving whether udev should be in /sbin or
>> /usr/sbin being resolved after 6 months of debate between then future
>> eudev founders and sys-fs/udev maintainers only because the systemd
>> developers told the sys-fs/udev maintainers it should be in /sbin like
>> others had told them.
> 
> So, this sounds like a disagreement between the future eudev founders
> and the udev maintainers in Gentoo.  It really has nothing to do with
> udev itself.

That is just one thing that I remembered off the top of my head and
quite frankly, that situation was the most absurd system breakage
incident that ever occurred involving udev. The arguments by the
sys-fs/udev maintainers at the time were that upstream wanted it that
way when even the systemd developers did not agree with them. The matter
was only resolved after one of the sys-fs/udev maintainers decided to
ask the systemd developers what they actually thought after 6 months of
claiming their way was the upstream way and were told that they thought
the packaging was wrong. Everyone else had believed the sys-fs/udev
maintainers' statements that upstream actually thought such things, and
consequently, were adamant that the systemd maintainers had no idea what
they were doing.

There were multiple breakages caused by sys-fs/udev maintainance
following systemd assimilating udev based on the principle that upstream
wanted it that way. The outsourcing of responsibility for thought on
such things were one of the things that contributed to eudev's creation.
Another were absolute refusal by Kay Sievers at the time to fix
regressions when given patches. It was not "rewrite the patch this way".
It was along the lines of "we are not fixing that because we don't care
about people affected by this and fixing that would add 40 lines to the
codebase".

> And that is OK - we're allowed to have the same package maintained
> under two different names by two sets of maintainers.  Obviously it
> isn't ideal, and it would be better if everybody could agree.
> 
>> Another broke support for older kernels for no apparent benefit (and
>> this sort of regression naturally enters sys-fs/udev):
> 
> That isn't really the same as "breaking Gentoo."  And as was pointed
> out they did accept patches to provide support back.

That is a new development.

> I think it is a bit unfair to characterize the udev maintainers as
> breaking things left and right.  They apparently differ with you in
> how they prefer to set their defaults, and what their dependencies
> are.  They apparently also accept patches when you provide them for
> older kernels, which is what upstreams are supposed to do.

There were multiple incidents where either the sys-fs/udev maintainers
or the systemd developers refused to listen to reason. Systems broke
because of it and there were no warnings.

> It really seems like the main reasons for eudev's existence right now
> are (based on this thread):
> 1.  The eudev maintainers don't trust the udev maintainer's QA and
> want to do their own layer of QA before introducing changes to the
> tree.
> 2.  The eudev maintainers prefer a different default network interface
> naming scheme (my understanding is that eudev can be configured to
> behave as udev does by default, and vice-versa - for example, on the
> box I'm typing this on my packets are going out over eth0 just fine on
> systemd).
> 3.  The eudev tarballs are smaller lacking the systemd components, and
> the udev build system doesn't have to build the systemd components (I
> don't think the same is true of udev but I could be wrong).
> 
> I'm not saying that eudev should go away, or that these concerns are
> completely inappropriate.  If somebody wanted to fork their own kernel
> stable series and carefully curate patches they could choose to do so
> and package it in Gentoo, and give it different default configuration
> options, and so on.

That is a false equivalence because:

1. We have plenty of sys-kernel/*-sources packages, but Gentoo has no
true default because the user must pick a package.
2. Both mainline and the Gentoo kernel team do a decent job of not
breaking things and fix them promptely when things do break. There are
no drawn out arguments or debates about why things should be broken in
lieu of fixing things when them being broken has been recognized.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Mon, Feb 8, 2016 at 4:08 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> Ohey,
>
> I've opened a bug at:
> https://bugs.gentoo.org/show_bug.cgi?id=573922
>
> The idea here is to change the order of the providers of virtual/udev.
> For existing installs this has zero impact.
> For stage3 this would mean that eudev is pulled in instead of udev.
>

Since this has utterly stalled and private emails were also unable to
resolve the deadlock I have requested a council decision one way or
the other:
https://bugs.gentoo.org/show_bug.cgi?id=575718

Most likely we'll issue one before the next meeting.  There is no need
to regurgitate this thread.  If somebody has something NEW to say feel
free, but we'll make a decision one way or another soon.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alexis Ballier]

On Fri, 26 Feb 2016 07:31:28 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Feb 8, 2016 at 4:08 AM, Patrick Lauer <patrick@gentoo.org>
> wrote:
> > Ohey,
> >
> > I've opened a bug at:
> > https://bugs.gentoo.org/show_bug.cgi?id=573922
> >
> > The idea here is to change the order of the providers of
> > virtual/udev. For existing installs this has zero impact.
> > For stage3 this would mean that eudev is pulled in instead of udev.
> >  
> 
> Since this has utterly stalled and private emails were also unable to
> resolve the deadlock I have requested a council decision one way or
> the other:
> https://bugs.gentoo.org/show_bug.cgi?id=575718
> 
> Most likely we'll issue one before the next meeting.  There is no need
> to regurgitate this thread.  If somebody has something NEW to say feel
> free, but we'll make a decision one way or another soon.


I think it'd be nice to have a summary of all the arguments used
against or for switching the default

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Fri, Feb 26, 2016 at 7:31 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Mon, Feb 8, 2016 at 4:08 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>> Ohey,
>>
>> I've opened a bug at:
>> https://bugs.gentoo.org/show_bug.cgi?id=573922
>>
>> The idea here is to change the order of the providers of virtual/udev.
>> For existing installs this has zero impact.
>> For stage3 this would mean that eudev is pulled in instead of udev.
>>
>
> Since this has utterly stalled and private emails were also unable to
> resolve the deadlock I have requested a council decision one way or
> the other:
> https://bugs.gentoo.org/show_bug.cgi?id=575718
>
> Most likely we'll issue one before the next meeting.  There is no need
> to regurgitate this thread.  If somebody has something NEW to say feel
> free, but we'll make a decision one way or another soon.
>

The council has approved the following decision 7-0:

"In light of the support for eudev among Gentoo non-systemd users, and
a lack of strong technical drivers to block a change, the Council
approves changing the default virtual/udev provider for non-systemd
users to eudev. The council encourages all maintainers to try to
support either provider and cooperate with those who provide patches
when necessary."

I'd recommend that the eudev team implement the change and communicate
vs just having a stampede for the virtual...

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Patrick Lauer]

On 02/08/2016 10:08 AM, Patrick Lauer wrote:
> Ohey,
>
> I've opened a bug at:
> https://bugs.gentoo.org/show_bug.cgi?id=573922
>
> The idea here is to change the order of the providers of virtual/udev.
> For existing installs this has zero impact.
> For stage3 this would mean that eudev is pulled in instead of udev.
>
>
Council vote on it was 7:0 in favour:
https://bugs.gentoo.org/show_bug.cgi?id=575718

The change has been committed.