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.

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

[Rich Freeman]

On Fri, Feb 26, 2016 at 7:31 AM, Rich Freeman  wrote:
> On Mon, Feb 8, 2016 at 4: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.
>>
>
> 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

[Alexis Ballier]

On Fri, 26 Feb 2016 07:31:28 -0500
Rich Freeman  wrote:

> On Mon, Feb 8, 2016 at 4: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.
> >  
> 
> 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 Mon, Feb 8, 2016 at 4: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.
>

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

[Richard Yao]

On 02/17/2016 01:47 PM, Rich Freeman wrote:
> On Wed, Feb 17, 2016 at 11:04 AM, Richard Yao  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 wan

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

[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

[Rich Freeman]

On Wed, Feb 17, 2016 at 11:04 AM, Richard Yao  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

[Richard Yao]

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



signature.asc
Description: OpenPGP digital signature

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

[Michał Górny]

On Wed, 17 Feb 2016 14:38:05 +0100
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".

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



pgp4CI5xpRJhX.pgp
Description: OpenPGP digital signature

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

[Richard Yao]

On 02/17/2016 09:54 AM, brettrse...@gmail.com wrote:
>  
> Sent from my Verizon Wireless BlackBerry
> 
> -Original Message-
> From: Ben Kohler 
> Date: Wed, 17 Feb 2016 08:01:32 
> To: 
> 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  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.



signature.asc
Description: OpenPGP digital signature

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

[brettrsears]

 
Sent from my Verizon Wireless BlackBerry

-Original Message-
From: Ben Kohler 
Date: Wed, 17 Feb 2016 08:01:32 
To: 
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  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

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

[Richard Yao]

> On Feb 17, 2016, at 9:41 AM, Richard Yao  wrote:
> 
> 
>> On Feb 17, 2016, at 9:01 AM, Ben Kohler  wrote:
>> 
>> 
>> 
>>> On Wed, Feb 17, 2016 at 7:55 AM, Richard Yao  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

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

[Richard Yao]

> On Feb 17, 2016, at 9:01 AM, Ben Kohler  wrote:
> 
> 
> 
>> On Wed, Feb 17, 2016 at 7:55 AM, Richard Yao  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

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

[Ben Kohler]

On Wed, Feb 17, 2016 at 7:55 AM, Richard Yao  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

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

[Richard Yao]

> On Feb 17, 2016, at 8:47 AM, Ben Kohler  wrote:
> 
> 
> 
>> On Wed, Feb 17, 2016 at 7:39 AM, Richard Yao  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
> 

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

[Ben Kohler]

On Wed, Feb 17, 2016 at 7:39 AM, Richard Yao  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

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

[Richard Yao]

> On Feb 17, 2016, at 5:52 AM, Alexis Ballier  wrote:
> 
> On Tue, 16 Feb 2016 23:00:27 -0500
> Richard Yao  wrote:
> 
>>> On 02/08/2016 10:09 PM, Rich Freeman wrote:
>>> On Mon, Feb 8, 2016 at 7:58 PM, Anthony G. Basile  
>>  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

[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 7:58 AM, Michał Górny  wrote:
> 
> On Wed, 17 Feb 2016 07:53:22 -0500
> Richard Yao  wrote:
> 
>>> On Feb 17, 2016, at 7:43 AM, Michał Górny  wrote:
>>> 
>>> On Tue, 16 Feb 2016 23:41:33 +0100
>>> Chí-Thanh Christopher Nguyễn  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

[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

[Michał Górny]

On Wed, 17 Feb 2016 14:09:57 +0100
Chí-Thanh Christopher Nguyễn  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



pgpMpi_G7A2Pi.pgp
Description: OpenPGP digital signature

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

[Richard Yao]

> On Feb 17, 2016, at 1:37 AM, Michał Górny  wrote:
> 
> On Tue, 16 Feb 2016 21:54:31 -0500
> Richard Yao  wrote:
> 
>>> On 02/08/2016 07:46 AM, Michał Górny wrote:
>>> On Mon, 8 Feb 2016 10:08:22 +0100
>>> 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 
 ...  
>>> 
>>> 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 wh

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

[Richard Yao]

> On Feb 17, 2016, at 5:34 AM, Michał Górny  wrote:
> 
> Dnia 17 lutego 2016 05:00:27 CET, Richard Yao  napisał(a):
>>> On 02/08/2016 10:09 PM, Rich Freeman wrote:
>>> On Mon, Feb 8, 2016 at 7:58 PM, Anthony G. Basile
>>  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

[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

[Alexis Ballier]

On Wed, 17 Feb 2016 13:58:51 +0100
Michał Górny  wrote:

> On Wed, 17 Feb 2016 07:53:22 -0500
> Richard Yao  wrote:
> 
> > > On Feb 17, 2016, at 7:43 AM, Michał Górny 
> > > wrote:
> > > 
> > > On Tue, 16 Feb 2016 23:41:33 +0100
> > > Chí-Thanh Christopher Nguyễn  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

[Richard Yao]

> On Feb 17, 2016, at 7:25 AM, Rich Freeman  wrote:
> 
>> On Tue, Feb 16, 2016 at 11:00 PM, Richard Yao  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

[Michał Górny]

On Wed, 17 Feb 2016 07:53:22 -0500
Richard Yao  wrote:

> > On Feb 17, 2016, at 7:43 AM, Michał Górny  wrote:
> > 
> > On Tue, 16 Feb 2016 23:41:33 +0100
> > Chí-Thanh Christopher Nguyễn  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



pgp_8h5x6FqVM.pgp
Description: OpenPGP digital signature

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

[Richard Yao]

> On Feb 17, 2016, at 7:43 AM, Michał Górny  wrote:
> 
> On Tue, 16 Feb 2016 23:41:33 +0100
> Chí-Thanh Christopher Nguyễn  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]

On Tue, 16 Feb 2016 23:41:33 +0100
Chí-Thanh Christopher Nguyễn  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



pgpQTNn24wD65.pgp
Description: OpenPGP digital signature

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

[Rich Freeman]

On Tue, Feb 16, 2016 at 11:00 PM, Richard Yao  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

[Alexis Ballier]

On Tue, 16 Feb 2016 23:00:27 -0500
Richard Yao  wrote:

> On 02/08/2016 10:09 PM, Rich Freeman wrote:
> > On Mon, Feb 8, 2016 at 7:58 PM, Anthony G. Basile  
>  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

[Michał Górny]

Dnia 17 lutego 2016 05:00:27 CET, Richard Yao  napisał(a):
>On 02/08/2016 10:09 PM, Rich Freeman wrote:
>> On Mon, Feb 8, 2016 at 7:58 PM, Anthony G. Basile
> 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

[Michał Górny]

Dnia 17 lutego 2016 09:17:37 CET, Patrick Lauer  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 e

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

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

[Michał Górny]

On Tue, 16 Feb 2016 21:54:31 -0500
Richard Yao  wrote:

> On 02/08/2016 07:46 AM, Michał Górny wrote:
> > On Mon, 8 Feb 2016 10:08:22 +0100
> > 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 
> >> ...  
> > 
> > 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



pgpcEYu26Ye6V.pgp
Description: OpenPGP digital signature

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

[Richard Yao]

On 02/08/2016 10:09 PM, Rich Freeman wrote:
> On Mon, Feb 8, 2016 at 7:58 PM, Anthony G. Basile
 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.



signature.asc
Description: OpenPGP digital signature

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

[Richard Yao]

On 02/08/2016 07:46 AM, Michał Górny wrote:
> On Mon, 8 Feb 2016 10:08:22 +0100
> 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 ...
> 
> 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.



signature.asc
Description: OpenPGP digital signature

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

[Richard Yao]

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



signature.asc
Description: OpenPGP digital signature

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

[Brian Dolbec]

On Tue, 16 Feb 2016 23:16:41 +0100
Michał Górny  wrote:

> On Tue, 16 Feb 2016 20:57:31 +0100
> Patrick Lauer  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 



pgpFDfuOoylwW.pgp
Description: OpenPGP digital signature

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

[Alexis Ballier]

On Tue, 16 Feb 2016 23:16:41 +0100
Michał Górny  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

[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

[Michał Górny]

On Tue, 16 Feb 2016 20:57:31 +0100
Patrick Lauer  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



pgprrnVox_mV3.pgp
Description: OpenPGP digital signature

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

[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

[Brian Dolbec]

On Tue, 16 Feb 2016 15:26:46 -0500
"Anthony G. Basile"  wrote:

> On 2/16/16 3:05 PM, Rich Freeman wrote:
> > On Tue, Feb 16, 2016 at 2:57 PM, Patrick Lauer 
> > 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 

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

[Alexis Ballier]

On Tue, 16 Feb 2016 15:09:23 -0500
Rich Freeman  wrote:

> On Tue, Feb 16, 2016 at 1:34 PM, Chí-Thanh Christopher Nguyễn
>  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

[Anthony G. Basile]

On 2/16/16 3:05 PM, Rich Freeman wrote:
> On Tue, Feb 16, 2016 at 2:57 PM, Patrick Lauer  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: bluen...@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 16, 2016 at 1:34 PM, Chí-Thanh Christopher Nguyễn
 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

[Alexis Ballier]

On Tue, 16 Feb 2016 20:33:55 +0100
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.
> 
> 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 2:57 PM, Patrick Lauer  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:14:03 +0100
Chí-Thanh Christopher Nguyễn  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

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

[Michał Górny]

On Tue, 16 Feb 2016 20:14:03 +0100
Chí-Thanh Christopher Nguyễn  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



pgp9m0EQxaIJ1.pgp
Description: OpenPGP digital signature

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

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

[Alexis Ballier]

On Tue, 16 Feb 2016 19:34:20 +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.

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]

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

[William Hubbs]

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



signature.asc
Description: Digital signature

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

[Alexis Ballier]

On Tue, 16 Feb 2016 11:45:41 -0600
William Hubbs  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
> >  wrote:  
> > > On Sun, 14 Feb 2016 19:34:52 -0600
> > > William Hubbs  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

[William Hubbs]

On Mon, Feb 15, 2016 at 07:11:26AM -0500, Rich Freeman wrote:
> On Mon, Feb 15, 2016 at 4:29 AM, Alexis Ballier  wrote:
> > On Sun, 14 Feb 2016 19:34:52 -0600
> > William Hubbs  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



signature.asc
Description: Digital signature

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

[Mike Frysinger]

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


signature.asc
Description: Digital signature

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

[Francesco Riosa]

2016-02-14 21:23 GMT+01:00 Mike Frysinger :

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

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

[Rich Freeman]

On Mon, Feb 15, 2016 at 4:29 AM, Alexis Ballier  wrote:
> On Sun, 14 Feb 2016 19:34:52 -0600
> William Hubbs  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

[Lars Wendler]

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


pgpcf9zp1NjJS.pgp
Description: Digitale Signatur von OpenPGP

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

[Alexis Ballier]

On Sun, 14 Feb 2016 19:34:52 -0600
William Hubbs  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

[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

[Mike Frysinger]

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


signature.asc
Description: Digital signature

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]

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


signature.asc
Description: Digital signature

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

[William Hubbs]

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



signature.asc
Description: Digital signature

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

[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: bluen...@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]

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


signature.asc
Description: Digital signature

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

[Mike Frysinger]

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


signature.asc
Description: Digital signature

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: bluen...@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: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: bluen...@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]

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


signature.asc
Description: Digital signature

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

[Mike Frysinger]

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


signature.asc
Description: Digital signature

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

[Rich Freeman]

On Sun, Feb 14, 2016 at 3:31 PM, Alon Bar-Lev  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

[Rich Freeman]

On Sun, Feb 14, 2016 at 3:27 PM, Patrick Lauer  wrote:
> On 02/14/2016 09:17 PM, Rich Freeman wrote:
>> On Sun, Feb 14, 2016 at 2:41 PM, 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...
>> 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

[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

[Alon Bar-Lev]

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.

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:17 PM, Rich Freeman wrote:
> On Sun, Feb 14, 2016 at 2:41 PM, 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...
> 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

[Mike Frysinger]

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


signature.asc
Description: Digital signature

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

[Rich Freeman]

On Sun, Feb 14, 2016 at 2:41 PM, 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...

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

[Brian Dolbec]

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

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 

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

[Rich Freeman]

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.

-- 
Rich

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

[Patrick Lauer]

On 02/09/2016 01:17 PM, Rich Freeman wrote:
> On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric  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 )

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

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

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

[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 
I don't run "desktop environments"; I run useful applications

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

:-)  :-) 

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