Since this is directed at, and obviously concerns Gentoo users, I thought I'd post the link here in order to get some feedback and discussion on what this portends for the average user, if anything. Basically they seem to be saying:

Quote:

"So using upstream udev will not be supported without using systemd. Lennart called out the Gentoo developers due to their eudev fork of udev."

I'm running 4 Gentoo installs with openRC, but do have a systemd Gentoo partition operational for about 6 months, so I am getting familiar with systemd, and kind of anticipating that eventually openRC might become more and more problematic as more packages require systemd. Hope that's not the case, as openRC works fine. On the other hand, I can also say that systemd works fine, too. I guess if one prefers a binary distro, none of this really matters.

Will any current or future udev/systemd/kdbus/openRC complexities really be no big deal with the Gentoo devs sorting it out, or will it become an ongoing nightmare of constant user intervention, recompiles, reinstalls, configuration misunderstandings, etc. just to keep your system booting? Will openRC gradually be phased out of existence? Will systemd really become the default linux init method? I guess we'll all just have to stay tuned._________________Main box- Gigabyte GIGABYTE GA-990FXA-UD3 AM3+ rev.-4.0
Amd FX 8320, 3.5 GHz, 16GB GSkill DDR3 1866mhz
Samsung SATA 1000GB, Radeon HD 6570 2GB DDR3
Gentoo ~x86, ~amd64, glibc-2.20-r1, gcc-4.9.2 kernel-3.19.0-gentoo (USE=experimental "native")

So based on assurances from ssuominen I've been sticking with udev so far, based on the his plan to maintain it as usable in a non-systemd environment.

Looks like upstream is forcing the issue.

I've got 30+ years in the VLSI CAD arena, much of that time as an early adopter. One thing I've learned over the years is that if a better tool becomes available, meaning that it does the job better, is more reliable, is easier to use, doesn't require onerous setup, etc - the users will pick it up on their own. Merit wins.

Personally I see some merit to systemd, but I also see some things I don't like, so for me caution is called for. The attitudes of the L.P. fanbois don't help a bit, but they're secondary. Over the years fellow VLSI CAD users have resented being forced onto some tool or other, and right now I resent systemd in exactly the same way._________________.sigs waste space and bandwidth

Since this is directed at, and obviously concerns Gentoo users, I thought I'd post the link here in order to get some feedback and discussion on what this portends for the average user, if anything. Basically they seem to be saying:

Quote:

"So using upstream udev will not be supported without using systemd. Lennart called out the Gentoo developers due to their eudev fork of udev."

And some of us saw this coming and have been trying to warn people for a while about it.
Not that it's done any good, all we've heard is excuses and "it'll never happen".
Looks like some people will be eating their words...real soon.

Well, I'm a happy user of eudev, and if need be will just switch to a static dev.
I don't need the aggravation of RH, LP and all the falderal out of them._________________Asus m5a99fx, FX 8320 - amd64-multilib, 3.15.9-zen, glibc-2.19, gcc-4.9.2, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4(2011)

On the contrary, this seems like a wakeup call to every other distro that hasn't planned an escape route (eudev) from RedHat's One Gnome Future™ ahead of this inevitability. Gentoo is business as usual.

So based on assurances from ssuominen I've been sticking with udev so far, based on the his plan to maintain it as usable in a non-systemd environment.

Looks like upstream is forcing the issue.

They can never force sys-fs/udev *ebuild in Gentoo* to somehow pull in systemd, so you don't have anything to worry about, despite of what upstream does.
If such time comes patchset will become unmaintainable in sys-fs/udev, there will be a Portage news item, and a migration path, that may or may not be
sys-fs/eudev.

I've been using Olde Fashioned Gentooee since udev got sucked into the systemd tarball, it was clear to me then that udev only had a limited future.
It mostly just works, but there are a few things to work out._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

And here you get to see how the guy keeping udev going really feels about systemd: "I wouldn't mind systemd becoming the Gentoo default, as I see systemd becoming the norm in Linux userspace, but that hasn't happened yet, and migration will need time."

So, we Gentoo users have to be guided gently into the SystemD pen. Goodnight nurse!

