Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Time to gentoo to reconsider udev
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  

What gentoo should do with udev
Keep udev as-is
29%
 29%  [ 12 ]
Make udev optional
70%
 70%  [ 29 ]
Total Votes : 41

Author Message
krinn
Advocate
Advocate


Joined: 02 May 2003
Posts: 4139

PostPosted: Tue Apr 23, 2013 8:46 pm    Post subject: Reply with quote

ssuominen wrote:
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.


I agree previous udev versions were fine, udev-197 was the first mistake, at first following upstream stupidity to remove /usr and drop old kernel, something you have done an awesome work at correcting, BUT only after a fork was made, because you weren't listening and treat people to act, well people have act and after that you change your mind and produce that good job.

And then udev-197 goes stable with those features, and users were happy, while people loose their time with the fork (not totally lost as this has made you rethink and change and eudev was made, but i think grey_dot and his followers could really claim udev-197 was made like that because of their actions and deserve a warm thank you from all gentoo users).

Now, it seems lesson isn't learn, as (right now) few are saying new scheme is the right step, and a lot are telling you it's a bad move. And you are again doing the same : "more noise with no work is not productive", isn't that the same scheme again ? Instead of fixing udev, you throw a treat, again...

Sorry, this thread isn't to answer to your treat, this thread is because someone already has done work and was productive, sadly for us, it's funtoo devs and not gentoo devs.
This thread is to say i think funtoo devs "may" have done what should have been done, and answer the current chaos udev is putting on us.

I just hope catalyst devs would see this, and think about the solve to the udev mess funtoo guys have made search for. Because i don't think gentoo booting process should be handle by upstream udev devs, and this is currently the case because of your attitude at blindly following them, even when everyone is telling you to rethink about it.

It's awesome that thread is about a funtoo bug that show they try to lower udev presence to lesser udev problems and you are keep saying "some people don't seem to understand". Well, by "some people", it seems this include funtoo devs as they saw a problem with udev, but are you sure you're not doing that too? Not understanding ?
Because what are your comments about that funtoo bug ? None.
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 2272
Location: UK

PostPosted: Tue Apr 23, 2013 10:19 pm    Post subject: Reply with quote

ssuominen wrote:
Some people don't seem to understand making more noise with no work is not productive.

True that: it's no effort at all to just break people's systems repeatedly, ignore their numerous complaints, and WONTFIX all their one-line patches to re-enable code which worked fine previously.

Worked great for the GTK+3 "transition", let's repeat the success here!
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2391
Location: The Peanut Gallery

PostPosted: Wed Apr 24, 2013 6:01 am    Post subject: Reply with quote

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

Oh please that is pathetic: like I said the whole point of the exercise is to allow for dynamic devices.
Quote:
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.

The original kernel method is a sensible default. The new default is someone trying to be clever, and coming up with yaf crap idea, just like racing the kernel to allocate names.

I'm not getting into your confusion about what a sane default is: you've clearly drunk the kool-aid for the new setup, and are unable to accept any other viewpoint.
Quote:
Quote:
Greg K-H is on record on the dev ml

Sorry, I am not really aware who did what.

Then you shouldn't make statements about not blaming the current devs for what was done earlier: since they're the same people; and you just sound like a fool. Which is pretty much what the rest of your argument does too, wherein you completely ignore the points made and blather on like a used-car salesman.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3999

PostPosted: Wed Apr 24, 2013 7:02 am    Post subject: Reply with quote

steveL wrote:
Then you shouldn't make statements about not blaming the current devs for what was done earlier: since they're the same people

My point was not so much whom to blame but for what to blame: The current fix is fine, the problem was years before - when you did not complain about it since then.
Quote:
The original kernel method is a sensible default.

As are the other 2 choices I mentioned and probably some more: Every choice has advantages and disadvantages - that lies in the nature of defaults. Making such a hype about it when you can select the default with one line...
Quote:
and you just sound like a fool.

everybody can judge by himself who is the fool: The one who is not able to configure one line or the one who says all this is only about configuring one line.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3999

PostPosted: Wed Apr 24, 2013 7:14 am    Post subject: Reply with quote

miket wrote:
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

