| 1 |
From: Dale [mailto:rdalek1967@×××××.com] |
| 2 |
Sent: Monday, March 12, 2012 7:23 PM |
| 3 |
|
| 4 |
> I like that quote. I may not be dev material but I know this /usr mess |
| 5 |
> is not right. The only reason it is happening is because of one or two |
| 6 |
> distros that push it to make it easier for themselves. |
| 7 |
|
| 8 |
If that's honestly what you think then I suspect you don't understand the problem as well as you believe. |
| 9 |
|
| 10 |
The idea of trying to launch udevd and initialize devices without the software, installed in /usr, which is required by those devices is a configuration that causes problems in many real-world, practical situations. |
| 11 |
|
| 12 |
The requirement of having /usr on the same partition as / is also a configuration that causes problems in many real-world, practical situations. |
| 13 |
|
| 14 |
The requirement to ensure that /usr is *somehow available* before launching udevd is a configuration that, I am told, causes problems in some specialized real-world, practical situations. (I am ignoring "problems" such as "initramd might possibly break maybe" or "that's more work than I want to do" as being the expected griping that always happens when you ask a group of geeks to change something.) |
| 15 |
|
| 16 |
It is impossible for udev to solve the problem for all users in all configuration. Given the three readily available options, the one that makes the most sense from a software engineering standpoint is to choose option three, thus ensuring that your solution pisses off the smallest subset of users. Those users are then free to create a solution that better suits their needs, such as replacing udev with different software which made a different choice. |
| 17 |
|
| 18 |
To call one option a "mess" that is "not right" is both an unrealistic oversimplification of a complex problem and utterly unfair to the people trying to solve that problem. |
| 19 |
|
| 20 |
--Mike |
Archives