And here you get to see how the guy keeping udev going really feels about systemd: "I wouldn't mind systemd becoming the Gentoo default, as I see systemd becoming the norm in Linux userspace, but that hasn't happened yet, and migration will need time."

So, we Gentoo users have to be guided gently into the SystemD pen. Goodnight nurse!

I have OpenRC+Linux, OpenRC+FreeBSD, systemd+Linux, and few even more odd systems. I don't like one over the another. I have no plans in installing systemd on the OpenRC based
ones even if *others* change systemd to be the default.
So, if you tried to be sarcastic, you really lost me there.

Last edited by ssuominen on Mon Jul 07, 2014 6:53 pm; edited 1 time in total

Well, it seems to me it was less than a year ago that Poettering was jumping up and down swearing this would never happen. Now he flat out admits that stand alone udev support is intended to be dropped and migrated into systemd. And I can't say that Poettering's maturity level has impressed me during this entire thing. His response has been like a 6 year old being told that he needs to share and that not everyone wants to play in his gnome sandbox.

As for software depending on what /dev you use, maybe he hasn't been paying attention but there is no sane reason any userspace application should care how the entries in /dev are made. There is also no sane reason to break your API every few months when the good idea fairy comes to call.

EDIT: @ssuominen I think your taking the entire discussion too personally. I believe most people appreciate what you do. We are simply frustrated at the way upstream is behaving and developing._________________First things first, but not necessarily in that order.

And here you get to see how the guy keeping udev going really feels about systemd: "I wouldn't mind systemd becoming the Gentoo default, as I see systemd becoming the norm in Linux userspace, but that hasn't happened yet, and migration will need time."

So, we Gentoo users have to be guided gently into the SystemD pen. Goodnight nurse!

Seems to be intended but it won't work out that way, despite the constant agitation of Poetterings fifth column in Gentoo.
We will not drink the kool-aid. Never.

I find it strange that some of the devs seem to want to shut down any discussion on the subject of udev/systemd.

What is wrong with people discussing this relatively important subject?
Is there some vested interest in keeping discussion on these things verboten?
Does RH/LP pay someone to keep these things from being discussed?

I think that since a dev that works on udev for gentoo was also making posts on
the phoronix thread that these things shouldn't be swept under the rug or kept secret.
That is if there is nothing for them to hide.

If the devs don't like these types of discussions, then why even click on these threads?????_________________Asus m5a99fx, FX 8320 - amd64-multilib, 3.15.9-zen, glibc-2.19, gcc-4.9.2, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4(2011)

last i heard Linus wasnt going to allow kdbus in the kernel till systemd was proven stable._________________A process cannot be understood by stopping it. Understanding must move with the flow of the process, must join it and flow with it.

I find it strange that some of the devs seem to want to shut down any discussion on the subject of udev/systemd.

What is wrong with people discussing this relatively important subject?
Is there some vested interest in keeping discussion on these things verboten?
Does RH/LP pay someone to keep these things from being discussed?

Why? Such shutdown has no effect; systemd is resounding everywhere by everyone,
up to a level that it convinces quite some developers to keep other init systems working.

Discussion isn't wrong, but it could be better than that as a discussion alone yields little results;
a movement beyond that is needed for bringing a future "we will not drink the kool-aid" up to scale.

wrc1944 wrote:

Will any current or future udev/systemd/kdbus/openRC complexities really be no big deal with the Gentoo devs sorting it out, or will it become an ongoing nightmare of constant user intervention, recompiles, reinstalls, configuration misunderstandings, etc. just to keep your system booting? Will openRC gradually be phased out of existence? Will systemd really become the default linux init method? I guess we'll all just have to stay tuned.

Given that upstream's changes imply much more work downstream,
these questions depend on how much we as a community contribute.

Ages ago, daydream mumbling about a bridge causes people to ignore you;
when a bridge was finally built by a few men, people became impressed.

One small step for man, ...

Anon-E-moose wrote:

If the devs don't like these types of discussions, then why even click on these threads?????

Given that upstream's changes imply much more work downstream, these questions depend on how much we as a community contribute.