The proper fix requires you to use a different name than eth%n. I cannot confirm that this requires reading of multiple sources: On most systems you do a grep in /etc/conf.d and change the symlink in /etc/init.d, so for the big majority of users this is almost nothing. Yes, for complex setups this can be more work, but it will make you setup more reliable, so it is worth to do it.
If you do not want to change the name you can use various "hackish" fixes which can work for particular systems (e.g. if you know that you will ever only have one eth0 device) as discussed with SteveL.
Quote:
Please do not tell me that this "fix" is "good enough." It is not. We need a better solution.

Feel free to suggest one. So far, I heard none except renaming which would work reliably when you have more than one eth%n (for the minimum requirement of "reliably" which I use all of the time: that it is guaranteed to work at every boot without any hardware change).
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3999

PostPosted: Wed Apr 24, 2013 7:28 am    Post subject: Reply with quote

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

Oh please that is pathetic: like I said the whole point of the exercise is to allow for dynamic devices.

No, the whole point of the exercise is to have the same setup at every boot. If it survives even a change in the hardware it is an additional bonus. The new default survives changes of the cards (even of the network card) but not necessarily adding another card or moving to another slot. If the default were based on MAC, it would survive changing/adding of other cards but not of the network card. Another default works only if there is exactly one network card and no things like ppp over firewire. Certainly one can list further possible defaults with further advantages and disadvantages. One was chosen which works in many cases, people who do not fall into these cases have to configure one line to chose another setup instead of the default.
Who is pathetic here?
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2240
Location: Dallas area

PostPosted: Wed Apr 24, 2013 9:50 am    Post subject: Reply with quote

Ant P. wrote:
ssuominen wrote:
Some people don't seem to understand making more noise with no work is not productive.


Yeah, those of us who don't want to drink the koolaid must be real morons for not wanting to do things the one true way and how dare we have an opinion about it :roll:
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.9.1-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2100
Location: Finland

PostPosted: Wed Apr 24, 2013 10:02 am    Post subject: Reply with quote

Anon-E-moose wrote:
Ant P. wrote:
ssuominen wrote:
Some people don't seem to understand making more noise with no work is not productive.


Yeah, those of us who don't want to drink the koolaid must be real morons for not wanting to do things the one true way and how dare we have an opinion about it :roll:


As you noticed it was not targeted to anyone in particular but was only a general observation. Yet, you identified yourself from it and took it personally? That should tell you something.


Last edited by ssuominen on Wed Apr 24, 2013 10:06 am; edited 1 time in total
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2100
Location: Finland

PostPosted: Wed Apr 24, 2013 10:05 am    Post subject: Reply with quote

Ant P. wrote:
ssuominen wrote:
Some people don't seem to understand making more noise with no work is not productive.

True that: it's no effort at all to just break people's systems repeatedly, ignore their numerous complaints, and WONTFIX all their one-line patches to re-enable code which worked fine previously.

Worked great for the GTK+3 "transition", let's repeat the success here!


I'm not sure what you mean. The GTK+ transition is going well with the established policies. Everything should use latest toolkit and it's still not a bug in applications if your favourite theme hasn't been ported to GTK+-3 yet.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2240
Location: Dallas area

PostPosted: Wed Apr 24, 2013 10:09 am    Post subject: Reply with quote

ssuominen wrote:
Anon-E-moose wrote:
Ant P. wrote:
ssuominen wrote:
Some people don't seem to understand making more noise with no work is not productive.


Yeah, those of us who don't want to drink the koolaid must be real morons for not wanting to do things the one true way and how dare we have an opinion about it :roll:


As you noticed it was not targeted to anyone in particular but was only a general observation. Yet, you identified yourself from it and took it a bit personally? That alone should tell you something.
No offense of course.


You mistake me, I took nothing personally as I don't invest any feelings into this. So save the attempt at psychology the diagnosis was wrong.
But what I said is how many perceive the way you and others say things about this udev brouhaha
and I was simply pointing it out in a graphic and blunt way.
I too mean no offense.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.9.1-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2100
Location: Finland

PostPosted: Wed Apr 24, 2013 10:50 am    Post subject: Reply with quote

