Slashdot Mirror
UDI spec 0.90 available for review
The Uniform Driver Interface spec is available
for public review until May 31. UDI is an initiative
proposed by Intel and proprietary Unix vendors to create
a single driver API. This would allow UDI drivers to run on
any hardware platform and UDI-supporting OS without changing
their source-code.
I didn't mean the Parallel Port was going away (although its "optional" in the PC 99 spec). Only that ParPort scanners, video capture stuff, hard drives, and so on have already been pretty much replaced by USB, which is fine because the ParPort has always seemed kinda flaky as a perhiphreal interface.
--
Business. Numbers. Money. People. Computer World.
The current Linux driver model is working just fine.
Yes, unless you have a box which Linux doesn't support, or doesn't support well. Or you are trying to run evil closed OSs like Solaris x86 or SCO. As far as a production system goes, the Linux decision might come down to whether a driver is available or not.
And don't forget all major commerical unixes will run on IA64, along with Linux. UDI support will be pretty much mandatory for any hardware vendor. Yet you are proposing looking this gift horse in the mouth to wait for someone to write a Linux native in their spare time.
My understanding is that non-GPL drivers are specifically allowed by the Linux licence, probably to encourage commercial support. And the native Linux interface is not going away, if there are are performance problems or you are worried about freedom issues.
--
Business. Numbers. Money. People. Computer World.
For those of us who run machines for profit-making corporations there's also the Best Possible Server Good Thing (tm). A different sort of ideology.
--
Business. Numbers. Money. People. Computer World.
OK, I stand corrected. Although, it does say Copyright Microsoft all over it, with no Adaptech copyright.
--
Business. Numbers. Money. People. Computer World.
Okay, now I know that this post will be followed with "But my x doesnt work!" And obviously we have a little ways to go, but I didn't think that drivers were really a problem for Linux.
My Intel ActionMedia II Display Adapter/A (speaking of Intel) isn't supported. I want video4linux for it NOW!
Admittidly, I'd like to see usb support (Inaky?) now, but it seems to me that Linux has superior device support right now. I mean, Linux supports things that NT doesn't for cripes sake. I am going to agree with the previous poster that this will only result in more binary only proprietary code. (Which is Bad).
<blush> Thank you.
USB support is there, but it's experimental. It at least works for the USB keyboard and mouse, and I believe there was an experimental audio module. It's in the same state as the Linux I20 modules--test 'em on a non-production environment and submit your bug reports or fix the code yourself and submit patches.
Cheers,
Joshua.
--jon. Postel is dead. May we all mourn his, and our, loss.
To application development that *USES* those device drivers, for example. Device drivers might be a fun geek hacking toy, and it's always nice to know whats going on at the lower level, but don't you think it's more important on a strategic basis for Linux developers to actually start moving into the Application development area rather than dealing with driver development?
It might seem like this at first, but when you lose the driver base, you're hosed. This bit us OS/2 users very hard. When your SCSI chipset doesn't work, your applications don't work, either. And having an ancient 16-bit driver that doesn't work with anything except disks does not count as support, even though some vendors (Rancho Technologies) thought it did.
The solution was to only buy IBM hardware or Adaptec hardware (until other drivers came out). So far, Linux has avoided that route.
Beware the binary primrose path. Maybe I'm just too much of a radical GNUer or maybe I'm just bitter after the OS/2 debacle--I just don't want to ever be burned by binary-only software again.
--jon. Postel is dead. May we all mourn his, and our, loss.
Have the ports of Linux to other platforms encouraged binary distributions? I don't think it has, and Linux does the same thing as UDI, just for programs (use it on many platforms without a recompile). Therefore, why would a port of UDI to Linux do this?
The question is, what does the UDI do other than do this? All the UDI does is enable support for non-free UNIX platforms. We need to ask: what do *we* get for this? If all we get is the a bunch of binary modules, we've gotten nothing. If we get Linux developers to write to the UDI, wow. We have yet another API abstraction.
But look at what SCO (and probably Solaris x86) get out of this. They get free code without having to give anything back, other than more binary-only modules which are a Bad Thing.
RMS has taught you paranoia well. Yes, perhaps SCO would then be able to use Linux drivers. Remember, however, it goes both ways. Linux will suddenly be able to use drivers from these other Unices. Is this a Bad Thing? I can't see why it would be.
Actually, working with OS/2 has taught me paranoia quite well. The OS/2 driver situation was simply terrible, and there was nothing a user could do about it. I don't want more binary modules, and that's all SCO has to offer. If I want a proprietary, binary-only system, I do run a Unixware 7.0 system, and could use it. (CDE isn't half bad, by the way, with the exception of the dog ugly Motif).
Certainly, that's your prerogative. But what if the Linux kernel had even better device support? Look at it this way: propple use different unices in different areas. But what if a developer could develop a single driver which could run on all Unices, and Linux to boot? That's going to be much more tempting than writing two drivers, one for Linux and one for everyone else.
We have that now. It's just as easy to implement support for the current Linux driver scheme in a Unix or Unix-like kernel as it would be to implement the UDI--and there aren't any UDI drivers today, unlike Linux drivers.
Be very, very, wary of those who promise you FREE binary code. It's always a bad thing, especially with a freed operating system.
--jon. Postel is dead. May we all mourn his, and our, loss.
That said, I have an honest question here which hadn't occurred to me before. Doesn't that defeat the whole point of writing a UDI driver? Why wouldn't a GPL'd driver be usable on a closed system?
I've never been 100% clear on this point, which seems to be at the center of the RMS vs ERS issue. Is this what they are talking about when they use the term "infects" in relation to the GPL, as in "we have to be careful not to use code that allows the GPL to "infect" the code tree" etc.?
I'll sit back, listen and learn now
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
It's called the Linux kernel's driver interface. It's clean and is very well documented. It has much example code available. O'Reilly has two well-written books on the topic.
Very true.
This UDI thing would also encourage distribution of binary driver images, which is a Bad Thing.
Have the ports of Linux to other platforms encouraged binary distributions? I don't think it has, and Linux does the same thing as UDI, just for programs (use it on many platforms without a recompile). Therefore, why would a port of UDI to Linux do this?
It's also probably an attempt by SCO to get a free ride by making future Linux drivers work with SCO (which would, BTW, be in grievous violation of the GPL).
RMS has taught you paranoia well. Yes, perhaps SCO would then be able to use Linux drivers. Remember, however, it goes both ways. Linux will suddenly be able to use drivers from these other Unices. Is this a Bad Thing? I can't see why it would be.
The current Linux driver model is working just fine. SCO and IBM can distill fun little PDF files if they like, but I'll keep on using the Linux kernel that I know works and has good device support today.
Certainly, that's your prerogative. But what if the Linux kernel had even better device support? Look at it this way: propple use different unices in different areas. But what if a developer could develop a single driver which could run on all Unices, and Linux to boot? That's going to be much more tempting than writing two drivers, one for Linux and one for everyone else.
This also harms the GPL. I wish Linus hadn't made that statement about binary-only modules being allowed, because it wasn't his statement to make. Binary-only anything in the Linux kernel is a grievous curse that must be avoided at all costs. Let us not sacrifice the freedom of Linux in the future on the altar of some extra device support today.
--jon. Postel is dead. May we all mourn his, and our, loss.
This is just another attempt of SCO, which is rapidly become the obsolete PC UNIX vendor, to make themselves important once more. It's also probably an attempt by SCO to get a free ride by making future Linux drivers work with SCO (which would, BTW, be in grievous violation of the GPL). This UDI thing would also encourage distribution of binary driver images, which is a Bad Thing.
The current Linux driver model is working just fine. SCO and IBM can distill fun little PDF files if they like, but I'll keep on using the Linux kernel that I know works and has good device support today.
--jon. Postel is dead. May we all mourn his, and our, loss.
Binary-only modules also violate the GPL, plain and simple. We can't tolerate that, or we might as well just rerelease Linux under the X11 licence.
The strength of the Linux kernel, which includes its device support, is its freed, opensource nature. Binary-only modules hurt that.
I should also add that support for SCO is our bottom zero priority. If anything, SCO should work to make Linux drivers usable in SCO (although that still violates the GPL), but not the other way around. SCO is effectively asking Linux developers right now to give them something for free.
--jon. Postel is dead. May we all mourn his, and our, loss.
A potential positive from their site: "While Project UDI does not intend to "take a side" in the debate, we are taking steps to facilitate UDI deployment in the OpenSource Community... We will also be releasing reference implementations of the UDI environment for Linux and other operating systems, as well as sample drivers. These will all be open source distributions."
Side Notes:
- they linked to the ESR OpenSource definition page, not FSF. See the comments about binary drivers, etc. as to a possible reason why.
- They also have done a proof of concept with an Adaptec SCSI controller and an Interphase component which I did not immediately recognize.
- One of the systems was a Linux system compiled by Intel [Intel Linux, anyone?
:^) ]
Because they did not mention the Linux Kernel Driver Interface, and binary drivers (which break the GPL) are allowed, this is not 100% a good thing, as Jerodd has previously noted. However, if the UDI is or could be made compliant with the Linux Kernel Driver interface, then this could potentially offer the community a larger installable bases of new "power" peripherals, etc. without always requiring us to reverse engineer the WinDoze drivers....Open Source isn't the only answer -- but it's almost always a better value than the alternatives...