TomWij ... we've invested far too much equity already (remember some of us have been supporting linux since the very beginning, and our contribution has been a major factor in making linux a viable OS and community) ... and why should we invest further in supporting an upstream, nay, our own "community", who piss in the water supply? You may have forgotten my detailed interrogation of this very subject, but did I not say that the introduction of systemd into the tree was a de-facto "fork" and that "we can no longer speak about gentoo as one entity"?

"The community" (sic) can point to upstream and say "there maketh the decision" but it wasn't upstream that provided tacit support by following the program ... and ... presenting the inclusion of systemd as about providing "choice". No one can claim that this outcome is surprising, Lennart stated as much back in Aug 2012 ... but "we" helped make that a reality because whenever this was mentioned, and the implications pointed out, the pointer was called a "systemd-hater", or accused of promoting an "anti-systemd religion" or having a "religious agenda", making the forums a "warzone", etc, etc. You yourself presented "the fading away of the idea of a default [init]" which I challenged for ignoring the reality of what certain "choices" will entail.

That cool-aid isn't cool-aid ... its urine, it doesn't matter if you want to drink it or not, its the state of the water supply. Everyone who subscribed to the "choice" to piss in the water can look to their neighbour and say "its your choice to drink it ... or not".

last i heard Linus wasnt going to allow kdbus in the kernel till systemd was proven stable.

Then you should look for better sources of what you hear. All that happened is that Linus refuses to take patches from Kay Sievers into the kernel until Sievers starts fixing his own bugs instead of blaming other projects.

khayyam, that is a turnaround of words; it instead highlights the Gentoo community, it instead supports other options than those of upstream. Gentoo is a meta-entity; it serves a collection of many entities, instead of a single entity. If we as a Gentoo community want another water supply, we can use it; if it doesn't exist or is unusable, we can create it and make it usable. Given the volume of these piss pointing discussions, as well as those already working on other options; there is definitely enough equity to accomplish that, if they step it up...

last i heard Linus wasnt going to allow kdbus in the kernel till systemd was proven stable.

Then you should look for better sources of what you hear. All that happened is that Linus refuses to take patches from Kay Sievers into the kernel until Sievers starts fixing his own bugs instead of blaming other projects.

Key, I'm f*cking tired of the fact that you don't fix problems in the
code *you* write, so that the kernel then has to work around the
problems you cause.

Greg - just for your information, I will *not* be merging any code
from Kay into the kernel until this constant pattern is fixed.

This has been going on for *years*, and doesn't seem to be getting any
better. This is relevant to you because I have seen you talk about the
kdbus patches, and this is a heads-up that you need to keep them
separate from other work. Let distributions merge it as they need to
and maybe we can merge it once it has been proven to be stable by
whatever distro that was willing to play games with the developers.

But I'm not willing to merge something where the maintainer is known
to not care about bugs and regressions and then forces people in other
projects to fix their project. Because I am *not* willing to take
patches from people who don't clean up after their problems, and don't
admit that it's their problem to fix.

Kay - one more time: you caused the problem, you need to fix it. None
of this "I can do whatever I want, others have to clean up after me"
crap.

Linus

From April 2 2014, not that terribly long ago

Now it may be that RH will do their own patches and anyone that wants to will use those patches,
but they should be honest and quit calling it linux and instead call it Potterings OS or POS for short._________________Asus m5a99fx, FX 8320 - amd64-multilib, 3.15.9-zen, glibc-2.19, gcc-4.9.2, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4(2011)

Ssuominen :
Upstream called you systemd hater... We knows already they have no limits with words and their ego, but i must say, they amaze me. They have no respect for your work, but we appreciate what you've done with udev.

Don't you think it might be time to make eudev the default virtual provider instead of udev?

Ssuominen :
Upstream called you systemd hater... We knows already they have no limits with words and their ego, but i must say, they amaze me. They have no respect for your work, but we appreciate what you've done with udev.

Don't you think it might be time to make eudev the default virtual provider instead of udev?

That is an interesting point. Taking it one step farther would there be any loss dropping udev from the tree completely? I mean what does udev do that eudev doesn't do?