hcaulfield57 wrote:
steveL wrote:
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.


+1

I've expressed my unsatisfaction to upstream as well regarding the speed of dropping old code when they could have just #ifdef'd the code for a while to give people more time
in converting to the new alternativies. However, kudos to them the new alternativies work well.
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2100
Location: Finland

PostPosted: Wed Apr 24, 2013 10:57 am    Post subject: Reply with quote

mv wrote:
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.


I couldn't agree more. Some people seem to think they live in a fantasy land where admins are not required.
Back to top
View user's profile Send private message
miket
Apprentice
Apprentice


Joined: 28 Apr 2007
Posts: 189
Location: Gainesville, FL, USA

PostPosted: Wed Apr 24, 2013 3:07 pm    Post subject: Reply with quote

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

Feel free to suggest one. So far, I heard none except renaming which would work reliably when you have more than one eth%n (for the minimum requirement of "reliably" which I use all of the time: that it is guaranteed to work at every boot without any hardware change).


I did: http://forums.gentoo.org/viewtopic-p-7290476-highlight-.html#7290476

In a nutshell: patch the kernel make it so that the user can configure it to use a pattern other than "eth" as a base name for Ethernet interfaces. New udev could still do the stupid enpXsY renaming if it wants. Old or new udev could still use the more sensible lanX or netX or wanX pattern if that's desirable. You'd also be able to get multiple ethX names without races.

Let me tell you again: I talk to lots of Debian sysadmins who manage jillions of hosts who can't even imagine why anyone wants to take away their eth0/eth1. They don't ever report booting problems because of interface-name races. In two or three years, when they are finally ready to move off of Wheezy (still a couple of weeks from release), they may be asking why Gentoo people didn't stand up more strongly for well-known interface names back in 2013.
Back to top
View user's profile Send private message
krinn
Advocate
Advocate


Joined: 02 May 2003
Posts: 4139

PostPosted: Wed Apr 24, 2013 6:50 pm    Post subject: Reply with quote

ssuominen wrote:
I've expressed my unsatisfaction to upstream as well regarding the speed of dropping old code when they could have just #ifdef'd the code for a while to give people more time

Let me guess, they closed it as WONTFIX, and told you they will called DEVREL if you say any more words ?
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2391
Location: The Peanut Gallery

PostPosted: Thu Apr 25, 2013 2:04 am    Post subject: Reply with quote

mv wrote:
steveL wrote:
Then you shouldn't make statements about not blaming the current devs for what was done earlier: since they're the same people

My point was not so much whom to blame but for what to blame: The current fix is fine, the problem was years before - when you did not complain about it since then.

The point you made was basically "this is all a good default, look it works after I reboot my machine, and kudos to the devs, it's not their fault what somebody else did years ago." But it is and it was.

And no of course I didn't complain: it didn't affect me, though I saw a lot of other people go through pain. That doesn't disqualify me from expressing my opinion, any more than it does you, who are not affected by the maintenance headache either.

They've just swapped one set of problems for another, in the default setup for users of desktop systems, who this is all supposedly aimed at.
Quote:
Quote:
The original kernel method is a sensible default.

As are the other 2 choices I mentioned and probably some more: Every choice has advantages and disadvantages - that lies in the nature of defaults. Making such a hype about it when you can select the default with one line...

No the problem is that the existing default is exactly right for 99% of the desktop users this is meant to be in aid of. It's almost as if kernel developers have already been in this situation with their machines..

And now we have a default that is basically obfuscated, and in addition is liable to change every time you plug a new device in. You can't seriously be telling me that you think that is a viable solution in the dynamic device domain this is purported to be about.

Furthermore the new default simply takes over and breaks existing setups. That's just amateur-hour, apart from being a heavy-handed way of forcing people to test your new shiny.
Quote:
Quote:
..you shouldn't make statements about not blaming the current devs for what was done earlier: since they're the same people; and you just sound like a fool. Which is pretty much what the rest of your argument does too, wherein you completely ignore the points made and blather on like a used-car salesman.

everybody can judge by himself who is the fool: The one who is not able to configure one line or the one who says all this is only about configuring one line.

