On Thu, Jan 5, 2012 at 03:21, Canek Peláez Valdés <can...@gmail.com> wrote: > On Wed, Jan 4, 2012 at 6:35 AM, Pandu Poluan <pa...@poluan.info> wrote: >>
----- >8 snip >> >> You were there in the thread linked by Walt, udev is just one of several >> packages maintained by RH people that *demands* /usr to be mounted during >> boot. >> >> And the RH devels insistence to deprecate /bin, /sbin, /usr/sbin... >> >> I'm getting depressed. One battle might be won (mdev vs udev), but there's >> still a war against the RH braindeadness... > > I'm sorry to tell you this, but (as admirable as it could be), the > mdev hack to use it instead of udev is not a "victory". We are not at > war, in the first place; and in the second place, the mdev hack would > be used by a handful of guys bent on refusing a change that, like it > or not, would in the end come. Like Gentoo on FreeBSD, it would be a > nice hack, maybe even worthy of applause, but in the end irrelevant: a > toy. A cute, entertaining (and, in a few cases, useful) toy. But a toy > nonetheless. > I may have been slightly hyperbolic in my usage of "battle" and "war", but then again why must Gentoo bend over to the wills of RH developers who insist on doing things their way? And mdev might be a 'toy' to you, but embedded Linux developers will vehemently disagree with you. And based on the responses in this thread, server guys will also disagree with you. For these two groups, mdev is not a toy but a necessity. > The heavy development will continue to happen in udev, and the devices > that will dominate in the future (touchscreens, bluetooth input and > audio devices, hardware that has a highly dynamic change rate) will > only be supported by udev. The mdev hack will be useful maybe to only > some guys, and even then udev would be able to do the same (and more). > The ability of mdev is more than enough for those handling the back-end servers, thank you. udev just adds bells and whistles *not* needed in server environs. > The use of an initramfs (or, alternatively, having /usr in the same > partition as /), and maybe the move of /bin to /usr/bin and /lib to > /usr/lib will be made, and in the future most of the interesting > software will simply assume that this is how a system works. Maybe we > will even stop to use the ridiculous short directory names from the > stone age, and we will start using sensible names: > > /usr -> /System > /etc -> /Config > /var -> /Variable > I can agree with sensible names. Unfortunately, forcing sensible names upon servers *already* in the field is a sure fire recipe to disaster. Besides, the FHS itself explains the reasoning behind each directory. As to the forced use of initramfs, again it runs counter to the wishes of embedded Linux people (for whom storage is at a premium) and the wishes of server people (whom would prefer as few 'breaking points' as possible). (As a side note, initramfs introduces not one, but *MANY* additional breaking points: the tool used to generate the initramfs might be buggy and/or feature-incomplete, the initramfs itself might encounter an unrecoverable error, the pivot_root or chroot might snag upon some not-so-edge cases, etc.) > I feel a deep respect for the people working on making mdev a > "replacement" of udev; it is not an easy task (even if it only works > for a really small subset of the use cases udev covers), and something > that I certainly would never do. But their hack (as beautiful as it > may be) will never be used by the majority of Linux users, and > probably not even by the majority of Gentoo users (if my > interpretation of the discussion on gentoo-dev is correct). And with > the pass of time it will be harder and harder to keep the hack working > with new hardware, new software, and new use cases. > > But, hey, this is FOSS; you guys go nuts hacking in whatever feature > (or anti-feature) you like. As in the case of this mdev hack, it may > even be included in the Gentoo ebuilds. Just don't expect it to be > supported forever, don't expect it to support general-purpose setups, > and certainly don't call it "a victory". It's just the same history as > always: the people writing the code are the ones calling the shots. > As long as there are embedded Linux, mdev *will* be maintained and supported in perpetuum. Besides, the so-called mdev "hack" is really just a small script which gets executed before "init" runs. The other convoluted steps waltdnes had provided is just necessary to fix the virtual/dev-manager ebuild to allow using mdev instead of udev (and, with the acceptance of his bug report, we will soon see in the main portage tree). The actual steps to replace udev with mdev are very simple. Rgds, -- FdS Pandu E Poluan ~ IT Optimizer ~ • LOPSA Member #15248 • Blog : http://pepoluan.tumblr.com • Linked-In : http://id.linkedin.com/in/pepoluan