While I admire the commitment to maintain udev for as long as possible at what point does it become too much? Clearly, its for devs like Ssuominen to decide what 'too much' is, but I couldn't resist throwing this out anyway._________________First things first, but not necessarily in that order.

khayyam, that is a turnaround of words; it instead highlights the Gentoo community, it instead supports other options than those of upstream. Gentoo is a meta-entity; it serves a collection of many entities, instead of a single entity. If we as a Gentoo community want another water supply, we can use it; if it doesn't exist or is unusable, we can create it and make it usable.

TomWij ... how is that a "turnaround of words"? You had written "these questions depend on how much we as a community contribute" to which I replied that some of us, in the wider scheme of things, have already contributed an awful lot ... and having done so find this equity owned by a "community" in which we are expected to see the "choice" of others to pollute the water supply as the same as our "choice" to drink it or not. If this really is a *community* then I expect that this community has more respect for my choices, and doesn't actively work toward the diminution of that choice. I pointed to that previous discussion because it underscores the issue ... "[...] the choice of systemd involves repercussions that are not relevant in the choice of openrc (systemd will similarly effect those who don't choose it) so they are not relationally comparable choices as one has negatives that the party not choosing will none the less have as an outcome." The analogy I used at the time was clear and setup to counter the idea that "systemd is a choice that will coexist with other choices". All of that was writ large at the time, and as I wrote back in Oct 2012 "no one needs a crystal ball to read upstreams intentions". None of this seemed to make any difference to "the community" because the entire issue was framed as though systemd was something that was entirely benign, users could choose it or not ... everyone gets what they want.

As to what "we as a Gentoo community want", I'm sorry but this very same community wasn't the least bit concerned about adopting systemd as a "choice" even when it was perfectly clear that this choice would effect those who didn't choose it. If this idea of community means that I can pollute the water supply without regard for others in my community then it isn't much of a community.

TomWij wrote:

Given the volume of these piss pointing discussions, as well as those already working on other options; there is definitely enough equity to accomplish that, if they step it up...

"piss pointing"? Your mixing things that were clearly delineated ... the "pollution of the water supply" and "the implications pointed out". Why is it that when the "implication are pointed out" these are inevitably made to function as a tool to whack-a-mole the "hate"? This is political machinations 101, the "systemd-haters" are sooooo unreasonable, look at them with their piss pointing hateatude church of the anti-systemd religion, turning the forum into a warzone. Of course, such machinations only work with less politically savvy persons ... which I am not. So, no, the above wasn't "piss pointing", the analogy of "polluting the water supply" was clearly argued in the link I provided.

last i heard Linus wasnt going to allow kdbus in the kernel till systemd was proven stable.

Then you should look for better sources of what you hear. All that happened is that Linus refuses to take patches from Kay Sievers into the kernel until Sievers starts fixing his own bugs instead of blaming other projects.

Key, I'm f*cking tired of the fact that you don't fix problems in the
code *you* write, so that the kernel then has to work around the
problems you cause.

Greg - just for your information, I will *not* be merging any code
from Kay into the kernel until this constant pattern is fixed.

This has been going on for *years*, and doesn't seem to be getting any
better. This is relevant to you because I have seen you talk about the
kdbus patches, and this is a heads-up that you need to keep them
separate from other work. Let distributions merge it as they need to
and maybe we can merge it once it has been proven to be stable by
whatever distro that was willing to play games with the developers.

But I'm not willing to merge something where the maintainer is known
to not care about bugs and regressions and then forces people in other
projects to fix their project. Because I am *not* willing to take
patches from people who don't clean up after their problems, and don't
admit that it's their problem to fix.

Kay - one more time: you caused the problem, you need to fix it. None
of this "I can do whatever I want, others have to clean up after me"
crap.

Linus

From April 2 2014, not that terribly long ago

Now it may be that RH will do their own patches and anyone that wants to will use those patches,
but they should be honest and quit calling it linux and instead call it Potterings OS or POS for short.

Exactly what I said: Sievers patches are not allowed into the kernel until he fixes his behavior when it comes to bugfixing. Only that they may also be allowed when a distro has tried them and they are deemed as stable enough /kdbus patches, not systemd).