eth? conflicted with the kernel naming but udev was handling that for most cases so the "need" for changing wasn't really there

"in most cases" unfortunately does not mean reliable. Having a reliable boot process is a need - it is the same reason why systemd is bad[TM].

Yes sure it is: but you're conflating "a reliable boot process" with "reliable using the same naming scheme across every machine in the world" which isn't going to happen. If as moose said, you were in one of the "most cases" then you already had something working reliably for you.

And let's not forget that the vast majority of users don't even need any of this in the first place, since they don't have multiple ethernet adaptors. So out of the minority of users who need this, most of them were getting on okay with the old naming scheme. So the nubs have now introduced a new bad default for everybody to help a small minority of a small minority, but everyone has to go through pain as a result.

Much like consolekit and the rest of nubkit.

Quote:

Quote:

and if they wanted they could have renamed eth? to net? even with the old versions

Well, in the lack of any other rules defaults should be provided which are not eth?

No that makes no sense: in the lack of any other rules, use eth0 and wlan0. If someone has multiple cards of one type and they actually need renaming (since some systems don't) then let them configure it to rename, and if you had been aware of these issues from the beginning (remember these idiots claim expertise over the whole "dynamic early userspace" problem domain which we users simply don't understand) you should have told people not to rename to kernel names, and in fact not allowed it. That would have meant no problems, ever.

But they didn't: with all their vast experience, and despite the fact that it was a collaboration between some expert kernel hackers and the cream of userspace developers (*cough* bullsh1t *cough*) they didn't see the obvious race sitting in front of their faces. Only how to hassle everyone else into adopting half-baked software.

So we are where we are, and an enormous amount of productions servers with multi-NIC use eth0-7 because they were told to. You cannot simply dump all those admins into a whole world of pain, because you've now got a "better" idea which in fact isn't: it's worse.

Quote:

Moreover, if one wants to do a change to the defaults (and the old rules had many drawbacks: I remember many complaints when they were introduced into udev) it is the ideal time to combine both changes. (Of course the new default naming scheme has its drawbacks, too, but at least you now can exchange a damaged network card [if you do it carefully] without the force of a software change which is sometimes not easily possible without having the network running...)

To be honest, I do not understand all the excitement about the change: After all, it is only a change in the defaults.

