Linked by Thom Holwerda on Sat 23rd Aug 2008 15:31 UTC
"Once upon a time, a Linux distribution would be installed with a /dev directory fully populated with device files. Most of them represented hardware which would never be present on the installed system, but they needed to be there just in case. Toward the end of this era, it was not uncommon to find systems with around 20,000 special files in /dev, and the number continued to grow. This scheme was unwieldy at best, and the growing number of hotpluggable devices (and devices in general) threatened to make the whole structure collapse under its own weight. Something, clearly, needed to be done." The solution came in the form of udev, and udev uses rules to determine how it should handle devices. This allows distributors to tweak how they want devices to be handled. "Or maybe not. Udev maintainer Kay Sievers has recently let it be known that he would like all distributors to be using the set of udev rules shipped with the program itself." ComputerWorld dives into the situation.
Thread beginning with comment 327741
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
RE: Agreed, but maintain caution
by google_ninja on Sun 24th Aug 2008 04:03
in reply to "Agreed, but maintain caution"
Member since:2006-02-05
This system-by-system flexibility is where Linux is currently a lot stronger than Windows
Windows has had a HAL for over a decade now. Not the main thing I wanted to respond to, but the Linux HAL was far from revolutionary, it is something it was way behind on.
...and I fear if these type of standards were too prevelant, app writers would start depending on facts that are virtually always true by convention, rather than always true by specification.
<rant>
Convention is almost always more important, and more useful, then specifications. Specs are usually a lowest common denominator, and typically convention goes far beyond specification. For example, the ANSI SQL spec has no way to do stored procedures in a database. SProcs are a vital feature of any half-way decent RDBMS, and any one worth its salt has a really good implementation of the feature. If you put out a database and didn't have support for sprocs, chances are nobody would ever use your product. They would have good reason too.
The other thing is Specs are generally put out by consortiums of companies with competing interests, and what gets in or doesn't tends to have as much to do with politics as technical merit. Conventions occur when everyone does something a certain way because that is the way that has proven itself to be the best.
</rant>
Edited 2008-08-24 04:05 UTC
RE[2]: Agreed, but maintain caution
by nick8325 on Sun 24th Aug 2008 11:44
in reply to "RE: Agreed, but maintain caution"
Member since:2005-10-06
Windows has had a HAL for over a decade now. Not the main thing I wanted to respond to, but the Linux HAL was far from revolutionary, it is something it was way behind on.
The Windows HAL is not the same as HAL the program, even though they have the same name. HAL the program provides information to user programs about devices and suchlike (the kernel already provided this information; HAL just makes it easier to get it); hal.dll is the lowest level of NT, and performs I/O and handles interrupts for the NT kernel.
RE[2]: Agreed, but maintain caution
by sbergman27 on Sun 24th Aug 2008 20:08
in reply to "RE: Agreed, but maintain caution"
Member since:2005-07-24
Convention is almost always more important, and more useful, then specifications.
Specification: This is what we want you to do.
Convention: This is how things are actually done in the real world.
Convention beats specification most every time. Almost by definition, really.
The standard udev rules may need to put up with some ugly cruft for a while, in the form of legacy device names. Of course, it's easy for me to say that since I don't have to support the additional maintenance overhead. But there is a notable (excruciatingly slow, but relentless and pragmatic) trend to eliminate arbitrary "differences which make no difference" in our Linux world. Someday, things'll be brighter. And this issue will be a non-issue that we will all have to give newbies an historical perspective upon before explaining the actual "problem".
Our lives and our consciousnesses are but cursors on the progress bar of time.
Edited 2008-08-24 20:10 UTC
RE[2]: Agreed, but maintain caution
by thecwin on Mon 25th Aug 2008 14:42
in reply to "RE: Agreed, but maintain caution"
Member since:2006-01-04
As others have said, Linux HAL is something different to Windows HAL entirely.
About your convention argument, it's true that convention pretty much always is more important than specification for the real world. However what I'm trying to argue is that application writers should be trying to depend on something that will *always* be true, for instance, they can find the first hard drive through hal, rather than, for example the first hard drive is always /dev/hda. Poor example but I think it illustrates what I mean.
In the case of SQL, if you're intending for your program to work with every SQL implementation, you shouldn't in that case use SQL SPs. You could target your application at all SQL implementations that support SPs. I take it that most app developers are targetting all modern Linux systems, rather than ones configured in a particular manner.
The point is, while convention essentially overrides specification, trying to follow the specifications will enable users, administrators, packagers, etc. to be more sure that it'll work properly on their system without being dependent on some unwritten convention.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2006-01-04
I agree with the idea that most mainstream distros should be using the same default udev rules, but I don't think application writers should rely the /dev filenames to always be the same. The nice thing about udev and all the other various new Linux hardware APIs (e.g. HAL) is that they provide an abstraction above direct traditionally populated /dev filesystem queries. This is good for many reasons that I'm sure many people here are aware of, not in the least is extensibility.
The rules should be written for the ease of understanding and maintenance by system administrators, and should remain flexible for individual sysadmins particular needs. Software writers should ensure their software works even when you play around with the rules. This system-by-system flexibility is where Linux is currently a lot stronger than Windows, and I fear if these type of standards were too prevelant, app writers would start depending on facts that are virtually always true by convention, rather than always true by specification.
Edited 2008-08-23 16:46 UTC