You are not logged in.
Pages: 1
While googling for something completly different I ran across this HOWTO :
http://kerneltrap.org/node/view/2439
(it's a bit down that page)
I haven't studied that file myself yet (but I will) and thought it might be interesting to some of you.
Offline
it boggles my mind that they would not mark udev as experimental in the kernel and have devfs not marked as obsolete. i would hardly consider something that is not completely viable yet as anything but experiemental.
this is another issue that has made me start to question the kernel developers approach.
AKA uknowme
I am not your friend
Offline
it boggles my mind that they would not mark udev as experimental in the kernel and have devfs not marked as obsolete. i would hardly consider something that is not completely viable yet as anything but experiemental.
this is another issue that has made me start to question the kernel developers approach.
yes, at least temporarely it would be better to mark it experimental, but the background is:
devfs was left without developer and udev started with full power of some people having great ideas how to make a better devfs --- devfs is "really old" (relatively meant) and it will be soon obsolete, because nobody is working on it since about half a year or so
kernel-docs are made that people do not start creating something new that relies on devfs, because devfs is a dead project and udev is the future --- archlinux has to merge sooner or later to the newer system
The impossible missions are the only ones which succeed.
Offline
devfs was left without developer and udev started with full power of some people having great ideas how to make a better devfs --- devfs is "really old" (relatively meant) and it will be soon obsolete, because nobody is working on it since about half a year or so
well partially true. based on very prliminary decisions it was arbitrarily decided that udev would replace devfs. whichever developers decided this did not inform or even talk to the developer who was responsible for devfs. summarily feeling left out of the loop and abandoined he left the development team and the kernel team has since been waiting for their new brainchild actually come to be.
but what can you expect from a group that is controlled largely by kids. the move they made was rude, very unbusinesslike, etc. it has not been their only poor decision in the last year. some of their decisions on how to handle serious kernel insecurities was pretty bad too.
then there is the constant removal, addition, or change of pats of the kernel without much announcement. for example how is someone who does not compile their own kernels supposed to keep abreast of changes as small as removing the generic usb scanner module? are they supposed to go through the every so tedious banter of a changelog that is horribly formatted? then they find they have to use a library that comes with documentation that is not current and only makes sense if you know the technical specifics of usb.
changelogs are great for people who what to know all sorts of bring data but it is no help to people who want to know what the f**k happened to support for their devices. marking functional devfs support as obsolete is a bad decision too as a newbie my not decide to compile support in when it is need.
and so forth.
AKA uknowme
I am not your friend
Offline
whichever developers decided this did not inform or even talk to the developer who was responsible for devfs.
it was the other way: the developer for devfs didnt touch the code for 5 months and people tried to contact him (over email, the only way possible) but no answer for long, so they decided to rewrite it (just to keep it working and under developement .. and by the way enhance it --- just to have an alternative to a notlonger developing module that sooner or later will break with something else)
i agree fully with you, that the anouncements/information form/to the kernel-developers are not really good --- they need a forum or at least some board to keep news sumarized // "unbusinesslike" are a lot of people .. but we all do all we do for opensource-things mostly because of passion to the matter and for free ... so it's not "business" it's more "passion" --- the only thing is: someone needs to coordinate this doings all around ... at least for the projects there are freshmeat.net and simmilar portals that at least keep some parts of opensoure-comunities together and bring order in passion ---> there should be some comunity/portal that handles this for kernel.org
The impossible missions are the only ones which succeed.
Offline
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
yes, i know, but this only a good try, not the solution --- they have news there, but if you search directly for something, you mostly cannot find it on kerneltrap -> google is more usefull in some ways
there must be something like a meta-forum, where you can find/post infos to each config-option/module in the kernel where you can discuss/search for info about why/what/how to use this module
The impossible missions are the only ones which succeed.
Offline
Seems like there are plenty of people misunderstanding udev...
Udev is totally in userspace, so you won't find an udev option in the kernel, thus it can't be marked experimental either. The primary goal of udev is consistent device naming, no matter in what order or where you plug in the device, dynamic /dev is more a free extra feature. Marking devfs obsolete isn't a bad idea if there is no maintainer, if it wasn't then people that like devfs wouldn't wake up and propose to maintain it. Devfs isn't gone, and will be still here for some time. No one forces you to drop devfs and to use udev, so what are you complaining anyway? When udev is stable it will be much better than devfs, so yet another reason to mark devfs obsolete. The argument that marking devfs obsolete can confuse newbies isn't a very strong one, either your distro uses devfs or not, the person should know that, not guess coincidentaly the right option.
See http://kernel.org/pub/linux/utils/kerne … v_vs_devfs for some extra info, or search the kernel mailinglist for udev and devfs if you want to know more details.
Offline
personally i doubt many noobs would decide to just go and compile a kernel anyway, at least before reading something about it first.
i remember a webchat with linus that was on linuxtoday not so long ago talking about devfsd and he was saying how devfsd's code was so broken that it couldnt be fixed anyway and they wanted to upgrade it.
i do agree with the comments about the scanner module, that was a hugely bad desision imo i;ve never been able to get my scanner working as well as it did with libusb, it works but not as well as it was.
"Covered in blood, Cant understand" - Biffy Clyro
Offline
Pages: 1