1 |
On Thu, Jan 5, 2012 at 03:21, Canek Peláez Valdés <caneko@×××××.com> wrote: |
2 |
> On Wed, Jan 4, 2012 at 6:35 AM, Pandu Poluan <pandu@××××××.info> wrote: |
3 |
>> |
4 |
|
5 |
----- >8 snip |
6 |
|
7 |
>> |
8 |
>> You were there in the thread linked by Walt, udev is just one of several |
9 |
>> packages maintained by RH people that *demands* /usr to be mounted during |
10 |
>> boot. |
11 |
>> |
12 |
>> And the RH devels insistence to deprecate /bin, /sbin, /usr/sbin... |
13 |
>> |
14 |
>> I'm getting depressed. One battle might be won (mdev vs udev), but there's |
15 |
>> still a war against the RH braindeadness... |
16 |
> |
17 |
> I'm sorry to tell you this, but (as admirable as it could be), the |
18 |
> mdev hack to use it instead of udev is not a "victory". We are not at |
19 |
> war, in the first place; and in the second place, the mdev hack would |
20 |
> be used by a handful of guys bent on refusing a change that, like it |
21 |
> or not, would in the end come. Like Gentoo on FreeBSD, it would be a |
22 |
> nice hack, maybe even worthy of applause, but in the end irrelevant: a |
23 |
> toy. A cute, entertaining (and, in a few cases, useful) toy. But a toy |
24 |
> nonetheless. |
25 |
> |
26 |
|
27 |
I may have been slightly hyperbolic in my usage of "battle" and "war", |
28 |
but then again why must Gentoo bend over to the wills of RH developers |
29 |
who insist on doing things their way? |
30 |
|
31 |
And mdev might be a 'toy' to you, but embedded Linux developers will |
32 |
vehemently disagree with you. |
33 |
|
34 |
And based on the responses in this thread, server guys will also |
35 |
disagree with you. |
36 |
|
37 |
For these two groups, mdev is not a toy but a necessity. |
38 |
|
39 |
> The heavy development will continue to happen in udev, and the devices |
40 |
> that will dominate in the future (touchscreens, bluetooth input and |
41 |
> audio devices, hardware that has a highly dynamic change rate) will |
42 |
> only be supported by udev. The mdev hack will be useful maybe to only |
43 |
> some guys, and even then udev would be able to do the same (and more). |
44 |
> |
45 |
|
46 |
The ability of mdev is more than enough for those handling the |
47 |
back-end servers, thank you. |
48 |
|
49 |
udev just adds bells and whistles *not* needed in server environs. |
50 |
|
51 |
> The use of an initramfs (or, alternatively, having /usr in the same |
52 |
> partition as /), and maybe the move of /bin to /usr/bin and /lib to |
53 |
> /usr/lib will be made, and in the future most of the interesting |
54 |
> software will simply assume that this is how a system works. Maybe we |
55 |
> will even stop to use the ridiculous short directory names from the |
56 |
> stone age, and we will start using sensible names: |
57 |
> |
58 |
> /usr -> /System |
59 |
> /etc -> /Config |
60 |
> /var -> /Variable |
61 |
> |
62 |
|
63 |
I can agree with sensible names. Unfortunately, forcing sensible names |
64 |
upon servers *already* in the field is a sure fire recipe to disaster. |
65 |
|
66 |
Besides, the FHS itself explains the reasoning behind each directory. |
67 |
|
68 |
As to the forced use of initramfs, again it runs counter to the wishes |
69 |
of embedded Linux people (for whom storage is at a premium) and the |
70 |
wishes of server people (whom would prefer as few 'breaking points' as |
71 |
possible). |
72 |
|
73 |
(As a side note, initramfs introduces not one, but *MANY* additional |
74 |
breaking points: the tool used to generate the initramfs might be |
75 |
buggy and/or feature-incomplete, the initramfs itself might encounter |
76 |
an unrecoverable error, the pivot_root or chroot might snag upon some |
77 |
not-so-edge cases, etc.) |
78 |
|
79 |
> I feel a deep respect for the people working on making mdev a |
80 |
> "replacement" of udev; it is not an easy task (even if it only works |
81 |
> for a really small subset of the use cases udev covers), and something |
82 |
> that I certainly would never do. But their hack (as beautiful as it |
83 |
> may be) will never be used by the majority of Linux users, and |
84 |
> probably not even by the majority of Gentoo users (if my |
85 |
> interpretation of the discussion on gentoo-dev is correct). And with |
86 |
> the pass of time it will be harder and harder to keep the hack working |
87 |
> with new hardware, new software, and new use cases. |
88 |
> |
89 |
> But, hey, this is FOSS; you guys go nuts hacking in whatever feature |
90 |
> (or anti-feature) you like. As in the case of this mdev hack, it may |
91 |
> even be included in the Gentoo ebuilds. Just don't expect it to be |
92 |
> supported forever, don't expect it to support general-purpose setups, |
93 |
> and certainly don't call it "a victory". It's just the same history as |
94 |
> always: the people writing the code are the ones calling the shots. |
95 |
> |
96 |
|
97 |
As long as there are embedded Linux, mdev *will* be maintained and |
98 |
supported in perpetuum. |
99 |
|
100 |
Besides, the so-called mdev "hack" is really just a small script which |
101 |
gets executed before "init" runs. The other convoluted steps waltdnes |
102 |
had provided is just necessary to fix the virtual/dev-manager ebuild |
103 |
to allow using mdev instead of udev (and, with the acceptance of his |
104 |
bug report, we will soon see in the main portage tree). The actual |
105 |
steps to replace udev with mdev are very simple. |
106 |
|
107 |
Rgds, |
108 |
-- |
109 |
FdS Pandu E Poluan |
110 |
~ IT Optimizer ~ |
111 |
|
112 |
• LOPSA Member #15248 |
113 |
• Blog : http://pepoluan.tumblr.com |
114 |
• Linked-In : http://id.linkedin.com/in/pepoluan |