Slashdot Mirror
Should Linux Have a Binary Kernel Driver Layer?
zerojoker writes "The discussion is not new but was heated up by a blog entry from Greg Kroah-Hartman: Three OSDL Japan members, namely Fujitsu, NEC and Hitachi are pushing for a stable Kernel driver layer/API, so that driver developers wouldn't need to put their drivers into the main kernel tree. GKH has several points against such an idea." What do you think?
Linux, with the stability of Windows prior to the advent of certified drivers.
Heresy!!!
If it means more and stable drivers I'm all for it!
Lets put it in Kernal 2.7.
Oh wait... OOPS!
Let's give them a UNARY kernel driver layer.
Having a kernel API for drivers allows developers to stay away from the mainstream kernel. This will enhance the stability of the kernel in general and also allow hardware vendors to support Linux with less effort.
To Terminate, or not to Terminate, that's the question - SCSIROB
No thanks, this is just a great way to promote closed source inside the linux kernel and to make debugging problems totally impossible.
Shadus
Microsoft could license code into the drivers or otherwise maneuver the driver makers to license their IP from MS, the drivers could form a layer between Linux and the hardware, Microsoft could then pull the run from under Linux.
Don't go there, it protects Linux from getting tripped up, and devalues any hardware that doesn't support Linux.
Don't underestimate the important of driver support for Linux, you practically can't make any server component without a good solid Linux driver.
I have been waiting for that for a long time. The lack of a stable interface is hampering adoption of Linux. Not all of the manufacturers are willing to open source drivers or for that matter to continuously change them as the APIs change. This is very welcome but unfortunately, I think they'll fail. There is just too much politics surrounding Linux these days.
http://www.kroah.com/log/2005/11/07/#osdl_gkai2
:-)
Some misunderstandings were made. But of course, if they posted this link, there'd be no point to posting TFA or the arguments that will almost certainly follow.
They'll think I've lost control again and leave it all to evolution. -- Supreme Being, Time Bandits
Texas has a Constitution with no "administrative" section. That being said, every law, whether new or an amendment is a constitutional change.
I think hardware manufacturers are in the right on this one, they want to develop drivers and peripherals without a constitutional amendment. Good thing all the way around IMHO.
Peace Out.
"This isn't a study in computer science, its a study in human behavior"
I gave up Linux mostly because I was tired of getting punished for having new hardware, which is often unsupported. Especially on laptops.
If you don't force the manufacturers to include their driver source in the kernel, you might get them to release actual drivers for their new hardware.
Toronto-area transit rider? Rate your ride.
No! err.. Yes! ...
Maybe? ...
Sometimes! ...
Absolutely Not! ...
For sure!
It's a bad idea because what happens when the driver ABI changes? You have to wait umpteen months for the company to get off thier asses and fix it - like nVidia.
It also precludes anyone else from fixing bugs in the broken, half assed crap most corporates spit out these days.
feh. stuff.
In his blog he states that a binary closed source driver would be illegal.
Isn't this exactly what NVidia does now?
one of the main problems for getting device manufacturers to support linux is the fact that they either have to release a new version of their driver every time the linux kernel changes some esoteric internal API, or be badmouthed for not having good linux support.
would it really hurt so much to guarantee a stable DKI? doesn't have to freeze the whole kernel, just a subset of functions that will be guaranteed to work as they do now in perpetuity.
backwards compatibility is just as important to driver writers as it is to app writers.
doesn't even have to be binary backwards compatible, source level would be sufficient for most.
The difference between Theory and Practice is greater in Practice than in Theory.
One of Linux's great strengths is the flexibility of changing to meet new needs and not being hobbled by rigid backwards compatibility. This can only be done if all source is open and anyone can update drivers to meet new needs. When someone comes up with a patch to streamline a certain minor part of the kernel, it frequently has repercussions elsewhere in kernel land. It is these small changes which have made linux better and better with breathtaking speed. A "stable" binary API removes the possibility of keeping everything up to date and would dramatically show down the adoption of new features and general improvements.
Continual refactoring is worth far more than some supposed binary API which prevents changes. Get rid of binary drivers! If companies are so paranoid that they want binary drivers, then the hell with them. Linux can advance better without that baggage.
Infuriate left and right
As someone who has tried to install various Linux distributions on RAID cards, and has had difficulty getting installers to use even third-party open-source drivers*, I'd love a binary driver API.
As someone who supports free software, and has struggled with NVIDIA's video drivers (and they're at least trying to meet us halfway by making it as easy as possible to install their closed-source driver under the current system) I can see the negative consequences of encouraging binary-only drivers.
*Example: Promise SX6000. Old cards work with I20, newer ones use their own interface. An open source driver is available, at least for the 2.4 kernel, but good luck if you want to get your installer's kernel to use it. Unless you can create a driver disk, a byzantine task in itself, you're stuck with a few outdated versions of Red Hat, SuSE, and I think TurboLinux.
As long as it's isolated enough from the kernel proper so that it would be *really* hard for the driver to crash the kernel, then for greater adoption in all areas, a stable binary interface is a Good Thing.
Companies can whine, "But, but, open sores!" all they want, but the real reason certain things don't get drivers until a bunch of crack/coffee fiends go nuts with gcc is that there's not all that much profit in supporting Linux for said companies.
Anything fun and happy and required on the server end is pretty much taken care of. Anything else (such as dollar-store-brand commodity crapware)... Well, that's what you get for buying crap hardware. Linux, she is doink you a favor, da!
I have non-working hardware under Linux. I have a Plextor 712SA DVD burner. An optical SATA* drive. Win2k insisted it must operate in PIO. Linux refuses to recognize it, even with the assorted kernel hacks which - even if they worked, people tell me would leave it unable to burn discs. The only OS I've seen it work under is Win XP. Har.
Toss in a driver layer. Would I expect to see Plextor rush to create Linux drivers?
Sure! Right after pigs fly, Google takes over the world with an impressively large military force, and I rescue Bill Gates from a burning car and he gives me $20.
* Not really, but that only adds to the problems!)
Actually, all drivers should be outside the kernel, as in QNX, and now Minix 3. But it's probably too late to do that to Linux.
These companies want a binary layer so they can build binary drivers.
What people tend to forget about this is that it's a bad idea- from most every perspective.
The Linux kernel was written as a Free Softwate alternative to the existing *nix systems.
We have thousands of drivers in the kernel from a combination of development efforts. Sometimes a driver is written by an independant kernel developer, and sometimes it's written from the company producing the hardware, working alongside the community.
What these companies want is to be able to have thier cake without giving back to the community. This is a very slippery slope at the least, and illegal at best, since these sorts of links to binary kernel drivers have been long known to be illegal to distribute alongside the kernel (unless special previsions are made, such as a userland driver).
Also, binary drivers have been known to be buggy and essentially removie the kernel developers from a position where they have control over the kernel as a whole project. I won't even go into the issues associated with a possible security hole in a binary driver, or a binary driver with, for example, spyware in it.
The arguement for it is, of course, that this might mean more drivers. This is a test of our strength as a community. Doing the right thing is harder. It means we won't have all the hardware at all times, and certainly not the newest thing. But we retain control over our computers.
It's hard to say no, but this looks like a clear case where we have to.
In fact... this world would be a better place if drivers could be "os independent".. but that's just dream :)
DON'T STEAL MUSIC!
...and let's call it Kernel 2.7. ed
Let's make it as hard as possible for hardware makers to develop Linux drivers. That'll help!
OK, so the above sentence is 100% troll, and I don't claim to understand all the subtleties of this debate. But it seems to me that anything that helps Linux get more and better drivers is at least worth considering... basically, at what point does a compromise with the hardware makers become the best option?
ClutterMe.com - easiest site creation on the Net. Just click and type.
I'm not really that well versed on the specifics of drivers and the linux kernel. However, I was under the impression that it was possible to have binary drivers for the linux kernel. If not, what are ATI and NVidia releasing as drivers for Linux? I'm pretty sure they aren't releasing open source drivers, so those drivers must be binary.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
If it can be done without making the kernel unstable, I'm all for it. Open source drivers would be nice, but aren't always practical.
Now, if drivers could be run in user space...
I don't think a Binary Driver layer should be introduced. Hardware manufacturers lose interest in products as soon as they're released. So to have the specs open and allow the community to maintain the driver as long as there's a community for it simply makes sense. It's in the consumers' best interest.
gasmonso http://religiousfreaks.com/Please read The Linux Kernel Driver Interface (all of your questions answered and then some) by the same author before commenting...
I haven't seen any stability problems in the Linux kernel in, literally, YEARS of use.
As for the second part of that statement, maybe yes, maybe no. It depends upon the API and those other developers. Which would bring it all back down to the level of "show me the code".
Rather than discussing this in generalities, focus on the code.
IANAKH, but couldn't more drivers be moved into userspace (or other lower rings) --- especially for things like USB printers and miscellaneous gizmos? I think it would also be nice to not bundle thousands of drivers and support for architectures I don't have with the kernel. The kernel itself could provide a very minimal layer of hardware protection (like an exokernel?) and there'd be libraries exporting generic abstractions for particular classes of hardware. Is the context-switching penalty really so great these days? Educate me!
If the companies are going to make it difficult for developers to fix problems with their drivers then we developers should not be obligated to make their life easier either! Let them provide userland binary drivers (e.g. like nvidia and ati) outside of the kernel. This seems to have worked fine. The only thing that doesn't work is that their drivers are broken. Who's fault is that ..the kernel's?
In my opinion, binary drivers are worse than no drivers at all because they release the pressure on the manufacturer. They can say they support Linux which in case of binary drivers is simply not true.
Save the bandwidth. Don't use sigs!
Yes, you got that right, OSDL Japan wants a stable kernel api layer so they can write binary only kernel drivers, which are just so illegal it's not even funny.
How are binary only kernel drivers illegal? There isn't any law against binary only kernel drivers. The "L" in "GPL" means license, not law.
Although since they aren't part of the group pushing for it, it'll probably just allow them to half their Linux development staff by half..... Assuming there's more then one person as is......
In undeveloped countries, the consumer controls the market. In capitalist America, the market controls you.
It isn't just an issue of ABI compability - it's also the fact that no one but that company can then _fix_ the bugs in that driver.
What happens when the company goes belly up in $x months, then a serious flaw is discovered in the binary driver? Whoops, guess you're just SOL. With an open source driver, you can _FIX_ the problem.
With a binary driver, you're at the whim of the company.
feh. stuff.
If that's what they want, then here is a site which might interest them.
If a baby duck is a "duckling," why would anyone want to eat "dumplings?"
it seems to me that this is uneccessary and nvidia has proved it. The have "binary" drivers and supply there own open source layer to provide the glue between their code and the kernel. All we are really talking about is a small layer inbetween the kernel and the driver to provide a "stable" (as it unchanging) interface. So bottom line is that this is simply a wrapper for the existing API. Well, just do what nvidia does, make the code that interacts directly with the kernel open source and proivde the API you need, then just make your binary link to that and interact with just that. Works pretty well. Yes, it would be nice if this was standardized, and could possibly save some people a little bit of time, but thre actual gain seems to be minimal (i've written drivers for linux before, not THAT much changes from release to release as far as the code your module will use goes).
proxy
Note I'm not talking about SUN'S stagnation, I'm talking about their OPERATING SYSTEM which is alive and well.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
As a user, the last thing I want is hunting down drivers that will work with the X or Y kernel version. I want driver COMPATIBILITY. I want EASE OF USE. I want to do LESS WORK in my Linux desktop. I want to be fully UP and RUNNING, after a kernel upgrade.
And this is one of the things that's gonna help me achieve all this, as a user. Sure, it's going to be hell for developers having to test each time that nothing got broke duing a new release, but I don't really care. The user must have the convenience, not the developer.
If the linux developers don't like that, well, they are on the the wrong profession.
This flexibility is also a great method for introducing hilarious new bugs to kernels, because it is way too easy to change stuff around. And you are missing the point. How can you update your drivers if there are no drivers for a certain piece of hardware? Several vendors are simply not in a position to release source code for their equipment, because of licensing issues and such. Even if they wanted. And Linux kernel has been in development 15 years. That's not a breathtaking speed in my book. How many false steps have been made because of sudden changes in kernel design? Also, you should note that it might be easier to craft open source drivers for closed source ones, if the closed source drivers implemented a common, well known and documented interface.
If it allows greater hardware support then yes. Maybe more manufacturers would be interested in developing Linux drivers if they didn't have to release new ones for every kernel version, regardless of whether or not the actual driver does anything new.
To combat drivers causing the entire system to become unstable, the kernel could have a built in mechanism to unload these binary drivers if they start misbehaving and replace them with a safe, generic driver included in the kernel.
Would this stable API need to actually be in the kernel itself if the kernel developers are against it? Couldn't these companies start a separate project which can maintain it is they really think that it is needed? Then the main kernel developers wouldn't need to worry about breaking compatibility as this separate project would fix it at their end.
I don't think that binary compatibility between kernel versions would be needed (though no doubt hardware manufacturers would appreciate it) so as long as the source compatibility is maintained, it will be easy for manufacturers to support new kernels: all that will be required is a recompile (their installer could determine the correct version to download).
Should they change their mind, they shouldn't provide a binary interface. They should provide a standard kernel-to-userspace bridge. Yes, they will take a penalty hit from context switches, no they will not be able to make the kernel unstable. Make sure that binary drivers are second class citizens. Though I don't understand why this would be a better idea now than one year ago or five years ago. It's a short-term gain sacrificng a long-term strength. I'm sure stockholders looking at next quarter would, I'm sure the kernel developers won't.
Live today, because you never know what tomorrow brings
One of Linux's biggest problems is the lack of device drivers for common devices, especially newer video cards. Let's face it, companies like ATI and NVIDIA aren't going to release fully open-source drivers. It would be wonderful if they would, but it would also be wonderful if we had flying cars.
Having a stable binary driver interface would make it easier for hardware manufacturers to embrace Linux, give things like wireless chipsets more usability on Linux and drive further adoption of Linux as a viable competitor to more proprietary solutions
The perfect is the enemy of the good, and the more Linux gains a foothold the better it is for open source. Insisting that device manufacturers need to have on-staff kernel hackers in order to keep ahead of a frequently-changing kernel makes it that much harder for manufacturers to support Linux as a viable alternative.
Provided Linux can have a stable binary driver infrastructure that doesn't harm stability, it would greatly help in the adoption of Linux worldwide.
basically, at what point does a compromise with the hardware makers become the best option?
When the hardware manufacturers are willing to compromise.
The best solution is for them to develop a kernel module and submit the driver for acceptance into the mainline kernel. The manufacturers would like to be able to release binary-only drivers. This means they are not available for Linux-- they are available for a specific build of Linux (say, x86), and not available for other architectures (ARM, PPC, any other non-supported architecture).
A compromise would be this: the manufacturers release full specifications to their hardware interfaces and allow third parties to develop kernel modules. *That's* compromise, where both parties give something, and receive something in return.
Going with a full binary API doesn't solve the Linux problem of lack of support. It solves the manufacturers' problem of not having a "Linux support" checkbox.
Microsoft is to software what Budweiser is to beer.
I can't believe that I'm seeing so many responses in support of binary-only drivers for the Linux kernel. Do you know what Linux is? Do you use it? Is part of the reason you use it the exceptional stability it offers?
Put two and two together, cretins.
Why on earth did they bother asking us what we think at the end of the artical, i mean how many of us actually know exactly what this would mean. Yes the site explains it but still to most slashdotters, its irrevent what we think should happen.
:o
Karma to burn and in a bad mood
- http://www.milkme.co.uk
But we retain control over our computers.
Tell me, what BIOS do you run ? Do you have the source to the firmware in your IDE disk drive ? In your CD-ROM/DVD-ROM drive ? Do you have the source to your SCSI controller's firmware ?
If you think you have control over your computer you are suffering under a delusion.
If a company is developing an embedded Linux ap for their own hardware. All of a sudden, all of the communications with the board-specific hardware is being done through binary drivers, resulting in an effectively closed system.
No more hacking WRT54G's for you, chump.
"Eve of Destruction", it's not just for old hippies anymore...
how would it even go against the license? You can't link to the kernel itself without opening your code, but providing an interface /layer/ would allow you to link to a dual-licensed layer. Nothing wrong with that.
The real question is, why are they talking about it? It sounds like they just dont want to open anything, even the interface (otherwise, just write it. There's nothing stopping you. This isnt like telling somebody who thought linux was ready for the desktop "write your own drivers if you dont like it!" these are corporations who already have developers developing things for the linux kernel.[*otherwise it wouldnt have been an issue in the first place])
P.S.: Drivers, if absolutely no other part of the computer, should be open. These are the parts that make the computer actually compute.
-- 'The' Lord and Master Bitman On High, Master Of All
This maybe a disaster just think of it to be like Windows next we will see a unified installer like Install Shield. I cannot bear to think of it, YES AOL AHHHHHHHHHHHHHHHHHHHHHHH
Linux was, is and hopefully will always be "open". I don't want closed drivers in the kernel (even via an API layer) any more than I want a Sony rootkit masquerading as DRM.
It isn't about "politics". It's about policy and philosophy.
If the hardware doesn't work with Linux, don't buy the hardware/pester the vendor for an open driver, or don't run Linux.
good point.
feh. stuff.
are you saying that most of us don't have linux? how would you know? oh - and this idea would be great.
If they half it by half, would that mean they quarter it?
Dynamic linking of GPL licensed and closed source binaries together is only a violation if you distribute them together, IIRC. There's certainly nothing preventing an end user from installing proprietary software on their home system running Linux, that would be ludicrous, so they should be able to run proprietary drivers as well.
That said, I'm 100% certain that Linux already does this to an extent. Binary compatibility from one version to the next seems to not be as good as many would like, though I have no first hand knowledge of any of this.
This is the problem with the open source movement. Putting the code before the user.
And this is why you fail.
-everphilski-
If you want buggy drivers introduced into the system with no way to fix them then
just buy windows. Not only no but hell no, I don't want and or need binary drivers
running in my system. Either that or keep that junk in user space where it is less likely to bother anything.
Got Code?
That link uncovered a better issue; who's on first at OSDL? This developer is rather pissed about getting caught in a misunderstanding.
Does OSDL need a 'Technical Marketing' department to handle this sort of communication?
Best regards.
Ever heard of NDISWRAPPER??
What many people don't realize is that a binary driver interface has already been developed, only without the central control or oversight needed to make sure it works well.
It's not only possible, it's not only inevitable, It's already happening!
I'd recommend putting together some kind of standardized binary driver interface, only put it in userland where it won't crash the O/S, and treat O/S crashes from buggy drivers as a bug, not the buggy driver.
I'd be happy to pay the performance price of usermode drivers if it meant I could *finally* use my small office inkjet printer/scanner on Linux.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
You know, there's nothing that I can see to prevent you from starting a project to create stable_binary_interface.o which provides a series of hooks that can be pulled by your very own stable binary kernel modules.
This sounds like a troll, but it's a nice thing about the kernel.
Of course getting it into the kernel mainline would be hard, but you could at least distribute the souce to your layer. As long as you stick to the public interfaces to the kernel you might not even be pilloried.
-- Have you ever imagined a world with no hypothetical situations?
I don't see how the freedom of Linux is in question with a feature like this. I mean, there are binary drivers available TODAY. They just break with each kernel release (usually). The only thing that will change with this new feature is that binary drivers won't break. But binary drivers existed before and will continue to exist in the future. This is just a user convenience thing (and trouble for the developers), not a stub at the GPL.
I think that the developers don't want it just because it's too much work to keep compatibility. It's an added headache for them. I don't think the real issue is the GPL here. If they make it sound like it is, I think they are hiding the real issue: more work for them.
If someone wrote their own 3rd party API for the kernel and then released it GPL'd, and then wrote their driver for that API, would it be permissible?
And if you had issues with it, how different is it from running closed-source non-driver apps on a GPL'd OS?
I think that asking slashdot and expecting some insightful discussion about this issue is pretty stupid.
It is not welcome. Linux is about Open Source, and allowing people to link-in binary closed drivers goes against this.
Bypassing the dogma of the above, there are numerous pragmatic reasons why this would be better for linux, even if you don't include support for binary third-party drivers.
Sure, some of these are extreme cases. You can usually get away with just re-compiling the driver, and occasionally, you can even use the binary from the existing version.
The point is you should *always* be able to do this wihtin the same major kernel version. There is no technical reason, aside form the politicis of not wanting to ever allow binary drivers, to not have a stable driver API.
Imagine if the Mozilla plugin API changed with every new version of Firefox. And look at all the complaints when a new Firefox version doesn't work with all the old extentions. It is the exact same.
The problem with supporting binary drivers is that binary drivers can't be fixed. They can't be tweaked. They are often buggy. They don't play well with other drivers. Companies insist on installing gods knows what into their drivers and since they run as root, they have unrestricted access to your system. Would you risk installing a driver from sony on your system? Will you have a choice?
And once a binary driver is available (even if it is crappy) it will make it that much less likely that someone will take the time to create suitable source drivers.
If you are going to take the strategy of "We will do things to attempt to force you to do thigns our way," don't be supprised if the response of companies is "Fine, then we will ignore you."
The simple fact of the matter is that most companies are not willing to go open source, for software or drivers. You can argue that's a bad thing, but it is the reality of the situation. So, if open source is out in their book, either because of contractual obligations or mentality or whatever, they are left with two choices:
1) Do Linux drivers, and update them every time the interface changes, which can be as often as every minor kernel revision.
2) Ignore Linux, and let the community write the drivers if they want.
The problem is that Linux is a bit player. They are larger than the other bit players, but they are still tiny, less than 10%. Given that the continous rewrites can get expensive, the choice for many will simply be not to write the driver.
So if you are ok with that, then great, but don't get mad at companies when they won't play by your rules. Are they being unaccomidating? Sure, but so are you.
In the end, it comes down to needing to make a decision of what you want Linux to be. If you want Linux to try and become the next big thing in OSes and start to really make an entrance in the home market, standardisation is needed. Standard APIs, standard UIs, inter-version consistencies, etc. In essence, it needs to become more like OS-X. Now if you are ok with Linux being more of a geek/server OS then that's not necessary, but you can't demand the world change around you.
i think I'll go with the 'CowboyNeal' option again...
Assuming that we had a stable kernel source interface for the kernel, a binary interface would naturally happen too, right? Wrong. Please consider the following facts about the Linux kernel:
But see, the thing is... a "stable" binary interface requires that structures used specify padding, alignment, and fields to be fixed! If these can vary, then by definition , it's not stable. Ditto the variations that depend on kernel build options.
Now, if you want to make the case that it's not possible / practical to make an interface that can cover all of these conditions adequately, well, by all means, do so (though I'd say that the hundreds of existing operating systems with binary interfaces show that this isn't the case in the general sense).
But what I see here is a relatively weak technical argument that is being used to justify an ideological decision.
CmdrTaco has stated the majority of visitors are Windows users.
I have an i810 and am running ubuntu, and 3D acceleration is buggy at best, broken at worst. Obviously, the hackers had a hard time reverse-engineering it. Now Windows, despite having closed-source binary drivers handles 3D fine. Therefore, I draw the following conclusions from this: proprietary drivers work. reverse engineered drivers don't work as well. furthermore, intel is extremely unlikely to ever release their specs (despite any amount of whining), so I am simply stuck with it. now, server owners are going to be concerned about the security of a closed, binary driver but note: SERVER OWNERS DON'T NEED 3D acceleration, or wireless, or any of that stuff.
Neither success, nor pleasing hardware companies, nor pleasing users is the number one goal ... pleasing developers is.
This is something that I hace always thought curious about Linux in general - the concept that the device driver is part of the Kernel, so that to support a new device, it has to be compiled in. And as everything under the sun has to be supported at any one time, that implies that the kernel gets bigger and bigger and bigger as time goes on. So at what point do you stop growing the kernel? Or can you even do it?
" Linux model stems from the days when it was a small system, and that was a reasonable thing to do. But to me it doesn't seem like a sound design principle that allows for scaling into a bigger system. Trust me, I am not knocking Linus or Linux, but the overall Linux system might be hampered by some decisions that were unforseen when Linus was banging away on his keyboard all those years ago.
You can argue, well you don't have to compile it in in the first place, but that brings on the question of how many linux users in the mainstream are capable of correctly configuring and compiling the kernel to suit their hardware? And what does that do to a plug and play concept?
Years ago I was using Microwares OS-9 (no not the Mac OS 9). It had a modular device drive model where you could load and unload drives on the fly, and similar devices were only differentiated by having a separate config file that pointed to a different hardware address. As such it was (still is?) a sweet system to use. If I wanted a new disk drive, I would plug the hardware in, and edit a the equivlent of a device drive ini file to say that it existed. Then I could load that drive as I needed. No change to the operating system at all. If the device required a new type of device manager (ie a fundementally different hardware model than what was already configured into the system), that manager could also be loaded on the fly as required. Of course you could then burn a system with all your new requirements, so they were available at boot. (and yes I am aware that the all of this does require knowledge of the intrenals a la Linux, but it is the process I am trying to highlight).
To me the concept of the "all-in-one-everything-including-the-kitchen-sink
I am Slashdot. Are you Slashdot as well?
I'm completely at a loss for linux. I spent 4 hours installing suse 9.3 on an older laptop and expected everything to be "auto-configured". Ok not everything, but when I needed to, just go out and get the drivers.
Ok so Linux doesn't have the support, I can handle that, but DAMN is it NOT INTUITIVE to try and install applications/drivers!
So here's the choice. Either have University Level people only using Linux and stop touting it as an alternative to MS, or get it into your heads that the current line of thinking regarding drivers is flawed.
Now to play devil's advocate it's a chicken/egg senerio, but I'm about to leave linux behind for a second time in the last 5 years because I can't make my USB device (isn't usb based on open standards already?) work.
I'm in a position to push it as an alternative, but only when it's easy enough to sink my teeth in to begin with.
Oh and the usb device is AWLL3026 if anybody cares.
Yo Grark
Canadian Bred with American Buttering
Why not mirror windoze? Have "driver signing" or a widely-disseminated "HCL: Hardware Compatibility List" such as Linux Hardware's?
The "friendly" manufacturers who "play ball" should be rewarded as "vendor of preference" for those corporates still sitting on the fence.
Those corporates found to be or *seeming* to be injecting viscious or cunning "proprietary and hi-hijack-potential" code should be on the "Red List" of companies whose software or contributions are fraught with potential licensing or other issues.
I'm not all that much *against* proprietary drivers as long as they play ball are are not greedy bastards trying to undermine Linux, O/S, F/LOSS and so on.
If a flag can be put into Linux, one such as the broadcast flag/ad-insert flag" and so on, then the USER or ADMIN of the system in use can set a policy to allow some, all or NO proprietary flagged hardware or software to be used.
Someone would have to be a maintainer, but if the list is sanitized daily it might server as a prototype until a better, more dynamic and real-time policy manager can be implemented.
Is it really that hard?
David Syes
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
You never know it might be keeping out the awful buggy drivers that manafactures have been hacking together under windows for years. There is no real money in writing or supporting drivers, why would you expect a company to do a half decent job? Of course there are exceptions..
I'm sure that 90% of the time the reason companies don't want to open their specs is the fear their buggy hardware will be exposed to the world.
Sheesh, make an open source interface and give it away. Once someone writes it, everyone can use it.
That being said my nVidia card works fine, I downloaded their kernel patch and I've been happy for years.
My RAID controller did not have drivers distributed with the kernel until recently (ITE8212). Before that I just downloaded the driver source, and built against my current kernels source. Alot off distros offer a kernel-devel package of sorts to allow just that. Please bear in mind that I did NOT RTFA, but it seems that the real motive would be so they did not have to release the source code for their drivers at all.
I am not a Kernel Developer, but I know some. ;) I guess that my open question is how this would benefit kernel users? Yes, I see it would reduce the workload of kernel devs. Yes, I see it would allow driver developers to not have to go through the kernel code vetting process. But, the kernel code vetting process is what is a strong benefit of using Linux, from a user perspective, as I know that the code is well tested by an army of users and developers.
Once you push driver development out of the kernel, yet give access to kernel internals in this way, you introduce a level of uncertainty in so far as stability and robustness is concerned. One must question why these big comapnies are pushing for this, but most human kernel devs are not.
I think most devices could get away with finely tuned generic drivers.
:)
Heck, back in the day just about everything could get away with generic drivers because they weren't these overcomplicated suites of utilities as they are today.
Printer drivers for example would just send the data to the printer and the printer would print the text/graphics. Now you have all these tools/utilities/diagnostics/etc built right into the so-called driver for tweaking and such but they aren't really nessessary to get the job done.
Let all the extras be their own software (closed or open). Keep the drivers simple, fine tuned, open, and generic.
DEAD DEAD DEAD DELETE ME
So, instead of complaining, these companies can simply decide to implement an Open Source kernel module that implements the full binary Windows driver interface, and then ship just one driver -- the Windows one -- for Linux.
Of course, they can keep their hardware, because I certainly won't be buying it. I buy hardware that is SUPPORTABLE -- and this means something COMPLETELY DIFFERENT than "supported". Because, hardware that is "supported" by a company that no longer exists is NOT useful to me. And all hardware will eventually be in that category.
So, by definition, any piece of hardware that doesn't come with Open Source drivers is not welcome in my home or business.
-- -pjk Perry Kundert perry@kundert.ca http://kundert.2y.net
GKH raises good points about how a stable binary driver interface will open the floodgates to both security problems and to update/maintenance problems. As it stands right now, Linux kernel developers can quickly respond to threats because they are able to fix all instances of a given problem, in all drivers, at the same time. If they do not maintain this flexibility, either some drivers stop working unexpectedly when security fixes are made and the interfaces are forced to change (making Linux appear "unstable") or backwards compatibility must be maintained making the Linux kernel grow over time (whenever a new interface has to be written to address flaws in the old interface).
Yes, abstraction is good...but, in this case, stability, the perception of the user and maintainability (where the *real* costs lie) must win over abstraction. Most of the kernel developers are not being compensated; how often do you think that backwards compatibility is going to be maintained? Its not. Right now, fixes are accomplished because it is easy to accomplish - global search and replace, etc. Make it difficult and it just won't be done.
Manufacturers want binary drivers because they want to play for free - they want all of the benefits of open source without any of the costs. Not cool.
more hardware MFGers should make a downloadable shell script for GNU/Linux and as long as users have their kernel source installed it will compile a kernel driver for whatever hardware they have purchased :^)
Politics is Treachery, Religion is Brainwashing
It exists. It is the way normal applications work. And the reason they don't crash the system is because there is an abstraction layer between them and the hardware called the kernel. This kernel needs to talk to the hardware and this is were drivers come in.
Secure messaging: http://quickmsg.vreeken.net/
hi,
as long it is opensource, I believe a open standard driver API is a good idea.
CU
Anonymous Coward
What about UDI? This has been around for a while and supports not just Linux but a variety of OSes.
“Common sense is not so common.” — Voltaire
Tell you what, when push comes to shove we don't even want your driver.
Give us the programming documentation to your hardware and we'll take care of it.
(Don't argue the Adaptec crap argument with me that an inferior O/S driver
could potentially damage the products public image. If enough people even care
enough to use your product someone else, more capable will then develop a
better driver)
If you want Linux to be the hacker's paradise, then by all means make people work to get their PCs to work properly. Most people don't want to futz with conf files to get their sound to work. It's not weakness or stupidity - people want to use PCs for things other than tinkering with drivers!
I've been using linux as a primary desktop OS for 8-9 years. I know what I'm talking about. Especially on laptops, device driver support can be a royal pain. Getting the audio to work on the Thinkpad 390X was (and continues to be) painful. OSS drivers *do* work, but out of the box they don't.
None of the non-geeks I know would tolerate that kind of performance. It's an elitist attitude like yours that will keep Linux away from "normals."
Congratulations!
But Herr Heisenberg, how does the electron know when I'm looking?
Can be possible to be easy to develop the driver for Windows by designing to consider the portability with Windows API.
This is from the proposal refenced in TFA. Does anyone have a clue about the authors intent?
My only guess is that they're asking us to reverse-engineer the Windows API so that they can use the same code cross-platform. How ironic!
Why the hell do *printer* drivers need to be in the kernel anyway? Userspace is a much more sensible place for them.
Ignoring for a moment, the ideological points, lets consider a frequently raised practical point: the idea that an API would either get out of sync with the kernel, or be a drag on innovation.
/lib/modules/binary/" than "you need to recompile and reinstall the whole kernel with this patch"?. For obscure hardware which will never be in the official kernel, it would be nice to have the ability to easily use it with any linux distro. No need for a slew of precompiled RPMs, DEBs, and a user-unfriendly source tarball, just one driver binary and you're ready to roll.
I agree that when the Linux kernel was young and untried, standardizing a binary API was bound to become a millstone in a short period of time, as the kernel internals were in a constant state of churn and iterative improvement. Nowadays though, surely, the kernel has been "shaken down" enough that it could afford to commit to binary APIs that are stable at least throughout each minor version number?
Returning to ideology, I can see how a stable binary API would be useful even to open source hardware. How much easier is it, to say "drop this file under
In itself, that says nothing, either pro or anti, about the availability of driver source.
Amen bro. In the past I worked as an engineer at one of those "closed source" corporations which manufactured SCSI host adapters. At the time I was using a competitors HBA (host bus adapter) for my drives. Finally a member of the Linux community volunteered his time and effort and delivered an excellent driver which the company finally took over maintenance on. When the next gen of newly architected HW was released a brand new driver was necessary. The internal debate was whether or not the new 'whiz-bang' driver architecture should be given away to the open source community. As this company never sells it's SW anyway the leap of faith was finally made, which brought it extra revenue as shortly thereafter all the large vendors (read customers) were insisting on a Linux presence.
Another benefit: vast improvements to the driver(s) as the community also assisted in code addition/refinement and debugging. Moral: Avoid the short range (read corporate) view, do everything possible to make and keep the future OPEN.
Remember George Santyana who said (paraphrasing): 'those who refuse to learn from the mistakes of the past, will be forced to relive them'.
Do you honestly think that most companies are really going to support Linux if it is even more of a pain in the ass to write good device drivers that don't let out the company IP than it is for Windows? People like you make it quite easy for these major companies to just write off Linux entirely for most of their hardware.
Click here or a puppy gets stomped!
Instead of a "stable kernel API layer", what is really needed is a stable hardware interface layer. That way we don't even need to have new drivers at all for the same class of device. A set of standard drivers conforming to the standards upon which the hardware interface layer is designed would be sufficient for communication between the kernel and the underlying hardware.
now we need to go OSS in diesel cars
The arguments for not doing this are really pretty weak. Reserving the right to change kernel interfaces is the weakest of all. At the upper level the kernel has no option but to adhere to the POSIX system call interface APIs, and I don't hear too many people whining about the the inability to change the system call APIs stifling innovation. Wanting to have drivers only in source form "so that people can fix them" is a weak argument. The same argument should the be extended to the other end of the stack, and refusing binary applications - "because people can't fix them". Stallman would agree, as would his diciples, most other people have a more flexible view of the world. Don't want to use binary dirivers/ Fine. Don't use them, but give those people who do a chance to do so -- won't the famous "natural selection" have everyone opting for the open source drivers after a while anyway? With virtualisation technology there is very little to prevent the creation of a firewalled environment to run these drivers in. That of course, would require a well thought-out, documented and supported set of APIs. Perhaps the biggest reason to do this is that if we don't, a consortium of vendors/distros will. That will split Linux into the "profesional" version targeted by commercial products, and the "hackers playground" where greg KH, Linus and Stallman can play whatever games they like.
Most of the people who are saying a closed driver API into the kernel would be a GOOD thing have Slashdot UIDs over 500,000. I think, somewhere along the line, "the message" has gotten lost. ;)
As I posted earlier, "Linux" is as much a philosophy as anything. It's about being open. It's about giving people the ability to make something they don't like into something they do. You can't do that with closed source software. I don't ever remember reading or hearing anywhere that the stated goal of "Linux" was to try and supplant every other Desktop and Server OS out there. I don't ever remember reading or hearing that "Linux" was going to be easy or accomodating for the casual user. Certainly, there are hundered of projects whos stated goals ARE to make the Desktop or Server distros of Linux easier to use. But people need to remember "Linux", at its most basic is about being free and open.
If you want easy, get a Mac
Just tell OSDL Japan to go to the devil, or the dameon at least.
(IOW use BSD and shut the @#$% up!)
They won't release now, but eventually they will. You don't cave in to "terrorist threats", ever. And that's what this is. If those vendors want in on the open source market that revolves around the linux kernel, then they can play ball, too, end of story.
Linux is at a really important part in its evolution. Caving in to closed source interests would be counter productive in the long term. It is better to force/cajole the vendors to finally "see the light" with open source and the GPL. Maybe eventually another graphics card vendor will appear and become the champion, precisely from having open source drivers. The manufacture of electronics in Asia in particular is exploding, where there is a market, a vendor will appear. Patience.
So far Linux community has chosen to be idealistic. I would really like to see it start turning to the useful side, but seeing how many answer 'no' to this question, I don't see that happening any time soon.
Just this summer, right before going back to the university, I decided to wipe my main workstation and give Linux an honest try as my primary OS. I messed around with it for a number of years now, but always either on crappy machines that were way underpowered to create a pleasant user experience, or on virtual workstations.
Oh how I hopped that my hardware would finally work, but no such luck. My mouse only had basic functionality, my keyboard couldn't use any hotkeys, my TV tuner didn't work, and neither did the dual-monitor setup, no matter how many times I tweaked the video settings. With a sigh, back to Windows I went.
This is by no means to sound like a Troll. I like Linux for some things, but drivers and graphical user interfaces are by far your weakest points. Until these issues are fixed (and I do believe that binary drivers would be of great help), I don't see Linux as being useful.
Before you jump on me for saying that, keep in mind that I'm not talking about Slashdot crowd. Hell, if I had the time or patience for it, I could probably get some distribution to work with all of my hardware as well. The problem is how much time and effort I would have to put into having a workstation that I can use for work, as opposed to having to work on my workstation (if you get my point).
In the end, even being a software developer, I don't want to be treated as one when I use my operating system. Drivers should simply exist, and work, if that goes against the open-source ideals, maybe it's time to re-think them and be a little more flexible. If there is an alternative that saves me time, energy, and a lot of frustration, and its only downside is that it goes against the idealistic ideas of the open-source community, sorry guys, but I'm going with that.
There are very good reasons for closed source drivers. Take modern grahics cards as an example. There is so much IP in the drivers its not funny. A graphics card these days is little more then a specialised CPU with really fast RAM. So much of the rendering process is in the driver, thats why a small driver revision can make so much difference to performance.
As much as I would like that source to be open there is no way NVidia for example could compete if they gave away all there interlectual property away for free. Thats how they make there money and can afford to pour more back into developing the next generation of cards.
And what about software modems. I know most people hate them but the companies how develop them do so to make them cheaper which is reflected in their retail price. The modems are just a dsp connected to a phone line. If they gave away there source anyone could buy the same processor stick it on a board and sell it from under them without any of the R&D costs.
I say bring on a static api for binary drivers!
I write high end drivers - but not for linux
This includes the fastest dual port Fibre Channel cards known, the best raid controllers, the first dual SCSI 320 cards, video capture encoders, InfiniBand, high end D/A boards, and much more... but not for linux.
The reason? I usually end up creating far more intellectual property (micro OSes) than you would ever imagine required for such products and will not start work on them for open source when I am not the beneficiary of the device hardware sales in any way, including indirectly.
I will stay with Mac/Win/BSD for now thank you.
As a driver developer i care for LITTLE of the host OS in any way, and in fact typically recreate all the I/O schedulers for multipathing, fault tolerance, booting from raided devices, total fault tolerance, etc... I get no benefit from the Open source community, other than lots of work with very little competent competition. I've looked at several "drivers" for linux and never had such a laugh in my life. The last thing i want to do is train others in my craft, including half the engineers in India. No Thanks.
I wish nothing more than a hardware abstraction layer to allow me to create drivers for linux. Mainly because I have so many linux buddies and they really could benefit from my hardware goodies, but nope. Politics forbids my participation. I guess only video card companies get special exemptions in the hypocrasy of linux? You want hypocracy? what about the 20 to 30 famous major projects taht STARTED as GPl and then went closed fork private after getting people to help them!!!! The foremost expert help drawn upon by these people are low level coding experts such as I. I see their goddamn scams. I will never trust a GPL zealot again becasue of the 20 to 30 major projects that stole aid and went closed source.
OPEN UP LINUX for binary driver abstraction and get some serious I/O devices
response 1) It should a have a tertiary kerner driver layer!
response 2) Kernerls should never drive, they are too highly ranked, make the corporal drive!
Both reasons are bunk. Honestly, there are virtually no drivers I can think of that merit that level of secrecy.
One of Linux's hallmarks is its customizability, by anyone, for any reason. If you release a driver that contains support for copy protecting music or video, I will decree that driver defective and fix it.
Besides, the driver API is going to need to be re-designed at least one, and possibly two, more times just to accommodate modern, effective power management. The existing API is simply inadequate to the task. If you drive a stake in the ground now, you will forever preclude future necessary improvements to the driver model.
And finally, complaints about Linux's driver API being a moving target are highly disingenuous. Microsoft has re-designed their driver API (badly) several times already, and Vista portends yet another rewrite, this time to support pervasive copy protection. Yet, strangely, the hardware vendors don't seem to have a problem with this.
So, no. Linux's openness is a key component of its value. Binary-only drivers undermine that, and should be discouraged.
Schwab
Editor, A1-AAA AmeriCaptions
Want a Binary Kernel Driver?
The source code is available, write one yourself and stop crying for somebody else to write it for you.
You don't know how to write one?
Buy a book and C, join the kernel mailing list and read the documentation.
That's what Free Software is all about.
More and more hardware is being implemented in software. This makes sense because as the CPU has increased in speed and capability it has gained the resources and free-time to pick up the slack for less-expensive hardware implementations. If you look at the new push for multi-core and multi-CPU systems this will be even more true. Plus, as a bonus, if they mess something up then they can more easily get people to install a new driver revison successfully than to flash a device or fix a problem in the silicon.
The problem for the open-source community is that these drivers are increasingly not just the way to talk to autonomous hardware but actually implement alot of the fucntionality of the device. Taking this in mind, the manufacturers are unlikely to give out the source code for these drivers as they will be giving their competitors a more significant view into their playbook. People in the Linux community complain about the lack of certain drivers like those for wireless cards in many notebooks, which in my understanding work as described, and are left hacking together a solution to run the Windows drivers under linux in order to get them to work. If you want things like that to work and work well in Linux then you have to give them a stable subsystem and make it as easy to port their drivers as possible while providing them the means to not give away the source which contains half of their work in creating the hardware.
I know that is not the ideal solution but thems the breaks. It is either Linux steps up with an API and binary subsystem or they will be left with fewer hardware options consisting of what more expensive all-hardware alternatives are left for many of these peripherals.
Everybody can just run Knoppix and be let it take care of hardware!
"Don't meddle in the affairs of a patent dragon, for thou art tasty and good with ketchup." ~ohcrapitssteve
Discreet (now Autodesk Media & Entertainment yadda yadda) ships Flint and Flame on Linux (yes, x86 only). They have a proprietary high performance realtime file system that lives on attached SCSI drives ("Stone"). Are they likely to give away their "crown jewels", the source to that driver? Not bloody likely. Would their customers like to be able to pop that driver into any version of Linux other than the exact kernel and options that Discreet ships? Certainly! Would Discreet even like to allow their customers to do this? Definitely! They wouldn't have to ship an update for every RedHat kernel update for instance.
Currently that driver has all the mangled kernel symbols in it, as well as the well-known struct-size/offset etc. issues. If there were a binary layer like nvidia uses for their drivers, this would be easy.
Note that this is not a hardware device that is portable to PPC, Alpha, whatever other devices you might want to run Linux on so the portability concerns are moot. And the chances of getting the driver "into the tree" are zero. It's a Flame ferchrissakes. Discreet has a right to control access to its hardware and its custom software. But it would sure make everyone's life easier if their driver could install on more than just one exact kernel build!
Anyway enough ranting for now.
First off, a short comment on legality: Linus views binary drivers as legal ONLY IF they were "ported" to Linux. His view is, if they were written for the kernel from scratch, they're derivative work. Otherwise they don't derive from GPL code and (though undesired) are considered legal. Note that this "Linus" I am referring to may have no actual relation to the "Linus Torvalds" person who wrote Linux, it's just what I think I remember him saying.
;-)
Now that's out of the way, the first curveball that hit me after Win32 world was the idea of no stable ABI. First let's get some misconceptions out of the way:
1) Windows doesn't have a stable driver ABI.
Ask NVidia. Ask Intel. Every service pack that can potentially break a driver means that the ABI has changed! How many times did you have to update a driver after a service pack? How many times did a driver "require" a new service pack to install? Yeah, I thought so.
2) Distributions have "stablish" driver ABIs.
SLES and RHEL have got reference kernels with stable ABI calls that's well documented AND YOU HAVE THE SOURCE. It's much simpler to update drivers for Linux than for a new Windows service pack since the Enterprise versions normally stick to the ultra-stable stuff.
But, noooooo! I hear. Screw this stable stuff, stable stuff is old! And that's the crux of it. On a desktop, you don't necessarily want 99.9999% availability, you'd rather have 20 more features, but a non-serious hang once a month. The difference between the Windows model and the Linux model is: YOU NEVER GET WINDOWS KERNEL FEATURE UPDATES! You have to pay for them! And wait years and years... Yah, the service packs add features, but to most people they are considered bugfixes
So that's why the kernel shouldn't have a stable API (let alone ABI) for drivers. It prevents big architectural decisions from being taken at the opportune moment. With the kernel under git management, it's even easier to maintain out-of-tree drivers (case in point: alsa). What developers who clamour for a stable ABI don't understand is that there _is_ one! Any fork of Linux they make can be as stable as they want it to be. If they want to benefit from continual improvement, they _have_ to make some sacrifices.
Second-to-lastly, the guys biting of the short stick here are the distro maintainers. Again, there are many options: follow the source route like Gentoo, allow only free hardware like Debian, rely on the user base to spin driver packages like Fedora, Ubuntu and OpenSuSE, or go the stable route like SLES and RHEL. If they really want a stable video ABI so NVIDIA's drivers are even easier to install, get THEM to work together on it. If it's good, it'll get in to the kernel. If not, it won't.
Lastly, try the following experiment. Buy a shiny new Windows XP Home (or Pro, for that matter) CD, and install it on your brand-spanking-new hardware. Now, try to write a USB driver using only software that you don't need to pay for, and for which you'd own the binaries after you'd written it. Finding it difficult? If you got it right, PLEASE TELL ME FREAKING HOW, SINCE I DON'T KNOW! Next step, PCI driver... but hey, Rome wasn't built in a day!
What do you think?
I think they should have a stable API and I think the kernel should be licensed as LGPL or similar to allow closed / non-free binary drivers. I've thought this was the right approach for years. Obviously many others disagree. My intention isn't to debate that.
Because it doesn't matter one bit what I think. There's no reason to solicit opinions on this from the general public. It's not our code.
The Linux kernel developers have made their opinion on this perfectly clear, again and again. They think a stable API is pointless and that binary modules are both not allowed by the GPL (in nearly every case, at least - even Linus vacillated on what was a derived work and what wasn't years ago) and - most importantly - not welcome. Even if a loophole like a stable API veneer were found that made binary modules both legal and workable (and I highly doubt that's possible), it's clear that the kernel developers won't play along and will do their damndest to break that patch in new versions.
Some of us may think they're making the wrong move, but Linus and company wrote the code and they picked the license - it's their ball, we play by their rules or we don't play at all. If the Japanese OSDL thinks this is a showstopper, they need to consider another kernel. They're not going to change the Linux developers' minds, and a legal workaround is highly unlikely if not impossible.
Just cuz Linus doesn't like it doesn't mean you can't just up and fork Linux and make it work like YOU want it. The rest is mindshare. Money can buy that.
Besides, it will make writing drivers for prototype devices easier. There are plenty of areas where you want to move the stability/convienience/possibilites point around.
Firstly, I get paid to do driver development. Secondly, I have never worked for a company that willingly said, ok lets open source the drivers we spend thousands of dollars writing and optimizing.
That said, this whole discussion is as silly as the one about not putting a kernel debugger in the main kernel source code. Frankly, linux desperatly needs both a kernel debugger, and an ABI to be a REAL alternative for many customers. It also needs the ABI for driver developers so that we can write a single driver and expect it to work on the dozens of flavors of linux we are expected to support. Saying that everyone should opensource their drivers is like saying food should be free. It isn't going to to happen and wishing for it, won't make it happen any sooner. In the interm, almost all the hardware out there has better support on windows (Our sysadmin can't even get support for major linux distributions, from major hardware vendors, even when they have little linux logos on their hardware and websites) the windows drivers tend, to accually work, and they almost always have better features sets. This isn't going to change as long as the "opensource" community treats hardware vendors that think they have IP in the driver as second class citizens.
Oh, and for people who don't accually work for hardware companies that ship drivers, driver development is often times an expensive process, not because the software engineers are expensive, but because the hardware and software needs to be tested and certified in particular enviroments. There are orders of magnitude more linux distributions this makes it cost orders of magnitude more to test and support than a half dozen windows enviroments, most of which can be tested at microsoft, or one of the major OEM's if the hardware isn't avialable onsite. Putting 10x the money into a market that may be less than 1/10 of sales is not always a good idea, especially when resources are limited. Creating an proper ABI helps to solve this problem.
That said, if the damn linux kernel accually had a real architecture, it could support an ABI, and even isolate itself from rogue drivers. As it is, the kernel arch is pretty much non existant and just a pile of code that tends to behave like a real kernel, except when you try to do something a little outside of the mainstream desktop or small web server enviroment. This was fine when the whole kernel was just a few hundred thousand lines, but given its current size its getting massivly unmaintainable. This is proven by the fact that linux system stability seems to have gotten really bad over the last few years. Getting to a stable system, takes a lot of vendor testing by the likes of Suse, Redhat, etc.
Lastly, the tainted concept works fine for the kernel developers, why not carry it forwared so that any binary driver simply marks the kernel as having a binary module loaded, and uses the standard abstract interfaces instead of linking against all kinds of unneeded kernel crap that just provides the posibility to screw something up.
No.
Next question.
> this is just a great way to promote closed source inside the linux kernel
But as the FA noted, closed source inside the kernel would be highly illegal according to the GPL.
It looks like there are two issues here, the open/closed source issue (hardware vendors who want to make close-source drivers), and the programming efficiency issue (driver programmers who don't want to rewrite their drivers every time the kernel is updated).
It looks to me like the GPL takes care of the first issue quite well by itself, so if your concern is preventing closed source drivers, the lack of a kernel API is redundant and unnecessary.
In terms of the second issue, cereating a kernel API looks like a good solution to an old problem.
Or am I missing something?
If someone could explain wht the GPL alone wouldn't protect against closed source drivers, or why a consistant API for open source driver writers would be bad, I'll change my position.
Otherwise, this looks like a good idea to me.
Reimplement Linux as a microkernel with user-mode binary drivers!
I could see a Binary API with the following conditions.
1. Bug reports for kernel issues where a driver is using the Binary API are rejected or given very low priority just like now when the Kernel is tainted
2. Vendors who use the ABI are REQUIRED to open the driver within a period of time.. say 18 months. If they do not comply the vendor will be blacklisted from the kernel
3. Some other additional conditions that I have not though of.
One of Linux's great strengths is the flexibility of changing to meet new needs and not being hobbled by rigid backwards compatibility.
Yeah, let's hobble it with dependency hell instead.
Stagnation? You need to look again. Sun has a LOT of new products that have shown up recently. Dual core AMD processor 1U servers starting at $795 isn't something new?
Exactly!The current situation chases away developers such as I.
I write high end drivers - but not for linux
This includes the fastest dual port Fibre Channel cards known, the best raid controllers, the first dual SCSI 320 cards, video capture encoders, InfiniBand, high end D/A boards, and much more... but not for linux.
The reason? I usually end up creating far more intellectual property (micro OSes) than you would ever imagine required for such products and will not start work on them for open source when I am not the beneficiary of the device hardware sales in any way, including indirectly.
I will stay with Mac/Win/BSD for now thank you.
As a driver developer i care for LITTLE of the host OS in any way, and in fact typically recreate all the I/O schedulers for multipathing, fault tolerance, booting from raided devices, total fault tolerance, etc... I get no benefit from the Open source community, other than lots of work with very little competent competition. I've looked at several "drivers" for linux and never had such a laugh in my life. The last thing i want to do is train others in my craft, including half the engineers in India. No Thanks.
I wish nothing more than a hardware abstraction layer to allow me to create drivers for linux. Mainly because I have so many linux buddies and they really could benefit from my hardware goodies, but nope. Politics forbids my participation. I guess only video card companies get special exemptions in the hypocrasy of linux? You want hypocracy? what about the 20 to 30 famous major projects taht STARTED as GPl and then went closed fork private after getting people to help them!!!! The foremost expert help drawn upon by these people are low level coding experts such as I. I see their goddamn scams. I will never trust a GPL zealot again becasue of the 20 to 30 major projects that stole aid and went closed source.
OPEN UP LINUX for binary driver abstraction and get stable and serious I/O devices.
A: No. Next question.
But seriously, if we wanted binary only proprietary drivers, we'd be running Windows or MacOS. If you can't play by the rules, then fuck off. It's called OPEN SOURCE for a reason. Furthermore, if you are a hardware company, what do you care about the client side software? Are you selling hardware? Or are you really a shitty closed source software company in disguise? Note: this goes for you all hardware companies that pull this shit (I'm looking at you, ATI, with your buggy closed source user level "driver" libraries. Nvidia is only slightly better because their drivers don't crash on a switch between X and console).
Nathan's blog
that doesn't mean they don't also use linux
This is necessary if we ever want Linux to be ready for the desktop. The ability to have driver modules is certainly more advanced than having everything compiled into the kernel, but it's severely lacking in many regards. The module has to be custom made for each kernel, making binary distribution useless because there are 2^100 kernels out there. So unless the manufacturer open sources the driver, they can't make a driver for Linux. Or you could go with an open source interface to a closed source driver.
Here's a sample of what I put up with. I downloaded Agnula Demudi 1.2.1 and installed it with the 2.6 kernel. I was ready to install some Nvidia drivers. But after some searching, I couldn't find any binary driver interfaces compatible with my kernel. Fine, I can compile my own. So I download the interface sources and launch module-assistant. It complains that riva driver support in my kernel conflicts with the nvidia driver, and I need to recompile the kernel. (I then went through the joy of trying to find the hidden demudi sources and figuring out how to patche them and configure them, ultimately failing to compile it, but this is getting away from the topic.) Finally, I said screw it.
You might blame the distro, but it's really the kernel at fault here. Recompiling the kernel to support a driver is NOT something that a user should have to do. Windows does not require you to recompile your kernel to install drivers.
Disclaimer: I'm not a kernel hacker, nor do I play one on TV.
Do your really believe that the answer is to trade stability for convenience? As the parent said, we would be right back to where Windows is.
Stupid question: is it possible (with the current kernel architecture) to have them run in userspace?
I realize there are performance implications (IIRC MS tried it with NT3.5) but if it's possible, could it give them the ability to "try" supporting Linux, while still maintaining the stability we expect?
First of all, I completely understand that drivers with source are better than binary-only kernel drivers. However, the fact of the matter is that companies do not feel comfortable freely releasing their intellectual property. Given the choice between a piece of hardware in a laptop which doesn't work with Linux at all and one that works with a binary-only driver, I would rather have the binary-only driver.
As long as Linux kernel developers complain that binary-only drivers are "illegal", Linux will have less hardware support. One of the major complaints people have against Linux is that a lot of devices that one can attach to a Windows machine plain simply do not work in Linux (I still think Linux is far behind Windows when it comes to wireless drivers, for example). I want to see a true alternative to Windows on the desktop; GPL fanaticism and an inability to understnad how big corporations work harms this.
What you seem to forget, is that for the majority of users, Linux is a 'free' unix like system, and they could give a rats ass about "Free". If "Free" starts making things difficult to use, or preventing companies from supplying drivers for hardware users buy, then not only do users not care about "Free", but they will actively dislike "Free".
The bottom line is that having code be open is only important to a fraction of *developers*, and an extremely small small fraction of the general populance. Ultimately, "Free" software people want to push their ideoligy on others, they don't care about makeing functional easy to use systems.
So preach all you want. Very few people care.
At the end of the day, there might not be a choice at all. What's to stop them forking the code and developing their own binary driver api? If people (and by people I mean businesses) want to use the hardware of these companies, it might become widespread.
Step off, Sauce.
A driver by definition runs with very high privs. Privs high enough that it can crash the system. What you seem to want is a virtual driver layer with the actual driver running at some sort of user level and message passing. That's a micro kernel architecture.
Looking over the parent and other comments, the biggest objection that people seem to have is the suggestion that this will allow closed source drivers. I don't understand why there couldn't be a stable device driver interface in the Linux kernel (other than Linus's objection to it).
I've been bitten by this issue many times with respect to providing Linux images for testing Itanium systems. I've essentially lost the battle with my management explaining that I have to requalify drivers each time a new release comes out.
Having a stable devices drivers interface for standard devices such as WD SCSI controllers, ATI Rage II and Fairchild Super IO would make my life a lot easier.
myke
Mimetics Inc. Twitter
Should Linux Slowly Back Out of Open Source?
How about, just give us register level documentation so that we can write our own drivers and maintain them ourselves?
How much in the way of intellectual property are you going to risk by telling us stuff like, "write a 1 to this register to manually initiate a disk parity check" and "read this register to get the state of heath of the array", etc?
Really, how many companies are there which we know of, which make pretty decent hardware, but crap software? How can open PROGRAMMING documentation be anything but a win-win?
That's PROGRAMMING documentation, not VLSI CAD files, firmware source code or microcode, but PROGRAMMING documentation. What buttons do we push and where do we look for the flashing lights? Thats all.
Allowing API's for drivers would be us giving up a part of the fight for open source. What good is an open source operating system if we let go of a key area where stability, performance and security can be severely impacted? If we give in to them on this, then it opens us up in the future for them to provide crap drivers, no more documentation for hardware which we PAY for and then ultimately a "sorry, we don't officially support non Microsoft systems any more". There will also be the problem of staff turnaround causing delays on the vendor side, less priority put on the open systems and smaller groups of people "in the know" becoming a bottleneck. Less eyes and communication problems where we don't know what they're doing and they don't know our side as well as we do. This could also cause an avalanche effect whereby other less used open source operating systems get completely left out in the cold and die off. Systems which have been giving back one way or another to Linux.
Documentation is a long term investment for all parties involved. API's will be a long term problem which will never get fixed. Look at the state of 3D acceleration! It sucks!
We are not going to figure out how those 100 million transistors are wired based on a handful of registers.
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
An ERP package is replaceable in ways a hardware device isn't; for a given hardware device, you NEED the driver or the device is just a paperweight, often an expensive paperweight that deprives you of functionality you may depend on. You can always obtain or write another ERP system (yes, it may be prohibitively difficult). If an OS update breaks the closed-source ERP program, you'd better hope the vendor still cares, but the rest of your system will still run. If an OS update breaks an open-source driver (which will be somewhat infrequent), chances of getting it back up are good even if the vendor's gone.
I take no position on whether the kernel driver policy is a good or bad idea, as I see arguments for both positions. What I *will* take a position on is the proposition that the present policy appears to work reasonably well, and is working better as time goes on. Hardware compatibility seems to be improving rather than getting worse.
"My strength is as the strength of ten men, for I am wired to the eyeballs on espresso."
Digital made a switch to a vectored kernal for later RSX-11 M Plus releases and it was "A Good Thing". It leads to more stability not less. Linux could do the same. It would not be all that hard to do, and although there is one additional layer of indirection, with current design patterns that would only affect the initial loading of a driver. Other options are to create a self linking driver format where the drivers are JIT linked when loaded. The kernal would be responsible for loading the drivers own jump table based on what it could provide. A minimal set of required routines and the driver could then see if it had enough information / routines / support and unload itself if it was not in an appropriate environment, or could provide support that some compiled kernals have and others omit if it was not present. Old technology made new again through lack of use!
- Tjp
I am in wallow with my inner money grubbing capitalistic pig. ... Oink!
Too bad I don't have mod points, because that is the most insightful post I have ever read! I almost feel bad hijacking your topic to mention it.
Most linux users don't know this, but the man pages were named after Chuck Norris. Chuck Norris fsck'ing hates noobs!
Perhaps not a binary layer.
But a universal driver kernel api could help reinvention of wheels. So perhaps a Linux network/wireless driver could be recompiled as is and used on BSD, ReactOS or GNU/GNU/Hurd.
Why not just fork the kernel? I do think that binary drivers will weaken Linux but if you really want them you can take the kernel sources and make your own fork. BSD ain't dead yet, no matter what Netcraft says. Most distros will either pick their favourite kernel (mostly commercial distros) or just support both (mostly free distros). As a Gentoo user I don't care much if we get a new Gentoo for the BinaryLinux kernel - hell, we already have Gentoo for OS X.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
Then we might actually get vendor hardware support in Linux.
Of course, for a GPL'ed project to legally go closed source all the copyright holders must agree to the license. I can't think of 20 such projects, but for any GPL project that goes closed source one of three things must be true:
1. All the code was written in-house, and no one outside contributed anything.
2. Every single contributor signed copyright over to the project maintainers.
3. Every single contributor agreed to take the project closed source.
Or a combination of #2 and #3.
#1 seems to be the most common. And hey, if no one's helping you, why bother keeping it open anymore?
#2 happens from time to time, but the only major project I can think of that does this is GNU, and their whole reason for being is tied up in the GPL.
#3 would be damn near impossible for anything with a lot of contributors.
But the problems that embedded vendors face in using Linux for new designs are difficult. Notably - it's legally impossible to use TI's line of hybrid ARM/DSP processors without some sort of binary shim between the kernel and the DSP.
You can (and I DO) argue that TI should open up their licensing to be GPL compatible, but they haven't. The alternative processors in this space are not as powerful, and thus the hardware guys are stuck between a rock and a hard place. I'm sure they are pushing TI equally hard about making their processor code GPL compatible as well.
The second problem is the language barrier between traditional (and japanese speaking!) embedded developers and mainstream kernel developers. Embedded developers often have different priorities.
An embedded developer wants: reliability stability over time low power consumption suspend/resume & fast boot low memory use just the features of the embedded device enabled and, lastly, adaquate performance. Most of the time, the people that drive the next design are the hardware people - they get a spec, they figure out what is the cheapest processor that can meet that spec, they do the design, then "it's a small matter of software development" to actually make the product work. The software guys get short shrift during the early phases, and then they get stuck with the resulting hardware, and then it's the fault of the software guys who can't make it work...
I've had this happen to me twice in recent years. I (as the software guy) chose a processor that had an easy to use software interface, enough power to handle all the tasks without a lot of headache - and was overrulled by the hardware guys that chose a TI processor that cost about 4 dollars less - (and made the software job impossibly difficult. I left. The products failed.). When you have a spreadsheet that has hundreds of lines for the hardware costs and a single line for the software development cost, this is what happens.
None of this is specifically relevant to the debate at present, I'm just trying to show the rock and hard place you can get into in the hope that other hardware manufacturers listen to their software guys during the hardware development process.
For a long, long time Linux has needed a binary driver interface. The need to maintain a driver and fix bugs over multiple kernel versions (even minor revisions) plus the need to open source (for the most part) that driver have long been major reasons that hardware vendors have been unwilling to support Linux.
The ability for a vendor to create a single version of their driver that they don't need to open source (of course, there are benefits for them and us if they do, and they still can) and to support that single version will spur manufacturer support, which will make many Linux users very happy. Too much decent hardware is sitting idle or isn't fully used because the only driver available for it is an early beta written by a college student five years ago who no longer uses computers at all. Don't get me wrong, there are some excellent driver writers in the open source community. But, they generally write drivers for hardware they have themselves and only on a volunteer basis. Drivers should be the responsibility of the hardware vendor, who should either provide them on disk or in firmware.
With regards to stability, the thing that made pre-certification windows drivers unstable was the lack of proper segmentation and preemptive multitasking in early windows versions, not the fact that they were binary drivers. If the binary API is written correctly (as I suspect it would be by the very talented Linux kernel developers) then isolation of faulty binary drivers will be taken into account. Perhaps they can even be user space binary drivers.
With more manufacturers (who know all the bugs/quirks in their hardware) getting more users (many people trying to break it) to use their software drivers, the overall quality of Linux drivers will improve tremendously, to the benefit of all Linux users.
To those of you suggesting that this is a way for vendors to use closed source software instead of open source, you're absolutely right. For the most part, these are vendors who won't release open source drivers for Linux at all. Wishful thinking about them being forced to open source their drivers or face the wrath of the Linux masses is just that, wishful thinking. I personally will continue to buy from vendors who support openness in their documentation and drivers, but if it's closed source or no support, I pick closed source.
One more thing... to those of you opposing this because of closed source concerns... are you opposing it because closed source software is inherently evil (it's not) or because you see any compromise on this issue as the "other team" "winning" and therefore "your team" must be "losing" and you hate losing?
Erik
PS: Taco, get Kupu.
That should be "These fellers don't sound like they're from these parts."
The fact is, that a driver is only one part of the openness puzzle. Sure, so you can patch a driver. Great. But drivers don't do much, they're just glue, not very interesting pieces of software. Now, if you could fork the designs of your hardware and go add features as you see fit, that would be useful. And in fact some pieces of hardware have firmware, which is basically software-on-hardware that is possible to change if you have the source code and can recompile/reflash it, but firmware is usually closed and nobody really cares about that. I never hear people (outside of a few kernel developers) saying things like "You know, I thought about buying an iPod but decided not to because it didn't have an open firmware".
But let's say that firmware was in fact open. Now what? Well, maybe you want to fork the iPod and add some new features to it. Great. But what if you need new features in the chips themselves .... chips can be open source. Actually many chips these days are synthesised by machine from VHDL/Verilog sources which looks like code and can be changed by people who know the system. But I never heard anybody, not even the most extreme kernel developers, refuse to buy a piece of hardware on the grounds that the Verilog wasn't available.
But even then, even if you could fork and redesign the iPod in any way you saw fit, it would still be controlled by Apple because at some point thoughts in your head and designs on paper have to actually be manufactured, and Apple have big honking factories which churn out their iPod design all day and not yours. So how are you actually going to get this to people? You need a factory too.
So, basically, you can keep going and going until you reach some bottleneck at which point you aren't in control anymore and are reliant on other people to get things done. It's tempting to think that the transition line is at the boundary between software and hardware, but this line isn't all that clear - hardware is hard to "fork" because it exists physically and has duplication cost, yet the purpose of copyright is to allow you to make something with a zero copy cost have non-zero copy cost so it can fit into our economy. Even when that privilege is not used, like with GPLd software, it doesn't stretch down the whole stack because that GPLd software still requires controlled things like hardware and electricity to be useful.
Put simply, there is no black/white open/closed divide. There are only shades of grey between one end of the spectrum and the other. We should strive for openness as it has several properties which help our society Get Things Done, but at no point should openness overrule getting things done as that's putting the cart before the horse.
Thats why i bought winxp pro.
Seemed expensive, but adding up the hours i had to fight to get shit working with linux, it was more convinient.
(Most people dont work around on a system for fun. If it takes more then 10 hours to get a system to work perfectly, i.e. all drivers are ok, all devices running as they are supposed to, ect), then windows is cheaper, imho)
HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
One thing I don't get about this is why a stable kernel driver API wouldn't benefit BOTH GROUPS -- the ones who want to release binary-only drivers and the ones who want to write open-source drivers. Both could use the API to interface with the kernel. Having a stable API means that open-source writers wouldn't have to continuously rewrite their code to be compatible with each release of the kernel. I'll be that'd make a LOT of people happy.
This doesn't mean the API can never change -- it just can't change with every revision. Change it at the big mileposts -- 2.4, 2.6, 2.8, etc.
"But it violates our idealisms!" shriek the F/OSS pundits. Well, that's a nice, happy, kum-bah-ya image you have going in your head there, Family Circle, but it's not reality. Some companies are going to be willing to create open-source drivers, some won't. Some protect their code with all power. So what? No skin off your back just because they won't open it. It doesn't violate your ideals just because someone HAS written a closed-source driver that works with your operating system. Don't use it! Write your own! I invite you. What would it hurt to have both a binary and an open driver for each piece of hardware?
Having an attitude of, "We'll make it so you CAN'T use binary drivers and then they'll open up their source!" is ignorant. You might get one or two converts to that ideal, but most are going to give you the bird and go their own way. Meanwhile you're alienating tons people that would otherwise use your software AND contribute to it, but they can't get their $150 video card to work and so have given up. The power of F/OSS is in numbers and you can't afford to not have them.
Remember: Another ideal of many F/OSS advocates is that just because you can use something in a negative way doesn't mean the idea is bad. DRM? Not a bad idea. Can be used in bad ways, though. TPM? Same idea. Even Linus said it. Kernel driver API? Could be used in many different ways, some good, some bad, some desireable, some less so. Doesn't mean the idea is bad. Quit throwing the baby out with the bathwater simply because there's a good chance that The Man will take advantage of it.
Blog,Twitter
Linux is a 'free' unix like system, and they could give a rats ass about "Free"
Obviously the developers don't care much if those people use it or not. There are enough people that do care enough about being capital F Free. Even commercial users appreciate the Freedom of not being locked into a single vendor, generally more than they care about license cost.
Ultimately, "Free" software people want to push their ideoligy on others
Not really. If you want to use the Free software, you have to agree to the terms. The developers aren't forcing you to use their software, or even "pushing" you to use it.
If this "silent majority" you speak of really does think the way you say, then why are they still using Linux? They could use BSD, or a even pirate a commercial OS (which is what most people that only care about free-money do).
I've had enough abrasive sigs. Kittens are cute and fuzzy.
The BIOS is indeed an issue, and there are efforts underway to make a Free BIOS.
But why not try our best to have as much control as we can?
I've used ATi hardware with Windows, Linux, FreeBSD and OS X. As far as I can tell, the only decent ATi hardware drivers are the ones not written by ATi. The DRI drivers for their older hardware is nice, and the Apple-written drivers for OS X also seem competent. Their binary drivers for Linux and Windows, however, contain some of the least stable code I've ever seen.
I am TheRaven on Soylent News
How would it be illegal for a hardware manufacturer to write their own closed source driver to interface to a Linux kernel API?
They would not have to extend GPL code, merely communicate with it in a standardized manner.
(Bear in mind that I am dead-set against this.)
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
OK, let's start by assuming that a stable binary driver ABI is, in general, a Good Thing. It means that, potentially...
Now, on the minus side, these benfits come with one problem from some points of view: hardware vendors would potentially be able to release binary-only drivers. Wait, though. This isn't a technical issue - it's a licensing issue. So why not just create a driver ABI for the kernel, and GPL it? Take steps to make sure that the only conceivable way you can build a driver to this interface is to place it under the GPL.
Existing drivers - those already under the GPL - can move to the binary interface without penalty. Any changes made to the way the binary interface works will be propagated out to all the drivers that use that interface. Companies that don't/can't use the GPL'd ABI can continue to write their drivers against the existing kernel driver interfaces, with all the headaches that entails; only now, they would have the lure of a much simpler, cleaner, binary interface for the small, small cost of opening up their driver code.
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
No contest. I've used Windows often enough to know that binary drivers that really work and work well are very very rare.
There simply is no excuse for binary drivers, either under Linux or any other OS. Windows users should be asking why they have to put up with it rather than Linux users asking to be included in the shitefest that is binary-only drivers.
It has nothing to do with Open Source ideals and everything to do with security and control of your investment.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
HA! Admit it! It's Sony and they've come with their so-called proprietary CD-Rom driver.
Please give Sony a stable kernel API so that they can hook your kernel system calls!
DRM: playing soon at a Linux distribution near you!
I never hear people (outside of a few kernel developers) saying things like "You know, I thought about buying an iPod but decided not to because it didn't have an open firmware"
Few people say that, but almost as you yourself argue, there are few developers working on such issues. We retain freedoms for everyone, but only a small percentage of people can use those freedoms at a given time.
That's okay, it's still important.
So, basically, you can keep going and going until you reach some bottleneck at which point you aren't in control anymore and are reliant on other people to get things done. It's tempting to think that the transition line is at the boundary between software and hardware, but this line isn't all that clear - hardware is hard to "fork" because it exists physically and has duplication cost, yet the purpose of copyright is to allow you to make something with a zero copy cost have non-zero copy cost so it can fit into our economy. Even when that privilege is not used, like with GPLd software, it doesn't stretch down the whole stack because that GPLd software still requires controlled things like hardware and electricity to be useful.
I don't think the transition line is at hardware and software, but software is an easier fight then hardware, though so much hardware now has firmware loaded on boot- the line blurs further.
Put simply, there is no black/white open/closed divide. There are only shades of grey between one end of the spectrum and the other. We should strive for openness as it has several properties which help our society Get Things Done, but at no point should openness overrule getting things done as that's putting the cart before the horse.
"Black and white" and even "shades of grey" is dualistic thinking. The issues are multifaceted, but saying that we shouldn't try is essentially saying we should give up. Why give up now, when we've made so much progress? We struggled for years for where we are now. The number of Free Software users is a critical mass. Companies are now working with us. We have a large, powerful community- now's when we can put pressure on the companies to do the right thing. We're winning the battle, so let's not give up now.
A small addendum to my above comment:
I have now read (yeah, yeah, read before replying -- bite me) this article about why a stable kernel interface is a bad idea. Some very, very good points here that, in essence, I have trouble debating from a technical standpoint. Ok, tough to keep things up-to-date, developers don't want to have to keep the old interfaces in place because it makes a maintenance nightmare, and you possibly sacrifice the stability of the OS as a whole if you do.
Well, that's groovy. I can dig that in ways that shovels can't even begin to contemplate.
The thing that always strikes me, though, is this: The kernel is developed on the F/OSS idealistic system, yet it is striving to break into the mainstream. However, the mainstream simply doesn't work that way. In the Real World(tm), you have to have backwards compatibility, you have to have systems that don't break APIs and standards very often, and you have to have an ease of development for anyone and everyone who wants to contribute to it. Why? Because this is how business works. Business doesn't always have time to stop and, "Do it the right way." Companies can't employ kernel hackers to work 24/7 on keeping a single driver up-to-date because the kernel changes all the time. It's like having a coworker that continually changes the function parameters of the code I'm trying to interface with -- I'd fucking kill him! I don't have time for that shit, and I suspect that's the attitude of many corporations who would otherwise contribute to Linux.
Same old, same old, folks. Idealisms meet reality, big mess ensues. I hate sitting on the fence between the two, but I see good points on both sides. Resolving the conflicts, however, isn't always cut-and-dried.
Blog,Twitter
Personally, I think the 'no stable ABI to discourage closed source drivers' is just wrong-headed. I mean, it has hardly stopped people writing closed source drivers for Linux, has it.
And it's just bad design - The kernel devs are deliberately making it harder for *anyone* to write drivers for the Linux kernel, regardless of their license. Two wrongs don't make a right.
And the only real effect is that it just makes it a hell of a lot harder for the users to make their computers do useful work.
They are quite happy, for example, to claim that Reiser4 can't go into the kernel because it implements its functionality in a non-standard way, not using the kernel VFS API/ABI, and then turn around and say that standards are the enemy of innovation and encourage closed source software when it comes to a generic driver ABI/API.
They are quite happy to take advantage of other peoples published standards and decry companies like Microsoft for not adhering to them, but then come out with crap like this - if standards are the enemy of innovation and encourage un-debuggable components in the kernel, then this is surely the case in other areas of software development as well.
Do kernel developers really believe that Internet Explorer's approach to supporting standards is the right one?
I gots ta ding a ding dang my dang a long ling long
Yes, it should. Why? Because if it doesn't, Red Hat and Novell (one or the other) will make one and the other will follow suite. And the one they make will end up being mediocre with ease of forward porting given priority over effectiveness.
Novell has bet the farm on Linux and they need this to keep the hardware vendors happy and convince them to make the move from supporting Netware to supporting SuSE. If we refuse it from the main kernel tree then it'll be yet another incompatibility in the vendor kernels and yet another roadblock to using a generic kernel on those distros.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
I actually think from both perspectives a clean binary driver API could be a Good Thing, especially if it involved some sort of sandbox that such a driver would be kept in, and even more so if it could be a common binary API between, say, Linux, BSD, and possibly one or two other OSes.
- You wouldn't have to rebuild/rerelease such a driver for each release of the kernel.
this would be really nice for distros, a kernel update wouldn't have to include
rebuilding the ABI-compliant drivers.
- If your code is sensitive to optimization flags, etc. it can be compiled "properly"
once and not redone wrong by various distro builders. (yeah, yeah, it probably means
the code actually sucks, but...)
- It would provide a clean boundary for the GPL-ness of the kernel; this gives you a way to
encircle vendors who think their code must be proprietary -- they keep a minimum amount
of proprietary code, and we encircle it with open, clean, GPL code. Then those vendors
can see how much business they get from Linux users, and start to take Linux users
concerns (like GPL-ing their drivers) more seriously.
- You could build software adaptors that let you take drivers for other platforms
(MS Windows? OS/2? BSD?) and load them against a Linux kernel; and you could do it
once.
- You could also build software adaptors that provide trace/debug/trace-playback
information for these ABI drivers, which could make it easier to debug problems.
Now of course, you could do the last two with the current, source-code driver interfaces; but they would be (in my opinion) much harder to maintain without the sort of set-in-stone nature of an ABI driver interface.I know some folks will argue for some sort of GPL purity -- that Linux should actively avoid any and all contact with proprietary code. But being able to run proprietary user-level code is actually a feature that lets you displace proprietary operating systems, and I think the same thing is true of drivers. And once the proprietary-driver vendors discover they can make money selling their hardware for Linux, they might discover that having their customers be able to send them bug fixes as well as bug reports is a Good Thing.
- "History shows again and again how nature points out the folly of men" -- Blue Oyster Cult, 'Godzilla'
Linux should support user-space drivers. Probably through FUSE and some other apis. These can then be binary, just like any other appliation. If they crash they will not take the system down. The API is limited but you will be able to open/read/write them. ioctl can be done with Plan9 style names, ie open "/dev/neato_device/volume" and write the desired volume there, etc.
Drivers that need more elaborate API's or need more speed will be stuck with the mutable binary interface and occasional GPL restrictions. Too bad. A lot of interesting drivers do not need this speed. And those that do may force the interface to user-level drivers to be improved until it is usable, which is a very desirable result.
I was playing to the audience here who are continually about "Sun's death imminent". No, I don't really think Sun is stagnant. But even if that weren't the case, Solaris is definitely vibrant and alive and it has a fine stable kernel ABI.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
Hardware manufacturers are not supporting linux because they are assholes and they don't care about supporting a OS with a 1-2% of the desktop market. It's not the "lack of a stable api" who causes that. Those who want to support it are supporting it.
BTW, the server market is different. 3com, adaptec intel etc. are writing themselves the opensource drivers and merging them in the kernel. See centrino wireless, intel SATA/e1000 drivers, etc. If intel and 3com and adaptec and cia can do it I don't see why nvidia or ati can't. The problem is that those companies SUCK and linux's desktop market is small, nothing else.
to be fair... just because the majority of people access slashdot from windows doesn't mean that they dont run linux... it might just mean that they run windows at work... everyone knows that people only use slashdot to avoid doing work and really almost never access the site from their home computers where they could spend their time looking at porn...
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
If you think solid interface documentation will just make a driver pop up, you're wrong.
I know several devices that have nice documentation, but no one has cared enough to write a driver.
For instance, my tvout chip, Chrontel 7011A has nice documentation, but no driver is available for Linux.
It's such a normal tvout chip, so there must be millions of computers with it.
This is an extremely insightful post, and I wholeheartedly concur. Just one problem: How does one build an API/ABI that forces the driver devs to include enough source code to let the GPL have its viral effect without technically corrupting the idea of a small, stable API?
Well if I have to choose inbetween _partially work_ and _not working at all_, I would take the former please thank you very much.
I don't waste 20 hours of wrestling with Ndiswrapper to "have fun".
Won't doing this slow down the overall performances?
Having a driver being part of the kernel should be faster then loading it externally right?
Having a binary driver instead of an open source means you can't contribute to it yourself?
Only those who risk going too far can possibly find out how far they can go. T. S. Eliot
Enterprise needs one thing, that applies to most OTS vendors as well. They need a stable API. There's really nothing to argue about that unless you believe the should bow to your personal political belief system and be forced to open all their software/drives. But of course that will not happen.
So the solution seems kind of simple. Split. Let Novell, Redhat, Oracle and anyone else interested in developing for a more static Linux environment can fund this project. I think its time that at least those parties interested in bringing Linux into the enterprise (or even serious/usable desktop) market place make some decisions that might not be popular.
But if you complain about this your missing the whole point. Linux is GPL. It is open so we lose nothing. Maybe it will work out well in which case we only gain. Otherwise there will always be hackers working on a version of Linux thats exactly what they want. Linux is already free. I don't think there's much to fight about.
Quack, quack.
If the kernel developers aren't willing to provide a stable interface then they should be more ready to accept code into the kernel. Too many things (in particular I'm thinking of reiser4 here) are kept out for political reasons. I can understand not wanting to make a stable interface, but in that case you have a responsibility to accept code that works and is GPL without making people jump through hoops.
I am trolling
This is NOT about the open-source movement. This about the GPL and Free-Software movement where they're against any proprietary (and possibly closed and/or pay) system integrating against them.
There are quite a few other OSs out there that have been open-source longer WITH stable ABIs.
What I have a problem with is the people that are of the "OSS everywhere, no compramise" mindset, but then insist that Linux is what everyone should use. I have no problem with a minimalist OS philsophy where everything is up to you, but to then say people should all use that is silly. People want an enriched, well defined OS experience, so if you want to be the big kid in town you need to offer that.
They don't release the source. There is no source. That's the whole point. They just release the programming docs so anyone can write a driver. There is no IP for them to protect.
It is done for the same reasons that most linux iso's are distributed with a MD5 hash next to them
Problem is that a naked MD5 or even SHA256 hash can easily be replaced by anybody who crax0rs the distribution servers. A digital signature, on the other hand, uses public-key crypto; if the signature file doesn't decrypt properly, it wasn't created by the signer. Ideally, for an operation as big as Microsoft, the signing server is battery-powered and kept in a room-size Faraday cage surrounded by armed guards, and the private key is stored in pieces held by multiple trustworthy parties.
For an OS which is continually evolving and was not designed with a lot many future developments in mind, it is very natural to say no to the stable binary API/ABI concept for drivers. But as it matures and there is no longer a need to fix interfaces to support some out-of-world functionality, the driver interfaces are automatically going to be stabilized. (Unless kernel folks decide they get bored with having one function name for more than a year or that they want to keep driver writers continuosly on their toes - all of which is unlikely.)
/ 31/363790.aspx).
API/ABI compatibility obviously has it's own pros and cons - some times it's impossible to break things, take Windows for example. The world is going with LP64 model for 64 bit machines but Windows developers had to stick with LLP64 just because they made some design mistakes and now they cannot break the tons of applications. (See http://blogs.msdn.com/oldnewthing/archive/2005/01
Linux on the other hand can afford to break and fix things until the time where binary and out-of-tree drivers grow to out number the in-tree stuff. By that time I guess there will be a very less need to break things such as driver interfaces and the like.
And I think the mad rush to put everything in the official kernel tree is not a good idea from maintenance and complexity stand point. So if and when the Linux ABI/API stabilizes that will be a good thing for out-of-tree kernel drivers and Linux itself.
This will enhance the stability of the kernel in general and also allow hardware vendors to support Linux with less effort
Scenary 1: Closed binary driver running in your system. The box oopses. Damn, since I'm using that damned binary driver and I can't see the source, debugging symbols, etc. i can't figure out if its the kernel or the driver who has the problem. After many hours wasted you might find the real problem.
Scenary 2: Several closed drivers in the system. The box oopses and trace reveals that binary modules are involved. Was it the kernel, or one of the 5 closed binary drivers running in my system? Maybe a problem between two of the closed binary drivers? You might aswell give up.
Is the bug in the kernel or in the binary drivers? God knows -> can't fix/harder to fix -> makes harder to make the kernel stable
I don't see
This is an interesting suggestion, and if it can potentiallly coax more developers into providing drivers for their hardware *cough*BROADCOM*cough*EVERYSOUNDCARDEVER*cough* then I can't see how it would be a bad thing.
Our greatest enemy is neither a single man, nor is it a nation, it is, as it has always been, our own greed.
Giving binary driver only options is like giving companies the option to release binary only drivers without the source.
Its like releasing an open loveable OS and then having your low level API's call windows - kinda defeatest.
If any company whants to relaease only binary drivers- let em, just dont encourage it by giving them an easy option to do so.
I like openbsd, and the whole wifi/scsi driver snafu only went to highlight that this binary only way/option is bad. Would openbsd have binary only drivers - hell no and if openbsd dont do you have to ask, hmm why.
Binary only drivers secure OS, cause hand compiled ddrivers dont assure this eaither but then least you have a fighting chance.
The day you can get third party IP licensors (e.g. that nice crossbar architecture used in previous-gen nVidia chipset memory control blocks wasn't developed in house by nVidia and they have contractual obligations not to release interface specifications for it) to agree to have their interfaces open by the licensees is the day you'll have fully open register-level documentation for consumer 3D graphics chips.
"The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown
For graphics, GGI and KGI would allow direct binary-only drivers to be written that applications can use, again without modifying the kernel.
Not sure whether you could make any use of the ABI/IBCS work for drivers, but they certainly allow "foreign" binaries to run under Linux, without anything foreign being put in the kernel itself.
In other words, a binary-only driver layer would seem unnecessary, given alternatives and mechanisms that already exist. It may be useful in some cases, but I can't see how it would be essential.
You could also use Xen as a reverse microkernel. Have foreign drivers in a "driver-only" mini OS, running as a parallel kernel. Then all Linux would need would be a way to call the other OS across Xen - and that need not be binary-only/closed-source. Companies interested in binary-only Linux work might even jointly fund development of such a capability.
The problem is not with the kernel, or even with the kernel developers. The problem is that corporations have unofficial choices rather than something they can put the blame on if their coding is crap. Officially sanctioned solutions are always preferred when being able to blame someone else is important.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
This is an inflammatory issue, but a stable interface doesn't necessarily open the kernel up to proprietary drivers. It's a matter of licensing. Any third party could introduce a GPLed abstraction layer. There are big practical advantages to being able to take a GPLed driver's object file and plug it in to any old kernel. In that case there would be no really fundamental reliability or debuggability problems. The remaining problem would be the increasing mismatch between the abstraction presented to the driver and the abstraction supported by the kernel as it develops.
It would be good to separate the discussion into two, one for inflammatory license- and/or ideology-related culs-de-sac, and another technical, to address legitimate needs for stability in drivers that are not (yet) in the kernel tree.
There's a joke- programming is a lot like sex. One mistake, and you're supporting it for the rest of your life. By this measure, writting a device driver for Linux is a mistake. Because even after the feature set and the hardware itself is stable, you are letting yourself into a never-ending task of constantly changing the driver to keep track of the current API changes. At a previous job we spec'd it out at about 1/2 of a full time position to keep up with all the kernel changes. This is your job, from now until eternity, or at least until you're willing to have the driver declared obsolete and abandoned (after all, we all know that there is just three types of software- vapor, beta, and obsolete).
Well, congratulations. You have your religous purity. And guess what- it's comming at a cost. You wonder why Linux isn't more popular on the desktop? Well, here's part of the reason. It's hardware support will always- ALWAYS- be behind that of Windows. Why? Because when the hardware ships, it ships with Windows drivers that the hardware vendor wrote with it. Note that Windows pulls the same sort of API changing crap that Linux does. The difference is that the hardware vendors look at Windows, and the half man-year per year cost of supporting Windows costs, and go "but we have to support Windows if we want to sell more than 3 units." They then look at Linux, and the half man-year per year cost of support Linux, and go "Supporting Linux is not cost-effective at this time." I know, because I've seen this happen. So now the hardware is out there. And now we wait, for someone willing to step up and volunteer the time to write, and maintain indefinately, the driver. Someone less capable of doing it than the hardware manufacturer (this isn't to question the capabilities of the current kernel developers, but the fact of the matter is that there is a huge advantage to being three cubes down from the hardware developers, and capable of wandering over and asking direct questions, instead of having to reverse engineer what is really going on, having worked both ways).
So this is the fundamental question: which is worse. Having binary-only proprietary drivers, or being forever behind in hardware support and not having people contribute simply because they don't feel like having to constantly update the driver once they finish it, they'd like to be able to move on. I come down on one side, Linus and the kernel developers down on the other.
Fine. Their kernel. Their problem.
I mean, for me, failing means not achieving a goal. I try to avoid that.
Since I don't see how anyone could have "defining the precedence of a nebulous ideology in relation to a completely undefined experience" as a goal, I find your post incomprehensible.
I suspect Linus would feel the same way. For whom are you speaking?
I'm honestly confused, not trying to flame. Who is failing, and by what measure? I am succeeding, personally.
Oh, and just to be on-topic for once, I vote NO (to a static kernel layer that is not allowed to improve in order to maximise the profits of some guy who doesn't want to share).
On network drivers at least, the driver has such a small interface the driver is put through a full formal methods based proof system to prove the driver doesn't have certain classes of bugs. I hear MS has quite a cluster devoted to model checking network drivers. Granted this doesn't work for all classes, but at least some get fairly rigerous verification. I personally wish Linux drivers got this kind of checking.
The one finally rewritten as microkernel, of course using the amazing message passing version of Visual Basic.
PS Half of this post is serious. Finding what part actually is is left as exercise to the reader
nbody2002:If you can read this you may be addicted to the internet
"Basically, I want people to know that when they use binary-only modules, it's THEIR problem. I want people to know that in their bones, and I want it shouted out from the rooftops. I want people to wake up in a cold sweat every once in a while if they use binary-only modules."
- Linus Torvalds on linux-kernel
And many people forgets that non-gpl drivers may be very well impossible to write at all (at least some lawyers think this), drivers are not at all like an app is WRT to gtk, drivers are more like "plugins". Plus, a closed driver module makes MUCH HARDER to debug bugs if the driver is doing bad things, and you can't know that (which makes harder to stabilize and/or develop the kernel. Several closed drivers can make it a hell or impossible at all.
So I wrote a nice driver for it, with help from the excellent Rubini book since there's no frickin' driver documentation and the Linux sources are uncommented (putting your name at the top doesn't count as commenting on any team I've been on). It worked for a few months, until the next incompatible change in the kernel. Then I poked around in the kernel until I thought I'd figured out what had changed. Got it kind-of working (DMA is unreliable and I don't know why). Then the 2nd edition of the Rubini book came out, so I rewrote the driver and got it semi-OK again. For a few months.
The kernel has had about a zillion incompatible changes in the driver interface since then, ALL UNDOCUMENTED, there's no 3rd edition of Rubini's book to sort it out for me, and I'm just lost digging through the kernel sources. It's always the same pattern: customer complains, I spend a few days fixing it, and it sort-of works for a few months until the next gratuitous interface change.
OK so I'm a for-profit vendor and therefore deserve to die (how dare I want to be paid for being a programmer, it's only people who don't create new IP who should be allowed to choose what they do for a living). But I'm not the vendor. I wrote the driver for their device (and plenty of other open source stuff) because it needed writing and no one else was doing it. The driver is distributed as fully commented source (obviously), and I've given it out to anyone who asked for it (uhh ... both of them -- this hasn't made me a nickel in extra sales for the package itself, I tell users who want reliable Q-bus interfacing to use my DOS version because there's no OS to break my driver there, it's worked unchanged for YEARS). The users haven't touched a single line of code on their own that I know of, all they do is complain to me. So what's wrong with this picture? Why isn't Open Source magically making everything work, at no cost to anyone?
It's just plain arrogant to assume that Groovy Open Source will always fix itself, and therefore it's OK to make the kernel interface be a rapidly moving target with no real manual. I'm sure that when we're talking about some extremely commonplace device that hundreds of thousands of people have, it's not hard at all to raise a posse and go after new bugs when the kernel changes. But this device I'm talking about costs $2575 a pop and is of no interest to anyone who isn't keeping a 30-year-old minicomputer system alive with a brain transplant. Absolutely no one is helping me maintain the driver even though they have everything they need to do it. I'm doing a lousy job of maintaining it because it's 0.0001% of my job description, and it's just not my strength (I know how to program bare metal, keeping up with Linux internals would have to be its own full-time job).
I couldn't care less whether drivers are required by law to be open source (although I really can't believe that's enforcible on a loadable driver, licenses exist to make exceptions to the default copyright restrictions, and interoperation is not copying). If people want to see my I/O code they're welcome to it. Just please stop making it break!!! Especially if you're not going to bother helping me maintain it. I've got my hands full just keeping the user-mode code working (WTF happened to /dev/vcsa7 and up?! and /proc/meminfo?!).
Anyway my point is, if Linux would pick one driver interface, and commit to supporting it (OK, possibly among other
By the way- another advantage to having a stable kernel API layer is the ability to write a dead-tree book about how to write Linux device drivers and not have it be obsolete by the time it gets published. I have half a dozen books on this subject- half of them were obsolete by the time they were published, they're all obsolete now.
I believe it is easier and far more economic to weed out bugs in source instead of in a binary you cannot really change and distribute because of copyright anyways. Linux hasn't been in the mainstream news for more than 2-3 years, and only now companies are beginning to really take notice. It will be interesting to see who was right in a few couple of years.
:-)
What will the interface expose, when you yourself has created said interface? Not much. You can gain perhaps a little by testing the API against a live driver, but reverse-engineering a winmodem or a graphics card 3D language will just not work when most of the work will be hidden inside the binary. Again, I do not see why Linux programmers should waste their time on such endeavour when it can both become a legal nightmare and is just lots more hassle and totally insane compared to getting the open source drivers in the first place. NDAs? Just because somebody gave away theirs, doesn't mean we should all give up our freedom.
We'll be quick to point out "we told you so", in a couple of years though, as always my pleasure
I'm hoping the answer is obvious - it should be the latter. Yet imagine a situation in which desktop Linux has 50% market share. What kind of hardware vendor would be able to to exclude themselves from 50% of the market by keeping their drivers closed and yet still be competitive? Effectively, the market and the policies of the kernel people would force them to GPL their drivers.
Now you could say, well nobody is forcing them to make hardware. But this is just dodging the point: if I wish to sell an AwesomeWidget which needs a driver, and I write that driver, it should be my decision whether to release that code under the GPL or not. The right way for the free software movement to achieve victory is to convince people that free software is superior to closed development, both pragmatically and ethically. The wrong way is to say "Shut the fuck up, just give us your damn code already" - this sends a message like "we don't care about you, all we want is what you have made". Not a message an enlightened society should be encouraging!
I've given up on quite a few seemingly worthwhile software packages because the kernel driver was incompatible with my version of the kernel, often by just a minor release number.
I've done a lot of programming in C, but debugging kernel drivers is not one of my goals in life. And I think it's asking a lot of a developer, whether open source or proprietary, to maintain a version of the driver for every kernel release which comes down the pike.
There should be more and updated standard hardware interfaces for things like wireless adapters, graphics adapters, etc. It works at the lowest levels, like monitors, CD-ROM drives, etc. Why not have a beefed up standard graphics adapter interface? Why not have a standard OpenGL driver interface implemented by the *hardware* itself? That way, the kernel is not in the way, there can be an open standard driver implementation, and the super secrets the hardware vender wants to hide can still be locked behind their own custom driver.
Perhaps this is naive, but interfaces allow us do just about everything in life. All that is needed is some agreement between hardware vendors and kernel developers, or my laptop won't be capable of running Linux.
I believe a binary driver interface would be a wonderful idea, and it was the first thing I simply couldn't understand when I first started to use Linux. Why is everything all in the kernel?
The question is, why haven't we got one already? Linux is Open Source! Why hasn't someone branched!? Think XFree86 vs X.org...
Another point which never ceases to amaze me is the number of Linux users who have never actually read any further than the digest in the GPL. You can link other programs against a GPL program if it could be said to be a different entity!
"If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works."
- GNU GPL v2, Section 2, Paragraph 2.
I would love to see Linux mainstream, and binary drivers, simple and consistent installation of software, and a consistent user interface are the only I am going to see that happen.
Is it more important to have control than it is to have hardware ?
A few year ago I wrote and maintained the Aironet driver. The years of maintaining the driver and supporting users (I still support them) has illustrated to me the importance of an ABI. I didn't really notice it at first, but it hit me in stages.
.config. It was hell. It was something that neither I nor they wanted to go through. I figured the problem would go away once I was integrated with kernel source.
1) Experimental driver stage. I distributed the source and had online instructions, but you would be surprised at the large number of people that I had to walk through compiling their kernel with the correct
2) Late experimental stage. I had all the problems of the previous stage, but now the kernel API was changing under me so I had to put #ifdefs in to deal with it. I figured the problem would go away once I was integrated with kernel source.
3) In the kernel. Yeah I made it into the kernel. Okay first it was the pcmcia package and then the kernel. But now I had to strip out all the #ifdefs because we don't want that cruft in the kernel, but I still had to maintain the #ifdefs for other kernels. So now I had all the previous problems, but now I had to make patches with and without the #ifdefs. I figured the problem would go aways once everyone moved to the new kernel.
4) Firmware changes. Oh no! Cisco changed the firmware which changed a bit the I/O interface. Oh and look they are still changing the API in the kernel. So I can patch the new kernel code to support the new firmware, but I can't expect everyone to upgrade kernel just for my driver. (I wouldn't even do that because the XXXX driver doesn't work so well in the latest kernel.) Now I have even more problems to deal with including everything from before.
5) Throwing in the towel. It became just too much of a time sink. Both sides of my driver was changing like mad (the hardware and the kernel API) and the poor users that were trying to make it all work with kernels that they wanted to use. All my time was being sucked up in maintaining the status quo and I couldn't work on anything new, so I turn the driver over to good hands and moved on.
Now imagine how nice would be if in the experimental phase I could release the source and a binary for everyone to use. I wouldn't have to tweak and recompile for every new kernel. Anyone would be able to just grab the binary and use it if they wanted to. (Kinda like Windows... Ironically I use ndiswrapper for my new laptop with a broadcom driver and it rocks! I've used the same windows driver in linux for the past year across many versions of the kernel. It sucks that the windows network driver ABI is the only driver ABI that linux has.) If the firmware changed, I or anyone else could fix it and everyone could use it.
Whether or not we Linux allows closed source drivers is orthogonal to an ABI. Technically you can write closed source drivers now and if you want to, you can prohibit closed source drivers with your new ABI.
Linux is actually much better at this than windows - you can see what the kernel does. Microsoft's test suite means nothing, as explained by a (great) microsoft programmer: http://blogs.msdn.com/oldnewthing/archive/2004/03/ 05/84469.aspx
"In a comment to one of my earlier entries, someone mentioned a driver that bluescreened under normal conditions, but once you enabled the Driver Verifier (to try to catch the driver doing whatever bad thing it was doing), the problem went away. Another commenter bemoaned that WHQL certification didn't seem to improve the quality of the drivers.
Video drivers will do anything to outdo their competition. Everybody knows that they cheat benchmarks, for example. I remember one driver that ran the DirectX "3D Tunnel" demonstration program extremely fast, demonstrating how totally awesome their video card is. Except that if you renamed TUNNEL.EXE to FUNNEL.EXE, it ran slow again.
There was another one that checked if you were printing a specific string used by a popular benchmark program. If so, then it only drew the string a quarter of the time and merely returned without doing anything the other three quarters of the time. Bingo! Their benchmark numbers just quadrupled.
Anyway, similar shenanigans are not unheard of when submitting a driver to WHQL for certification. Some unscrupulous drivers will detect that they are being run by WHQL and disable various features so they pass certification. Of course, they also run dog slow in the WHQL lab, but that's okay, because WHQL is interested in whether the driver contains any bugs, not whether the driver has the fastest triangle fill rate in the industry.
The most common cheat I've seen is drivers which check for a secret "Enable Dubious Optimizations" switch in the registry or some other place external to the driver itself. They take the driver and put it in an installer which does not turn the switch on and submit it to WHQL. When WHQL runs the driver through all its tests, the driver is running in "safe but slow" mode and passes certification with flying colors.
The vendor then takes that driver (now with the WHQL stamp of approval) and puts it inside an installer that enables the secret "Enable Dubious Optimizations" switch. Now the driver sees the switch enabled and performs all sorts of dubious optimizations, none of which were tested by WHQL.
(IOW: it doesn't guarantee stability or quality at all. It's just a false sense of "stability")
So preach all you want. Very few people care.
Just because you don't care, doesn't mean we will stop caring..
You continue being plagued by spyware, adware, Sony rootkits and those NSA backdoors in Windows, etc, etc. The list is pretty long, but maybe we'll never know for sure..
Leave computing to the experts. We care.
Gotcha..I can attest that they are alive and well. I start work for them next week :)
If you have an Intel gfx chip a framebuffer driver does exist:
0 05-July/000457.html
http://mail.directfb.org/pipermail/directfb-dev/2
OK, all you folks against the binary driver interface: Let's assume ATI and nvidia never release source code drivers nor sufficient documentation for their hardware -- which is their right, by the way. Whose graphics hardware are you going to use in your linux boxes then? If you have a chance to select a powerful graphics board with binary driver only or a considerably slower and older one with "community" written drivers, what's it going to be?
How about each of us making our own decision if we like to buy their hardware+software bundle or not. If you do not like their deal, don't buy their stuff. Buy something else.
I just want to pay a fair price for a system that doesn't crash or force me to make "upgrades" that are not beneficial to me.
Obviously, I need source code so vendors can't extort more money from me after the sale, or force me to load upgrades in order to obtain security fixes. You can't really have a fair and free market without source code.
Having worked in a laptop vendor, its a different problem. What laptop vendors want is the best laptop for a price point (like $799) in the shortest time. So someone out in Taipei (the ODM) gets to do the mainboard, selecting parts from the list of things that work on windows. And that is because "works on Linux" is not something that the customers push back on.
The best way to get Linux support on drivers is for the vendors to demand it, which means that the customers want it. This is why it is good that (a) HP ships linux laptops, (b) Ubuntu are being really good at laptop-ready linux. I worry about the effects of IBM's exit from the laptop biz tho', and I don't see dell caring enough about Linux. Plus ACPI2.0 is coming out of MS and Intel, which leads to an even tighter OS/bios integration.
This really matters. Out there in the office and the home, the desktop is over, the future is the laptop. And Linux lags in hardware support. But it is a lot more mobile that it was before, and with a faster dev cycle than windows, things can only get better.
-steve
I wasn't aware that the Linux Kernel now supported RPM. Where can I find more information about this?
Linux is not Windows
You really think the open source movement is failing?
When even one major national PC maker puts a 30 second spot on national TV advertising a home PC loaded with Linspire or Ubuntu or FreeBSD or another operating system based on a Free kernel and a Free graphical operating environment, then free software has succeeded in displacing Microsoft software. It may be succeeding on the server, but until a Linux PC vendor starts advertising nationally, Linux is failing at the home desktop level.
Then let these few people use teh Free Software and let the others suffer through Windows. I take developer-friendly open systems over closed-source MS-hell any day even if I have to spend a whole hour before every hardware purchase to check if it runs with Linux.
Linux is not Windows
I might agree with you if there were no hardware out there in most categories supported by Linux
Many K-12 schools and other non-profit organizations, as well as home users who cannot find a job in this economy, rely on donated hardware. If Windows works better with the hardware donated to a given user than Linux does, then Windows is a better choice. The situation is similar for users switching to Linux without buying a new computer.
you mean. linux dont need no such hard work in the first place..
If a device won't work in Linux for WHATEVER reason then I just won't buy it.
Hypothetical: I'm trying to switch my home PC to Linux, or I run IT for a non-profit organization that receives lots of donated hardware. The problem is that hardware that I already own works better in Windows than in Linux.
Let's see here. Manufacturers want us to create a kernel than allows them to infect and interfere with its integrity, reliability, performance, and security, just so they don't have to keep maintaining that driver as the design of the kernel continues to be improved? They want us to stagnate the design of the kernel so they can let us use their stagnant device drivers? And they want us to have a system that is no longer viably supported by staff or consultants, while they are most likely not ever going to provide system support (if they can't keep the driver maintained, how the hell are they going to provide support for an old driver)?
I'd just stay away from their hardware.
now we need to go OSS in diesel cars
That's a flawed argument since we have working hardware.
Linux is growing in popularity in every segment it's in.
What about the segment "preloaded operating system on national-brand home PCs"?
Friends from HDS, NEC and Fujitsu. If you want to write binary drivers for an Open Source OS go and write for Open Solaris...
this is the worst idea I've heard in, well, about 10 minutes. hardware companies make mediocore hardware with worse drivers. give us the docs, and let us write quality drivers. that way, you don't have to support those users, nor bother writing the driver for that platform. you have the documentation anyways, thats how you made the windows drivers. your competitors can't use that to steal your secrets, since the actual magic is done in hardware, away from the driver.
also, the whole world isn't windows on x86. these drivers won't work on amd64 machines. or on macppc. or sparc64.
if being free (as in speech) and open provides a chilling effect for a company to contribute, and they don't contribute, then we didn't want them anyways.
Imagine working in the IT department of a non-profit organization that receives substantial donations of hardware made by a company that chooses not to contribute. If you ask for a different make or model instead, you get "beggars can't be choosers" instead of compatible hardware. Trouble is that many of these non-profit organizations are the schools who are teaching our children to use Windows and Windows only.
Firstly, I'm not going to talk about anything to do with commercial drivers, it's just too much of a religious war and no-one will listen to the arguments either way...
Instead, I can show why having a stable, backwardly compatible and well engineered* driver kernel interface, be it binary or not, is good for everyone, even those hard working open source driver developers:-
*Note: I use the word "engineered" purposefully. Anyone can design something, such as a bridge, but it doesn't mean that it will work. Engineering is a rigorous process with only a small part beinf design, the major part is proving the design works and is the correct one.
(1) A constantly metamorphosing DKI means that everyone has to run to stand still.
Just think of the number of man hours which has to go into modifying every single little device driver when the kernel interface changes. Just think of the number of times the interface has changed in the 2.6 "stable" series. Just think how many man hours could have gone into making the drivers better instead.
(2) A constantly metamorphosing DKI means that drivers get orphaned.
If a driver maintainer gives up or the company which made the hardware and maintained a driver goes under or is taken over then it won't be very long until the change in the kernel interface makes the driver unusable. There are many drivers in the current kernel which are still lurking, unloved and uncompilable at the moment, such as the Advansys SCSI driver. One of the great cries as to why Linux was so great was that it supported all that old, lovely hardware that the manufacturers forgot about. Well, it seems that because of the supersonic DKI Linux has as well.
(3) Separating the kernel totally from the drivers means both can concentrate on what they do best.
OK, so what would separating logically the driver and the kernel mean?
Well, firstly, with a fully engineered interface the kernel can interface with all the drivers in a sane and virtual way. The drivers are a black box, the kernel doesn't know and shouldn't know how a disk drive works, just that every disk drive looks like any other disk drive. In that way the kernel developers can stop worrying about those trivia and worry more about how they may optimise moving data around the kernel better or scheduling the reads etc. Why should the kernel care if it's an IDE disk on its own motherboard or a virtual disk held on a server the other side of the world as long as when it requests something to happen it happens?
Secondly, if the kernel is a black box to the device driver author then he/she doesn't need to care what the kernel does, as long as it performs to the tight specification and the driver is written to that specification then it will work. If it doesn't then there's a bug in the driver code and he/she knows that they have to fix it. It also means that the kernel can vet the arguments and data it's given to make sure that the driver isn't insane and trying to do nasty things to it.
(4) But we need supersonic goal posts because we need to be flexible and make things better!
How many times have I heard that one? Far too many.
If a kernel/driver interface is properly engineered there should never be a need to change it other than to maybe add functionality in a structured and backwardly compatible fashion for new types of device which were not envisioned when the original specification was produced.
ie. if the specification has to be changed incompatibily then whoever engineered the original needs a kick up the backside for not doing his/her job.
The problem with trying to produce such an interface specification is that it takes a great deal of effort and thought for somerthing which in the short term will only produce pain. Most developers of free software are unlikely to either put the effort in or have the political power to make it happen in the first place.
Agrajag: "Oh no, not again!"
Binary Kernel Driver Layer has you!
Fred Palowakski, is that you?
Been here 10 years, actually. Drop a line to my nick at gmail when you start.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
This is a legitimate question I have. Why not support a system like Apple introduced with their kernel in OS 10.4? When it comes to operating systems, I am just a user. I don't hack on them. So, I could be missing something in the whole "the drivers must be open source so that they can be included in the kernel and updated along with it" thing. I would like a clear explanation why doing things the current way is better than implementing a new system that supports binary drivers in a clean way.
/ 4. I think it is a rather neat solution:
If you are not familiar with the "KPI" thing, here is a short summary from http://arstechnica.com/reviews/os/macosx-10.4.ars
"With Tiger, Apple is finally ready to put some kernel interface stakes in the ground. For the first time, there are stable, officially supported kernel programming interfaces (KPIs). Even better, there's an interface versioning mechanism and migration policy in place that will ensure that the pre-Tiger situation never happens again.
From Tiger forward, kernel extensions will link against KPIs, rather than directly against the kernel. The KPIs have been broken down into smaller modules, so kexts can link against only the interfaces that they actually need to use.
Each KPI has a well-defined life cycle made up of the following stages.
* Supported - The KPI is source and binary compatible from release to release.
* Deprecated - The interface may be removed in the following major release. Compiler warnings are generated on use.
* Obsolete - It's no longer possible to build new kernel extensions using this KPI, but binary compatibility for existing kexts that use this KPI is still assured.
* Unsupported - Kexts using this KPI will no longer work, period.
The most significant part of this new system is that the kernel itself can and will change behind the scenes. KPIs will descend towards the "unsupported" end of the life cycle only as kernel changes absolutely demand.
Best of all, multiple versions of a KPI can coexist on the same system. This allows a KPI to move forward with new abilities and a changed interface without breaking kernel extensions that link to the older version of the KPI. The expectation is that the kernel can undergo a heck of a lot of changes while still supporting all of the KPIs."
If the fecking *driver* needs to know about the crossbar controller, things are seriously fucked up.
I suspect that the driver interface has bugger all to do with technology like that - the driver says "do this" and the GPU decides how to handle memory.
We've been through the whole libc5->glibc transition years ago, and for distributions offering binaries (Debian?) these transitions have always been a pain. Thankfully they don't happen very often, and there are numerous ways how userland libraries provide space for future API-expansion. If I choose to use binary applications, I can do so, but it's my choice to forgo the freedom-of-source, not that of the library developers. Now how would you like to recompile all your binaries each time a new version of glibc comes out? Because this is what we've been having to do with device drivers every new kernel release. It just isn't necessary.
Essentially what driver developers get is a moving target. A driver working today can be broken tomorrow, no guarentees. Naturally, your precious kernelspace ivory tower can not be compared to us lowly userland developers, but as I see it the kernel developers are treating this as a moral problem, not as a technical one.
So, instead of one proper ABI, we get companies creating compatibility layers, of which they know the interface doesn't change (as they wrote it themselves). Look at what nvidia has done. You are not stopping people from using non-free 'illegal' drivers, you are merely making it harder for companies to develop for linux and for us users to use. Does this change the result? We still have non-free drivers floating around, your choices thankfully can't stop them (for they give us more freedom!). And instead of having easy-to-use repositories of device drivers, we have to recompile all of them every time we want to upgrade our kernel a notch.
Freedom is good. So is the freedom of making decisions that are not your own. Grow up, and give us users our freedom.
This sig is intentionally left blank
Can he ignore his employers? Closed source kernel next?
I have carefully read what Linus and others wrote about practical impossibility
g _id=13588670
g _id=13609229
to implelement stable kernel ABI and sounds to me like nonsense - to the extent I'd
like to write a document which disproves their point.
If I ever do it, the document will be based on the ideas discussed in
debuggability of ALSA
thread I started. The thread started as
http://sourceforge.net/mailarchive/message.php?ms
, an ABI proposal of mine is
http://sourceforge.net/mailarchive/message.php?ms
.
The kernel developers' argument about different versions of compilers and
different ways they map data is nonsense because drivers should be statically
linked and not depend on any external library, they should be executable memory
image.
I just bought a new graphics card and the reason I didn't even consider ATI is that a friend of mine had one (just replaced it too =) and I've seen what ATI calls "driver support" for linux.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
What sort of drive does the Indy use? A 1GB drive runs $30; from what I can google up, it uses a plain Fast SCSI drive... hmm, want one mailed to you? There's a computer used-parts store near here that carries that sort of thing.
Heck, it'd be the least I could do to encourage kernel development, y'know? Not that I have an Indy or anything, but it's the principle of the thing.
Laws do not persuade just because they threaten. --Seneca
...if there was a stable driver API. But, it would sure open us up for all those security problems that plague Windows.
Linus and the "Linux Community" set out to produce a fun project that would work liike Unix, be stable, run on a 80386 platform, and be open for all to see and modify. These simple, high and lofty goals have guided the community since its inception.
One of the protections that I have come to rely on is that the code is open for many eyes to see. This helps to keep out the cracker riff-raff and the NAZI-like over zealous corporate types (not all, just some...) from spying on me or using my computer for unethical purposes.
Alowing a closed-source hardware driver in at a level that has kernel access, can filter my keystrokes, or somesuch nonesense without the opportunity for peer review to catch unethical (or simply unwise coding) behavior is stupid.
Yes, opening up a standard API would attract more hardware vendors, but at what price? It makes more sense to have a more modular API to begin with, but have the hardware vendor supply an API specification for their hardware; not what would reveal their secret internals, just how to properly communicate with it.
It wouldn't hurt Linux to have a slower adoption rate. We're fine right now. As the community grows and matures, however, more vendors will simplyy learn to play by our rules. No fight is necessary. This will be won by simply sticking to principles and allowing hardware vendors to fade into the "I should have ported to Linux" sunset.
In 10 to 15 years, I can see 4 or 5 OSs owning 90% to 95% of the market in a somewhat even tug-of-war. Linux will be one of them. Windows, if Microsoft still exists as a software company, will have less than 5%. That's not to say that Microsoft can't come out with a new, great OS that will be one of these 4 or 5 top OSs. It's just that Windows is losing out. Too much baggage.
I really love The Art of Unix Programming. http://www.faqs.org/docs/artu/ Maybe the simplicity of the kernel confuses them. What they are probably looking for is a driver development kit. http://www.jungo.com/linux.html This is nice, but what about all the new features that are added to the kernel. Plus, what about different architectures? You can run linux on an Xbox now. Do the companies think about that? Open source would be nice, but only shows half the picture. I vote for full documentation of hardware and half written software. Have a relaxed use policy where the documentation can only be used to create drivers. The company could use code words in the driver that confuse people, but they still release the source code. The function printk could be renamed to eaksdjfkasd and it could still work, but it is more difficult to understand.
One rant of mine is restricted use of products. Who says I can't use a screwdriver as a hammer? Why can I use a piece of software in any (legal) way I want? Pencil and pen companies don't bother writers about wanting a share of the profits.
WE WANT AND NEED FULL DOCUMENTATION and k.i.s.s.
frank
fsuarez2005@yahoo.com
Now that that's out of the way, is there still a reason we can't have a stable kernel ABI? I don't see that there is any way to make the "your module is a derived work" argument that really makes sense in this case. But of course, legal phantasy should be left to legal minds, and mine isn't one (thankfully).
As someone who has personally had to tweak the source code of his WLAN driver in order to get it running on 2.6 kernels by changing one line of C and 12 of shell script utility, I can say that we need to find a way to keep drivers working across kernel versions. Come on people, this was the open source linux-wlan-ng driver. The lack of a standard interface is holding back open source drivers as well as proprietary.
I was without net access for 3 days just because I switched to Gentoo! I had to download local copies of the linux-wlan-ng drivers in Windoze, hack their source and then spend another day figuring out how to use the accompanying shell scripts to start the network interface wlan0 without crashing the driver due to an unneeded firmware upload. This has got to stop, it is inane and idiotic that I must do this on every distro switch or major kernel upgrade.
"one of the main problems for getting device manufacturers to support linux is the fact that they either have to release a new version of their driver every time the linux kernel changes some esoteric internal API, or be badmouthed for not having good linux support."
Um, no.
There are two easy ways around this:
1) Publish the hardware specs and let the community write the driver.
2) Get the driver into mainline and let others take over maintenance of it for you.
I think the answer you would hear from those that contribute to Linux rather than just use it is "yes!"
How exactly does that help the adoptation of Linux on the desktop?
The policy doesn't help Linux on the Desktop, but the Linux Desktop does not matter anyway. Its a novelty- the desktop war was fought a while ago and everything not called Windows lost.
Linux matters on embedded devices, servers, and super computers- thats its biggest market. In each of those markets having binary drivers is not a big deal. In fact, for a super admin, having something they can't mess with in a server is a possible security risk.
Linux gets in people lives through TiVo's, cell phones, wireless hubs and free google use- not the desktop. Thats where it matters.
Open Source Sushi
Joe sixpack does not care if a driver is binary or open source, he wants it to work. So do we care about joe sixpack? I hate to say, I do. I have to help people with their Windows computers and I find it exceedingly frustrating that I actually have more years of Window experience but much less of an ability to actually fix problems on Windows than Linux, let alone get Windows to do anything outside of that small box Microsoft has prescribed. It would be great if the systems I need to support could run an operating system that doesn't make me hate IT work. But it takes a bit of time to learn a new OS and I can only expect that a user will only switch if the expected value of the switch is greater than the cost. Hardware that doesn't work will quickly make the cost appear high.
I would like to see linux distributions that target the average user and provide at least the same ease of use as Windows. I think Ubuntu, Xandros, Linspire, etc are seeking this end. Enabling proprietary drivers to just work in many cases will drasticly improve the users experience with a these linux distributions.
I understand the kernel developers desire to not be tied down to a fixed interface. But why not declare a kernel binary stable on a predictable time table (e.g. every year) and let binary driver developers target that kernel? That kernel will likely not get any updates short of something extremely critical. Distributions that would gain from binary compatibility by default would use these binary stable kernels. Might not get the latest and greatest features, but I expect a years worth of kernel features would be of less value to most people than hardware that actually works.
I also think for the most part binary drivers are assinine. But I don't see that anyone will convince companies like nVidia of this anytime soon. So why not work with them to make these drivers just work but clearly inform the user that they are using binary drivers and the problems with binary drivers.
Making more hardware just work with Linux can only encourage its use. Allowing binary drivers in the short term could encourage more open source drivers (and binary ones) in the long term.
If open source drivers really provide a substantial technical advantage (stability, working properly, lower cost) I would like to think with a little time those companies producing endorsing open source drivers would find a competitive advantage over their proprietary counterparts.
Is the goal to rid the world of binary drivers or to empower the users/developers?
Who cares? The Linux Desktop does not matter anyway. Its a novelty- the desktop war was fought a while ago and everything not called Windows lost.
Linux matters on embedded devices, servers, and super computers- thats its biggest market. In each of those markets having binary drivers is not a big deal. In fact, for a super admin, having something they can't mess with in a server is a possible security risk.
Linux gets in people lives through TiVo's, cell phones, wireless hubs and free google use- not the desktop. Thats where it matters.
Linux should not and will never change itself to compete in a market in which it can't win. Who cares if Linux is not a wild success on the desktop? Desktop users are usually not developers, so they cannot help Linux with its true goal- to be better software. Linux wasn't made to win popularity contests.
Open Source Sushi
As an ordinary end-user (Debian, Ubuntu and SUSE) I feel ground down by all the rowing and politics in and around Linux. Most of it is utterly immature and some of it is Utopian enough to make an anticapitalist rioter look like Gordon Gecko. You can be as open source as you like, but unless you produce an operating system that does what people want, in a way that suits them, then no one will use it and they'd be mugs if they did.
Most of us want something that "Just Works" and have no wish to live in a permanent building site because developers are so blinded by politics and squabbles they cannot ever see the finished building. I guess there isn't much hope for desktop Linux unless a fairly powerful outfit moves in, forks the kernel if necessary and focuses ruthlessly on delivering what the end user wants, not what a clutch of devs decide an end-user "should" want or must be made to want in a politically correct world. And if that means a very different model of kernel development and a binary driver api, so be it. Ironcially, if either Steve Jobs or Bill Gates were running a big Linux distro this is very likely the approach they would take, I would guess, and no one can accuse either of being unsuccessful.
Las qué passoun
tournoun pas maï
Then let them use Windows. Its not like at Microsoft where every time a competitor is used then Linux loses a sale. Its not like "The Linux Company" benefits from greater desktop use.
Use what fits. Use what software works best. If Linux does not work for you or someone else they have options.
Linux is about quality software, not winning some silly desktop war.
Open Source Sushi
I'm a linux user myelf. Wouldn't mind being more for it, but right now it's probably for the common good to keep me out of the code :) The hardware situation is pretty diappointing right now due to the driver problem. The thing is...I'm disapointed in the hardware vendors, not Linux or kernel devs. That's where the blame goes. I'm reading all these people saying, basically, binary drivers are how it works, linux coders shouldg et with the program. Sorry, try again. The reason it's not there is because the people who want the most of of there computer know that old model DOESN'T WORK.
The crap everyone is used to is not the best solution. Maybe open source isn't either, but at least it's an improvemnet. The way Linux works now, the system gets better by donation from every direction (you know, anyone who can code or help). How can locking out that possibility make anything better?? Yeah, I'm ranting. all these replies saying for Linux to "get with the times" is just annoying. How about the vendors get with the times instead.
AB HOC POSSUM VIDERE DOMUM TUUM
I have been on the inside of several large companies who shall remain nameless...
It is not so that they can have a "stable" or "easy to write" driver, it's so they don't have to release under the GPL. Remeber, if it hooks in the kernel it is supposed to be released GPL. I attended several classes on how to write for linux, and not have to publish under the GPL. These large companies want to protect thier IP.
Have their cake without giving back to the community? More drivers (binary or not) = more hardware support = more users = more companies release drivers = more users = ... sounds like giving back to the community to me.
When I write a program for myself or in a team with just a few developers who know how every aspect of the solution works, it's nice to change stuff at a whim. Since the team is small, everyone monitors each cvs-update for changes and talks to each other frequently to keeps abreast of what has changed. However, for projects spanning more than just a handful people, specs quickly becomes essential as a communication tool.
An API is just that, a communication instrument (or protocol) which is intended to describe the exposed interfaces, their purpose, what they do when used in various ways etc. Essential information for using a component. This is information any user of the component would need to know anyway in order to use it properly.
Now, when you mentioned refactoring being sacrificed if interfaces (APIs) are published (which is what I interpreted your text to say), I completely failed to see the underlying reasoning.
(reference). What this seems to say is that the whole point of refactoring is to keep the code from decaying while not changing the interfaces!
If you require new features / behaviors, why not simply create new function signatures and deprecate old ones? What's so difficult or bad with that approach to changes?
In a society that believes in nothing, fear becomes the only agenda ~ Bill Durodié
Initial costs associated with a manufacturer-supported driver:
Ongoing costs associated with a manufacturer-supported driver:
These costs exist even if a version of the driver is merged into the mainline kernel. The only problem solved by such source-level merging is compatibility with the latest kernel version. It is not acceptable to the manufacturers' customers to be required to update to the latest kernel/distribution to be able to use the device.
Here's the key point: If there is no binary interface between the driver and the kernel, all of the above costs skyrocket. You have M kernel versions against N distributions, with the total increasing over the life of the product. If there is a binary interface guarantee from the kernel development team to change only very slowly and only extremely rarely breaking compatibility -- like the guarantee Windows provides -- then the incremental costs are containable. It is reasonable to expect that 95% of their testing on 2.6.5 is valid on 2.6.14.
The perfectly reasonable response from kernel developers is that with closed-source drivers they get stuck debugging problems that are't kernel-related (I don't hold ideology to be economically significant so I'll ignore it here, without insult to people's strong opinions on the subject). Their proposed solution is to require the driver's source before they'll help with the debugging.
From the manufacturers' point of view that's a very draconian requirement. They are justifiably concerned about intellectual property (availability of the source makes it much easier for competitors to reverse-engineer the hardware/firmware). Surely there must be a middle ground. Is there some way to have a relationship between the device manufacturers and the kernel developers that minimizes everyone's costs?
I think there is. Note that all of the above costs and issues are just as valid in the Windows world as in the Linux world. Microsoft doesn't want to deal with bad drivers crashing their systems, costing them both development/debugging time and reduced perceived stability (--> lower sales). Their solution is the Windows Hardware Quality Lab (WHQL).
The WHQL is a separate entity from Microsoft. Device manufacturers are required to submit their driver source (effectively under NDA) along with their device. The WHQL staff runs the driver through a battery of tests, probably mostly automated. If the device and driver meet stability standards set by Microsoft, the driver is signed by WHQL. Windows checks for this signature at installation time and warns the administrator if it is not present. Microsoft can reasonably refuse to support non-WHQL-signed drivers when crashes occur, for exactly the same reasons that Linux kernel developers refuse to support drivers without the source. This system has been the single most important factor in Windows' significan
Bandannarama
The most important thing to realize about Free Software is the idea that the user should have complete control over his system. With non-Free software, this cannot happen. The user would just be a serf, opressed by bugs and viruses and rootkits and DRM and all the other "fun" things that come with black-box systems like Windows.
I care about Free Software because I want my system to work for ME, not the other way around!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
The GPL is a license. If you don't agree to that license, you aren't committing any crime.
Now, if you redistribute copyrighted software without a license to do so, that would be committing a crime... but how many hardware developers redistribute the Linux kernel? Put the ".h" files corresponding to this new ABI in the public domain, and those will be the only code that driver authors need to redistribute derived works of. Give them a restricted license, and it just means that driver authors will have to rewrite them. (no, SCO apologists, you can't copyright an interface)
Binary Linux drivers don't have to be in user land to be legal - there's a reason why kernel developers have added a "tainted" flag to help them sort out bug reports, rather than just sueing Nvidia.
Finally: The slippery slope started long ago, with ABIs for applications that allow binary compatibility and closed source software. Other than bad bug reports, every one of your arguments applies to applications running on Linux as much as to drivers running on Linux, and that experience might be instructive. Would Netscape have gone open source immediately just to get their apps running on Linux? Or do we have an open source Mozilla/Firefox application today because of those developers' experience writing closed source apps for open source platforms a decade ago? Closed source software on my Linux drives at work and home right now includes Flash, Acrobat Reader, Doom 3, Neverwinter Nights, GMV, SimCity 3000, Enemy Territory, Matlab, Cubit, Intel's compilers, Tecplot, and of course Nvidia's video drivers. Other than Doom 3 (several years from now), how many of these programs would have a Linux version at all if they were required to be open source first?
In fact, I suspect we have *more* open source software today because of the decision to allow closed source software: giving people the ability to use more software gives us "control over our computers" in a practical sense, a sense that attracts more users. I don't know of any closed source software whose authors would rather release source code than stop supporting Linux, but I do know of open source developers who would be Windows developers if they were forced to stop using closed source software on Linux, and I know of Windows users who would be Linux users if they were able to use all their hardware on Linux.
I don't really know much about the workings of Linux (but don't talk down to me and rest assured that I know what is being discussed here.) Could someone please explain to me why a consistent binary driver API would lead to a lack of stability?
Le français vous intéresse?
So what? You expect to be able to get the benefits of Linux for free and not contribute something in return?
This extra cost is your own fault. As GregKH makes very clear in his postings, if you released the source code of your driver, you wouldn't need to individually certify it for all those Linux distributions. The Linux hacker community would do much of the work for you. In short, it's hard to feel sympathy for your position at all.well this could solved easily, just use the Hurd instead of the monolithic Linux kernel, driver are in user space, oh, wait ... wait ... wait ... wait... wait... wait... wait... wait... wait... wait... wait
I just got out two nvidia geforce cards out of my main desktop box because I could not work.
....
I am not a newbie to linux, but a happy user since 94 and while not a kernel or X hacker I have some knowledge of troubleshooting servers or desktops with linux.
The nvidia cards work just fine in windows (where they did not lock-up or misbehave in the last 14 days, but under X i had all kinds of weird problems.
I just dropped in an old MGA 450 matrox with 16 megs and I am the happiest X user on earth.
I won't play quake a lot, but can work without the whole crap collapsing on me, or my pointer disappearing without an error in the log, forcing me to angrily smash ctrl-alt-backslash with a curse in hungarian-spanglish with a bleeding nose
Now what does that mean?
With all respect to Nvidia, maker of kickass chips, if they would open their driver source so people with more X knowledge could look at it would make thousands a happy user of their cards
If binary kernel development starts, that means one thing for me: no hardware that needs a binary driver in my servers, and unless it is some "better than anything" coold hardware I cannot live without - not even on my desktop.
I respect kernel maintainers a lot, and trust them, even that some drivers cause problems or they completely suck.
I do not trust big-evil-corporation that cannot give a decent OPEN SOURCE driver with their "make 200% at least profit a chip" hardware.
Make money on your hardware, I pay for it, but gimme the opportunity to have the developers inspect and improve that damn driver so I can actually use the hardware, instead of replacing it and shoving it under the table where my dog can piss on it.
why do hardware vendors so secretly guard their driver code?
I mean it's not like it contains their corporate credit card number in the source.
I've written drivers before (college, not since, just PoC, but still...) and it wasn't some huge horrible task using ultra powerful genius level insightful code, it was mainly just a lot of hacks a kludging and worked as stable as needed, but good lord it was fairly routine code.
I'd wager the apache2 hybrid multi-process/thread code is ten times as complex as the NIC driver I'm using right now, and it's open source.
But to get to a point, I do agree to a point that a binary driver api would be useful as all hell for those shallow minded groups out there that think their driver code is made up of something that might hurt national security or somesuch crap, but they better damned well start actually making drivers, I mean the knife we've had to crank into nVidia's back since the days of quake3 to get viable linux drivers has taken it's toll and they now release linux drivers almost as religiously as they release windows drivers, and I'll be the first to admit that I don't want to sit through a compile of a driver as large as nVidia's, but the 30 seconds it'll take to compile the driver for my 3com nic I can live with.
And I do still want some control over the driver, a "health check" if you will, something I can run the driver through that will spit out all the I/O the driver will do, the memory it will register, basically GDB on steroids, if I can't see the source, I can atleast see every single thing the driver will or can do.
But I'd honestly rather have open source drivers.
We have open source because a single piece of code is only as good as the people who have looked at it, and if only 1 person has ever looked at it, well...
but if thousands have looked at it, just look at the stability of the kernel now (or BSD, not to start a religious war but christ man we have some work to do in the kernel cause BSD really IS beating us when it comes to a couple of big factors, and I'm kind of ashamed of it being the kernel jockey around my enterprise)
This is a hard one. At one side I see what Linus is trying to do. He's trying to make it HARD to maintain binary drivers, and for good reason. He likes the stability it offers, and frankly, it forces the FOSS hand.
But on the other hand, I can see how a stable binary interface would be good for FOSS driver developers too. There are a lot of instances where I think a open source driver would be better maintained outside of the standard tree. Different development cycles, etc.
But no, I don't want to give binary drivers a free pass. It's bad enough the situation we have with NVidia and ATI. I don't want that with my NIC or with my sound card.
Say you're writing a sensor for a new CPU thermal ic, and you want to export it via a pseudofile (eg, /proc). How is it going to help your cause to have several subsystems that may or may not be present at very high levels (eg, the UNIX subsystem, the filesystem subsystem, etc.)?
In fact, a ukernel could protenally make it much more difficult to design something like that, especially if you can't guarantee that subsystems are present or that they can go up/down (gee, the filesystem subsystem went away, what do I do now?!?) In practice, it's a beautiful cathedral and not a funcational bazar.
I would also point to MacOS X, which makes some use of a ukernel (although most of the system I/O completely bypasses it for efficiency reasons -- nothing like a slow disk eh?); practically every device driver written for it needs to be re-written for new versions (ProTools being the example I'm most familiar with). Many of them use kernel extensions that do not gracefully upgrade.
The wheel is turning, but the hamster is dead.
This is not about preaching. This is not about pushing ideology. This is about developers maintaining creative control over the kernel, the kernel that they themselves have been building. Exactly what is your problem with this?
You say here that 'not only do users not care about "Free", but they will actively dislike "Free".' While regrettable, that is fine -- that is the users' prerogative. I sincerely expect they will think more highly of "Free" the tighter the IP and DRM restrictions become, but these related issues have been discussed to better effect in many other threads.
The trouble with your argument here is that the folks building and maintaining the Linux kernel (and most of the rest of userland Linux software too) are precisely the people who are concerned with this "Free" that you apparently couldn't give a rat's ass about. This has nothing to do with wanting 'to push their ideoligy [sic] on others', and everything to do with wanting to stay in control. As A nonymous Coward noted, building an unchanging driver API for the convenience of corporates does nothing for the kernel:
Again, this has nothing to do with pushing ideology. This has to do with developers maintaining control over their own project, a project that has been provided to you as a courtesy out of the strong moral belief of many in the OSS community that the tools we use to get our work done should be freely available.
Furthermore, given the significant number of websites devoted to OSS usability concerns (over 17,000 at last count), I think we can safely regard as invalidated your claim that '"Free" software people ... don't care about makeing [sic] functional easy to use systems.' They would indeed seem to care, but specifically within the scope of making free software -- i.e., they are not interested in kowtowing to your whinging demands that they gut their principles solely to make something passably usable right this very moment, and shackle themselves with a rigid driver API that hampers kernel development far into the future and threatens to scuttle years of effort to make a fully-usable computer system that is not beholden to secret vested interests.
You, sir, appear to be crying out that consumer convenience is more important than freedom. This is much in tune with the prevailing cultural trends in the United States. I find this deeply ironic -- "Give me liberty or give me death" has been turned into "give me convenience or I shall whinge", while "the land of the free and the home of the brave" has become "the land of the sheep and the home of the enslaved". While I understand the frustration apparent in your posting regarding when things do not work, I cannot agree with your sentiment. Some things, sir, are more important than instant gratification. I am deeply sorry that you do not appear able to recognize this.
"What in the name of Fats Waller is that?"
"A four-foot prune."
I wonder sometimes why someone can't just create an insulating layer that connects some standard interface to the kernel. Driver writers target the standard interface and the user installs the kernel interface for their kernel + the driver.
ok, so it's not as simple as having a stable interface in the kernel but don't you think distros would love something like this? It doesn't matter if it's not in the main kernel because the average joe user doesn't use that one.
All it would take is a few of those companies/people that want to have a stable API to "port" the compatibility blanket to each new kernel version.
Every company does expensive stuff they get no immediate return on but is required to get the company to function enough for the client to pay money to get what they want. It is important to consider this before criticising those that released their source code as out of touch.
NO!
If the linux adoption continues to grow, companies will be forced to make the changes. The balls in our court people. We have a chance to change how certain aspects of industry (the world) operation. And perhaps its not fair to dictate in this manner, but if it does end consumers the world of good, then it can't be bad can it?
Lets keep doing what we're currently doing. Lets change the world!
Giving IE users a taste of their own medicine since 2005 - http://pods.-is-a-geek.net/
The thing that always (not really, though) mystifies me is that the people complaining about a stable interface could just do it themselves. Maybe not J. Random Hacker, but the big companies could do so. I mean, nVidia does just such a thing, seperating the in-kernel part from the driver proper.
So, why don't these folks just make their own driver API out-of-tree and provide a patch for the vanilla kernel and popular vendor branches? Then they get to write their ABI or API compatible drivers and only port the interface between in-branch kernel releases. Boom, they write easy drivers, stay legal (debateable, but likely), and don't even have to answer to the mainline kernel developers. They won't get a lot of mainline help, but heh, it makes writing their drivers easier.
Answer: they don't want to do it. They simply don't value having ABI or API stable drivers enough to do the work themselves. That's it, simple. They can't or won't provide or partner with other players to provide such an interface. Its too much work, for too little gain.
Funny, that's also the story from the mainline kernel devs! Ironic how that works out, no?
I always get the shakes before a drop.
Not that Mr. T. and I aren't tight, and not that I don't believe in OSS or anything, but one of the great things about the GPL is that everyone is quite free to say "hey! FUCK Linus! We want a binary kernel driver API!" And so it would be, if enough people decided it would be a good idea to fork the kernel for this purpose.
+++ATH0
Isn't this usually done through firmware on the card rather than the software of a driver?
It seems a bit silly to me to allow features on a graphics card to be switchable by drivers.
+++ATH0
as subject.
Get 'yer panties back on.
A presentation was released at his followup post (the one the submitter omitted). The companies made the following points:
1. They wanted the API to be optional
2. They wanted the API to be GPL'ed
3. They wanted the API to be incompatible with binary drivers
4. They wanted a stable development platform
This covers every discussion on this topic (above this post).
The author posted a followup entry on his blog...
After reading that, it sounds like this was a non-issue. Sounds like typical business in Japan, and that Greg got caught up in the mix of things. Japanese will always defer to the senpai. And in this case, that's what he is.
Nick Lange nick.lange@SPAMTASTIC.hushmail.com
All of these complaints are frankly bull. Microsoft somehow manages to release security patches without breaking the driver model. They manage to make major changes to the kernel, like the numerous changes to the memory manager in Windows XP, NX support in XP-SP2, or the many changes in Windows Vista, without breaking the driver model.
It's not either-or. Yes, you have to tread lightly when you have a specification to follow. But that's the point. Imagine if IEEE refused to standardize 802.11b because they need to be able to update it for "future security fixes".
Open Source drivers are the cornerstone of OSS... because if you can't see how something works, or even HOW to make it work then you have nothing but a plastic box on your desk. The point is that you paid for the device, printer, video card, cpu, so you should have to have anybody's permission telling you how or when you can use it.
While I'd like proprietary drivers too, some stuff is patented or secret and they don't want to share it, offically it will never happen... Linus's view is that he can't fix things if he can't see them.. and he's not going to sign a bunch of NDAs just for drivers, he's too busy. Nor, can he gaurantee what the kernel is doing if you're running a bunch of "secret" stuff that could be doing "god-knows-what" behind your back!
You're going off on a tangent. I was saying there are two big issues that people keep coming back to, and this would address one of them. I happen to agree with you about the desktop.
Linux is about quality software.
And theres nothing about a binary kernel driver layer that would preclude that.
-everphilski-
and "you" account for what.... 1% of users? He won't complain. But by making it easy for the developer to make drivers for Linux, you make it easier for people to use linux with their existing hardware you raise your market penetration.
-everphilski-
Intel sells the most video cards.
Open Source Sushi
It was Berkeley Softworks
You can verify this spelling of KERNAL on a GEOS page. Feel free to Google for other pages relevant to "GEOS 1.3" or "GEOS 2.0".
Of interest to note is that the Amiga Kickstart OS numbering followed the GEOS pattern. After 1.3 we recieved 2.0x.
fast as fast can be. you'll never catch me.
Yes it is in having a free choice, compromising your ideology to get some more 'choice' in hardware, is only a short term gain and doesn't really help you long term in being better off. As for them not opening the documentation to there drivers, well that can't be helped, it is there hardware. If they wish to insist on not being compatible with open source methodologies there is no way to force them. Personally I'm just a bit disappointed with them really and if more proper alternatives appear I will obviously take those instead.
PS I believe Soundblaster Live was an example of the documentation being opened, so it isn't a surprise the drivers are so good. And I think it indeed also proves the point that drivers is better writeen by people with experience with the kernel than hardware makers with little. Really, they could save themselves quite some money with this. Not like they can hide anything anyway, competition will just buy one of the cards and backwards engineer everything.
If you add a binary layer you will get trusted computing. Simultaneously you will be giving up any chance of exponential growth a la open source in the realm of drivers which it could be argued, really need the kind of exponentially fast growth and reusability of open source.
...). If they just opened up an API and source code they would have had lots of help.
It would have been nice to have for my Brother MFC-410CN multiprinter. I waited over 6 months for linux drivers and they were binary apps, often questionable how to get them working and there are functions I doubt are implemented (ethernet connectivity, PC faxing, full scanning capabilities, ultra-high res.,
I had the exact same thought.
Another Example, is some usb devices, mass storage and hid for example, most usb hardware supports standard interfaces, and then you get plain
retarded hardware like a few early memory card readers, and some stupid Tablets, and webcams.
Surely for example a webcam should be able to specify the output framerate, frame format, and any controls it has, and work like every other
webcam. It does it on the software API side anyway, so why not have a standard hardware interface, then we would only need one USB webcam driver, one USB scanner driver, etc.
Maybe we can hope for better with the release of the "next fantastic bus".
What could be better than a jet powered motorcycle? http://www.youtube.com/watch?v=u8l6GTHLSWE
Provide a stable (across kernel versions) API for binary drivers (Is compatibility with the Windows driver API possible?), BUT.....
---Ensure those drivers do not run in Kernel mode---
Reasons:
(1) You must protect the stability of the overall kernel
(2) We really need all those drivers for oodles of old and new hardware..
(3) Hardware manufacturers will find a great deal of competitive advantage in providing source drivers.....hopefully enough to outdo any perceived competitive advantage in keeping them proprietary.
Matthew C. Tedder
Given my experience with hardware that follows a common spec compared to those that need their own drivers I prefer the ones that follow a common spec. I can print to a postscript printer without anything but a general postscript driver instead of a device specific driver. I would prefer that the driver was part of the device and it just presented a common interface to the os. You would flash the device or something like that if the driver had to be updated but the os would not have a specific driver per se. Just like at one point we could just use vesa to connect to a video card and not a video card specific driver. Now a days it seems that the video card could just have an opengl and directx interface as part of the card, a sound card could do openal or something like that and so on and so forth. We actually have this kind of thing for a lot of other devices. Look at the usb situation where we have 3 drivers total to run all ofthem (ehci, uhci, ohci). Or how about SATA where is there is a spec now for that, or usb mass storage devices etc. I can install a zip drive, fuji camera, usb flash drive etc with no drivers at all.
Putting a custom driver for every hardware type into the os is just a larger waste of time. You have a lot more software that has to be written and debugged on all sides. Putting the driver in the hardware and presenting a common interface or set of interfaces to the os would make it easier for people like ati and nvidia since they would not have anything to protect. They don't need to provide jack for documenation other then how to send the opengl, directx etc commands to it.
Computer modeling for biotech drug manufacturing is HARD!
There is no IP in docs. Tons of companies release docs. Just because a few companies are trying to protect their deceit, and make up bullshit IP excuses to justify their behaviour, doesn't mean you need to be a good corporate bitch and retell their lies endlessly.
This discussion is weakened by moving along the framing of the open source movement. That movement says nothing about software freedom, in fact it was built in part to talk about much the same software as the older free software movement minus the ethical discussion. This is a serious philosophical difference between the two movements and it has practical consequences--do users get freedom to run, inspect, share, and modify any time they want for whatever reason they want? Some of the choices the open source movement has made indicate that the answer is of secondary interest to whatever a business wants.
Digital Citizen
The open source movement has made their name quite popular but I doubt you'll be able to find people who understand what it actually means. The FSF wrote about this in their essay on the differences between the two movements.
Digital Citizen
The bigger problem is when the interfaces are not publicly described at all. This tends to go hand-in-hand with binary drivers, because it's a result of a similar mindset, but it causes more problems. If the interfaces are proprietary, it's very hard to make a good quality open source driver.
There is one thing you all keep leaving out about certified drivers:
Without them you aren't guaranteed support from Microsoft.
If you are running machines with all certified drivers and WMI/MSI installed applications then Microsoft will be right there with you until the problem is solved. You won't find it written anywhere but Microsoft gurantees that you're machine will not crash (BSOD) if you use certified drivers and MSI installed software. At home this isn't possible, but in some environments it is possible (and a good idea in other places).
In a way you are locked in to what Microsoft has approved, but if they've approved it then the problem is theirs to fix - not yours. Good luck meeting those two requirements, but if you can: hold them to it.
Get your Unix fortune now!
GNU has nothing to do with open source. The GNU Project predates the open source movement by over a decade and started the free software movement, a movement with a different philosophy than the open source movement. RMS has spent a lot of time in his talks and essays explaining that the work he has done for the past two decades was not done in the name of open source.
One particular example of this came up recently. Lots of people miscredit GCC, the GNU Compiler Collection, as an "open source" compiler. RMS, the initial author of GCC, has said quite clearly that GCC is a free software compiler. RMS gently but forthrightly corrected CNet.com writer Stephen Shankland on this issue, but Shankland still got it wrong a few months later. Hopefully CNet can bring themselves to mention the phrase "free software" in the proper context as often as they mention "open source" in the proper context.
Digital Citizen
... will be the death of the free operating system.
We need to be doing everything possible to keep our computers our computers. Making life easier for manufacturers to turn Linux into Yet Another Windows is counter-productive at best.
That arguement breaks for source-driven drivers as well. Can you use a driver for a 2.0 or 2.1 kernel with the 2.6 kernel? Maybe. Maybe not. Just because it's source-based doesn't mean that there's a guarantee it will build.
Using an abstracted binary driver interface means that newer kernels could guarantee backwards compatability, by supporting prior versions of the binary driver interface. The older interfaces might not allow the driver to use the latest-and-greatest features, but at least it would work as it used to.
An added benefit of putting drivers in a "box": recovery. Binary driver interfaces could be configured to validate parameters, logging and restarting drivers that attempt to do bad things before the driver can damage the rest of the system. My Windows XP ATI Catalyst drivers do that now...
Beware: I believe all are created equal, and have the right to life, liberty, and the pursuit of happiness.
Lets face it, saying put them into the kernel isnt good enough for two reasons
....
1 - The kernel team usually makes it fairly difficult to get them in
2 - Users arent neccessarily happy about their kernel getting massive updates in a "stable" series
In short, it would be nice, but its not realistic.
Unfortunately, this means that tons of open soure kernel modules are always lagging behind the released kernel, and the effort involved in maintaining it (for the developer) and installing/using it (for the end user) is much larger than it should be.
Doing anything to lengthen the time that external modules could be expected to work would be a Very Good idea.
All of us, developers, sysadmins, users have gone through the
upgrade my kernel
recompile alll my non included open source modules
see which ones break
try to update them
recompile
Its a real pain and something should be done to cushion it.
RMS uses the term "open source" primarily to refer to Eric Raymond's attacks on RMS's overall leadership of the non commercial unixy software movement. No question Eric has a different philosophy than RMS. However the world at large has not accepted RMS's definitions of the terms "free software" and "open source". In general they've continued to use:
free software = free of cost (java would qualify here)
open source = ability to modify and redistribute source code (QT under the old "non commercial license" would qualify here).
gpl = free software in the RMS sense (including non GPLed code under things like the X license).
Clearly RMS's definitions are "better" for his purposes. But I'm not sure his definitions don't assume you accept his idealogy. In any case my point to the original poster was that the goals of the open source movements (as they existed) 10 years ago have been met.
Alternatively, it could be just a driver that wasn't included in the XP cd but it was compiled for the same stable API such as NDIS many years ago.
All you then have to do is install the driver and you're done. There's no recompiling, no attempting to see if the driver is for the correct kernel version number x.x.x.x, no reinstall ing/rebuilding all the drivers just because you went from a 2.4 kernel to a 2.6 kernel.
That's the advantage of a stable ABI.
At my work, we're forced to upgrade to FC4 from the very stable RH8 install just because the RH8 CD won't install on the newer vendor hardware due to these specific driver issues where nothing carries over. And nobody makes updated install CDs... I know I know..
Sure it's the bazaar way to have multiple threads toward a common goal, and choose the best one.
But continual means you have no frelling idea what you're doing because you're just making a half-ass design that doesn't work, and then switching to another one, and another one instead of stepping back and designing it right in the first place.
Is that what you're saying Linux is? A work by amateurs for amateurs who are just dicking around like millions of monekys on a typewriter and hoping to come out with Shakespeare?
There's nothing wrong with having multiple revisions of an ABI and still having one. Look at OpenGL, or even DirectX.
RMS did not define "open source", the Open Source Initiative did that with their 10-part definition. Anyone who understands "GPL" to mean all free software is sorely mistaken and does not understand licensing; this misunderstanding has nothing to do with advancing or agreeing with RMS' argument justifying a user's software freedom. Finally, there's plenty commercial about the GNU Project. Not long after RMS wrote some of the earliest GNU programs, RMS himself was distributing copies of GNU software for a fee—a commercial endeavor—and later large and small businesses have enhanced and distributed free software for a fee.
I notice that your explanation of terms doesn't come with any pointers to back up your claims. I'd like to read instances of these terms being used as you say they're being used, in particular by those who know what these terms mean—RMS using the term "open source" to refer to ESR's attacks, for instance.
Digital Citizen
Of course, sticking to the steering wheel and gas pedal interface has not, in fact, hindered cars in any way... imagine a world where every year the control system for your car was tweaked for reasons byzantine and senseless to you, as a user?
If you implement a "stable" binary module API, the binary driver people will want that API frozen for all of eternity. You won't be able to come up with a better solution in three months or a year. Whereas if you have the source, even if you don't understand the finest details of every last line in it, you can usually understand it well enough to track API changes. Anybody can; if someone comes up with a better internal interface to timers, or memory allocators, it's not that hard to change code they have never seen before.
It's one thing to have a stable system call interface between the kernel and userland. But an internal API needs to be flexible.
Infuriate left and right
Maybe a stable driver API inside the kernel is not the real McCoy here, but maybe something completely different should be done: I suggest moving parts of the driver API to the userspace. Sure, that would have some performance impact but as I see it the requirements of a stable API could be fulfilled much easier there, and even without losing any flexibility inside the kernel. I know, suggesting something non-monolithic or even a more microkernel-like system to the Linux community is like begging to be stoned to death, but I do believe in the idea.. ;-)
I'm glad I'm not the only one who recognizes that Project UDI would benefit Linux and free software developers in general. Isn't it obvious that every time someone successfully standardizes open interfaces, major leaps in productivity follow?
Without open standards, the Internet would not exist. Various proprietary networking standards (Novell Netware, IBM channel architecture, Banyan Vines, etc.) used to work in their own isolated worlds, rarely speaking to each other. And people generally thought that was okay, because that's how it had always had been, and look how well each one works in its own little world! Similarly, email systems were proprietary and incompatible. Then along comes TCP/IP, SMTP and other open Internet protocols, and the world is transformed. Suddenly, everything can talk to everything, and with the 20/20 benefit of hindsight, it's clear to all how much better it is with the Internet than it was with all those proprietary islands.
Many implementations of the Internet protocols were proprietary and it didn't matter. There were always both free and proprietary implementations of the Internet protocols, but the important thing was that they all agreed on the same standards and (more or less) followed them, which bridged all those little proprietary islands into this wondrous whole we have today, where virtually any networked device is capable of communicating with any other. What mattered was that the standard was open, no matter how many of the implementations were proprietary. (And, of course, natural evolution tends to favor the extinction of most of the proprietary systems in favor of free software whenever such competition occurred, especially since vendor lock-in fails when customers demand conformance with open standards.)
The computer industry is starting to realize that XML, like TCP/IP, can bridge proprietary islands. Look at the number of legacy systems, interfaces, protocols and file formats which are being interfaced with XML to achieve at the application level what TCP/IP achieved at the networking level. Legacy systems, proprietary systems and even free systems, each with its own way of doing things, can suddenly be made to talk to each other in a robust, loosely-coupled fashion which was unfathomable just a decade or two ago. This process appears to be well on the way to revolutionizing the computer industry yet again.
Operating systems and device drivers are full of proprietary islands just waiting to be bridged, and it could revolutionize operating systems as much as TCP/IP revolutionized computer networking. Not all of these proprietary islands are "proprietary" in the closed-source sense -- many are also free-software islands which are "proprietary" in the "only works with this system" sense. Just in the domain of free software, there are countless little proprietary islands between various versions of Linux, FreeBSD, OpenBSD, NetBSD, Dragonfly BSD, Darwin, HURD, etc. These aren't "proprietary" as Stallman uses the term, but just try to take a random device driver from one of these random islands and dump it on another at random and see how likely it is to work without changes. Then, of course, there are also the truly proprietary systems such as Windows.
Bridging all those islands would benefit free software immensely, regardless of whether or not proprietary closed-source vendors jump on the bandwagon. Imagine if every device driver only needed to be implemented once to a common API, and it worked without source code changes on every operating system that supports that API? That's exactly the promise that Project UDI holds for operating systems and device drivers, and it's as revolutionary as the promise of TCP/IP.
The Internet wouldn't be where it is today without free software, yet free software wouldn't be where it is today without the Internet! This seems like a conundrum -- a chicken-and-egg problem. Actually, it's a truly symbiotic relationship, and it
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
I read few postings on how binary drivers are a bottleneck and why API can't be given. Their are two ways to argue. One is Kernel devs/Linus is forcing to open source for your driver so that they can integrate the driver into kernel and as it its said in Greg's email Simple, get your kernel driver into the main kernel tree (remember we are talking about GPL released drivers here, if your code doesn't fall under this category, good luck, you are on your own here, you leech .If your driver is in the tree, and a kernel interface changes, it will be fixed up by the person who did the kernel change in the first place. This ensures that your driver is always buildable, and works over time, with very little effort on your part.
Some are valid points like the discussion of how USB interface changed 3 times. This is the way Open Source works. What is the need of the hour is a software engineering process that can bridge the gap between open source developers and companies who want to support linux without investing lot of resources.
Just like how GOOGLE came and killed big monopolies, some company will come and change this to ultimately benefit the consumer. I am glad vendors now have an open mind to support Linux.
Don't even dream to kill the evil empire with such an attitude. Change and Innovate, else stop whinning about the evil folks, you are no better
Tell me, what BIOS do you run ?
The kernel can boot from it for now, and take over then, so we have control. And there is at least one free BIOS project under way.
Do you have the source to the firmware in your IDE disk drive ?
No, but it has to obey a standard to have a chance to communicate with the motherboard and the OS without special drivers. These drivers are all in the kernel, so we have control.
In your CD-ROM/DVD-ROM drive ?
They have to obey some standard too (ATAPI at least), so we have control.
Do you have the source to your SCSI controller's firmware ?
No, but we have the source of the driver. This is actually the only problematic hardware among those you listed. Some people spend time analysing how to circumvent hindrances in these firmwares (mostly zone change count for DVD). I still have to choose carefully a DVD drive for which I can find a firmware not crippled.
If you think you have control over your computer you are suffering under a delusion.
I don't think so.
To justify this payment, microsoft has to do some sort of testing, but (as many people have pointed out) there are all sorts of ways to game the test. == and: No. Microsoft doesn't take responsibility for any of this... Read your EULA.
Ultimately, Microsoft certification means Microsoft got their money, and digitally signed it. The rest is just PR foddeer (although it sometimes actually catches real bugs, that's just a pleasant side effect).
WHQL certification might also be how Microsoft prevents manufacturers from releasing their specs to the Open Source community -- If you release your specs, It may mysteriously take an extra 6 months to get your certification as they add test cases seemingly almost designed to break your unit during testing.
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
A good pointer is your own post. You use the word "open source" to refer to the OSI (Eric Raymond's organization). The term predates OSI by many many years. For example in the 1960s IBM had two classes of software:
"Open Source" which was software which came bundled with your system and you could do whatever you wanted with it (unclear in today's terms what kind of license this would be)
"Licensed" which were cost add-ons where things like redistribution were clearly illegal.
And this is my point. RMS choose to have the OSI's definition be the definition for "open source" since it responded to RMS's ideas and not a more neutral definition.
As for "know what the terms means" you are begging the question. The point in dispute is what those terms mean.
The primary reasons for my Linux switch:
/home and /etc up, reinstalling the machine takes about two-three hours at worst compared to days of trying to get settings back to how they were. I don't need to worry about registries, programs storing their own preferences elsewhere. The packages are freely downloadable and therefore I can afford *not* to back them up if I ever needed to. It also means software management is so simple it's hardly worth mentioning. Upgrades can be trusted to happen automatically via things like swaret as you know that two commands gets you back to where you were.
1) I now know what my computer does and when. I know when it loads a driver, I can exclude a driver (even one of the base OS drivers, such as filesystems), I know what drivers crash or don't mix and can easily exclude them. I can MAKE CERTAIN that when I boot from my hard drive, it doesn't write to the disk in any way... perfect for diagnostics and advanced troubleshooting. I also know that drivers can't be loaded into the kernel without my permission.
2) I can still boot 10-year-old versions of Linux (kernel, apps etc.) if necessary, without having to lose my current settings (using chroots, kernels, initrds). I can still run 10-year-old Linux apps and be pretty much assured that they will run (even if it does mean a recompile).
3) 99% of my hardware "just works" and the 1% I really don't care about. I've always bought hardware that was "real" hardware, not some fake winmodem rubbish, and therefore have not had any problems with the stuff that I've bought. So far, 1 non-supported parallel/USB scanner out of the four I have and 1 cheapy soundcard out of 6 that didn't give the performance I would like. I see it as the hardware manufacturer's fault if something does not work... they designed it, they should have stuck to standards, made the design simple enough to implement or, at worst, got off their backsides and maintained a driver for it. Why should ANYONE have to reverse-engineer their network/sound/video card to make it work?
4) When Windows decides to throw a wobbler, go into a reboot loop, give stop errors on boot, there's not much I can do to bring it back but restore from a ghost image (if I have one and if it's fairly recent). When (if) linux goes, I get USEFUL error messages, I can narrow it down to kernel or userspace. Kernel can be upgraded/downgraded, userspace can be changed. Userspace can be backed up to a tar file, not some fancy format, there's no registry to worry about and at worst reinstalling the problem app (be it bash or KDE) will fix the problem.
5) All my apps are self-contained in packages (be they slackware tgz's, RPM's, deb's). That means that so long as I back them,
6) I have all of my data in a format that can be read off my disks using a single floppy, I can read it in some of the most ancient of kernels, I can read it from a small Windows driver. I can even have a stab at trying to fix the filesystem manually because it's in a semi-sensible format.
7) I know that my computer is not spying on me, not "checking" that I have the right numbers typed in, not constantly accusing me of possibly being a pirate because I want to reinstall an OS.
8) Upgrades are a dream. I can, for example, go from a 2.4 kernel KDE 3.2 system to a 2.6 kernel KDE 3.4 without losing any functionality. (the equivalent of a 2K-XP upgrade or similar) Functionality losses (if any) are CLEARLY advertised in changelogs, readme's etc. and I can choose to just stay where I am if I want.
9) The damn computer finally does what I tell it to. Technically speaking it has always done what it was told to, but that was by a combination of me, MS and applications. It would do what you told it to even though that might be crash or break or format my disk, but now it FEELS like I have control. Sometimes I screw up and things get complicated but in the end I can see WHY things happened (I removed the library, upgraded the wrong file, d
With the current movement towards digital restriction management and things like the a'hole bill proposal, I'd say yes. No control means no working hardware in the long run.
Mind Booster Noori
No, they don't, unless you are putting Windows XP and Windows 95 in the same category. Just about any Windows 2000 driver will work on any version through service pack 4, but with Linux I need to recompile my drivers whenever a minor version number changes. Joy.
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
Why do we still have to have a user program (X) with device drivers in it? (Would anybody think it's a good idea if the Linux kernel didn't have any sound drivers, and required gstreamer to implement its own?)
That's not exactly a legit comparison. gstreamer is an application; X may run in userspace, but it's part of the system in the same way udev is; it's not in the kernel because it doesn't have to be.
It seems we have two competing driver models in Linux: some are in the kernel, and provide a consistent interface (sound cards, SCSI/IDE/... cards, network cards), and some aren't in the kernel at all, but expose them at a low level and rely on userspace programs to provide actual drivers (X11 for video cards, CUPS for printers).
Not exactly. For instance, CUPS may have printer drivers, but it relies on the USB, parport or network communications exported by the printer. There's no compelling reason for it to be in the kernel, since those drivers don't talk directly to the hardware in the same sense that the port drivers do.
Or consider gphoto. The port drivers are part of the kernel, but the camera drivers are in userspace--because there's no compelling reason to put them in the kernel, since there's nothing in there they need.
So that's my understanding of why X or CUPS or gphoto have their drivers in userspace, while sound drivers and port drivers are in the kernel.
Laws do not persuade just because they threaten. --Seneca
The issue, more than a stable ABI/API, is stable semantics, no? If the ABI/API is changed, but *semantics are preserved* then venders can simply add an adapter/translation abstraction layer. In fact, they could all get together and agree on one, completely separately from the Linux core developers (and in fact they probably SHOULD do this anyway). It would be nice to have more drivers, but it's also nice for the kernel to advance. So it's just a matter of who has to do more work: the kernel develepors to adapt the kernel to a fixed ABI/API, or the driver developers to adapt their drivest to a non-fixed ABI/API.
It's 10 PM. Do you know if you're un-American?
You're obviously not much of a Windows user. Driver quality has improved markedly since WHQL came online, and there haven't been any rootkits in the drivers.
Oh, they're quite invested in making sure that drivers are decent. It's no fun for anyone concerned for Microsoft to provide a driver via windows update and for that driver to make a system unbootable or otherwise hosed.
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
On the contrary, I believe there would be incentive. A hardware vendor wants to sell hardware, but not support hardware as support costs money. It wouldn't be long before hardware vendors realized that they could save some significant green by allowing th community to take care of itself, or perhaps provide some basic skeletal framework for a driver and allowing the community to roll their own.
Actually, I think ATI does that now. They don't write drivers for most of their newer cards; they let the board manufacturers who use the ATI graphics cores do it. ATI also has some open source drivers, I think, but that's unrelated.
Laws do not persuade just because they threaten. --Seneca
Where is the post from RMS you mentioned? What's your source for the IBM usage? No citation was given. I'm familiar with IBM mainframe OS software being shared and modified, but this was the norm then and therefore there was no social movement to defend this way of doing things on the computer.
There is nothing "neutral" about the distinction you describe. Any software that cannot be redistributed leaves users helpless to build a community by sharing copies of programs even if they are allowed to improve the software. This is oppressive.
RMS did not choose for the open source movement to begin at all. He had already started his movement, a social movement he called the free software movement. In reading the OSI's website, it seems that it was part of their purpose to remove any discussion of ethics from their framing of issues before business because they believed that ethical discussion made people uncomfortable.
It seems remarkably one-sided that so many in the business press are reluctant to mention free software at all (despite the term being used for the better part of 20 years and an important body of work being done in that movement's name), and didn't mention open source until the OSI popularized the term (despite the OSI not being around as long). This clearly conveys the impression that they stand with the open source movement, not the free software movement. Which would be fine if they were describing software written in the name of that movement; people and organizations should be able to choose their affiliation. But to describe software written explicitly for software freedom and credit it to the movement that never talks about software freedom strikes me as disrespectful at the least.
Digital Citizen
I hereby pledge that my hobby operating system will support Project UDI Core Spec version 1.01 from the very beginning.
Those people need to get over themselves, and understand that there will never be a single tool appropriate for all levels of skill unless we dumb everyone down to the level of the most mentally handicapped individual (and if we do that, the tool will be a rubber nipple, or possibly a spork, not an OS).
I think it's just fine that people like Miguel de Icaza are building a user-friendly interface to linux. But it's not really important to me like Ted T'so's work on capabilities is.
Though you haven't supplied any details, I suspect you're focusing too tightly - it's more than just a lack of a binary interface driver that has put you in such a frustrating situation.
It's not just binary drivers.
I use some open source drivers that are not in my kernel yet (the CentOS kernels), and won't be in this release. However, each time I get a kernel update, I have to rebuild the open source FUSE drivers and reinstall them. It's a pain in the ass.
If there is one thing I would fix about Linux is the development model. A 'stable' kernel series (say, 2.6) would have a stable API for kernel modules. So if you build a module for 2.6.0, it still works with 2.6.9. 2.6 would be bug fixes only - no new features in the kernel. You wouldn't need to put new features in a stable kernel series if it was done this way, because distros and end users can build modules and have a reasonable chance of them working for the entire kernel series without needing a rebuild.
Alternately, a method to automatically rebuild all 3rd party or add-on kernel modules as part of an upgrade could be made by a distribution maker, so you install the module as source, and distribution tools build them, then rebuild them for each kernel.
Manufacturers can _already_ use binary drivers, (nVidia already does) by providing their own abstraction layer, so this argument is a complete red herring. A stable kernel ABI helps _end users_ the most.
Oolite: Elite-like game. For Mac, Linux and Windows
It wasn't a post from RMS it was a post from you. I was asserting that you were conflating the words "open source" and the OSI (which continued to do in the parent to this post). As for RMS http://www.gnu.org/philosophy/free-software-for-fr eedom.html. Note in particular:
1) He talks about the "open source movement" not about open source
As for IBM if you agree that IBM had open source software that what are you disagreeing with? That they used the term? Go to www.share.org the IBM users group (1955).
As for software written in the name of the movement this goes back to the old GNU/Linux debate. TeX, X, most shells, most window managers, etc... were not explicitly written as part of the GNU movement; and may have had goals hostile to GNU. KDE for example uses the LGPL/GPL but has had a long history of hostile relations with RMS. Linus uses the GPL but considers himself part of the open source movement (he works for OSDL and is on the board of OSI). Apache explicitly rejected the GNU goals. That's why the mainstream business press rejects RMS's description of this as "free software", rather what is in common is a belief in code sharing and community.
This is the beauty of Linux. Anyone can do anything they want with it, except distribute your changes without source or forcing your changes on everyone.
Just do it. If you do it well & it solves real problems, others will adopt it & even help you make it better. Some of us, however, will be happy to not use it, & that's just fine.
I hereby pledge that my hobby operating system will support Project UDI Core Spec version 1.01 from the very beginning.
Hopefully that wasn't sarcastic. I know, for my part, if I ever get around to writing a hobby operating system of my own (as I've long wanted to), I'd like to have UDI as the native driver interface. Of course, I never find any time to work on such things, but in principle that would be my goal.
I would hope every fringe OS developer would see the benefits of UDI and adopt it fully -- but the pool of resources represented by such projects is small compared to Linux or the major BSD systems. Maybe enough of the one-man OS projects could break the chicken-and-egg stalemate and make UDI more enticing for the larger players, but it would be so much better if a major OS would adopt UDI and start porting drivers...
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
The kernel developers could simply ban closed source drivers by stating that in their licence, or rather declaring that the requirements of the GPL are also meant to apply to drivers. Likewise all closed source user space applications could be banned.
An unstable ABI does discourage the development of drivers in general, not just of closed source drivers.
``The vendor then takes that driver (now with the WHQL stamp of approval) and puts it inside an installer that enables the secret "Enable Dubious Optimizations" switch. Now the driver sees the switch enabled and performs all sorts of dubious optimizations, none of which were tested by WHQL.''
Isn't the idea that Microsoft cryptographically signs the drivers they approve? Then how come vendors can ship a different package without losing the signature? Is the signature flawed? Does it apply only to part of the package? In both cases, this whole thing is incredibly stupid and harmful; you think you get a tested and certified driver, but, actually, you don't. It's like the SSL implementation in your web browser telling you you're really communicating with your bank's site, but actually you're communicating with a different site - worse than giving no indication at all.
Please correct me if I got my facts wrong.
As far as I am concerned, a stable API is simply good software engineer practise. It would make it easier for other groups to maintian and build drivers, regardless of their development model. The API is not stable for *political* reasons, not technical ones. The kernel team does not want binary drivers, despite the fact that the availability of such drivers does *nothing* to "take control away from the developers".
The GPL is not about keeping source open. It is about forcing OTHERS to keep their addtions open. The same is true of the kernel binary API. They want to discourage others from making closed source software. So it is very much about pushing idiologies on others.
Additionally, you "Free" people really need to get a reality check. The purpose of computers is to provide functionality for *users*. Developers are really a small fraction of computer users. I'm not saying open source is bad. I've created open source software myself, and contributed patches to open source projects. But the open source has become so mired in the false sense of holy rightousness that is "Free" software that they seem to have forgotten that purpose of software in the first place!
Finally, DRM has nothing to do with open source. You can easily have DRM-free closed source software. Besides, DRM is not the issue really. It is just reflecting current copyright and IP law, which of course is the source of the problem. DRM is just enforcing current laws.
But if you want to be more concerned with some silly idiology than with real issues, that's fine. Open source will continue to lose out to closed source.
So on the one hand, we have you claiming that there's a secret unwritten guarantee that Windows won't crash if you use all-certified drivers.
And on the other hand, we have the Windows XP EULA, which explicitly says in writing that:
So, shall I believe you that Microsoft guarantees certified drivers won't crash? Or shall I believe the written license that tells me installed drivers, certified or not, are never covered by any kind of warranty?
Gosh, that's a tough one.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
See the long version of this post for expanded discussion of these points...
[By the way -- AKAImBatman, please send me some email, I'd like to chat with you further about Project UDI...]
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
I visited www.share.org and I couldn't find any document from the 1950's indicating the use of the term "open source". Is there a specific document you can point me to? I'm willing to try to be more careful in my use of the term if I can see evidence of the unbroken line of usage you're talking about.
Regarding Shankland and CNet News' unwillingness to call GCC a free software compiler instead of an open source compiler: I'm not talking about TeX, X, most shells, or window managers. I wrote about a specific program—GCC—and how RMS kindly explained why he would like the program to be called free software. What should matter here is not reflecting the desire of the reporter or their news organization, but respecting the wishes of the programmer. People extend this courtesy to Linus Torvalds when describing the Linux kernel, I think fairness demands the same for RMS.
Finally, if "what is in common is a belief in code sharing and community", then there are some strange bedfellows in this group. Linus Torvalds recently stopped using Bitkeeper, the proprietary revision tracking software. For quite some time he was happy to endorse the proprietary program for other Linux kernel hackers in word and deed. At about the time Torvalds' Bitkeeper license was pulled, it became known that Andrew Tridgell was working on what was described as a free software program to get data from Bitkeeper repositories. Tridgell reverse engineered the proprietary Bitkeeper protocol as part of the work to write this program, and Torvalds reportedly disagreed with this and defended a software proprietor. Communities are denied the ability to do code sharing when proprietary software is involved. Torvalds strikes me as a pragmatist—he'll use whatever software is convenient to get the job done, apparently he's not someone who shares the aforementioned belief in code sharing or community if it is inconvenient or a challenge to a proprietor.
Digital Citizen
Really? Could have fooled me... Windows can still run DOS and Windows applications from 20 years ago, linux can still run application from 10 years ago. When an API is created, usually there are hooks for extending it in the future. I wouldn't say either one has stagnated, over the course of the last 10 years. If that were the case windows wouldn't run on my quad 64-bit athlon.
Really? Because I've had a heck of a time getting XP to run most of my old DOS games, and quite a few of my 9x ones. Not to mention the scanner that won't work because there isn't a driver for XP to run the SCSI card it uses (not supported by the vender, binary-only... buy a new scanner), and just for shits and giggles why not try using a gameport MICROSOFT sidewinder joystick in XP (hint: it doesn't work, it's not supported!).
The point being given is that when binary drivers die, nobody can continue them. When a company doesn't see profit in a product, they discontinue binary drivers. I've plenty of old hardware that does not work in windows to prove it, but quite often it still works in 'nix with the Reverse-engineered Open-Source drivers. Go figure...
My comment was in no way sarcastic. My OS WILL have UDI built-in as its native driver interface right from the start.
Lots of good points
My comment was in no way sarcastic. My OS WILL have UDI built-in as its native driver interface right from the start.
Good to hear. We need more UDI-native operating systems...
Hey, send me some email so we can still discuss this when this thread is dead and gone!
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
I'm a professional Linux driver developer in training, and I'm a little confused by your post. Why are you having to fix your driver for every single version change?
If you're distributing the driver as a separate tarball, it's simple: you only distribute it for specific kernel versions. Anything else is unsupported. Just pick the kernel versions you want to support (maybe coinciding with certain distributions), and that's it. Add newer versions as you have time or it becomes apparent that customers are tired of being stuck with a very old kernel version.
In my job, the driver we provide has two versions, one for kernel 2.4.20 and one for kernel 2.6.13 (maybe 14; it's not released yet). If someone doesn't like that they have to use 2.4.20, too bad. They can get the source and modify it themselves, or they can just use the older version until we're ready to port it to a newer kernel.
What's so hard about that?
Don't let your customers push you around. State clearly what you provide and what you support, and forget the rest.
Can you name some things that make Linux special? Like the ability for the end user to become educated and modify the system, or the right to fork? And then, can you explain how widespread adoption of Linux will change these things?
Laws do not persuade just because they threaten. --Seneca
*Any* linking is enough to require GPL. The only reason binary modules are possible at all is because Linux is not licensed under simply the GPL, but includes an exception making it licensed under a modified version of the GPL.
Luke-Jr