Yeah, keep banging on about your strawman arguments: you're missing the points. Firstly this isn't a viable solution; it has as many holes in it as kernel renaming, and is much worse to work with than the existing default. Secondly there are a whole load of admins who've gone along with the pre-existing setup, and it's simply unacceptable to dump them all in a load of pain.

"Breaking userspace" does not begin to cover it.
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2100
Location: Finland

PostPosted: Thu Apr 25, 2013 6:18 am    Post subject: Reply with quote

steveL wrote:
Furthermore the new default simply takes over and breaks existing setups.


No it doesn't. It stops you at multiple points, first at the news item, second at the red warning in post installation phase. Or are you telling me you are blindly upgrading core packages related to booting?

GLEP: 42
Title: Critical News Reporting

http://www.gentoo.org/proj/en/glep/glep-0042.html
Back to top
View user's profile Send private message
Yamakuzure
Veteran
Veteran


Joined: 21 Jun 2006
Posts: 1340
Location: Bardowick, Germany

PostPosted: Thu Apr 25, 2013 7:01 am    Post subject: Reply with quote

ssuominen wrote:
steveL wrote:
Furthermore the new default simply takes over and breaks existing setups.
Or are you telling me you are blindly upgrading core packages related to booting?
It seems that many people do that.

However, we have two servers here, both having eth0 to eth15, all in use, because both have many NAS attached using iSCSI. The renaming of the network devices was a one-time-work of about 15 minutes per server.

So what the hell is everybode whining about? I don't get it. Please, folks, change, add, remove or swap any hardware in a Windows Server (or desktop) and see what's happening.
_________________
I *do* know that I easily aggravate people due to my condensed writing. Rule of thumb: If I wrote anything that can be understood in two different ways, and one way offends you, then I meant the other! ;)
Back to top
View user's profile Send private message
CneGroumF
n00b
n00b


Joined: 04 Aug 2005
Posts: 57
Location: France

PostPosted: Thu Apr 25, 2013 7:56 am    Post subject: Reply with quote

Yamakuzure wrote:
The renaming of the network devices was a one-time-work of about 15 minutes per server.

This delay is very optimistic. I'm sure you don't use netfilter/iptables, or specific routing rules on your servers. Nor static IPs on your NICs (either you're lucky, and the order of the interfaces doesn't change, or you have to tcpdump on each to know who talks to who).

Quote:
Please, folks, change, add, remove or swap any hardware in a Windows Server (or desktop) and see what's happening.

I don't use to compliment M$, but the names of the interfaces are really persistent, on Windows. The drivers are antoher problem.
Back to top
View user's profile Send private message
Yamakuzure
Veteran
Veteran


Joined: 21 Jun 2006
Posts: 1340
Location: Bardowick, Germany

PostPosted: Thu Apr 25, 2013 9:04 am    Post subject: Reply with quote

CneGroumF wrote:
Yamakuzure wrote:
The renaming of the network devices was a one-time-work of about 15 minutes per server.

