First, let me start out by stating that I use Unix (Solaris) almost every day. While I am not the master of all things Unix, I have a better than average knowledge of it, I like to think. I like a great many things about Unix. Pipes are probably the most useful concept I have ever seen in computer science. It is componentization of software some 20 years before it came into vogue.
While I like Unix, it has some issues, too. Some ideas whose time is past. Some concepts that are outdated and need to be replaced. I believe that foremost among these archaic constructs is /dev.
I can hear the wailing already. Hear me out. For those not initiated in the rites of the acolytes of Bell Labs, /dev is the directory where devices are mounted. So you could look at see /dev/tty for a teletype device. Or /dev/prt for a printer. Back in the days when everything was character based, this was exceptionally powerful. If you wanted to get input from a device, you could do it right from the command line. cat < /dev/foo. Very nice. Or send output to a device - cat tmp.txt > /dev/bar. This has served us well for a very long time, but that time is past.
The first issue that I take with this approach is that most devices are not simple minded printers or modems or teletypes anymore. It doesn't make any sense to say cat < /dev/scanner. Few people want to deal with joysticks, ethernet cards or video cards from the command line in this way. Much of the benefit of making your devices accessible easily from the shell is gone.
Secondly, / is a place for files. Overloading it with devices and other various hardware interfaces doesn't make sense to the average user. Why does it make sense to have a video card in /dev?
Thirdly, from a programmer's point of view, using *only* open, close, read, write and ioctl on devices no longer makes sense. It forces us to funnel every possible command that couldn't be forseen by guys with teletypes to go through ioctl. Think about the act of setting up a scanner for scanning. You end up with code that is very hard to read.
The ioctl commands must be published and (hopefully) standardized. Say you are writing a CD ripper. If one CD Rom's ioctl for "start rip on track 4" is different from a different driver's command, your code must account for that, if you want to work with both devices.
With /dev, you have to know the name of the device that you are interested in. Or, at least, what directory the device driver will publish itself to (yes, that is hard coded). So if you publish an app for, say, MIDI manipulation, you will probably search for /dev/serial1. But what if someone has a /dev/usb/midi/1 device? You can't work with it.
The /dev directory has been filled, too, with "psuedo" devices. The most obvious is /ptty - psuedo tty's for use with PCs. But there are others - kmem (kernel memory) is a good example. This is a nightmare for beginning users.
While I could go on, I have to leave room for the solution to this issue...
BeOS has a wonderful concept called rosters. A roster is basically an "intelligent" keeper of a list. You can use the roster's API questions and it can respond with items or sublists. My concept is a device roster. All devices would have a roster entry that allows you to get one or more device classes back. You can query based on type of data or on device type. For example, you could ask for all devices that can return anything in the mime type "image/". This should return digital cameras, scanners, hard disks, etc. Or you could query for every printer device, etc. All of these devices should derive from a common class (BDevice or some such), but be subclassed (maybe more than once). As an example - a CD ROM drive could be BDevice-->BMassStorage-->BCDRom. This would allow developers some flexability in addressing devices - they could choose to dig deep in the features or they could stay shallow and address more devices.
On a related note, I think that this would open the door to a different type of file panel. How about a BImageFilePanel? One that queries the device system for image yielding devices and has neat features like thumbnails, etc? Or a BSoundFilePanel that lets you play snippets before loading the whole file?
This system should also make it easier to deal with device configuration. A single application could exist that shows all of the devices. They could be configured via a single GUI, using standardized interfaces.
There are certainly details that would need to be worked out, but I believe that this system would be far more powerful and would shed the legacy pain of /dev.