Slashdot Mirror
Update On Free Linux Driver Development
Remember the offer Greg Kroah-Hartman made earlier this year, to get Linux drivers written for free for any company that wanted them? Now an anonymous reader points us to an article up on linuxworld with an update to this program. Greg K-H, who leads the development of several kernel subsystems including USB and PCI, admits that the January offer was a bit of "marketing hype" — but says it has brought companies and developers together anyway. Twelve companies have said "yes please," one driver is already in the kernel, and five more are in the pipeline.
if he did, good for him, if he didn't he just like every other lieing software house out there.
If you mod me down, I will become more powerful than you can imagine....
A list of the twelve companies, please?
"I think an etch-a-sketch with an ethernet port would beat IE7 in web standards compliance."
Marketing hype or not, I'm always happy to see more hardware supported by free drivers. Thanks, Greg.
To me, the issue isn't so much drivers as patents and usability.
My daughter's mp3 player didn't need any special drivers, because it's simply a standard keychain drive that happens to be able to play mp3's. However, she totally couldn't figure out how to use it on her ubuntu box. There was one problem after another. Ubuntu tried to do the right thing by popping up a gui app when she connected it, but then we couldn't get the gui app to do what we wanted to do. Part of the problem was that getting the mp3 codec to work was a pain, and that springs directly from the fact that mp3 is patented.
My Brother HL-1440 laser printer is 100% supported in Linux. Brother hired the CUPS developers to write GPL-licensed drivers for all their printers. Joy! Unfortunately, I've run into one usability problem after another, all of which are basically problems with the usability of CUPS. I know I'm not the only person in the world who thinks CUPS is a pain, because I've seen other people criticize it for problems that are the same ones I'm experiencing. For instance, CUPS remembers too much of its state, and when it freaks out (e.g., printer spewing page after page of garbage), it's difficult to get CUPS back into a known-good state.
Find free books.
This post brought to you by these two patches, against 2.6.22-rc2:s s.general/2368 s s.general/2369
http://thread.gmane.org/gmane.linux.kernel.wirele
http://thread.gmane.org/gmane.linux.kernel.wirele
The little WG11v2 is a happy interface. Figure I'll need to stockpile a couple them critters.
Now, how is it that I'm off the hook for managing any of that bad, bad firmware with this wee beastie?
Ivo or Michael, though I'm nowhere near as cool as you dudes, I'll buy you a beverage if I see you in Ottawa next month.
Dunno if GKH's driver program actually helped in this matter, but the general trend in hardware is positive, and I feel Realtek and Netgear deserve a free shill.
Best,
Chris
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
How about a driver for this ATI All-In-Wonder 3D Rage II +DVD PCI card I can't find drivers for?
--
make install -not war
this is productive
"With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea...."
RFC 1925
From TFA:
What? If the driver code is GPL, why can't I copy it?
I suspect he means "copy" as in "make a derived work" that would have chunks of code taken from the original. But still, this is what GPL is about ... being able to take an existing source and make a derived work from it (that presumably would be better), and redistribute that derived work also under GPL (so someone else can derive from that later on ... and on ... and on).
now we need to go OSS in diesel cars
1. They're loadable modules.
2. You should maybe leave the kernel development to the kernel developers.
How we know is more important than what we know.
Modules. Pretty much all drivers are modules and not compiled directly into the kernel. They don't increase the kernel size unless you load them. Although they do increase the kernel source size (in their own files generally) so it is taking a little longer to compile all kernel modules, but that's a price I'm willing to pay for things just working.
Tharkban (It is a signature after all)
You're only half wrong.
Maybe you should try to understand that some people ask questions in an attempt to learn, and not to troll.
Uhhh.. no he wasn't. He wasn't lying at all.
Why would you feel the need to post a "translation" when you have no idea what you are talking about?
The fact that people are willing to write Open Source software without charging a fee for their services is hardly a new concept, but Greg did the smart thing of treating it like it is and, in doing so, attracted the attention of people who thought that it wasn't the case.
This was one of the biggest problems with the Free Software movement before Open Source came along.. no-one talked about the benefits that businesses could get from the community. For a while, no-one talked about anything else, and then it went quiet again. RMS will tell you that we need to talk about freedom. I happen to agree, but we also need to talk about the practical advantages of open software development too.
How we know is more important than what we know.
oh shut up
Maybe you should try some humility instead of phrasing your question like you're a know-it-all.
How we know is more important than what we know.
Yes and no. For one, they can be dynamically loaded as kernel modules. Or you can custom compile your kernel without any dynamic loading, to have just the drivers you need. As long as driver foo isn't touching many systems, it doesn't drive up complexity to have driver bar that touches the same number of systems.
--
WHO ATE MY BREAKFAST PANTS?
The question mark at the end of the sentence indicates humility. I admit that I do not know, therefore I ask. Thus is the reason for the question mark.
How exactly was he lying? They said that they would code drivers for free for companies that released their specs, and they did. The "marketing hype" was that they were making a big deal and advertising for something that they already did, and would have done anyway
Then you need to learn how to ask questions better.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
I believe it's because you mentioned that they are "Two things that a reliable kernel should avoid?" That makes you sound like you know better, so that's the troll-like bit. Also, everyone on /. is assumed to know everything about everything when posting unless said otherwise...
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
BTW, you may wish to go easy on john. On the Saturn, they lost a few of the engines on the way up. Fortunately, they did not blow, but plain and simple, they did fail. As you pointed, Spacex and Armadillo is looking to place a large number of identical engines along the line of parallel server. But they are not the first. In addition to USA, the Russian have been and still do. As long as the engine is well developed, this makes sense. In fact, I think that both Amadillo And spacex are doing it right.
I prefer the "u" in honour as it seems to be missing these days.
I think that ever increasing size and complexity are things that a reliable kernel should avoid. What is wrong with that?
Yeah. The GATOS project would have worked with this, however it seems to be discontinued for modern kernels. Even if it weren't, the documentation seems pretty horrid, so I couldn't tell either way.
If you had said "I think" or "I thought", you wouldn't have sounded like a "knows-better-than-you" kind of person. Linguistics and all that.
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
I wonder if support could get out to little groups who are trying hard. I personally have a webcam with no driver and the group trying to develop one just doesn't seem to be there enough. If someone is offering this support then it would be nice if he found a group like this and helped out. It would be nice to have a website that brings together all drivers that are being worked on and make them easy to find for someone who really wants to help. Here is the driver I was talking about by the way: http://www.actiongames.co.uk/m560x/
Utinam me logica falsa tuam philosophiam totam suffodiant.
Seriously, I don't know crap about kernel development, but:
1) I knew the answer to your question since the first time I even tried to compile a kernel. By "compile a kernel", I mean run make menuconfig, flip through idiot proof menus and say yes when it tells me to.
2) You proposed a bunch of dumb ideas implying that the people who actually do know how to develop one are idiots.
3) asking questions in a dick way and then appending a question mark in no way indicates humility, or even politeness.
Seriously, asking dumb questions is fine, but *you* need to actively treat them as dumb questions if you want them to be treated as legitimate questions in a problem space in which you're ignorant. Don't treat the people you want answers from as dumb preemptively.
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
If you compile your own kernel you can choose to either leave out the functionality entirely, build it as a runtime-loadable module, or build it into the kernel.
So the only permanent size increase is in the kernel source code. Assuming that the driver is part of a class of similar devices, there is basically no complexity increase as the driver will bind into the standard API for that class of devices.
So generally there is very little downside to adding new drivers to the tree.
With MS Windows drivers still run in kernel space but are often produced outside of the control of Microsoft.
People are only getting defensive because you're asking them difficult questions.
p i_nonsense.txt
Inside the kernel, the software interfaces are subject to change without notice.
http://lxr.linux.no/source/Documentation/stable_a
So the only approved way to get support for a driver is to GPL the code and get it included there. Then, if one of the kernel maintainers feels like doing some refactoring it's their responsibility to make sure your code builds after the change is made.
Now the next question is who's responsible for running the unit test to make sure the code is really OK after the kernel was refactored. Is it the guy that wrote the code originally, has hardware samples and knows how to run the test, or the kernel maintainer who knows about the change but doesn't have hardware or the time/knowledge to test it?
And the answer is I don't know.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
FYI, Linux is still a monolithic kernel. It has loadable module support but that just means it gets loaded into the monolith.
XePhi Computers sell really cheap Linux CDs! http://www.xephi.co.uk
'Once scientists, even the dim-witted social scientists, get muzzled, the Western Civilization is finished.' - oldhack
Why do people continually make the same argument for a binary interface?
It's been addressed again and again and again.
Here's the definitive response.
Give it up.
How we know is more important than what we know.
What is wrong with that?
The believe that more driver modules make the kernel more complicated.
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
No - in terms of compiling the kernel it means what I wrote above or more precisely what you will find in the README file. I suspect you are getting mixed up with terms used in the microkernel debate but I am not talking about that.
Comment removed based on user account deletion
NVIDIA bought ULi and then cancelled development of the M920x, but you can (still) buy DVB receivers which use this chipset.
Requests for assistance or interface specifications have been refused by NVIDIA.
1) where? you say you've had problems with CUPS and others have complained, but there's nothing about an actualy complaint, just complaining in your OP
2) Ubuntu's problem, not CUPS most likely
3) Admin functions are disabled because you're supposed to log in as administrator. IIRC you can have that as your normal login account, but it's just "log in" to the CUPS webpage (there's a "login" option, which should have sparked the idea off...) as administrator and you have your administration functions available. Unlike windows, this is a multi-user system which uses limited accounts to do some stuff so that a break in one service doesn't break any others: apache having a bug that gives local access does so as user "http", so the damage that can be done is limited to the damage that account can do.
4) This happens with Windows too, if you don't use the Brother install CD to set up your printer. You click on "Brother" in the printer drivers and see a huge list of Brother printers, none of which say 1440 Laser. So you try another brother laser. low res. Another crashes and eventually you find that "Apple: postscript" works because your printer has postscript (I don't know if your system has, but this happened to me with a laser printer). Why Apple? Because that's what Windows works best with. Don't ask me why. So this isn't a problem with CUPS either. If brother had a "CUPS installer" this would work fine. Just as it does with Windows.
5) This does sound like a bug. Talk to the CUPS people and they'll tell you how to log where it's falling over. They'll be able to work out from that what the problem could be, offer ways to test and/or work around the problem and eventually a fix will be available and you'll be asked to test the fix for them. This is what happened to me when I found a bug in the konqueror renderer (div tags weren't being closed).
Someone has to gather together all the drivers that are considered of sufficiant quality and keep them up to date with new kernel versions. Given the instability of linux's module API (not a descision i particularlly agree with but i can see why they made it), the people who develop the kernel are as good a choice as any.
typically drivers are compiled as modules nowadays so they aren't loaded into the running kernel unless the hardware detection system says they should be.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
So if I want XZY driver then I have to install the latest 'beta' kernel because the drivers aren't separate from the kernel.
maybe if the drivers were separate I could just get the driver I wanted without all the 'bonus' features in the new kernel.
The problem is that the kernel api changes so much that the only way to track the changes in the drivers is to make the drivers part of the kernel, I'm sure as hell there are a lot of people out their who wish that the kernel api was a bit more stable.
thank God the internet isn't a human right.
As an useful example on how communication and interpersonal skills (like properly phrasing a question so not to trigger the troll flag), Theo (of *BSD fame) may not really be the [insert opinion here] he appears to be. I think his lack of empathy and, therefore, his inability to properly communicate and to relate to other people is to account for his reputation.
If that does not ring a bell, perhaps I may suggest you to seek a good shrink in your area to help you understand and deal with this "non-problem".
BTW, if you read this, Theo, it is valid suggestion. I strongly advise you to take it.
The question mark indicated a question. The rest of the question implied a "I know better" attitude that is utterly unwelcome just about everywhere.
It would take you about 10 seconds of googling to find out most drivers on Linux are loadable drivers and are not compiled into the kernel, but belong to what we call the kernel because they are maintained together and released as a single set of files.
http://www.dieblinkenlights.com
Nemosoft wrote a GPL driver which called out to a binary decompressor module. All was OK for a couple of years. Then Greg decided to rip out the callback. So suddenly the camera would only work in 160*120. Nemosoft then asked for the crippled driver to be removed. Greg did. Then Saillard forked the driver and decompiled the decompressor and put it back in the kernel. Nemosoft then complained that the decompiled code was illegal and got it removed from the kernel again.
Each step sounds like a perfect example of what the original poster was complaining about - people keep making changes that cause things to stop working.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Link?
An open prism54 driver which works with WPA would be nice. NDISWrapper, though functional, is such a hack that I feel vaguely dirty using it.
Welcome to the Panopticon. Used to be a prison, now it's your home.
That's why I ended the statement with a question mark. I was not stating it as a fact, but I was asking it as a question.
One person correctly read my syntax, and provided a helpful answer (for which I thanked him/her). If I were a "knows-better-than-you" kind of person, as you assert, I doubt if I would have been so thankful towards the person who helped me.
'open source' was an attempt to confiscate the Free Software movement, and build a 'business model' on other people's work.
If the political & religious (sic) implications of "Free as in Freedom" make you nervous, just stay away from the whole thing.
Don't forget that FSF started by actually paying people salaries for writing free software; people have to eat in order to write software, free or proprietary.
Those 'open source' lies about people writing working software in their free time remind me of sport in socialism, where professional athletes were supposed to work hard in factories, and train only during the weekend.
Nobody is writing a functional driver at home at night after 10 or 12 hours of hard, stressing day work.
If you have to lie for corporate ideological reasons, at least don't pretend that people are actually believing you :)
Car analogy:
The last time I used a car, I had to hand crank it myself to start it. It was completely unacceptable!
a few replies later...
From the replies, I'm glad to hear this problem fixed, but approx. 70 years ago, it was a well-known limitation of cars.
Seriously, you make broad criticisms and then admit you really don't know the current state of things? How fair is that?
Next time, be honest about the last time you used the system, state your concerns about how the system behaved then, and then ask if your experience is still relevant.
*sigh* back to work...
Are you aware of the reasons for the lack of a stable binary API? If not, I suggest you read the following:
s /linux-2.6.git;a=blob;f=Documentation/stable_api_n onsense.txt;h=a2afca3b2bab6fb923fb9eda102073606d15 c278;hb=HEAD
http://git.kernel.org/?p=linux/kernel/git/torvald
The best way to get something supported by linux is to get it into the mainline tree as early as possible. Linux has support for hardware with a single unit in existance, so its not as if its really hard to get drivers accepted into the tree.
As for not wanting to release hardware specs....do you really think that their competitors don't already have the specs on the hardware? I had a roommate who worked for a company that did nothing but reverse-engineer chips and write specs on how they worked.
You forgot the first step:
'Nemosoft decides to use some weird patented compression for its cameras.'
Every problem followed from that decision.
If corporations are people, aren't stockholders guilty of slavery?
If Linux ran on one type of processor architecture, a stable binary API might be possible. That's the reason Windows has been able to provide one for so long; there were/are discontinuities at major bit-width shifts (right now some people are struggling to get 32-bit drivers working on their new 64-bit Windows), but since the underlying hardware is basically always x86 things chug on with a simple driver model.
The fact that this is completely untrue for Linux makes a binary API impossible. Please read The Linux Kernel Driver Interface for more information; the "Binary Kernel Interface" section explains exactly why what you think should happen can't.
This isn't a political argument, it's a technical one. The only way to get a "stable binary API" into Linux would be to put a virtual machine-like interface on top of the kernel that drivers could talk to while being completely insulated from platform issues. While possible, the performance would be bad, and building/supporting that mess would turn into a political problem with the kernel developers.
But that link is completely disengenuous. Lots of other OSs have stable API (source level) between drivers and the kernel. Unix type OSs have a relatively simple driver API, so it's not very hard to keep it stable. And in fact every processor has an ABI document describing how the parameters in his "Binary Kernel Interface" section should be set, so it's not hard too get a stable binary interface too.
Even in the Windows world which has a much more complex driver API, it's not too hard to write a driver to support a couple of OS revisions (E.g. Win2k, XP and Vista) and distribute it as a binary, I know because I've done it. Other driver classes are even better - SCSI miniports can run from Win98 and Me,to NT,2k,XP and Vista. They can also run in NTLDR's weird pre OS environment and on Risc NT workstations or 64 bit Vista boxes. You need to build a binary per architecture, but that's probably for the best.
Sure it's extra work for the kernel maintainer to keep interfaces stable, but Microsoft do it because they want OEMs to write Windows drivers for their hardware.
Greg doesn't want to do this because he wants to make things so hard for NVidia and all the other binary blob companies that they decide to GPL and release the source code to their drivers. And he wants to be able to refactor things without having to discuss it with anyone else. That document doesn't mention all that though, he just tries to raise a bunch of technically hard sounding problems, announce they are unsolvable and leave it at that.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Philips decided to use the compression because they make the camera. Nemosoft wrote the driver. From what I can tell, you need compression to get a decent frame rate/resolution on USB 1.0. Philips worked out a way to compress efficiently in hardware. Since this the only part of the webcam which is non obvious, Philips wanted to make money out of it by licensing, or maybe they licensed it from someone else. For whatever reason, they didn't want to release source code to the decompressor. They did let Nemosoft get the details under NDA and write a binary only plugin for the driver.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
I understand that companies might be hush-hush about works in progress, but how did this article get published without even naming the one completed driver that this program has yielded? I know Greg K-H didn't say what it was, but someone could have at least asked him.
It would be extra nice if the Plustek OpticBook 3600 was on that list, but somehow I doubt it.
Laws do not persuade just because they threaten. --Seneca
Eventually you give up, tear out CUPS entirely, and install the Berkeley LPD, which works perfectly 100% of the time despite being a horrific mess of incomprehensible spaghetti code.
If you haven't had this experience, you lucked out, friend. But many of us weren't so lucky. I suspect CUPS is way too complicated, and has emergent behaviour that the developers can't get a grip on.
In case the driver does something which is out of spec, the emulation code would have two options, either behave as the real hardware would, or cause the unit test to fail. Actually I have sometimes been thinking how much easier a lot of things would be if every hardware vendor would provide such emulation code. I'd be perfectly happy with getting the emulation code as binary blobs, as long as I can just run them isolated in a user mode process for the purpose of testing interaction. Whether the CPU emulation in such a case would be similar to xen, qemu, vmware, or a complete emulation provided by a CPU vendor might depend on exactly what you wanted to test. Before anybody say vendors would not do this, because then people would use the emulation rather than buying the hardware, I'd like to point out, that obviously the performance of the emulation would suck compared to the real hardware.
As for the licensing question, I don't see any problems in having the hardware emulation code beeing a propertary license as long as we are allowed to copy it and use it for testing of interaction between hardware and drivers. This code is not being linked against the kernel, thus it does not have to be GPL. If a vendor is able to do some good planning, they could even release this code before the hardware enters the market. AMD was able to do this with the 64 bit architecture, and for that reason Linux supported the architecture even before the hardware was finished. (Too bad it took Intel and Microsoft years to catch up, and when they finally did made it sound like Intel invented the whole thing).
Do you care about the security of your wireless mouse?
Yep, and it's the best reason why RMS has totally failed to present an argument for Free Software that business finds acceptable. It took a new push to fix it. Go read some Bruce Parens sometime. There's a reason why "Open Source Software" is defined using the 4 freedoms of Free Software..
How we know is more important than what we know.
If you can't read that document and get the fundamental message that: if we freeze interfaces we will have to support backwards compatability on those interfaces forever and the benefits of doing that just don't outweigh the advantages; then you're not trying.
Apple can do what they do because of two things: they control the hardware, and they don't support backwards compatibility for drivers. Linux, which not only doesn't support the hardware, but actively encourages the use of plenty of different architectures, can only do what it does because the development team is so much bigger than Apple's.
As for Windows? How is this even remotely relevant? They're a billion dollar company and they spend all their time and money maintaining backwards compatibility and developing bolt ons to their OS. If anything, Windows is a perfect example of what happens when you present a stable API to driver makers.. you end up with 20 different stable apis, all which you must maintain.
You'd know all this if you'd ever tried to write a driver for Windows.
How we know is more important than what we know.
Hopefully Greg KH and Linus will realise this one day but until then we are stuck with waiting 3 years after a piece of hardware was released for someone in the community to reverse engineer the windows driver and create their (our) own.
It would definitely be "their" and not "our", because "our" would imply that you had some kind of ownership over the driver. Since your post demonstrates a total failure to understand the current Linux development model and advocates a new model which would basically ruin it, I don't think that you can really consider yourself a part of the community.
I know you'll argue that you have just as much right as anyone else to try and steer Linux kernel development in the right direction through argument, but actually you don't because you're not a kernel developer. Contributing a lot of time wasting whining is not the same as making a useful contribution.
This is the main thing holding back linux from supporting a great deal of the hardware that is currently supported by Windows, OSX or BSD.
Linux supports a much greater range of hardware than OSX and I'm pretty sure that BSD doesn't have a stable binary API. A Windows driver for 95/98 will not work on 2000/XP and a 2000/XP driver probably won't work on Vista. The 64bit versions of XP has been available for some time now, but isn't exactly blessed with an over-abundance of drivers. How can that be so when the stable API makes it so easy to develop drivers?
So basically all of your examples are flawed. You should have used Solaris as an example, since that has the most stable binary API. Of course, it also supports the smallest amount of hardware which is even worse for your argument but that's just nitpicking at this point.
The current approach might well produce a better quality driver (and kernel) but it is far to slow. Who wants to spend several hundred pounds on new hardware only to find it is obsolete before the linux kernel supports it.
If you're willing to trade quality and stability for the ability to use the latest whizz-bang hardware, then what's stopping you from using Windows? It's clearly not a financial consideration if you're willing to spend hundreds of pounds on hardware.
Since you fundamentally disagree with the philosophy and development path of Linux, I don't see why you would want to use it anyway. Also, any ideas you have to "improve" Linux must automatically be treated with suspicion.
Volunteer firemen heroic part time job, but the volunteer part is a misnomer (I think).
Unaccountable leaders are masters, and unrepresented people are slaves. How do US and EU fare?
The unit test really should include sufficient emulation of the hardware to test the driver. If the hardware vendor supplied such a unit test, you could run it after a refactoring without access to the hardware. If the driver which passed the unit tests turns out not to work, somebody with enough knowledge of the hardware should improve the unit tests.
You've never written any code which deals with hardware that actually works, have you? This is the kind of thing people say until they actually do it, and find that the hardware does things like randomly drop interrupts, or corrupt memory by bus mastering, or miss register accesses, and it only does it under obscure circumstances. And there can be bugs in the OS kernel or other drivers might corrupt memory. And the hard ones are ones that only happen 0.0001% of the time. The only way you can tell if a driver really works in a real system is to test it with the real hardware which has all the bugs, not some idealised model which only has the ones you can know about.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
You'd know all this if you'd ever tried to write a driver for Windows.
I've written several drivers for Windows. Incidentally, Windows isn't completely back compatible for drivers - they don't guarantee an XP driver will work on Vista for example. E.g. Win2k introduced WDM and plug and play to NT kernels which forced most drivers to be completely rewritten. The API for display drivers is very dependent on OS. Vista and later have a kernel mode framework which doesn't work on earlier OSs. NDIS has changed enormously, mostly for performance reasons.
Having said that it's not too hard to make a driver which works on two to three revisions of the OS, and usually with one binary. Probably you could do a driver which does Win2k, XP and Vista for example spending a couple of weeks coding and testing when the betas come out or bugs get reported, and that's 90% of the OS market. I.e. a few man months of effort over five years gives you a driver which supports the vast majority of computer users. Most companies only care about the last two revisions of the OS anyway.
But this is completely different from Linux where the interfaces inside the kernel change between minor kernel revisions without changing performance at all, and the kernel maintainers go out of their way to make it impossible to use binary drivers. So you spend endless effort supporting a platform with 0% of the market.
The cost/benefit ratio is enormously worse for Linux and even if you do it a people will just call you a leech because you didn't release the source code. Given that there's no commercial reason to do it, why bother?
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
What triggers a problem with flaky hardware doesn't have to be a driver change. If it happens rarely, there is no guarantee a developer would find it, even if he had the actual hardware. OTOH, if the circurmstances and the symptoms are known, they could be simulated in a unit test, and the probability could be increased to the point where you are bound to see them in a test run. Also such problems are likely to only show up with certain combinations of hardware. I have for example seen a system where Linux would lock up if sound card and harddisk were in use at the same time, but only if a network interface was present in the system. However it didn't make any difference whether the driver for the network interface was loaded or not. If an additional ATA card was added to the machine, the problem would also show up in Windows. Do you think Creative would have discovered this, had they written the driver themselves? I think not, because they probably never tested the card with this hardware combination. Would the problem have showed up if you tested it with an emulation of the same set of hardware components? Maybe not, but nevertheless it would have been a useful tool when debuging the problem. Simply seeing the difference between emulation and real hardware could provide a hint about the cause. And a problem can often be easier to figure out, if you have a working instance to look at.
Do you care about the security of your wireless mouse?
Nothing there to make your position interesting. Claiming an EE as an AC doesn't and shouldn't get you much in the way of credibility.
Thanks for the link, I hadnt read that before but has read similar postings from Greg.
Unfortunately it did not really answer my main point. I was in no way trying to suggest that the current situation was not the best one for producing the best quality, most stable and most reliable linux kernel.
What I was trying to suggest is that this is a very one sided attitude however that does not take into account the legal issues regarding selling hardware that supports linux and can be represented as such. In many ways the link you sen confirmed this very early on with the disclaimer where the author clearly states he is not a lawyer.
I did however take on Gregs point regarding kernel developers not being paid and it being hard to force them to donate their time for free to something with no gain. I was under the impression that by now, most of the kernel developers were being paid for their time like Greg and Linus. I am not either of thems line manager though so I have no idea what it says in their job description.
All I was trying to point out is that maybe a more balanced approach was required and that allowing companies to build proprietary closed source code on top of a Linux base was a very good thing if it made Linux invaluable to the commercial world. This would help ensure it continued survival.
Try looking at the Syllable project. (http://www.syllable.org/)
This project may or may not succeed but I do think they have some valid points about developer centric design sometime stiffling linux growth in the desktop market.
I dont read
You come off like a total asshole; that's why you're getting this response. If you don't like being treated as an asshole, maybe you should go back to school and take some English classes, for instance in composition. Even a high-schooler would know better how to write in order to not sound like a complete jerk, as you have.