I'm amazed that with your experience you can't see that it's a bad change. It doesn't solve any problem, in fact it creates more: hardware devices come and go (that's why we need "dynamic" device configuration, remember?) so the bus ids are not fixed. They might be sometimes, and on others not. Hardly the "reliable" mechanism you claim to want. More "cleverness" that doesn't fix anything, just leads to pain all around, and more work in the future, since it's ill-conceived.

So why not leave the default the way it is?

Given the amount of legacy config, imo renaming can't be done robustly in userspace any more: they fscked it up, just like they fscked up module-loading. I think we should just say: if you want renaming, edit /etc/mactab and pass the kernel the bootline parameter so it reserves those interface names, for those MAC addresses.
All that is, is a minimal amount of code that is a configuration option for compile and at runtime. It wouldn't slow anything down, since it only optionally does anything when an interface is brought up by the kernel.

And no, dumping it all on admins and saying "we broke it, you fix it" is not an acceptable solution.

I'm amazed that with your experience you can't see that it's a bad change.

Oh mv sees things perfectly well, he's just your typical troll, which is why I don't interface with him anymore.

Quote:

Given the amount of legacy config, imo renaming can't be done robustly in userspace any more: they fscked it up, just like they fscked up module-loading. I think we should just say: if you want renaming, edit /etc/mactab and pass the kernel the bootline parameter so it reserves those interface names, for those MAC addresses.
All that is, is a minimal amount of code that is a configuration option for compile and at runtime. It wouldn't slow anything down, since it only optionally does anything when an interface is brought up by the kernel.

I hope the kernel maintainers do decide to do most of what udev is used for or at least the network part
then we won't have a need for udev and the leverage games being played around it._________________Asus m5a99fx, FX 8320 - amd64-multilib, 4.11.3-zen, glibc-2.21, gcc-4.9.4, eudev
xorg-server-1.19.2 w/mesa-17.1.0, openbox, nouveau and radeon, oss4(2017)

I really do not want to repeat all the arguments from the other thread again. Anyway, since you addressed me directly, I should reply:

steveL wrote:

but you're conflating "a reliable boot process" with "reliable using the same naming scheme across every machine in the world"

No. By reliable I mean that the machine comes up in the same state at every boot, no matter how often I boot. The old scheme was not able to do this.

Quote:

And let's not forget that the vast majority of users don't even need any of this in the first place, since they don't have multiple ethernet adaptors.

Many users got a broken system, once ppp over firewire was available and was sometimes initialized earlier. In fact, it is that many people have run into issues like these that the udev developers decided to make the persistent names.

Quote:

Quote:

Well, in the lack of any other rules defaults should be provided which are not eth?

No that makes no sense: in the lack of any other rules, use eth0 and wlan0.

This would mean to break a system almost surely if a second device is attached/availble. This is the worst possible default, even compared to the previous race condition which only had a chance to break the system.

Quote:

you should have told people not to rename to kernel names, and in fact not allowed it

Yes, this should have been done from the very beginning. This is the conceptual bug of the early udev releases which was finally fixed now.

Quote:

they didn't see the obvious race sitting in front of their faces

Tell this to the previous udev maintainers, not to the current ones who made their best to repair this mistake.

Quote:

So we are where we are, and an enormous amount of productions servers with multi-NIC use eth0-7 because they were told to.

Even if the bug would have been observed at the first release of udev, these servers would have to switch from eth0-7 to net0-7. This happened now later, because the bug was observed only now. So what?

Quote:

I'm amazed that with your experience you can't see that it's a bad change. It doesn't solve any problem

I mentioned an example which it solves which was one of the main complaints in early udev: If your network card is broken, you can now replace it.

Quote:

Hardly the "reliable" mechanism you claim to want.

It does never change at the next boot with the same hardware. It does not change if I replace the card/stick by another. Both things I did not get with the previous defaults. So it is more reliable.

Trollish behavior would be quite the opposite: Did you realize that I was previously voting strongly against practically all of Lennartware (systemd, *kit etc)? However, I am not trollishly generalizing and shooting the messenger: It is hard to admit that the particular network naming change was probably the best which could be done in the previously broken situation - not optimal and without any problems, but probably the best which could be done.

Yes, that's troll speak, first because you are telling us that, like if we are discovering something : OMG they add a virtual for udev ? Wowwww amazing didn't knew we could use evdev instead of udev ! Thank you for teaching us that hidden feature...

And second, because you are speaking on a thread you didn't took care to read, like a good troll.
Else you would have seen that ssuominen already said it, and get answered.

On my new install I'm setting up (read giving up on), I couldn't get my internet to work initially, because of, you guessed it!, udev messing up network interfaces. After installing eudev onto that computer, the internet magically worked like it should have. There has to be a better solution than udev, I'm unsure why people are still using it._________________"To design the perfect anti-Unix, make all file formats binary and opaque, and require heavyweight tools to read and edit them." - The Art of Unix Programming

Aha, summarizing the situation why the poll is unclear is trolling. Instead of accusing me of trolling you could have attempted to clarify the situation (e.g. what you mean by "making optional" if you do not mean that a virtual is optional or whether the poll is about the virtual being optional). Since you seem to have no interest in such a clarification, I guess you are not really interested in the poll, but just use it as an excuse for universal trolling against udev. With that assumption it now becomes clear why you defamed me as a troll when I said that one particular point of udev was done correctly. Thanks and bye in this thread.

There has to be a better solution than udev, I'm unsure why people are still using it.

Some are using it because "it's new and shiny".
Some think that because of the hype it must be better.
Some just follow it because they are groupies of the developers.
Most that use it are using it because they think the distro devs have given it their blessing
so it must be good as gold or they have no choice unless they leave the distro they use.

While it may or may not have fixed some "perceived problems" it introduced much (unneeded) grief in the implementation.

Personally I've frozen an older version of udev (pre-takeover) and am happy.
I expect either eudev to finally get it's act together and be a serious contender
or the kernel people to get tired of trying to fix new udevs breakages every release
by working around it with kernel kludges and simply put it in the kernel._________________Asus m5a99fx, FX 8320 - amd64-multilib, 4.11.3-zen, glibc-2.21, gcc-4.9.4, eudev
xorg-server-1.19.2 w/mesa-17.1.0, openbox, nouveau and radeon, oss4(2017)

I recently tried mdev as device manager, but it is really not useable for common desktop systems : the version of Busybox I tested was not able to manage correctly hotplug, especially with audio devices : the groups settings were completely wrong, and coldplug was quite tricky.

It seems there was a regression at that moment, so I decided mdev is not mure enough to use it now.

I use udev because it works.

The only thing I don't accept is the push to change classical eth* names with rules I found too obfuscated and not predictable. Most user configurations have 1 ethernet ane 1 wifi device, which for me should always be eth0 and wlan0 for sake of simplicity and portability.
So I enabled a blanc 80-blah-blah-network-rules file and reverted back to that behaviour.

I don't care whether udev is part of systemd or not either.
Though I do expect that one day one will not be able to build
and deploy udev without systemd being deployed also.
But that's neither here nor there.

Yes udev is optional, at least here in gentoo, not so much in other distros,
as at least arch and redhat seem to be making it the default along with systemd
so no real choice to end users there._________________Asus m5a99fx, FX 8320 - amd64-multilib, 4.11.3-zen, glibc-2.21, gcc-4.9.4, eudev
xorg-server-1.19.2 w/mesa-17.1.0, openbox, nouveau and radeon, oss4(2017)

As I see it, udev is optional in Gentoo, but not in any other distro. I'm under the impression that Debian is switch to systemd as well, but this may be just hearsay. Hopefully the day will not come when you have to build your own distro to get away from systemd. Unless Linux undergoes a major architecture change, it will always be possible to run it without systemd, I think the most troublesome thing is X11, which hopefully does not require systemd at some point._________________"To design the perfect anti-Unix, make all file formats binary and opaque, and require heavyweight tools to read and edit them." - The Art of Unix Programming

Sure, but, today, eudev *IS NOT* marked as stable. We have to choose between a _stable_ package that alters seriously the way the system works (and which is changing quite often himself), and an _instable_ one, which works exactly as before. Which one to use on a stable production server ?

Sure, but, today, eudev *IS NOT* marked as stable. We have to choose between a _stable_ package that alters seriously the way the system works (and which is changing quite often himself), and an _instable_ one, which works exactly as before. Which one to use on a stable production server ?

the stable default, sys-fs/udev, of course, which doesn't change that often in stable at all -- from 171 to 197'ish in period of 2+ years with only one major change is "Debian oldstable comparable" conservative line
you can safely expect nothing major to change for another 2+ years now and when and if there will be such a major change, there will be a news item like this time
~arch ("unstable") is of course a moving target so no guarantees there

the stable default, sys-fs/udev, of course, which doesn't change that often in stable at all -- from 171 to 197'ish in period of 2+ years with only one major change is "Debian oldstable comparable" conservative line

I agree. But, since 197 version is stable, the rythm seems to be faster. In 197 version, I had to modify configuration files, and create an ugly init script, just to avoid an "optional" way of naming my NICs. Then 200 comes, the option becomes the lonely available choice. Now I have either to modify all occurences of eth* names in all my scripts (for 2 years or more, sure ?) or switch to eudev. I'm a sysadmin, I'm a lazy boy.

Quote:

you can safely expect nothing major to change for another 2+ years now

I really want to believe you. But udev changelog already talks about 201 and 202 versions, just two weeks after 200 was stable. I suppose these versions only contain minor fixes, but how can I be sure these minor edits will not alter the behavior of my systems again ?

Quote:

and if there will be such a major change, there will be a news item like this time

the stable default, sys-fs/udev, of course, which doesn't change that often in stable at all -- from 171 to 197'ish in period of 2+ years with only one major change is "Debian oldstable comparable" conservative line

I agree. But, since 197 version is stable, the rythm seems to be faster. In 197 version, I had to modify configuration files, and create an ugly init script, just to avoid an "optional" way of naming my NICs. Then 200 comes, the option becomes the lonely available choice. Now I have either to modify all occurences of eth* names in all my scripts (for 2 years or more, sure ?) or switch to eudev. I'm a sysadmin, I'm a lazy boy.

Quote:

you can safely expect nothing major to change for another 2+ years now

I really want to believe you. But udev changelog already talks about 201 and 202 versions, just two weeks after 200 was stable. I suppose these versions only contain minor fixes, but how can I be sure these minor edits will not alter the behavior of my systems again ?

Quote:

and if there will be such a major change, there will be a news item like this time

Maybe a little more earlier ?
Therefore, thank you, developpers.

*nod* *agreed*

If you compare current stable 200, and current ~arch 202, there are only minor bugfixes. Minor bugfix releases might go stable in between, and it's what they are if there is no news item.

I won't say more since this thread is just replicating the earlier threads and the "vote" is just cherry on top of it. Some people don't seem to understand making more noise with no work is
not productive.

you can safely expect nothing major to change for another 2+ years now

I really want to believe you. But udev changelog already talks about 201 and 202 versions, just two weeks after 200 was stable. I suppose these versions only contain minor fixes, but how can I be sure these minor edits will not alter the behavior of my systems again ?

You can't be sure that more changes won't come along given the past track record.
And anyone that promises that they won't change for the next few years...well I will leave it to your imagination whether they are believable
especially if they aren't the upstream developers._________________Asus m5a99fx, FX 8320 - amd64-multilib, 4.11.3-zen, glibc-2.21, gcc-4.9.4, eudev
xorg-server-1.19.2 w/mesa-17.1.0, openbox, nouveau and radeon, oss4(2017)

you can safely expect nothing major to change for another 2+ years now

I really want to believe you. But udev changelog already talks about 201 and 202 versions, just two weeks after 200 was stable. I suppose these versions only contain minor fixes, but how can I be sure these minor edits will not alter the behavior of my systems again ?

You can't be sure that more changes won't come along given the past track record.
And anyone that promises that they won't change for the next few years...well I will leave it to your imagination whether they are believable
especially if they aren't the upstream developers.

ChangeLog of sys-fs/udev speaks for itself regarding stabilizations (if one remembers the versions where major changes happened). The in-between time has always been 2 years.
I don't see any reason to stabilize other than minor bugfix releases anytime soon now that we have Linux 2.6.32 -> 3.9/git compability and no major bugs left open at Gentoo's bugzilla.
Perfect time to let documentation play catch up (it's not outdated but it should be more complete).

By reliable I mean that the machine comes up in the same state at every boot, no matter how often I boot. The old scheme was not able to do this.

Nor is the new one: just check comment 90 in the bug against comments 6 and 7.

The whole point of the exercise is to allow for "dynamic" devices: bus ids are not robust in that regard. Please read the bug and confirm that you have understood this, as you do not appear to atm.

Quote:

Quote:

And let's not forget that the vast majority of users don't even need any of this in the first place, since they don't have multiple ethernet adaptors.

Many users got a broken system, once ppp over firewire was available and was sometimes initialized earlier. In fact, it is that many people have run into issues like these that the udev developers decided to make the persistent names.

Some people have that issue (I don't know enough about it, and am unsure as to why those come up with ethN and not pppN) and I'm all for letting them configure what the interface is called. This new default doesn't help with that at all imo, it just obfuscates the matter.
In any event, most do not, so you haven't really contradicted what I was saying: just provided another use-case which afaik isn't even ethN, and if whether it is or is not, doesn't change that sometimes renaming is useful, and that this new default does not add anything to that, only makes it harder to work with.

Quote:

Quote:

Quote:

Well, in the lack of any other rules defaults should be provided which are not eth?

No that makes no sense: in the lack of any other rules, use eth0 and wlan0.

This would mean to break a system almost surely if a second device is attached/availble. This is the worst possible default, even compared to the previous race condition which only had a chance to break the system.

Nonsense: just use the standard mechanism of ethN or wlanN (sorry about the 0; if that is what confused you.) After all, many systems come up with them in the same order (especially if they're always in the same slot, so we already have the supposed robustness of the new scheme), and that's what the admin configures when they install.
If that is not sufficient, it is the user who has to make that call, and setup a rename.

Quote:

Quote:

you should have told people not to rename to kernel names, and in fact not allowed it

Yes, this should have been done from the very beginning. This is the conceptual bug of the early udev releases which was finally fixed now.

Only it's not fixed now; as the bug shows the new default has a similar conceptual flaw, since it presumes that bus ids are fixed, and they are not (or we wouldn't need a dynamic device manager.)

Quote:

Quote:

they didn't see the obvious race sitting in front of their faces

Tell this to the previous udev maintainers, not to the current ones who made their best to repair this mistake.

Now that is disingenuous. Greg K-H is on record on the dev ml (last year iirc) telling us all we didn't understand this problem-space, and that the people working on udev and systemd are the experts. The same people he collaborated with after he started udev (remember hal? Poettering made a great deal of hald being written by his "colleague"), and who now maintain it under the auspices of systemd.

So that's a totally flawed argument: the same people who brought us the racy names are the ones who've brought us this turd of an idea. And as ever they push it out without sufficient testing, since "users can test it for us" and expect everyone else to polish it, instead of thinking it through first.

Quote:

Quote:

So we are where we are, and an enormous amount of productions servers with multi-NIC use eth0-7 because they were told to.

Even if the bug would have been observed at the first release of udev, these servers would have to switch from eth0-7 to net0-7. This happened now later, because the bug was observed only now. So what?

No, if they'd thought it through, or y'know tested it in collaboration with people who actually ran production servers with multi-NIC, they would never even have allowed renaming in kernel namespace. So those people would never even have used eth0-7 in the first place, and this would never have been an issue.

My point is that they're the ones who put admins in this position. So they have to provide a way forward that doesn't break current setups. That's what "not breaking userspace" means: it's a much wider philosophy than just providing a stable ABI (which udev never has, as if the fact that they're not in-kernel frees them from all responsibility) which is the minimal base.

And given that they put admins in this position, they now need to make the kernel renaming work, which as I pointed out can be done very simply; mdev even gives us a standard filename to use.

So, given where we are now we basically have to make eth0-7 work without disrupting end-admins' workflow.

Quote:

Quote:

I'm amazed that with your experience you can't see that it's a bad change. It doesn't solve any problem

I mentioned an example which it solves which was one of the main complaints in early udev: If your network card is broken, you can now replace it.

I could do that before as well: and it didn't matter which slot I plugged it into, nor what bus: eth0 was eth0.

And if I'm a network admin, I don't mind editing the mactab when I slot in a new card: that's when I'm ready to deal with changes, and that's what I'm paid for. In the meantime, it's fire-and-forget.

What I'm not up for, is a software upgrade suddenly deciding to change everything around, so that now all my production servers require editing of all their configuration files. (The very antithesis of "fire-and-forget".) And it's not even reliable. Sorry, "devs" back to the drawing board.
Your expert users think it sucks and can't make it work without a world of pain, so it doesn't matter what idiot-box mechanisms you've put in place, that half-work if nothing complex is needed.

Quote:

It does never change at the next boot with the same hardware. It does not change if I replace the card/stick by another. Both things I did not get with the previous defaults. So it is more reliable.

It changes if you plug in a new graphics card, or another peripheral. Only now you need to change the name of the initscript, and all configuration using it. Or change to use a new name (more work) even if you never needed to before.

So not only is it not reliable, it also leads to a maintenance explosion. Double fail.

As I said at the beginning, you appear to have bought the idea that bus-ids are reliable, because they appear to work on your setup. That's not enough: after all, eth0 and wlan0 are already working for the desktop users that all this "work" is supposedly aimed at.

And no I'm not using eudev, fwtw: I've been using udev starting after localmount for the last year, and this new problem doesn't affect me. I'm just amazed network admins put up with it: I would not, if managing systems were my profession. I'd expect much better from the software I base my infrastructure on.

I'm just amazed network admins put up with it: I would not, if managing systems were my profession. I'd expect much better from the software I base my infrastructure on.

This is one of the most troubling issues in my opinion, it's the quickness that the systemd developers deprecate old solutions and only offer users the option to 'upgrade' to whatever they find interesting at the time._________________"To design the perfect anti-Unix, make all file formats binary and opaque, and require heavyweight tools to read and edit them." - The Art of Unix Programming

I'm just amazed network admins put up with it: I would not, if managing systems were my profession.

steveL ... what tends to happen is that they find another solution. I'd been scoffed at in another thread for simply mentioning that I met with quite a number of people who were doing just that and abandoning linux for *BSD. These were serious cluster and simulation admins from the European Space Agency and The International Grid (iGrid), and these people don't tend to make any noise they just move on. A lot of time and planning goes into their infrastructure, it has to be dependable and have a life expectancy that scales to project time (sometimes these are eight to ten year projects).

The irony it that it was me that got these guys started with linux back in 2003 (at iGrid 2003) having got gentoo booting their new Apple racks and it having out performed other machines there (the task was to load a CD into RAM and transfer it from x to the University of Illinois), the cluster that came out of that I wasn't involved with but it ran a lot of the data coming from Spirit, Mars Exploration Rover.

These people simply don't take linux seriously any more, its not on their list of possible options because they expect that any systems they build *will* be, as you say, "fire-and-forget".

Perhaps the discussion about the udev naming scheme should really be moved to another thread, since it does not belong here.

steveL wrote:

mv wrote:

By reliable I mean that the machine comes up in the same state at every boot, no matter how often I boot. The old scheme was not able to do this.

Nor is the new one: just check comment 90 in the bug against comments 6 and 7.

This is after a massive hardware change (adding of a graphics card), not just by a new boot.

Quote:

The whole point of the exercise is to allow for "dynamic" devices: bus ids are not robust in that regard.

You cannot have something which is completely robust on the one hand and simultaneously survives every change/replacement of the device on the other hand, since both requirements contradict each other. The default is a compromise between both. If you want your own compromise or extreme, it is easy to write a corresponding rule: Certainly net0 with your own rule is preferrably over anything else, but in the lack of such a rule the default is reasonable.

Quote:

Some people have that issue (I don't know enough about it, and am unsure as to why those come up with ethN and not pppN) and I'm all for letting them configure what the interface is called. This new default doesn't help with that at all imo, it just obfuscates the matter.

It comes up with KERNEL==eth%n (unless they have changed recently), and I am completely on your side: Let the people configure how that interface is called. The problem is that without udev it might come up as eth0 or as eth1, depending on the boot. And with udev and old scheme it might be that it also comes up with eth0 and the ethernet card does not appear at all (if you ran into the race condition). It works reliably (with old or new udev) if you have rules which set the card to net0 and anything else to e.g. net1. In the lack of such rules the old scheme simply works unreliable: udev had to chose a default which is different from eth*. Whether for this default the eXpYY or eMAC (or eth%n as you want below) rule is better can certainly be discussed and depends on your particular setup, but this is also trivially configurable, so I do not understand all the hype about it, if this is really what is worrying you.

Quote:

Nonsense: just use the standard mechanism of ethN or wlanN (sorry about the 0; if that is what confused you.)

Yes, the 0 confused me, but what you mean is not much better: You mean the rule

Well, if you want it, it is this one line of configuration (and another one for wlan) while the new default eXpYY would make somewhat more work to setup (I am not sure whether it could be done without a helper script). Of course, if you use this line you have then all the disadvantages of not using udev for net-related stuff at all, in particular it is not much better than hard-coding eth0.

Quote:

Greg K-H is on record on the dev ml

Sorry, I am not really aware who did what. If it is was already the same people earlier who made this race condition mistake, then yes, you have to blame these people. However, you have to blame them for that earlier mistake, not for the current fix which IMHO still is the best which could be done in the current situation.

Quote:

And if I'm a network admin, I don't mind editing the mactab when I slot in a new card

I heard these complaints from admins in companies where it is customary that some worker replaces a defect card, perhaps in the middle of the night (if it is an important server which should never go down) or when the admin is in holidays. Software, on the other hand, would never be upgraded when the admin is not available. Of course, people claiming this, might be liars - I cannot easily check - but such arguments had often been brought up in German usenet.

Quote:

What I'm not up for, is a software upgrade suddenly deciding to change everything around, so that now all my production servers require editing of all their configuration files.

Sorry, but when you are ready to upgrade some crucial package you must also be ready to upgrade the corresponding configuration. Otherwise something is wrong in your workflow.

Quote:

eth0 and wlan0 are already working for the desktop users that all this "work" is supposedly aimed at.

And for the admin (in whose name you are complaining) they did not work - for these this was finally fixed. Or they had machines in which they knew they will ever have only one card and used the rule I mentioned above in which case it still works without any changes.

Quote:

I'd expect much better from the software I base my infrastructure on.

Actually, I'd expect network tools not to have such trouble with name changes. It is actually the limited possibility of the network setup software which causes these issues. It was already observed by Roy Marples that all related Linux tools (in contrast to e.g. BSD tools) are rather poor: You could see how simpler things became already with his dhcpcd (and also with iproute2 instead of net-tools, although this is still far from being ideal). IMHO NetworkManager is from its functionality on the right track - if it just would not have these inacceptable bindings to policykit and dbus which is of course an absolute no-go.

This is one of the most troubling issues in my opinion, it's the quickness that the systemd developers deprecate old solutions and only offer users the option to 'upgrade' to whatever they find interesting at the time.

In a sense, this is what developers have to do - they are not the main testers but have to implement and react on feedback of those who are actually using the software: This is exactly the idea of open software development.
It is the distributions who have the responsibility to declare new solutions as "stable" only when they are well-tested - and the stabilization in a 2-year rhythm in Gentoo does not sound so terribly quickly to me. The current naming scheme issue is somewhat an exceptional situation for distributions since the old scheme is known to break in certain cases - i.e. you have to decide whether to stabilize early for fixing the issue or wait for possibly a better fix. So for distributions both decisions might be wrong. The developers, on the other hand, are in a sense even in charge to release a fix as soon as possible after the issue is known (and if the fix turns out to be wrong to release a better fix again as soon as possible).

Edit: Please note that I am not claiming that the udev developers always react no feedback of users - the situation here is certainly not ideal. I am just saying that throwing a solution over board which is known to be broken and to replace it quickly by something presumably correct, is the right behaviour.

I am just saying that throwing a solution over board which is known to be broken and to replace it quickly by something presumably correct, is the right behaviour.

Granted, the race-condition situation is not correct, but for the most part it doesn't bite most people so often that they clamor for a change. So far as I know, I have never been tripped up by it. What I do know is that the fix going on now inescapably causes pain. It inevitably requires a lot of close, careful reading from multiple sources, a lot of trial-setup testing, and crossed fingers for actual deployment. Now multiply that by multiple systems.

I've got two machines with really screwy setups, including mounting of /usr from a separate LVM volume and network bridging. I've also got VM's that boot using NFS and need to have good, known interface names. I've been delaying an upgrade because the pain of working out a testing and rollout strategy--and the time it will take--has been too high so far.

Please do not tell me that this "fix" is "good enough." It is not. We need a better solution.