This delay is very optimistic. I'm sure you don't use netfilter/iptables, or specific routing rules on your servers. Nor static IPs on your NICs (either you're lucky, and the order of the interfaces doesn't change, or you have to tcpdump on each to know who talks to who).
*sh, find, grep, sed and"perl -p -i.bak -e 's/<your regex here>/<your substitution here>/mg'". It's all there.
And with
Code:
for i in /sys/class/net/* ; do echo "$(basename $i) => $(udevadm test-builtin net_id $i 2>/dev/null | grep NET_NAME | cut -d '=' -f 2)" ; done
you know *before* you reboot. The order of the interfaces and so on are irrelevant then. Was "ethX", becomes "foo". Search&Replace&BeDone.

But that's the point. If you read the news item and the post-merge information, it's really easy.

Why? Because all you need is there. Right on the screen. And that was the whole point.
CneGroumF wrote:
Quote:
Please, folks, change, add, remove or swap any hardware in a Windows Server (or desktop) and see what's happening.

I don't use to compliment M$, but the names of the interfaces are really persistent, on Windows. The drivers are antoher problem.
Yes. Driver configuration. And "configuration" is all everybody is complaining about.
_________________
I *do* know that I easily aggravate people due to my condensed writing. Rule of thumb: If I wrote anything that can be understood in two different ways, and one way offends you, then I meant the other! ;)
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2240
Location: Dallas area

PostPosted: Thu Apr 25, 2013 9:21 am    Post subject: Reply with quote

Yamakuzure wrote:
Please, folks, change, add, remove or swap any hardware in a Windows Server (or desktop) and see what's happening.


That has got to be one of the stupidest strawman attempts at an argument that I've ever heard. :roll:
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.9.1-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2240
Location: Dallas area

PostPosted: Thu Apr 25, 2013 9:26 am    Post subject: Reply with quote

CneGroumF wrote:
Yamakuzure wrote:
The renaming of the network devices was a one-time-work of about 15 minutes per server.

This delay is very optimistic. I'm sure you don't use netfilter/iptables, or specific routing rules on your servers. Nor static IPs on your NICs (either you're lucky, and the order of the interfaces doesn't change, or you have to tcpdump on each to know who talks to who).


I'm sure his system is as simplistic as his arguments.
But the real key is that the "one time work" was simply not needed for
the great majority of users but was foisted on them anyway by moronic developers.

Edit to add:
Note: I said developers not ebuild maintainers (added before someone takes it the wrong way)

Edit to add2:
[rant]What many seem to be forgetting in their chanting of "a simple one time change" is that starting with 171 it's been several "one time changes" always impacting the end user. Adding DEVTMPFS (added because of whining by udev developers) which necessitated a kernel recompile, making people with a separate /usr do something different (a new initramfs) simply because the udev devs put no forethought into their changes in their mad rush to make the latest, greatest shiny new thing, and to hell with the end users, now renaming interfaces that have been stable for several years (impacting many people). And despite the pronouncement that things will be stable for the next 2+ years people don't really believe that and are preparing for the worst. So pardon us that haven't drunk the koolaid about it being stable from now on. People would like a viable option (no, being told just go with the latest isn't appealing to many) to this seemingly endless mad rush for the newest shiny object. [/rant]

All these various problems are caused by the systemd maintainers that have taken over udev
trying to make udev fit cleanly with systemd not the other way around. If udev were a brand
new product that would be no problem, but it isn't and the changes to udev (simply to make
life easier for systemd devs) is a wrong headed approach IMO.


Anyway y'all have fun.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.9.1-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2100
Location: Finland

PostPosted: Thu Apr 25, 2013 11:55 am    Post subject: Reply with quote

Anon-E-moose wrote:
CneGroumF wrote:
Yamakuzure wrote:
The renaming of the network devices was a one-time-work of about 15 minutes per server.

This delay is very optimistic. I'm sure you don't use netfilter/iptables, or specific routing rules on your servers. Nor static IPs on your NICs (either you're lucky, and the order of the interfaces doesn't change, or you have to tcpdump on each to know who talks to who).


I'm sure his system is as simplistic as his arguments.


Well, within same 15 minutes I configured 12 servers at work for the enx* based MAC names. It took of course a bit time to verify everything was in order (that every service came up as advertised, which they did). And the servers are far from simple. However it doesn't take long to grep /etc, check iptables-save, init.d symlinks, etc.

Anon-E-moose wrote:

Edit to add2:
[rant]What many seem to be forgetting in their chanting of "a simple one time change" is that starting with 171 it's been several "one time changes" always impacting the end user. Adding DEVTMPFS (added because of whining by udev developers) which necessitated a kernel recompile, making people with a separate /usr do something different (a new initramfs) simply because the udev devs put no forethought into their changes in their mad rush to make the latest, greatest shiny new thing, and to hell with the end users, now renaming interfaces that have been stable for several years (impacting many people). And despite the pronouncement that things will be stable for the next 2+ years people don't really believe that and are preparing for the worst. So pardon us that haven't drunk the koolaid about it being stable from now on. People would like a viable option (no, being told just go with the latest isn't appealing to many) to this seemingly endless mad rush for the newest shiny object. [/rant]


Don't act like the CONFIG_DEVTMPFS change is anything but part of the normal system configuration on a rolling distribution, it's no way unique when compared to previous CONFIG_SYSFS*, CONFIG_IDE, CONFIG_INOTIFY*, CONFIG_EPOLL, CONFIG_SIGNALFD, CONFIG_BLK_DEV_BSG, ... all of which would have stopped the booting process if left unattended for.
The /usr change never impacted stable users either.
So stable users really got all of them at once and needed to configure the system only once.
If you are using ~arch then you should already know to be prepared to do them more often -- it's a moving target and is designed to be so.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2391
Location: The Peanut Gallery

PostPosted: Thu Apr 25, 2013 3:21 pm    Post subject: Reply with quote

ssuominen wrote:
steveL wrote:
Furthermore the new default simply takes over and breaks existing setups.


No it doesn't. It stops you at multiple points, first at the news item, second at the red warning in post installation phase. Or are you telling me you are blindly upgrading core packages related to booting?

Oh very clever: put it all on me. Well, just so you know, I do not blindly upgrade: in fact update has had udev in /etc/warning for the last year, in various versions, thanks to the nuttiness that its devs have been putting end-users through. I am actually still on 171-r9. So you tell me: am I blindly upgrading without considering the impact on my machine?

Further, you're completely missing my point: I'm talking about the software as released by upstream, not as packaged by you or any other distro.

Some of us consider software in that regard, as a work put out by someone, and not just as what we can get from distro-X, or "does it flash when an email has arrived even though it's nothing to do with email, cos that's really important.."
ssuominen wrote:
The /usr change never impacted stable users either.

LMAO that is the biggest load of crap I've heard in a long time. Seriously man, take a break, as you appear to be getting burnt-out. Please bear in mind I have a lot of respect for Gentoo and the work that goes into it, and for you. But you're off your tits if you think the changes in the last year have not affected stable users.

As for "it's just configuration" the point you're missing is that it's not just a change in the configuration for udev, which could be seen as part of a normal upgrade: it's the cascade of changes it requires in all other configuration files, which is much more relevant for network admins.

So bleating about how it was quite easy for a desktop user to change his eth0 to ensp5x20 (just rename the initscript and edit the firewall configuration) is completely pointless. Firstly, these changes don't do anything for the vast majority of desktop users, since they were fine with eth0 and wlan0 already; additionally that desktop user is liable to pain when s/he plugs a new device in, which is hardly "a robust solution for the modern era." Secondly it says nothing at all about the amount of work that would be required for a multi-NIC admin, who may well have many custom config files tied into their network setup. You know, that setup they were advised to use and did so in good faith.

Sure, we can work around that with scripts et al. But there has to be a damn good reason to go making wholesale changes across the board like that: it's a big ask, and requires an investment of resources in testing. It's not something admins worth the salt like doing: they prefer fire-and-forget for damn good reasons.
And a flaky design that is supposedly meant for desktop users but makes their life harder, while not doing anything at all for net admins, is not it.

Frankly I find it disturbing that I even have to argue this point. Programmers used to be justifiably proud of their craft, and in making things work for end-users, most especially when upgrading. It used to be something we'd want our users to look forward to, so we took effort to make it into a smooth process, doubly so for beta-testers as they were our power-users, and gave us the best feedback, and we'd have the most discussion with them.

So I won't any more: good luck with the kool-aid. I hope it does what they told you, and not what it appears to. (The emperor has no clothes on, btw.)

Let's face it, beta-testers and free QA and bug-fixing is all we are for RedHat. Only we're also competition.
_________________
creaker wrote:
systemd. It is a really ass pain

update - "a most excellent portage wrapper"

#friendly-coders -- We're still here for you™ ;)
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2240
Location: Dallas area

PostPosted: Thu Apr 25, 2013 7:20 pm    Post subject: Reply with quote

steveL wrote:
Frankly I find it disturbing that I even have to argue this point. Programmers used to be justifiably proud of their craft


Real programmers still are.

But I won't argue about udev any more as it seems that some of those responding have a severe case of reading comprehension disorder.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.9.1-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 31708
Location: 56N 3W

PostPosted: Thu Apr 25, 2013 8:34 pm    Post subject: Reply with quote

The whole thing reminds me of this
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3, 4  Next
Page 3 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum