Vanishing Features Of The 2.6 Kernel

chromatic writes "Jerry Cooperstein has written an excellent article summarizing the features removed from the upcoming 2.6 kernel. One controversial change may be tightening restrictions on binary-only modules." And Lovechild writes with some more 2.6 news: "I recently did an inteview with famous kernel hacker extraordinare and all round nice guy Robert M. Love for Tinyminds.org, about kernel 2.6 and what can be expected for desktop Linux users, when the new kernel series is released.

Comments

oh the irony

[rainman31415]

hopefully there wont be anything in the kernel related to the advertising. M$ .net sdeems to be paying for this article....


bite me
rainman

They aren't gone!

[jlharris_50010]

Nothing's vanished... just not included... now you too can learn to kernel hack!

Re:They aren't gone!

[mandolin]

There are some notable kernel developers who would claim that changing an occurance of EXPORT_SYMBOL_GPL() to plain EXPORT_SYMBOL() (well, actually the alternative -- lying about MODULE_LICENSE) would be a violation of the DMCA. Not that these people are lawyers or even necessarily have a clue, but they are clearly hostile to the idea.

On a different tack, one technical objection to removing EXPORT_SYMBOL(sys_call_table) is that in addition to not being able to replace default system calls (which was always a bad idea), one can no longer call system calls from kernel-land that aren't specifically exported. That means there is kernel functionality available to userland that isn't available to modules. That is IMHO limiting and generally a Bad Idea.

Re:They aren't gone!

[mandolin]

On x86, this works (at least for the calls I've tried). There are certain platforms (MIPS, and it's the only one I've dinked w/ besides x86) where no one ever bothered to get the do-interrupt-from-kernel functionality working :-(. Exporting the syscall table, exporting each asmlinkage function individually, or fixing that functionality are all possible solutions. The first one was the easiest (and should be faster than doing a software interrupt).

Binary modules

[IamTheRealMike]

Could somebody sum up the pros/cons of binary modules. I've been trying to understand this issue for some time, but it's nearly impossible to get technical reasons without ideological bias. So far I have:

Pros:

• Commercial interests are happy because they keep trade secrets they may need to stay in business
• Better drivers (usually)
• Patented tech can be used in Linux, like that nVidia texture compression thing (i don't think all patents are stupid).

Cons:

• Makes kernel harder to debug
• Sticky GPL enforcenment issues
• Some kernel developers don't like it
• Often come with stupid licensing, ie nVidia - you can't distribute our drivers, only download them (and then no psyche rpms).

Have the kernel devs decided whether they are good or not?

Re:Binary modules

[Otter]

Cons:

As a PowerPC Linux user, I'd add that they're rarely made available for non-x86 architectures.

Re:Binary modules

[crow]

You left off one major con:

Binary-only modules must be updated by the vendor when the kernel interface changes.

If we must have binary-only modules, I like how Cisco did it for their VPN software: you compile a small wrapper function with a provided library file to generate the module. That way you can generate one specific to your kernel version.

Re:Binary modules

[bbk]

I've always heard it stated as a debugging issue - if a bunch of people send in bug reports saying "Kernel 2.x.x is broken", and they're using a binary only module, how do the linux developers know the problem is with the kernel, and not with the binary module? To aid in debugging, they put limits on what binary only drivers can do, which narrows the range of problems.

I think it makes a good deal of sense, from a linux developer standpoint - they all have their own reasons to work on linux, and answering bogus bug reports caused by faulty binary modules cuts time from other development tasks.

BBK

Re:Binary modules

[Reality Master 101]

At the risk of this sounding like flamebait, it's about power and control.

There are people who think you should not be able to download a binary-only module and use it with a GPL program. Note that I say you, and not the creators of the programs themselves. The binary only creators are not using any GPL code. The GPL code is not using the binary. It's the combination of the two that many will tell you is a "sticky area".

It's exactly the same as if Microsoft changed the Windows license to say you could not run any GPL programs under the Windows operating system. Imagine the screaming that would take place if they tried that.

I think a lot of people need to get a grip and just mind their own business. If you don't want binary-only software on your computer, then don't do it. But don't presume to tell me what software I can or can't run on my computer.

Now, it's valid to worry about whether I'm redidistributing software according to the license. But if I follow each individual software's license, then leave me alone.

Re:Binary modules

[IamTheRealMike]

Why does the kernel module interface change so often though? I mean, surely there are only so many ways to write a mouse driver

Re:Binary modules

[kasperd]

Better drivers (usually)

I don't believe it. Assume a driver has been written and released in binary form. How could the driver become any worse by releasing the source? It couldn't, but more people might realize how badly it was written. And nVidia's is assumed responsible for a lot of the kernel crashes. If anybody reports and error on a system that has been using nVidia drivers, the kernel developers will tell the person to reproduce it without the nVidia driver or go bother nVidia.

Re:Binary modules

[kasperd]

You left off one major con:
Binary-only modules must be updated by the vendor when the kernel interface changes.

That is not just a major con, it is probably the most important of all cons.

you compile a small wrapper function with a provided library file to generate the module. That way you can generate one specific to your kernel version.

Hasn't something similar been done for gfx drivers as well?

Re:Binary modules

[kawika]

It's certainly possible to make good interfaces to facilitate debugging binary-only code. Most likely the kernel developers have decided that their time is better spent in other places, rather than making life easier for the binary-only module developers. =That decision is made easier by open source bias, of course, and the lack of a large user constituency that would be intolerant of breaking old apps.

If Linux ever becomes a mass-market operating system, the kernel developers are going to have to reprioritize things. Imagine telling a company with 10,000 Linux desktops that they would have to fix, recompile, retest, and redeploy a major in-house app because a deprecated kernel interface had been removed. Linux can make these kind of changes only because it's not yet mainstream.

Re:Binary modules

[kasperd]

Why does the kernel module interface change so often though? I mean, surely there are only so many ways to write a mouse driver

The mouse driver is one of the simplest drivers, and most of the stuff is done in usermode anyway. But a changing interface doesn't mean that each and every piece of the interface changes, it just means that the overall interface has changed in some way.

It doesn't take much to make a change in the binary interface, a small change of a .h file will do. In fact even changing just a kernel configuration option could change the binary interface. The API on source level is however more stable. It doesn't change that often, and it doesn't change in unpredictable ways by modifying something completely unrelated to what you are writing. This API has been kept almost unchanged all the way through the 2.4 series.

Re:Binary modules

[Cid Highwind]

If anybody reports and error on a system that has been using nVidia drivers, the kernel developers will tell the person to reproduce it without the nVidia driver or go bother nVidia.

This is just another facet of the kernel developers' jihad against binary modules. Presumption of guilt does not imply bad code, it implies prejudice(*).

(*) Please don't flame me for calling Linus a racist. I use the word prejudice because it literally means "to judge before" which is exactly what they are doing to nVidia and users of nVidia's hardware.

Re:Binary modules

[vinsci]

It's exactly the same as if Microsoft changed the Windows license to say you could not run any GPL programs under the Windows operating system. Imagine the screaming that would take place if they tried that.

Microsoft are busy working on just this and it's much worse than you would imagine. See the TCPA/Palladium FAQ.

Translations: German, Spanish, Italian, Dutch, Chinese, Norwegian, Swedish, Finnish, Hebrew and French

Re:Binary modules

[IamTheRealMike]

Ah, similar to library ABI breaks.

Surely there are better ways of doing it than that. Drivers don't have to resolve every symbol possible do they?

Re:Binary modules

[Reality Master 101]

Microsoft are busy working on just this and it's much worse than you would imagine.

No, they aren't. Palladium will NEVER stop you from running unsigned code. Never. Ever.

There is a very simple reason for this: it would break backward compatibility. No backward compatibility, then no operating systems sold.

Yes, there are people who are LYING about Palladium. Yes, LYING.

And yes, Palladium can be used for digital rights management. But that is a completely separate issue from the idiots who assert that only Microsoft-signed software will be allowed to run, which is completely absurd.

Palladium is nothing like this binary module issue.

Re:Binary modules

[The Vulture]

The way I see it, the people who wrote the kernel have the control. If they choose to say that you can't run non-GPL'd drivers/modules with the kernel this way, it's their choice. They wrote the code, they have the power to make people conform. Any module/driver developers who don't agree with the kernel team can distribute their code seperately.

Also, by the same token, Microsoft is well within their rights to say, "We will only allow you to run Microsoft sanctioned software under Windows". If you don't like it, you can either (1) stop using Windows, or (2) hope that the government strikes them down through the monopoly rules.

If you don't like the terms, then don't use the software, or find a way to make it work yourself. Nothing says that I must allow your software to interoperate with mine.

-- Joe

Re:Binary modules

[Reality Master 101]

I didn't say they didn't have the legal right to do it. I'm just explaining that the root of this is people who can't mind their own business and want to control the computer choices of others. It's no different than if some programmer releases a utility with a requirement that only born again Christians can use it. Does he have the right to do it? Of course. But that doesn't make the decision less idiotic and wrong.

Re:Binary modules

[Vellmont]

Yes. Nvidia did this for the Nforce drivers, and I believe for the GeForce drivers. This doesn't always solve the problem though. The RedHat 8 kernel (and I'm assuming other new distributions) was compiled with gcc 3.2, while the binary library Nvidia provides was compiled with gcc 2.95. Having kernel modules and the rest of your kernel compiled with major revision changes can cause problems, and inmod will refuse to load this module unless you use the force option. The end result is incompatibility until the Nvidia gets around to simply re-compiling the module with gcc3.2 (or you're technical enough to know to how to use the --force option with insmod, and are willing to take the risk it breaks something)

It's true that providing a binary library and a wrapper is a better solution than a completely closed binary, but there are still some large problems with this approach.

Re:Binary modules

[silvaran]

Now, it's valid to worry about whether I'm redidistributing software according to the license. But if I follow each individual software's license, then leave me alone.

Wow, I can't think of a better way to put it. It's interesting that the GPL tries to tell you what you can do with the software, while the people who enforce it are now telling you what you cannot do. I honestly can't see any licensing reasons why I can't take two pieces of software and run them together on my computer (as you indicate).

But then... the kernel has a table of system calls, and that table can be edited to effectively pipeline calls to the binary-only modules. So a binary-only module (with the older method) can effectively replace different kernel services (maybe?). Are there any licensing issues that occur with this?

Re:Binary modules

[vinsci]

No, they aren't. Palladium will NEVER stop you from running unsigned code. Never. Ever.

So what if Palladium lets your GPL program run, it wouldn't matter at all. This is because your GPL program will not be able, or rather allowed to, access the Palladium infrastructure in order to get the needed cryptographic credentials to perform certain tasks. So yes, your program will run, but no, it won't be able to do anything useful for you, not for anything that requires access to Palladium. And that would be mission completed for Microsoft: GPL software rendered useless.

The easily fooled will probably be glad to hear that the full source code to Palladium will likely be made available. Again, the source code is as powerless as your GPL program, and is of no use to you - even with the source, you can not make modifications to it and run the modified version in place of the version endorsed by Microsoft.

Furthermore, Microsoft already has a license in place that exludes open source development and specifically GPL and LGPL open source, see this article by Bruce Perens

Yes, there are people who are LYING about Palladium. Yes, LYING.

If you are aware of any lie in Ross Anderson's TCPA/Palladium FAQ, please state what it is.

Re:Binary modules

[LordNimon]

Why does the kernel module interface change so often though?

Because the kernel developers don't want to have to maintain backwards compatibility in any interface to the kernel. Binary-only drivers can only be fully supported by an unchangeable API. This means that if you realize an API needs changing (because it doesn't support some new concept or hardware), then you're SOL.

Backwards compatibility is not that much of a problem if you take the time to design the API correctly. But this is something that doesn't interest the kernel developers, because it would only have value to non-GPL drivers.

Re:Binary modules

[Dan D.]

Either way, I doubt its hard to make a patch which removes that if. Heck if it turns out they do completely remove them, I'll put the patch on my webpage (and no worries, it will be free to download or I'll send it to you for no more than the cost of the medium).

Re:Binary modules

[Daniel Phillips]

It's exactly the same as if Microsoft changed the Windows license to say you could not run any GPL programs under the Windows operating system.

No, it's not. There is no restriction whatsoever in running any kind of application you want under Linux. Did you ignore the distinction between kernel and user mode intentionally?

It's more like Microsoft changing the Windows license to disallow any GPL code in the Windows kernel. Oh wait...

Re:Binary modules

[Reality Master 101]

If you are aware of any lie in Ross Anderson's TCPA/Palladium FAQ, please state what it is.

Sheesh, that piece of trash is loaded with them. How about this beauty...

Software companies can also make it harder for you to switch to their competitors' products; for example, Word could encrypt all your documents using keys that only Microsoft products have access to; this would mean that you could only read them using Microsoft products, not with any competing word processor.

And I don't care if he uses words like "could" or "may" or any other wishy-washy term. For purposes of his document, he stating that Microsoft WILL do these things, no matter how absurd. Note, by the way, that Microsoft could implement the above bullshit right now if they wanted to without waiting.

That document is a load of scare mongering crap.

Re:Binary modules

[Reality Master 101]

Did you ignore the distinction between kernel and user mode intentionally?

Yes. It's none of their business in what mode I decide to run my programs.

Re:Binary modules

[Daniel Phillips]

"Microsoft are busy working on just this and it's much worse than you would imagine."

No, they aren't. Palladium will NEVER stop you from running unsigned code. Never. Ever.

You don't know that.

Re:Binary modules

[kasperd]

Drivers don't have to resolve every symbol possible do they?

No they don't have to. But there are other ways the ABI can break. A symbol being exported or not is the least significant change of the ABI, and that change can easilly be reverted. What is much more important is the layout of structs used in the kernel. A struct with same name in two different kernel builds does not necesarilly have the same fields at the same offsets or even the same size.

Re:Binary modules

[The Vulture]

But that doesn't make the decision less idiotic and wrong.

But it's their decision to make, and not yours (unless you contributed to the kernel). You don't have to agree with it, heck you don't even have to respect it, but it's their decision.

That is the point that I am trying to make.

-- Joe

Re:Binary modules

[Daniel Phillips]

Why does the kernel module interface change so often though? I mean, surely there are only so many ways to write a mouse driver

The module interface itself doesn't change often (though it happens to be going through a big change right now, it's the first in a long while). The calls that support normal Unix programs hardly ever change either, which you can verify for yourself by checking running an old application that links to, say, libc5. It still works, even with recent Linux kernels. If there are changes to the interface between libc and the kernel, they are nearly always additions, to add 64 bit versions of file operations, for example.

What do change regularly are the internal kernel apis, and this is always to make them better, for some definition of better: faster, easier to use, more capable, more reliable, easier to understand, better error handling, etc. Breakage of binary modules is invariably due to them relying on those internal kernel interfaces.[1] But it is exactly this willingness to change the kernel internals at a moment's notice[2] that keeps Linux evolving and improving so fast. That's already plenty of reason for doing it, and if it also provides gentle encouragement to people to share their code with the public, so much the better.

[1] But for modules provided in source form, the kernel developers will happily do the work of updating them to reflect kernel api changes. Often, there will be no changes at all required to modules in source form, because api changes can be hidden behind macros etc.

[2] Even within the kernel, such changes are normally only made in the development kernel series, so that even internal apis stay stable through each stable kernel cycle, i.e., about two years.

Re:Binary modules

[__aaahtg7394]

The issue is not with what _you_ can do. That's never been stated. There is no push to tell people "no, no, don't use binary modules!" That would be patently absurd, and while some (most?) of the kernel guys are out of touch with reality, most are more level-headed than that.

The issue is rather complicated, but the crux of it is this: the binary modules are linked against GPL'd kernel functions, and when that module is loaded, it becomes part of the kernel's address space and context. IE: it looks an awful lot like a derivative work. So now all exclusively GPL'd symbols are exported via GPL_SYMBOL().

It's not a matter of "you can't run binary modules," it's a matter of "you can't create a derivative work from GPL'd software and distribute it sans-source."

(This doesn't even get started on all the posts to l-k of "VMWare doesn't work with the brand new devel kernel! I forced loading of the 2.4 modules and it ate my hard drive!" or the endless supply of "Subject: Instability with nVidia drivers in kernel x.x.xx...". The only way to really support binary-only modules is to explicitly code for them, and nobody wants to do that.)

Re:Binary modules

[The Vulture]

Linus does have control over the kernel but I don't think he is as dogmatic about binary only drivers as are other people.

Yes, ultimately this will probably be Linus' decision. However, he must take into account the people who contribute code to the kernel.

Honestly, I don't care which way or other this works, because I make sure that I buy hardware that works with drivers that have source published. And, this doesn't necessarily mean, "staying behind the times", I got my All In Wonder 9700 working under XFree86 in 2D mode with the CVS tree. Next step is the TV tuner, as that's all I really use under Linux, and if the GATOS team doesn't make much progress on it by the time I get back from Christmas holidays, then I'll probably drop them a line and contribute.

For those who really care about binary modules, then perhaps you should voice your opinion to both Linus and the makers of the modules.

As I pointed out to Reality Master 101, this is about choice. Linus and the people who write code for the kernel have their choice of what to do with it. If they want a BSD license, it's their choice. GPL license? Their choice. Only born-again Christians can use it? Their choice. If you don't like their choices, then you can use alternate code, or because of the nature of the GPL, you can fix it and distribute your own version of the code.

This I don't agree with. It would be a blatant abuse of their monopoly power and therefore illegal.

I don't necessarily agree with it either, but like I said, they wrote it, it's their choice. It's then up to them to deal with the reprecussions that their choice has (be it angry end-users, or government reprisal).

-- Joe

Re:Binary modules

[__aaahtg7394]

If you have 10k desktops and your IT guy/gal/team
1. doesn't have an automated system to push updates, or
2. decides you need to upgrade to a new kernel for no apparent reason (security updates are almost universally backported), or is unable to do the kernel patching to fix things themselves, or
3. you have software that's somehow hacked into the kernel on desktops but you don't have the source to,

you're fucked. Start writing your resignation letter, you totally blew it for anyone you're responsible to. Hope you weren't there too long so you can put it on your resume as a hiatus.

Linux doesn't have to worry about backwards ABI compatibility because most vendors use the API instead...

Re:Binary modules

[Daniel Phillips]

If Linux ever becomes a mass-market operating system, the kernel developers are going to have to reprioritize things. Imagine telling a company with 10,000 Linux desktops that they would have to fix, recompile, retest, and redeploy a major in-house app because a deprecated kernel interface had been removed. Linux can make these kind of changes only because it's not yet mainstream.

Linux is already mainstream, or perhaps you do not think that 20 million users is mainstream.

Perhaps you meant 'dominant', in which case you would be even more wrong, because when Linux does become dominant, companies will have even more reason to go with the flow and release their kernel modules in source form. Note that they will still be, and always have been, free to release their applications in closed, binary form.

Note also, that companies doing the right thing and releasing their drivers in source form is always better for the user because such code is more likely to operate reliably and won't fall into hopeless disrepair if the original vendor dies.

Re:Binary modules

[mcelrath]

Do not fall into the must-upgrade fallacy. Just because there is a new kernel version does not mean that company has to use it. Older kernels are still maintained, and security updates do make it in.

If it didn't do what you wanted at the time you installed linux, you made the wrong choice. If it did, then there's no motivation to upgrade.

This cyclic consumerism where we have to upgrade our computers once a week makes me sick. Buy tools to perform a particular job. They're not going to magically stop doing that job years down the road.

-- Bob

Re:Binary modules

[Daniel Phillips]

This is just another facet of the kernel developers' jihad against binary modules. Presumption of guilt does not imply bad code, it implies prejudice(*).

No, calling it a jihad is a little bit of an exaggeration for one thing. And for another, if it is a holy war, it's against the failure to disclose technical specifications that would allow kernel developers to write and maintain their own driver code for the hardware.

(*) Please don't flame me for calling Linus a racist. I use the word prejudice because it literally means "to judge before" which is exactly what they are doing to nVidia and users of nVidia's hardware.

Acting against the interests of the users? Hardly. The best possible result for the users would be that nVidia releases their specs to the public, causing their development team to suddenly increase from a handful to hundreds or thousands. Considering that nVidia is now in the process of getting hammered by ATI (who is, coincidentally, more open with tech specs) perhaps they should reflect on the wisdon of doing just that. At the very least, they'd increase their sales to Linux users dramatically, and trust me, that is no longer small change. "Earth to nVidia".

Re:Binary modules

[oconnorcjo]

Why does the kernel module interface change so often though? I mean, surely there are only so many ways to write a mouse driver

The simplest answer is that the kernel developers are not sure how they want modules to communicate with the kernel. How are modules to communicate when things go wrong? how do you insure there are no races, how do you shut down a module that is still in use by others, how much information and what information should/needs to be passed to a module(and vice versa)? All these questions and more need to be dealt with. The more important modules become, the more serious those issues become and kernel developers are not yet satisfied with how modules do these things (and they have no qualms about backward compatibilty since they never promised there would be). Sure if modules only had to deal with mouse drivers then these issues would not exist but some kernel developers are dreaming of the day when all device drivers are modules and no kernel has any drivers compiled internally. I also hope that one day they will promise an API freeze (at least for the duration of any stable release) but I don't expect that to happen until the driver code is much better than it is right now.

Re:Binary modules

[bnenning]

Note, by the way, that Microsoft could implement the above bullshit right now if they wanted to without waiting.

They could try to, but it wouldn't be effective because users have full root (er, Administrator) access to their machines, and if necessary could use debuggers and/or virtual machines to figure out how Word is decrypting documents and create a nonproprietary replacement. But when your computer is "protected" by Palladium, applications will be black boxes that you can't look inside, and it will be much more conducive to that sort of behavior. The document addresses that point when discussing MP3 players:

This could all be done today - Microsoft would just have to download a patch into your player - but once TCPA / Palladium makes it hard for people to tamper with the player software, and easier for Microsoft to control upgrades and patches, it will be harder for you to escape, and will therefore be a more attractive way of doing business.

That document is a load of scare mongering crap.

It definitely presents the worst-case scenarios, but everything it describes is theoretically possible.

Re:Binary modules

[nihilogos]

The end result is incompatibility until the Nvidia gets around to simply re-compiling the module with gcc3.2 (or you're technical enough to know to how to use the --force option with insmod, and are willing to take the risk it breaks something)

Just download the .tar.gz files like everyone else and type "make; make install;" They work fine.

The *really* retarded thing about Red Hat 8.0 and nvidia cards is the way the Red Hat installer chooses the vesa driver for your $400 GF 4.

Re:Binary modules

[vinsci]

That document is a load of scare mongering [...]

...but it is a document which the inventor of TCPA himself, Bill Arbaugh, seem to agree with. He opens his comment on Ross Anderson with this statement:

"We are all aware of the criticisms that the TCPA has received. Ross Anderson did a good job of explaining the problems in an abstract fashion, but I felt that there were some things left out (Privacy concerns)." (my emphasis).

You write:

And I don't care if he uses words like "could" or "may" or any other wishy-washy term.

The rest of your comment, "Reality Master 101", builds on ignoring what Anderson is actually saying and is thus just a straw man argument, with which you have apparently fooled yourself.

Re:Binary modules

[jmauro]

In that situtation why the hell would you be running a kernel like that. Run the RedHat kernel or the distro kernel. These people are paid to see that the interface breaks don't happen. And stop complaining when you vary from the distro that the things that used to work before now no longer work.

Re:Binary modules

[bogado]

And it already does it, to the best of its capabilities. Why do you think theres not a single word processor capable of reading 100% formated office documents, other then office it self?

And no MS could not do this now, a simple disk tool or debug would review the key that could decript the files. This kind of restriction has to take place in the hardware, and that is what Palladium is all about, restricting your rights at hardware, giving power to MS, disney, RIAA, and other AAs at the hardware level. And yes, lets not forget. render open source usuless.

Re:Binary modules

[Erik Hollensbe]

No, this is a support issue.

No one wants to debug other people's code, when they can't actually fix it.

They're not saying, 'we won't debug it', they're saying 'tell us it's not hte nvidia driver and then we'll debug it'. This just sounds like a problem that's gone on far too long to even cause a question in their heads.

Re:Binary modules

[Hobbex]

Yes. It's none of their business in what mode I decide to run my programs.

Which is why the GPL only pertains to distribution, on your own computer you always have the right to do exactly whatever you want (unlike with your beloved Palladium fuckware).

Astroturf is green!

Re:Binary modules

[sjames]

There are people who think you should not be able to download a binary-only module and use it with a GPL program.

Note that we're talking about kernel modules, not user binaries. Without Linus's special exception, binary only modules would be completely forbidden.

There's actually a good reason for that. Without restrictions on linking binary code w/ GPL code, we'd end up in a situation where a GPL app gets swallowed whole into a proprietary app to the extent that the GPL app has effectively been made proprietary against the express wishes of the author.

It is worth noting that any claim of using a binary module to protect a patent is absurd. The existance of a patent necessarily means that the details are already public knowledge (unless the patent isn't really valid in the first place). More likely, it's binary only in order to hide serious flaws in the hardware.

Another common reason is to hide the fact that a so called feature of the hardware is actually implemented in software (Like many supposedly IDE hardware raid cards).

Frankly, I have no sympathy for any of those reasons since they border on fraud anyway. (In other words, they are morally and ethically but not legally fraud).

If you want a fair comparison to MS, go ahead and write a GPL driver for Windows 2000 and release it. Be sure to intercept a system call or two. Please report on your experiance.

Re:Binary modules

[mpe]

This is just another facet of the kernel developers' jihad against binary modules.

Why shouldn't they complain about a struggle (look up what "jihad" actually means) pushed on them by third parties?

Re:Binary modules

[bnenning]

ouch, you never seen proper encryption? If MS would do it properly, one wouldn't just be able to 'debug' the doc in order to find out what it means

Encrypting a file so you can't read it at all is easy, but this is different. In this hypothetical scenario, MS (or whoever) wants to allow only "authorized" programs to be able to decrypt and view content. To defeat it you need to watch the program doing the decryption sufficiently closely to figure out exactly what it's doing. A primary goal of Palladium is to remove that capability, thus creating a "trusted client". (As in, third parties can trust your computer to not trust you).

Re:Binary modules

[vrmlguy]

Presumption of guilt does not imply bad code, it implies prejudice(*).

(*) Please don't flame me for calling Linus a racist.

What's wrong with you that you assume that you're going to be flamed for using a word correctly? Do you think that most slashdot readers are too niggardly to own a dictionary?

Re:Binary modules

[Omnifarious]

Sure, a brute force attack would take years. But you wouldn't apply a brute force attack. You would pluck the key out of memory while Word was decrypting the document. If Word were Palladium enabled on Palladium enabled hardware, you'd no longer be able to do that, and you would be reduced to trying a brute force attack.

Re:Binary modules

[nihilogos]

Worked for me. The kernel interface *can* be recompiled. What do you think make does?

Re:Binary modules

[vinsci]

Code signing has it problems. Would you for example install a component that was signed by "Microsoft Corporation"? You should not do that. (Read the article The Age).

Another recent code signing problem from Microsoft was also discussed recently on Slashdot.

Arrogance

[rossz]

This may very well break some rather expensive commercial Linux products, but that doesn't seem to bother most kernel developers. Reminding the purveyors of binary modules that they continue to operate at the pleasure of the Linux kernel developers and their open-source licenses is seen to be a necessary (even enjoyable) task.

What an arrogant attitude. The kernel developers need to be reminded that widespread acceptance of Linux might very well require the support of big commercial enterprises, not just hobbiests and open source enthusiasts. Few companies are going to make major investments in Linux if they have to deal with prima donna programmers who love fucking with them.

Re:Arrogance

[pclminion]

What an arrogant attitude. The kernel developers need to be reminded that widespread acceptance of Linux might very well require the support of big commercial enterprises, not just hobbiests and open source enthusiasts

If you read over the LKML mailing list archives, it will become quite clear to you that the kernel developers don't give a cold shit in hell about user requests or complaints. They do what they want, and fuck everyone else.

At least, that was the sense I got from the conversation..

Re:Arrogance

[silvaran]

How about you go branch your own Linux kernel tree and add code back in that better supports binary-only modules? It's their tree, they can do what they want. If Red Hat doesn't like it, they can maintain their own tree (which they do). If nVidia doesn't like it, they can do likewise.

After all the hard work of the kernel folks, you seem to expect them to be perfectly happy with having to support binary modules that they can't debug, and that fall in a grey area of the GPL.

How about you go create your own open-source project. Then I'll go create some hardware, and keep all the information proprietary. To tease you a bit, I'll keep all information about my hardware proprietary, so you have two choices:

1) Reverse engineer my hardware and write your own software.
2) Indicate to me that your software is valuable, and depends on my hardware, until you convince me to release sources so they'll work better with your software.

That's the position nVidia's in. They've got one of the most widely-used video cards on the market. And the only way to use that video card effectively under Linux is to use their binary-only drivers. Get a clue. Linux doesn't belong to commercial entities any more than it belongs to Linus. What you do with your kernel tree is your own business.

Re:Arrogance

[bbk]

Last time I checked, linux was a homebrew project by Linus. He gets to do what he wants with it - he's not even paid to write it. His time is valuable, and wasting it debugging binary modules isn't productive.

Corporations that write binary modules are only allowed to write them by Linus' good graces - normally, the GPL doesn't allow for non-source availible binaries to be linked into GPL code in the manner that kernel modules are added.

Corporations should be happy they are allowed the level of integration that linux gives them, as they get an exemption (no-GPL) from the rules. They are also free to switch to the BSD's any time they want, which lacks many of the GPL's problems.

BBK

Re:Arrogance

[rossz]

Last time I checked, linux was a homebrew project by Linus.

It's been a long time since you've checked, obviously. Linux has grown way beyond a homebrew project for Linus. It's a multibillion dollar business these days.

Re:Arrogance

[silvaran]

Very cool. I am missing something. How did I reinforce your point exactly?

Re:Arrogance

[Subcarrier]

What an arrogant attitude.

Arrogance indeed. Users are so used to being customers that they don't know when they are receiving a gift.

It's weird how, after over ten years, many people still don't get Linux. Every single Linux developer does what he does does because he gets something out of it. Not because he want's you to get something out of it. That's the beauty of the GPL. It guarantees that everyone can do what they want with the code, as long as they give others the same courtesy.

If you want something, just do it. If you can't, find a way to motivate someone to do it for you. You have the same rights as everyone else, no more, no less.

Re:Arrogance

[finkployd]

Perhaps, but they sure produce a great product with these attitudes...

Finkployd

Re:Arrogance

[Mannerism]

What an arrogant attitude. The kernel developers need to be reminded that widespread acceptance of Linux might very well require the support of big commercial enterprises, not just hobbiests and open source enthusiasts. Few companies are going to make major investments in Linux if they have to deal with prima donna programmers who love fucking with them.

I see your point, but I respectfully disagree. Linux will ultimately be accepted or rejected by businesses based on the cost of running it versus the cost of running a competing OS. I do not believe that forcing commercial developers to evolve their products to match changes in Linux will increase the relative cost of running Linux, because commercial developers typically have to do this for other OS's anyway. Regularly paying for upgrades of your commercial software is standard practice.

By indefinitely supporting obsolete (and potentially bad) features, however, the kernel developers could actually drive up the relative cost of running Linux. Why? Because there's less motivation for commercial developers to modify their products to utilize the new-and-improved features and, ultimately, make the system as a whole more robust and less costly to operate.

Open source software already has the disadvantage of not necessarily being driven by short-term economic gain. I say disadvantage, because short- term economic gain is an easy thing to sell to people. Given this disadvantage, a little arrogance and strong-arming is not only justified, it's essential.

Re:Arrogance

[finkployd]

Despite that, everyone still has to play by the developer's rules. These rules may piss off some of these multibillion dollar corporations, but their development models obviously cannot produce their own kernel that has the same success.

Finkployd

Re:Arrogance

[rossz]

I guess I should have stated this in my original post. I don't necessarily object to the code changes (I'm not qualified to make that call, to be honest). If they are needed for the good of Linux, then I'm all for it, even if it does break expensive commercial programs.

It's the arrogant attitude that I have a problem with. Working on open source means working with a community. Sometimes that community includes commercial operations. Messing with them just because "you can" just doesn't seem like good diplomacy.

Re:Arrogance

[IamTheRealMike]

Messing with them just because "you can" just doesn't seem like good diplomacy.

Is that what you think? That's hardly how things are, it's not like Linus sits in his dark tower, steeples his fingers and says "Today, I think I shall once again break binary compatability to screw over nVidia.. bwhahahahaha".

When they break kernel interfaces, it's to make a better kernel. If they didn't, those parts of the kernel would effectively be frozen in time, and the kernel woudln't move forward, it'd get more crufty and less reliable. We'd all suffer, just so binary driver producers don't have to recompile their drivers. Doesn't sound like a good tradeoff to me.

Re:Arrogance

[MisterFancypants]

If Red Hat doesn't like it, they can maintain their own tree (which they do). If nVidia doesn't like it, they can do likewise.

The problem is nvidia (and I use nvidia simply as an example, this applies to many others) WON'T, since unlike Red Hat, having a Linux kernel branch is very tangential to their real business. There are a number of companies that offer Linux support simply as a goodwill gesture, or at most for an extra bit of PR, despite the fact that the limited Linux support they do offer isn't really a good return on investment (just like id games for Linux aren't a good ROI but id releases them anyway for their own reasons). Anything the kernel developers do to make it harder for these folks to support Linux will mean less Linux support from hardware makers, which will make the much-vaunted Linux desktop push stillborn. If that's what the kernel developers want to do, that's fine. As you said, it is their code... But then they can't go crying later when everyone drops their Linux support.

Re:Arrogance

[Subcarrier]

It's the arrogant attitude that I have a problem with. Working on open source means working with a community. Sometimes that community includes commercial operations. Messing with them just because "you can" just doesn't seem like good diplomacy.

The commercial operations are a part of the community as well, hence they must be contributing to the atmosphere of arrogance. Seriously, if they had a good standing in the community they would be less likely to be walked over. The Linux community tends to have little patience for would be members who want things but are reluctant to contribute. This, I think, is completely understandable.

Let's see. How could my company, as a hardware manufacturer, get on the good side of the Linux community? How about we GPL our device drivers? What a great idea! It would work too.

Re:Arrogance

[Waffle Iron]

normally, the GPL doesn't allow for non-source availible binaries to be linked into GPL code in the manner that kernel modules are added.

The GPL does not stop you from linking binary only code to GPLed code. Nor does it stop you from distributing your own binary-only code that can be linked to GPLed code. It only stops you from redistributing someone else's GPLed code which is linked to your binary-only code.

This is because the GPL puts no restrictions on the use of GPLed code, only on the redistribution of it. If you don't distribute the GPLed code, you can't violate the GPL. As long as a company that writes binary modules doesn't distribute the Linux kernel, there is no way that they can be in violation of the GPL.

The end user can link the binary module to the Linux kernel and use it. The end user can't redistribute this combo, however.

Re:Arrogance

[kasperd]

What commercial application would you most like to see migrated to run natively on Linux"? I guess for these kernel developers the answer is "NONE of them".

There are major differences between kernel modules and applications. I don't use any closed source kernel modules, and I certainly hope I never have to. But I happily use a few closed source userspace programs.

If you take a closer look on the kernel/module ABI and the kernel/user mode ABI, you will see that the first one is changing basically on every build of the kernel while the second is almost unchanged all the way from 2.0 to 2.6.

Closed source modules never was a good idea and always causes trouble, while userspace applications can be closed source and work on a wide range of kernels because the system call ABI is very stable.

Re:Arrogance

[Yunzil]

After all the hard work of the kernel folks, you seem to expect them to be perfectly happy with having to support binary modules that they can't debug, and that fall in a grey area of the GPL.

They don't have to be happy about it, but given how things work in the Real World, they damn well ought to learn to deal with it.

Re:Arrogance

[kasperd]

normally, the GPL doesn't allow for non-source availible binaries to be linked into GPL code

It is a very grey area. The GPL does not forbid linking GPL code with closed source code for your own personal use. But you are not allowed to distribute such code.

Now since the modules as they are distributed is not yet linked they might be legal. The linking is done at load time, at which time it might be considered personal use.

Re:Arrogance

[sweede]

Let's see. How could my company, as a hardware manufacturer, get on the good side of the Linux community? How about we GPL our device drivers? What a great idea! It would work too.

Accountant: but Mr CEO person, our research shows that only 200,000 people use Open Source software that would have a use for our super-deluxe hardware. at the same time, 4.5 million Windows users have a potential need for our super-deluxe hardware. in addition to that, the cost of creating and maintaining and Open Source driver would cost us an extra 15% on the development of super-deluxe hardware. If we dont have OpenSource compatible drivers, we can lower the cost of super-deluxe hardware by 15% and still make profit on it.

Mr CEO: Ok, that sounds even better.

Re:Arrogance

[rossz]

Exactly my point. Linux needs the goodwill of big companies more than big companies need the good will of the Linux community. As far as market goes, Linux is hardly a blip in the radar compared to Windoze. I wish it was different. Piss of the hardware companies and they'll just say, "screw it, it's not worth the time, effort, or money, we'll concentrate on windows." I'm not suggesting we bend over backwards and make unreasonable changes or continue to support long obsolete APIs. I am suggesting there should be no big surprises and that we should solicite input from the hardware companies.

As much as others would like to think otherwise, compared to Windoze, Linux is a niche market. I'm talking about desktop systems, not servers. Servers don't need hardware accelerated video cards or force-feedback joysticks. Hell, my server doesn't even have a video card, mouse, or keyboard.

On the other hand, it goes both ways. If a hardware company is taking advantage of the open source community - fuck 'em.

Re:Arrogance

[Daniel Phillips]

"This may very well break some rather expensive commercial Linux products, but that doesn't seem to bother most kernel developers. Reminding the purveyors of binary modules that they continue to operate at the pleasure of the Linux kernel developers and their open-source licenses is seen to be a necessary (even enjoyable) task."

What an arrogant attitude. The kernel developers need to be reminded that widespread acceptance of Linux might very well require the support of big commercial enterprises, not just hobbiests and open source enthusiasts. Few companies are going to make major investments in Linux if they have to deal with prima donna programmers who love fucking with them.

Err. Many (or perhaps even most) companies have already made major investments in Linux. And your point is?

Re:Arrogance

[Daniel Phillips]

How about you go branch your own Linux kernel tree and add code back in that better supports binary-only modules?

Well, he'd have to be careful there, since some copyright holders might take issue if the changes amounted to a relicensing, but sure, he could maintain his own tree if he liked, and never change it so that binary modules never break. Of course it would never get better either...

Re:Arrogance

[Daniel Phillips]

The GPL does not forbid linking GPL code with closed source code for your own personal use. But you are not allowed to distribute such code.

Now since the modules as they are distributed is not yet linked they might be legal. The linking is done at load time, at which time it might be considered personal use.

Dynamic linking is treated the same as static linking, which is why the LGPL exists.

Re:Arrogance

[DeathPenguin]

>>Few companies are going to make major investments in Linux if they have to deal with prima donna programmers who love fucking with them.

Alas, what good is a God if he has no followers?

Re:Arrogance

[coaxial]

Perhaps, but they sure produce a great product with these attitudes...

Imagine what quality would be improved if they did listen.

Seriously. Nothing justifies an arrogant asshole.

Re:Arrogance

[coaxial]

So let me get this straight.

Are you saying that I should just grin and bear it when my computer goes BOOM! when the soundcard gets initialized? I should say "Wow! I am so lucky to have something that just barely supports my videocard!"? And when I point this out to those that "support" these features, I'm told I should drop everything I'm doing, spend several months reading up on the low level details of my card, learn the intricacies of the kernel, learn the intricacies of CVS, write a patch, kiss ass for another month or two so that my patch is actually added, so I ineffect cleanup someone else's mess and/or stroke someone else's ego, instead of doing what brings me joy (say my own project)? Now tell me, who's more arrogant?

Re:Arrogance

[Xpilot]

Removing binary-only module support is a good thing. Binary-only modules suck. Big time. Binary-only module support is about as good as no support at all. The reason being is a module compiled for a specific kernel can't be used (safely) on another kernel. So a vendor releases a module for the latest Redhat kernel. How about people who use other distros? How about people who custom-patch their kernel and run a less popular distro like Slackware?

NVidia do release source versions of their modules, but not with a GPL license. So NVidia is a different case.

Re:Arrogance

[Shelled]

There are a number of companies that offer Linux support simply as a goodwill gesture...

Or as a wise investment in the future? Nvidia must realize that being the only viable performance solution for a group of hardcore and influential computer users has more than feel-good benefits.

Re:Arrogance

[oh]

This is because the GPL puts no restrictions on the use of GPLed code, only on the redistribution of it.

The arguemnt is over the derms derivitive work.

From the GPL,

This License applies to any program or other work [...] [and] any derivative work under copyright law
[..]

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program

The argument is based around the term "derivative work". If I take you code, and modify it to add a feature, the modified program is covered by the GPL, and therefore Free software. Remember that I am allowed to sell the new program, it is Free but not free.

If I don't sell the modified program, but use diff to produce a patch to your program. Is the patch GPL? Can I sell it under a non-Free license, making money and preventing the purchaser from passing it on to a third party.

Re:Arrogance

[finkployd]

I'm not convinced they are being arrogant assholes. They do not respond well to others who have not proven themselves as reliable programmers making demands as to how they should design the kernel, but who would? The technical decisions behind the kernel always seem to be sound, only when these decisions conflict with someone's personal agenda or a corporation's fiscial agenda are they blasted as being arrogant assholes.

Sure there are occational in-fights regarding differences of opinion in technical matters, but you need that for the best ideas to be accepted.

They DO listen, just not to every wannabe kernel hacker who comes out of the woodwork and demands that their crappy code be integrated into the kernel that they know next to nothing about. You want to propose a complete rewrite to the VM? First you have to establish yourself with good solid work and make ourself known as a intelligent programmer. Having a .sig that says "Senior Systems Programmer at XYZ" is not enough to jump in and start making demands.

Finkployd

Re:Arrogance

[praedor]

Until this point, at which they have arbitrarily decided to break hardware that some people MUST use. Sorry, your hardware is no longer viable under linux because we are asswipe primadonnas.

For some of these crybaby philosophical TYRANTS, I would love to see the company they work for fire them. See how much of a living they manage just on "love" of coding.

It's the CUSTOMERS stupid! The CUSTOMER is ALWAYS right. Period. Once you move out of your basement dwelling (and out from under mommy and daddy's monetary support) you do not get to do whatever you want just because. Linux is no longer a basement hobby and it needs to be handled thusly. Not ALL software is amenable to GPL. Much is, but not ALL. There is no black and white...except for the statement that there is no black and white.

Re:Arrogance

[finkployd]

Wrong wrong wrong! They are breaking no hardware at all. They are simply making a decision that they will not bend over backward to accomadate binary only drivers. Lately making sure the kernel supports, debugging around, and dealing with these drivers has been a serious pain in the ass. Not to mention technically a violation of the GPL. I suppose it is much easier to call them asswhipe primadonnas than to actually educate youself regarding the reasons and technical issues surrounding thus stuff.

You certainly seem to have some major aggression issues with the kernel maintainers. Have you considered simply not using Linux? I'm not tring to be an asshole but since you hate it and it's development idealogy so much, do you really think it is the right solution for you?

As you correctly point out, "it is the customers stupid". The customers have been demanding open source drivers for hardware for quite a long time now, I know I personally have been on Cisco's ass to make their crappy VPN driver open source, and many people I know who work with visualization technologies are after nVidia about their crummy drivers. I know of NO CUSTOMER who prefers a closed source driver which must be updated with every kernel release. A binary only driver that does not keep up with the kernel revisions, and only works on x86 hardware in not acceptable, these companies NEED to start listening to the customer.

Linux got where it is today following the development procedures and idealogies that you feel are not right for a prject of it's importance. However you fail to understand that it is this that allowed Linux to be a success where most other similar attempts have failed. Why would you have Linux now "play the game" and bow down to the corporate philosphy which has killed so many other operating systems?

Finkployd

Re:Arrogance

[warpSpeed]

Are you saying that I should just grin and bear it when my computer goes BOOM! when the soundcard gets initialized? I should say "Wow! I am so lucky to have something that just barely supports my videocard!"?

Are you paying for the software and support? If you are does your vendor suuport the hardware that went "BOOM"? You should take this up with your vendor.

And when I point this out to those that "support" these features, I'm told I should drop everything I'm doing, spend several months reading up on the low level details of my card, learn the intricacies of the kernel, learn the intricacies of CVS, write a patch, kiss ass for another month or two so that my patch is actually added, so I ineffect cleanup someone else's mess and/or stroke someone else's ego, instead of doing what brings me joy (say my own project)?

Again, are you paying for this "support", are they contractualy obligated to listen to your points about thier software drivers? Talk to your vendor. If you do not have a vendor, what are you bitching about?

As for developing patches why kiss anyones ass? If you feel that the maintainers are not listening, or taking your patch submisions create the patch yourself and keep it to yourself. Or, better yet publish it on your own web site. Hell run your own CVS tree with your own set of patches. You are as obligated to do this as the people that develop the kernel in the first place.

Now tell me, who's more arrogant?

I would have to say, that expecting free "support" from people that write and maintain code because they like to, not because they are paid for it, pretty much smacks of arrogance to me...

Re:Arrogance

[warpSpeed]

If you read over the LKML mailing list archives, it will become quite clear to you that the kernel developers don't give a cold shit in hell about user requests or complaints. They do what they want, and fuck everyone else.

This development method seems to work for MS too. The only difference is that you can take the code and fuck yourself with it, but MS prevents your from fucking yourself, they do it for you.

Re:Arrogance

[oh]

The test:

Run your code without the GPL'ed code. If it runs, it's standalone. If it cannot run without the GPL'ed code, it needs to be under the GPL.

I'm not trying to be rude, but thats a bad test.

I can write code that uses linux specific functions, but does not contain any GLP code itself. Most everyone thinks that is it legal to run propriatry code under linux, but I cant take a binary built under linux and just go and run on on any other platform. Well, not easily.

Re:Arrogance

[psamuels]

Now the Kernel developers see fit to make Linux about `Freedom and Choice, the freedom to run whatever software i want, how ever i want, as long as everything on the system is 100% open source. '

Where on earth did you get the ideas that either binary-only drivers or any other binary-only software have been disallowed?

Sheesh, RTFA already. Do you even know what the syscall table is? Hint, 99% or more of the modules out there don't need to touch it. (By "need" I mean it would be a reasonable approach to the problems a given module is designed to solve.)

I wonder when they will remove the ability to run non-open source applications in User-space land so that things like UT2003 wont work anymore

Ummm, yeah, you do that. Perhaps you can spend a few sleepless nights curled up in a shivering ball on your bed wondering when the Kernel Gestapo will kick in your door, boot up your l33t XP/Mandrake dual boot and forcibly upgrade it to some unholy GNU/Palladium. Or maybe you can imagine some dark day when Linus sends you The Announcement: your kernel is vulnerable to a horrible hack, you must upgrade with this hotfix NOW, and oh by the way here's a 15-page EULA you have to click through, don't worry it's all fine print except the bit where they disable all heathen, politically incorrect software such as BitKeeper, which Linus uses for source management.

Have you ever read anything, by the way, that would indicate that even one kernel hacker would support disabling non-free software? I certainly haven't, and I like to think I keep up on these things.

Just great...

[xchino]

I am an op in a Linux support channel on IRC, and I always dread new rleases of both kernels and redhat. It never fails.. some noobie comes in *demanding* we help him fix the production mail server he just trashed by installing RH8 or the newest kernel (dev or otherwise).

For anyone out there who is just waiting and drooling on themselves over 2.6, unless you NEED one of the few features present in a new kernel, you have no need to upgrade. The latest isn't always the greatest, and even "stable" releases need to go through testing before you put them in production.

Re:Just great...

[EvilStein]

Just tell him to RTFM like most of the people in IRC linux channels do. ;)

Re:Just great...

[coaxial]

some noobie comes in *demanding* we help him fix the production mail server he just trashed by installing RH8 or the newest kernel (dev or otherwise).

My god. Someone came to IRC for support. It's not like he's been told "Linux is perfect for buisnesses. It is The Way and The Light.". So he switches, and runs into a problem. So he turns to The Community, because afterall he's been told it's friendly, informative, and always willing to help.

And what does he find? People that say: "How dare you want help from me?" , "RTFM!" , "You shouldn't have done that you idiot."

Now tell me again why linux support is so much better than anything an unnamed megacorp gives.

Re:Just great...

[Erik Hollensbe]

Coming from other support channels I know this scenario.

Guy: Blah Blah 2.6 Blah Blah Beta Blah Blah Production Server Blah Blah Fucked.
Help: Did you check this and this and that? Did you make backups?
Guy: WTF? d00d, I just installed the shit, I shouldn't have to make backups. Why doesn't this work like windows? Just tell me how to fix it.
Help: Well, read this and this and that. If you're having any problems along the way just ask.

for(0..1000) {
Guy: JUST TELL ME HOW TO FIX IT
Help: I just did.
}

Guy: parts channel
Help: has one more notch towards the never-ending RTFM response loop.

(The irony is, even though this guy 'didn't get help', he will indefinately come back 15-20 times and ask other questions which could be easily answered but his lack of ability to understand that he's getting SUPPORT ON SOMEONE ELSE'S FREE TIME makes him a candidate for /kb)

Re:Just great...

[coaxial]

his lack of ability to understand that he's getting SUPPORT ON SOMEONE ELSE'S FREE TIME makes him a candidate for /kb)

It's stop being "free time" when you volunteer. Let's take a meatspace example. Someone volunteers for a soup kitchen. A homeless guy shows up and wants some food, afterall he's been told that if he comes here, he'll get food. He looks around and says to the person behind the counter, "Hey. Where's the food?" The answer, "Fuck off you rude bastard. This is MY FREE TIME!" Ummm...

If you don't want to provide support (and everything that goes with that) then what are you doing in the channel?

Re:Just great...

[Erik Hollensbe]

For the most part I agree, and that's part of the reason why I don't hang out in those channels anymore.

The other reason was what I said in the grandparent. No matter how many times I would help people, they would refuse to help themselves.

It's open source, damnit!

[europrobe]

If non-GPL companies feel they can require users to install binary-only modules, why not simply requiring them to apply a kernel patch to remove this new limitation first?

Or, better still, why not delivering the whole product with an installer doing all this for them? It's not going to break GPL, as long as they publish the source code for the patch itself, which should be trivial.

I'm all for GPL, but this is not going to make that big an impact.

Re:It's open source, damnit!

[MasterOfMagic]

If non-GPL companies feel they can require users to install binary-only modules, why not simply requiring them to apply a kernel patch to remove this new limitation first?

Or if this bothers you, you can always stick with kernel 2.4 or kernel 2.2 or kernel 2.0. As long as they are maintained and you have the source, they can't take this away from you. I, for one, will not be upgrading to 2.6.0. I usually wait until the last number is at least ten so it doesn't seriously mess up my desktop system.

Are they nuts?

[I Am The Owl]

This may very well break some rather expensive commercial Linux products, but that doesn't seem to bother most kernel developers. Reminding the purveyors of binary modules that they continue to operate at the pleasure of the Linux kernel developers and their open-source licenses is seen to be a necessary (even enjoyable) task.

See also: quickest way to discourage commercial development on your platform.

Gee, do you think all these corporations who have been embracing Linux in these past few years will still be using it when they can no longer use their expensive software investments with it? I doubt there are reasonable open source alternatives for most of these applications, like video card drivers or movie production applications, for example. Good luck on getting more people to adopt your platform after that.

I forsee a massive move to FreeBSD if this bullshit continues.

Re:Are they nuts?

[finkployd]

Note: this really only applies to drivers, not applications.

Finkployd

Re:Are they nuts?

[rseuhs]

Wow, I was amazed when some morons thought that just because binary-only drivers no longer have full access to the whole kernel (yes, there will be Linux 2.6 binary only kernel modules) but you seem to top them all by thinking that commercial *applications* are affected by all this.

I wonder if the parent is a professional Linux-hater spreading FUD or just plain ignorant.

Re:Are they nuts?

[pavera]

One of the first rules of economics and business decisions:
IGNORE SUNK COSTS.
IE. the money they have already spent means dick. If its not worth it going forward, they will abondon ship right now.

Reiser4?

[Dionysus]

Anyone know if Reiserfs4 got into the 2.6 release? I think I read Reiser had been pushing Linus to include Reiser4, and from what I've read in LinuxJournal, Reiser4 supposed to be 2-3 times faster than Reiser3.

Re:Reiser4?

[darketernal]

Reiser4 is currently in 2.5, which should drift over to 2.6 assuming it doesn't screw up big time mid-transition..

Re:Reiser4?

[kryps]

Reiser4 is currently in 2.5, which should drift over to 2.6 assuming it doesn't screw up big time mid-transition.

What have you been smoking? Reiser4 has *not* been integrated into 2.5. Judging from discussion on their mailing list and the available documents on their site it is currently in a very early alpha state (i.e. data loss is to be expected). Since adding a new filesystem is not a very intrusive change it might still get added now after the features freeze maybe even in the (early) 2.6 series but not before it becomes quite a bit more mature.

Adding alpha-quality filesystem to a mainline kernel does not really help anyone.

-- kryps

Weird interview

[Telex4]

That interview was interesting, but weird. I've just finished writing a tutorial introducing the Linux kernel, and I had to scratch my head over some of the things mentioned in the Tinyminds article. I know they didn't exactly aim the article at complete newbies, but it'd be nice if hackers could make a little more effort to make what they say intelligible for the average human.

A simple example might be where Robert Love mentions the need for a standard disk layer. What does that mean, to somebody who doesn't understand the way that the kernel in many areas creates a standard set of instructions (e.g. for disks, like "write", "access x data") and that he thinks this should be extended to disks, to take some of the bloated code that repeats all this stuff out of the SCSI codebase?

I think hackers in general really need to work on getting their ideas across to the more average person, otherwise most people have no reason to get excited by new releases unless they enjoy growing numbers!

Re:Weird interview

[Chundra]

I think hackers in general really need to work on getting their ideas across to the more average person

If everyone were to do that, nothing would ever get done because we'd all be writing tutorials (no offense). In any field--hell, in life--you learn to denote complex semantics with symbols so you can then refer to even more complex semantics. Those symbols might be words like "disk layer" or "dog" or "average person" or whatever. To have to constantly explain the never ending chain of meaning of the composite parts to the would be fruitless.

Re:Weird interview

[Telex4]

You make an interesting point. Maybe Tinyminds just chose the wrong person to ask, or maybe they should have tried to clarify his answers :) Either way, I think it's important that big changes like kernel 2.6 are explained to the whole community.

Perhaps alongside the normal changelogs with major revisions, a layman-friendly changelog could be written, just describing the changes in easier terms (not laymans, you can always simply link to a useful tutorial (ahem, *grin*) which will explain the complete basics).

Just imagine you're a manager, and your IT staff have converted your servers over to GNU/Linux. You read somewhere that kernel 2.6 is out, and you wonder "what does that mean?", and yet you can't find out, and perhaps even your IT staff can't find out (as kernel internals arent' exactly a prerequisite for every sysadmin) - will that impress you? I doubt it.

Yay for binary modules

[Kiwi]

The only reason I am able to post this article right now is because Linux supports binary-only modules. namely, there is no interest in the free software community to develop a driver for the various Winmodems out there. I have a laptop with a built-in Winmodem. The only way I am able to use this modem is to use a binary module.

On the downside, the module (for the Lucent winmodems) was originally released for the 2.2.x kernel. It was never updated by Lucent, but some people on the net figured out how to change the headers so it works with the 2.4.x kernels.

If it becomes impossible to use this module with 2.6, and it looks like the changes to the module interface are large enough to make the module completely incompatible, I have a few choices:

• Stick with an older Linux distro which uses a 2.4.x kernel.
• Wipe Linux and use Windows. [1]
• Spend over $100 for an external modem (I'm a college student, so no).
• Drop out of school for the next semester, and abandon my current open-source project so I have the time to develop an open-source driver for win modems. I want to graduate ASAP, so alas no.

- Sam

Then again, Lucent may force people to use older drivers for newer versions of Windows, like XP. Then again, Windows 98 is still supported (name one Linux distribiution which came out in 1998 which is still officially supported), and it should be possible to use a Win98 driver with XP.

Re:Yay for binary modules

[Amazing Quantum Man]

You can get a new winmodem though, one that has modern and compatible Linux drivers for the chipset.

No he can't. RTFP. He's a student (hence not much spare cash) with a laptop that has a built-in winmodem.

Re:Yay for binary modules

[Daniel Phillips]

If it becomes impossible to use this module with 2.6, and it looks like the changes to the module interface are large enough to make the module completely incompatible..

They are not. If the modem driver already runs under a wrapper, then updating the wrapper will be sufficient.

Re:Yay for binary modules

[warpSpeed]

You can get a new winmodem though, one that has modern and compatible Linux drivers for the chipset.

No he can't. RTFP. He's a student (hence not much spare cash) with a laptop that has a built-in winmodem.

He chose to spend his limited cash on a laptop with components that were not supported with open source... or he received the laptop for free. Either way, why should the rest of the development community be penalized, or have to make decisions based on what this guy owns? He should do more research first next time, and stop bitching about "poor me, I can't run a modem, somebody help me..."

The kernel is GPLed, if hardware vendors cannot figure out that it is to thier benifit to release the software, or release timly updates, the let darwin do his work on them...

get a life, sheesh...

Best solution

[nuggz]

The best solution depends on your point of view.

For some technical correctness is a primary goal, in Linux this means that sometimes features and interfaces change.

This may tend to piss of some, but you end up with a technically superior product.

For others consistency of interfaces may be most important and technical correctness is secondary.
This tends to generate lots of legacy crap, we see this in MS Windows. Now they're cleaning up, and we have the compatibility problems.

There is always a tradeoff. But I think a well documented technically good solution is best.

Beggers can't be choosers

[nuggz]

You can use the old kernel, you can use the new kernel, you can use your own kernel.
Everyone can make whatever they want.

They don't owe you anything.

Re:Beggers can't be choosers

[pclminion]

You can use the old kernel, you can use the new kernel, you can use your own kernel. Everyone can make whatever they want.

Untrue. Most people are incapable of hacking kernel code, or any kind of code.

The kernel developers can use their abilities and positions to essentially blackmail the user base. New hardware drivers aren't usually backported to older kernels, so in order to get modern support for most things you have to run the latest. Want to run on modern hardware? You have to upgrade to a new kernel, with a new license, new restrictions, etc.

They don't owe you anything.

This is hilarious. You know, I once posted a rant on LKML about some particular issue (details unimportant). I essentially said that if it wasn't addressed, I might consider moving to BeOS (which was looking very good to me at the time). I have the freedom to make that choice, right? They don't OWE me anything, right? So clearly I most not owe THEM anything.

But I got several responses accusing me of BLACKMAIL, saying that I was "threatening" to move to BeOS in order to force someone to do something.

I could understand if there was some disagreement on a technical point, but by that point the conversation had degenerated into a flamethrowing competition between Andre Hendrick and the rest of the list. I was the only guy backing up Hendrick.

Anyway, I know from experience that many kernel developers are elitist, arrogant people. I guess they think that because their code runs in Ring 0 they must be somehow superior to the rest of us.

Re:Beggers can't be choosers

[nuggz]

You can use the old kernel, you can use the new kernel, you can use your own kernel. Everyone can make whatever they want.

Untrue. Most people are incapable of hacking kernel code, or any kind of code.

You can learn, you can hire someone, a group can get together and hire someone. A company could be formed to service that need.

Blackmail the user base?
With free software they can't force you to move, the software doesn't self destruct.
If you don't like it, go to BeOS or wherever.

Re:Beggers can't be choosers

[pclminion]

So, wait.. you accuse the kernel devs of "blackmail" because new drivers (which may or may not be written by the kernel devs) aren't usually ported to older versions.

I never said so on the list or in private to anyone. That's just how I feel about it.

The "rant" was the result of me being extremely pissed. And I believe justifiably so. There was something in the kernel that Andre considered a "defect." He had a simple piece of code to fix it. The kernel people rejected this, because "in theory, someone can get around this, so there's no point plugging a hole which someone can reopen."

At this point, I made some remark about how it would boost user morale if the patch were in place, regardless of any real technical merit. I made some statement to the effect of, "You guys should care more about what the users want, even if you think you know better than them." I didn't mean it in a combative sense. I was just growing irritated with their arrogance, and wanted to say so. I had earlier made some comment about how BeOS offered some feature that I wanted, and of course this got used as ammo against me, claiming that I was trying to blackmail the kernel developers by threatening to leave Linux -- as if my sole usership was pivotal to their existence. I'm not idiotic enough to make such a claim.

I've tried the "ya know, this really needs changing, and here's a few reasons why..." approach. The response I've gotten was "No. You're an idiot. Your idea is stupid. We'll never do that. Go away."

Kinda makes one bitter, you know...

Re:Beggers can't be choosers

[mandolin]

I've tried the "ya know, this really needs changing, and here's a few reasons why..." approach. The response I've gotten was "No. You're an idiot. Your idea is stupid. We'll never do that. Go away."

Linus did this very thing to Andrea Arcangeli. Andrea's persistence eventually paid off.

I'm not saying Linus was right (and he's probably just as much of an asshole as he claims to be) but you can workaround the defects in the kernel developer foodchain if you keep plugging away and acquire better experience. The hard part of course is doing that instead of just saying "fuckit", which is what most sane people would do.

Re:Beggers can't be choosers

[fishbowl]

" I essentially said that if it wasn't addressed, I might consider moving to BeOS (which was looking very good to me at the time). "

So did the BeOS folks trip over themselves to address your individual wants and needs? Maybe Microsoft will do that?

Linux developers do not respond well to threats.

Re:Beggers can't be choosers

[DeathPenguin]

And if they fuck stab nVidia in the back, I'll be using the Win32 kernel.

Re:Beggers can't be choosers

[pclminion]

Why would the kernel developers deserve to be called that? They are developing a system that is intended for users whose primary interest is technical computing and computer science research. That the project has been successful enough to have merit in the network server market is just a perk.

The fact is, Linux has users whether the kernel developers like it or not. If they don't want to respond to user issues, they will drive away the user base. And without a user base, what is the point of this entire exercise? Fun?

Maybe I'm too idealistic, but I think the kernel developers, being in positions of power and respect, should be gracious to the user base. Regardless of their individual political and ethical motivations, they have a real base of millions of people depending on them, and they should at least acknowledge that without the users their own efforts are pointless...

Re:Beggers can't be choosers

[psamuels]

The "rant" was the result of me being extremely pissed. And I believe justifiably so. There was something in the kernel that Andre considered a "defect." He had a simple piece of code to fix it. The kernel people rejected this, because "in theory, someone can get around this, so there's no point plugging a hole which someone can reopen."

In theory? This was like setting a policy that if you sell a gun to an ex-con, it must be sold with the safety catch set. Sure, criminals can "in theory" turn off the safety themselves, but hey, it's better than nothing, right? At least "by default" they can't go out and start shooting people, right?

...Wait. Did you just call Andre's taskfile patch "simple"? Maybe you're one of those people who consider ACPI parsing "simple" too? Have you even read the patch, or was this just hearsay?

For those of you who weren't following along back then, Andre wanted to provide an ioctl-based way to run vendor-specific, often undocumented hard disk commands. This would be things like "make disk read-only" or "unlock extra 10 GB of space the firmware rounded down so they could sell those excess 40GB drives as 30GB" or such. Being vendor-specific and often undocumented commands, the applications that used them might be buggy and, if buggy enough, might be able to turn a hard disk into a paperweight.

The taskfile patch was intended to provide sanity checking in the kernel to guard against buggy applications. Of course, Andre being Andre, he didn't put it that way. By the time he was done yelling, it sounded as though EVIL HACKERS WILL DESTROY YOUR HARD DISKS IN THE BLINK OF AN EYE AND IT'LL BE ALL LINUX'S FAULT. Never mind that the EVIL HACKER already needs to crack root before he gets the necessary raw hard disk access. Never mind that the taskfile patch would not prevent the EVIL HACKER from bypassing the ioctl interface and bit-banging the ATA chip directly. Never mind that, as root, there are a lot of horrible things an EVIL HACKER could do to your system, much more insidious and EVIL than crashing a hard drive, like installing backdoors and making your system fail in subtle ways that you wouldn't notice for a month. Never mind that those same EVIL HACKERS have been able to destroy these same hard disks in any version of Linux or Windows since the beginning of time (well, the beginning of ATA hard disks with these command sets) and yet somehow, remarkably, we haven't yet heard of it being done.

And never mind the whole problem that if a buggy application can destroy your disk, so can a buggy taskfile patch. (Andre tends to exude an abnormally high level of confidence in the quality of his implementations.)

In short, at the risk of sounding like I know what I'm talking about, which I don't really, it was a stupid idea. At least as initially presented on the mailing list. Some time later, the startling revelation came out that the taskfile patch actually had some other uses besides the one listed above (protecting against EVIL HACKERS DESTROYING YOUR HARD DISKS AS YOU SLEEP). And then, marvel of marvels, Linus was suddenly a lot more sympathetic to the patch.

I made some remark about how it would boost user morale if the patch were in place, regardless of any real technical merit. I made some statement to the effect of, "You guys should care more about what the users want, even if you think you know better than them."

And that, at the risk of sounding like one of your alleged arrogant pricks on linux-kernel, is idiotic too. Hard to explain what's so utterly wrong with your statement - I guess it's just one of those things - if you have to ask, you'll never know. (Now how's that for elitist?...)

Derivative works.

[OoSync]

I think the position the kernel developers are in is determining exactly what is a derivative work. In any other GPL piece of code, if you muddle with the inner workings of the code, then your code is a derivative work and must also be GPL if you release it. Well, according to this article, most modules fiddle with the inner workings of the kernel in a very intimate way. The logic follows that such code is a derivative work (i.e. it has to use kernel code to do such things) and must be GPL, which binary-only modules violate. This isn't about doing away with binary-only modules, its about clarifying the Linux kernel's license and enforcing it. Binary-only modules can still run, they are just restricted in what interfaces they can use to communicate with the kernel instead of being on intimate terms with GPL modules. Sounds fair. Furthermore, its the *legal* thing to do.

As other posters have already specified, you can distribute your own kernel or patch that doesn't enforce the GPL license, but in doing so you may indeed be violating the GPL yourself. Remember, the GPL is like any other license, you must abide by it or lose the privelidge of using the software.

Also, this does not break userspace (i.e. proprietary and binary-only applications), unless such software is dependent on a binary-only module.

I, for one, am curious to see how those people who really want to distribute binary modules will react. I think many have a market in Linux systems and will continue to provide their code. However, they may be well-served to develop a GPL module that provides very consistent interfaces for binary-only modules. The kernel developers don't want to do this, but if developers of binary-only modules develop it and apply it, well that's their business.

Re:Derivative works.

[Dionysus]

Remember, the GPL is like any other license, you must abide by it or lose the privelidge of using the software.

Actually, no. GPL doesn't deal with use at all, only with distribution.

Multibillion dollar business

[nuggz]

And that multibillion dollar business can't find a handful of guys to make their own kernel.
I don't think kernel developers are _that_ expensive

Re:the mighty slashdot effect killed TinyMinds

[dubious9]

Jesus, give me some whitespace! At least a
here and there.

See how nice this looks?

Even if you make good points, nobody is going to read a long post with no whitespace.

Drivers please

[visualight]

When a new product comes out on the market, the box almost always includes a cd with a windows driver on it. That driver is written and supported by the manufacturer of the product.

I love linux but I want so bad to be able to buy the latest neates thing and have it just work right away in linux and not a year later. Right now I have a radeon 9000 pro and a wintv pvr 250 I'm struggling with.

Drivers are the ONLY issue I have with linux and because of that I'm trying to learn C but I have so far to go and in the meantime I have to just be patient and wait for the vendor to produce a driver or for some linux developer go buy the same card I have and make it work. That's all fine and dandy except for this one thing: Some of these kernel developers are PAID to develop the linux kernel. That's right, it's their JOB. Not to show any disrespect to those kind hearted souls who sacrifice their spare time to do a community service, but as an enduser who has paid far far more for linux distro's than I ever would have paid if I was using Windows I have a right to insist on support for ME the end user. I have purchased Redhat 7.1, Mandrake 8.2,9.0 and every Suse since 6.2. It's my opinion that the kernel developer employed by the distro's have an obligation to develop the linux kernel with me in mind. And I want drivers. I don't care if they're GPL or not. I want hardware vendors to write the driver for the hardware they sell and distribute that driver WITH the hardware. And I want that driver to just work. That means the linux kernel must allow it to work. Politics and personal philosophy regarding open source have nothing to do with the discussion. I'm a paying customer and I should be treated that way.

Re:Drivers please

[mcelrath]

That driver is written and supported by the manufacturer of the product.

This is almost universally a bad way to do it. It results in crappy drivers and poor user support (companies only want to sell you shit...after you buy it they don't really care if you can't get the driver to work). This is the source of 99% of the instability of Windoze...crappy drivers that bring the system down.

Back in the day there was this company called WordPerfect. Their schtick was that there were thousands of printers, but no universal way to get shit printed. So they wrote printer drivers, for all of them, and they were fantastic. WordPerfect quickly took over the market because they wrote printer drivers. They knew how the printers would be used and figured the best way to access them, and were motivated to maintain the whole base of drivers.

Open source drivers are much the same way. Owners of hardware have a pretty serious motivation to make the drivers work. You also get higher quality drivers because of the many-eyeball effect. The best situation for customers and companies alike is for the companies to release a "beta" driver, detailed specs, and hire one guy to coordinate work on the driver. Then let the thing evolve. It's the beauty of the source.

"Source code is like manure, if you spread it around things grow. If you hoarde it, it just smells bad."

-- Bob

Re:Drivers please

[visualight]

Somehow my point went right over your head didn't it? My post wasn't so much about the radeon 9000 or about the wintv card. Let me try again:

Good luck telling people like Alan Cox that. They could care less about what you think. In fact I'm pretty sure they have never cared for what people like you think. They care about only one thing, and that is pushing out an open source kernel. So far they've done a pretty good job at it IMHO.

So stop your bitching,
Sunny Dubey

First off Alan Cox seems like a pretty decent guy from what I've read and I think he does care what user's think, even one user.
Second, the whole point of my post is "I pay, I get to bitch, period." No one has to pay attention to what I say or change their behavior/priorities because of it, but I still get to do it.
You need to get the "if it's open source you don't get to complaing about it" idea right out of your head. This is no longer a hobby dude. It's a business. That means customer service issues fucking matter.

bitch.

Re:Drivers please

[FamedLamer]

Oh please dear god make it stop.

Why are you using Linux if IT DOES NOT WORK FOR YOU?

Obviously, you just enjoy having something to be mad about. If Windows works, use that. If DOS works, by all means, USE THAT. If a hobby-OS (dare I say it? Yes! A KERNEL WITH SOME STUFF) does not meet your needs, stop whining and use something else. I don't see anyone in Home Depot demanding a full refund for the hammer they bought last week because it wont turn screws. Use the tool the fits the job or find another job to do.

Linux is a kernel. Its developed by people who just want to develop a kernel. Red Hat, Mandrake, and all those are Corporations who are feeding the world garbage, and then selling them more garbage to go with it (but hey, it comes with support!).

As said before, after all this time, you people STILL dont GET Linux.

Re:Drivers please

[Cyno]

I never fully understood the bias against binary drivers until I read this article, if its the same one I read earlier. In it they mentioned that binary kernel modules have access to override system calls as well as make use of GPL system calls, etc. The recent changes will prevent this from happening in the future by limitting the access non-GPL drivers have, limitting which system calls they care override, etc. Security, especially against close-source commercial software that may not have my best interests at heart, makes me happy. I love linux. :)

Re:Drivers please

[visualight]

Hey, read my post again. I said drivers are the only problem I have with linux.

I use linux because I like it. Maybe you use it because of some personal philosophy or a political agenda, it sounds like it.

Question - Is linux an OS or a concept? Maybe you should consider things like who the hell are "you people" and what the hell makes you think you're not one of them? In other words YOU are not on the inside of this "linux" thing so that you get to say things like "you people". It's a group thing, and there is NO demarcation line of inside and outside. Merely going to CompUSA and buying a distro, hell even downloading one for free puts you in the group.

My post is an opinion (maybe a rant, but this isn't a dev mailing list, it's /. for chrissakes). No one has to listen to my opinion, but I get to have one.

FWIW, I don't have something to be mad about, but I do get tired of the linux is a gift attitude. It is NOT as you called it, a hobby O/S. It's a business and people are paid salaries to develop it. Oh, I "get" the linux community, open source community, gift economy whatever concept. But things are different now and there doesn't seem to be enough people (you) who realize it.

Re:Drivers please

[MyHair]

Not to show any disrespect to those kind hearted souls who sacrifice their spare time to do a community service, but as an enduser who has paid far far more for linux distro's than I ever would have paid if I was using Windows I have a right to insist on support for ME the end user. I have purchased Redhat 7.1, Mandrake 8.2,9.0 and every Suse since 6.2. It's my opinion that the kernel developer employed by the distro's have an obligation to develop the linux kernel with me in mind.

Dude, thanks for paying for GNU/Linux.

But think about this: You paid roughly US$60 a version for: An OS, a GUI, three office suites, two professional databases (mySQL & PostgreSQL), a production-grade web server, a development suite for C, C++, Objective C, FORTRAN, Pascal (I think, or maybe there's just a Pascal->C converter), PERL, Python and God knows what other languages I forgot, a POSIX-compliant set of libraries and network daemons, IPv6 and IPsec support. Etc., etc., etc.. Try buying all that from Microsoft and it will cost you more than $60 per upgrade.

Anyway, you're not paying every contributor to the code off all the products, and you're not even paying every kernel developer. You're paying mostly packaging, warehousing and shipping plus a couple of markups and then the software package maintainers that make sure the distribution runs smoothly as packaged. If the provided app packages conflict with each other, then yeah you're entitled to support from Suse or whoever, but if you think $60 every few months entitles you to having the kernel developers reverse-engineer and scratch-write drivers for your new hardware, look them up and email them; I'm sure they'll be happy to hear from you.

By the way I like ATI for Linux; I just buy an older card that I know has good open source Linux drivers. (Yeah ATI may have some binary ones, but I know the open source ones will be around as long as my card is working.)

Re:Drivers please

[praedor]

So you'd THINK. But you are wrong. The opensource drivers for ATI cards suck. Period. The cards perform midlin, barely work with the OSS Mesa OpenGL libs (I have had GPL-supported ATI Radeons and experienced their broken-ness first hand). I have since gone to NVidia and their closed drivers - and it works FAR better than the Radeon with its oh-so-wonderful GPL drivers. The binary drivers are also STILL superior to the GPL Nvidia drivers. That is a fact, I am afraid.

I don't give a rat for how the driver is made or developed so long as it works. It would be NICE for Nvidia to publish their specs enough to allow for decent open drivers (just to ensure continued support if they drop out of the linux driver business) but they MUST protect their legit property (their hardware). In any case, and I reiterate, the GPL Radeon drivers STINK! The Nvidia GPL driver STINKS! If GPL is so great at this why DO they stink then?

This is kind of funny and pathetic. Just as linux is taking off, it seems the kernel developers, over philosphical nonsense, have decided to shoot linux in the face and try to drive it back into obscurity.

So long as my Nvidia card keeps working WELL, then I don't mind, but screw that up, prevent people from properly using THE best video card on the market, and you kill linux's growth.

Re:Drivers please

[Abcd1234]

Bah, clearly you don't get the Linux community/OSS concept at all! The vast majority of people who develop Linux or software for the OSes it's based on are not paid. Moreover, you an quite easily download Linux *for free* from any number of FTP sites. How can you not consider this a gift? The only reason this whole "Linux thing" is viewed as a business is because some companies decided that they could package up Linux (written by people who aren't compensated) with a bunch of applications (also written by people who aren't compensated) and sell it to users who can't download it themselves.

Unfortunately, you'll never really understand this whole Linux thing until you become a developer/contributor, and actually spend *your* free time developing something and distributing it for free, just because you want to. Once you've done that, you'll realize what a generous gift Linux really is, and how you are not, in fact, owed *anything* by the developers. Hell, you should be thanking them for doing what work they have (for free) to allow Linux to exist in them form we have it today.

Now, if you feel your distribution maintainers owe you some support, fine. You paid them, so complain to them. But the guys in the trenches, the ones writing the code, are by and large doing it for nothing. Yes, there is the odd man out getting paid for it, but they are definitely in the minority. So, unless you want to send these kind people money directly, thereby obligating them to help you out, I suggest you re-evaluate your position on this whole open-source thing.

Re:Drivers please

[dvdeug]

they MUST protect their legit property (their hardware).

At best, you could argue that they should protect thier legit property; they are under no obligation to do so. It also does not follow the best way to protect the value of their property is by only releasing binary drivers.

the kernel developers, over philosphical nonsense, have decided to shoot linux in the face and try to drive it back into obscurity.

So some hardware doesn't run with Linux because the hardware company isn't willing to work with Linux people in supporting it. Boo-hoo. You should buy your hardware, keeping in mind what you want to do with it. If you want to use Linux, then buy a card that works well with Linux.

Re:Drivers please

[mcelrath]

You obviously haven't tried ALSA lately. It simply fucking rocks.

-- Bob

Re:Drivers please

[mcelrath]

The single best thing you can have for good drivers is a group of dedicated people working on the driver, with proper access to the specifications of the device. This is the primary reason why you see the variation in the drivers, not the GPL. Given two driver development groups where everything else is equal, the GPL'ed driver will quickly be superior, and it will outlive its binary counterpart.

Of course, there's also the fact that large parts of the ATI specs are not ever going to be released to the OSS community, so there's no way they could write a really fast driver... (from what I've heard)

-- Bob

Re:Drivers please

[praedor]

As I understand it, NVidia isn't exactly free to release everything necessary for coders to produce an equivalently performing driver to the binary NVidia driver. So, they do not fully control the situation so they are evil because they don't violate the law and give up someone else's IP? Like or hate IP, it is a current legal reality and you cannot blow it off and pretend it doesn't apply.

As I understand it as well, ATI has released everything needed for driver development of their cards (for the most part, perhaps they are also not quite free to provide all pertinent info?) and that is the driver used by ATI card owners. But it STINKS. Prone to system lockups and X crashing. I had a radeon using the GPL drivers and this is what I experienced again and again. This is why I HAD to go with an NVidia card (and its binary driver) because I need my video card to work. Period. Guess what? It does. I never experience any of the problems I had with my Radeon.

Now just for the sake of argument here, if this is what GPL hardware drivers do then we can do without them. They may be great for non-3d accelerated vidcards, but they appear in practice to suck hard in the physical world. Be nice if it wasn't the truth but it is and not everyone can sit around waiting for a day when they wont suck. Many need their hardware to work right this instant.

The argument is moot in any case, if it is true that Nvidia binary drivers will still work with the new kernel changes. Not so sure how big shops with expensive software that breaks will feel about it but that isn't me.

Re:Drivers please

[dvdeug]

they do not fully control the situation so they are evil

I never said evil. But giving up control over a situation is always a perilous decision, and I don't see why I should have mercy on them because they made some wrong decisions.

Now just for the sake of argument here

Just for the sake of argument, you want me to take one case favorable to you and massively generalize it? Man, I wish I could have gotten away with that in debate.

I had a radeon using the GPL drivers and this is what I experienced again and again.

And I take it you filed a bug report? Because it's considered tacky to trash Free software if you didn't bother to file a bug report.

they appear in practice to suck hard in the physical world.

So 3d-accelerated video cards is the physical world? Not mice, or keyboards, or RAID cards, or SCSI adaptors? Just 3d-accelerated video cards?

It'd help if you stopped with the rhetoric.

Re:Drivers please

[praedor]

No, not mice, keyboards, etc, because 3D accelerators are more complex than any of these and thus prone to problems. Sorry, never EVER had a mouse driver or keyboard driver lockup my system. They are relatively simple devices. Not so with 3D cards of today which are practically computers in their own right.

Wow

[MeanMF]

Most observers foresee a tightening of the limits on binary modules. This may very well break some rather expensive commercial Linux products, but that doesn't seem to bother most kernel developers.

Can you imagine the magnitude of the sh*tstorm they would create if Microsoft tried to pull something like this?? That's a pretty ballsy move for people who rely on the good will of the companies developing software for their platform.

Re:Wow

[Doppleganger]

Of course, Microsoft has *never* made changes that broke commercial windows products...

*glances at the cd rack with quite a few games that stopped working after Win95...*

Binary modules can still be used.

[cureless]

I've seen quite a few posts that seem to imply that binary modules cannot be used with the new kernel. That is not true.

What is true is that they are doing things like not exporting the system call table so that any module can change it at their will. That is, a binary module can't replace the write call or fork call. There are other mechanisms like syscall registering for modules that need some new system call. (I haven't looked into that aspect yet).

What they are doing is not encouraging binary only modules. (and by binary I mean non GPL). The example they use is the modification of work queues. Things like tainting the kernel (so the kernel knows when it's been tampered with by proprietary code (read loaded a non GPL module)) have been around for a while now. Kernel people will not give support to problems with tainted kernels.

I use and nvidia driver in one of my computers, and that taints my kernel. I understand the implications. I also see no reason why nvidia has to modify my syscall table.

In short, I don't think normal "drivers" need to modify the syscall table. You can add a new filesystem, network protocol, etc without the need to modify the syscall table. So stop complaining about no more binary only drivers.

I agree with the developers in the choice. I also wish nVidia, along with the other companies, GPLed their drivers. After all, they are _drivers_ for the hardware I bought. And if they don't want to, they could at least release the complete specifications for the hardware so we can build our own 3D accelerated drivers.

cl

Re:Perhaps now

[meshko]

You are wrong when portraing the fact that you can still run Corel 3.0 as a plus. Windows is paying a huge price for maintaining backwards compatibility, it is really hurting the operating system and especially the developers who develop for Windows. The fact that Linux kernel changes the APIs often and does not have backward compatibility is is well-compensated by the fact that all the interface changes are completely transparent and has the advantage of preventing drivers bit rot (among others).

Open discussion.

[OoSync]

Its also important to realize that the methods being used to enforce the GPL in the kernel have been developed completely in the open. If binary-only module developers are having problems with this, have they spoken out, have they said anything, does this really affect them much? I've not seen much of a discussion of this on Kernel Traffic, except that the Linux kernel developers don't feel its their business to make concessions for binary-only modules.

As for arrogance, they're enforcing the license on their product. Microsoft would do the same for their products if your code massages their code without abiding by their license.

BTW, this sounds like an idea for Ask Slashdot. Get someone developing the Linux/BSD drivers from nVidia to answer questions about this and find out if it really is a problem, or if /. readers are just gettting huffy for no real reason.

Re:What is a Winmodem?

[glebfrank]

You're missing the point. He already has one built into his laptop. He has no problem with the existing (binary) driver. What does your rant about how bad winmodems are have to do with anything?

Binary-only restrictions

[karlm]

Each kernel module declairs what liscence it falls under. More symbols are exported for Free modules.

Nobody is preventing NVidia from writing binary-only drivers, they just need to hook into the kernel at lower levels. Some kernel developers want the NVidia people to mooch less.

They're tightening restrictions, not banning binary-only modules. Relax. They're just saying if NVidia wants to use binary-only modules, that's thier perogative, but it's a huge pain for the developers that become de facto support for those NVidia drivers. Basically "You want to be a pain in my ass, go ahead, but you're now getting less help from me to do it."

The *BSD kernels are simpler and may not have equivalents to the special higher-level functions that are being hidden from non-Free modules. I don't know. In any case, it's unlikely NVidia is going to jump ship for one of the *BSDs. I'm not even surewhat companies hope to achieve by providing binary-only drivers. Thier competitors certainly have decompilers. If they really need to protect patented algorithms, that can be done in firmware/hardware and/or usermode drivers. Usermode drivers also prevent binary-only kernel instabilities and reduce kernel dependancies.

Re:Binary-only restrictions

[DeathPenguin]

As if it weren't already a stretch for the community to ask commercial developers to make drivers with performance and functionality on-par with their Win32 counterparts. Now the developers want to put that at risk by making it even more difficult for commercial developers to write good drivers? I'm awe-struck.

As an anonymous reader already pointed out, hardware companies do not feel they need to support Linux as well as they support Windows. Making Linux support more difficult is just going to alienate desperately needed supporters. I admire the idealism, but let's be realistic. If anything, the kernel devs should be making stride to accomodate binary module writers, especially those with good drivers to contribute.

Re:Binary-only restrictions

[mr3038]

They're tightening restrictions, not banning binary-only modules.

This sure is not the way to ensure broad hardware support and acceptance. Believe it or not, hardware companies do not feel the same need to support linux as they do windows, and making the platform hostle isn't going to win anyone over. (emphasis mine)

IMO, the value on the stuff they sell should be on hardware. A good example for this is so called "winmodems" which, in worst case, contain only minimum hardware required to connect phone cord to the PC and all the logic is done in the drivers. In this case selling the stuff as "hardware" is misleading and I understand fully if the manufacturer doesn't want to release full source code. Stuff like this should be sold as software and I think kernel should include API to allow running this kind of software if commercial software is allowed to be run in user mode. However, this kind of software doesn't need to mess with syscall table and stuff so I think current restrictions given to binary drivers should be kept in the future too.

On the other hand, if the manufacturer is selling real hardware then writing the driver is only pain in the ass and I cannot imagine any reason not to open spec to the hardware interface. After that, many manufacturers doing cool stuff could get drivers for their products for practically free by giving out a piece of hardware to some known open source developer. If that piece of hardware is worth the money, one could be pretty sure that GPLed version of the driver ends up to the kernel distribution and manufacturer doesn't have to pay anybody to be able to support linux.

That being said, I must add that even though I think that nVidia does some pretty awesome hardware they also do some hairy tricks to speed up the driver and other display adapter manufactures would love to use those tricks too. When the driver must do stuff like full OpenGL support I'd allow doing that in proprietary format. Though, nVidia should probably do proprietary stuff in the user mode and keep kernel mode driver part open, though.

The software is still free

[Chuck Chunder]

If (and when) Microsoft do this it's significantly worse because they have total control of their operating system.

If the changes the Linux folk are making are indeed heinous then any one of us is permitted to fork if we so desire. With MS it would be all or nothing. With Linux if you don't like what you're being offered you can change it if you want to.

Presumed guilty? No, just guilty

[marm]

This is just another facet of the kernel developers' jihad against binary modules. Presumption of guilt does not imply bad code, it implies prejudice(*).

Recent drivers are better than they used to be, but the nvidia kernel module really, genuinely has had a LOT of problems. I have a machine with a Geforce2 that will stay up for months when using the open-source nv XFree86 driver (which uses no in-kernel code at all), but using the nvidia binary drivers oopsed at least once a day with random memory management errors and would freeze hard about once every 3-4 days. It finally seems to be fixed in the most recent release of the binary drivers. And let's not even go anywhere near AGP support - even with the most recent drivers, if I leave the AGP support on I am guaranteed a wedged machine within 5 minutes of starting X, whether I tell the driver to use the kernel or its own agpgart support. I'm not using weird hardware either - this is a PIII Abit motherboard with Intel BX chipset - about as standard as you can get. The card is flawless in Win2k with AGP on, again using the nvidia reference drivers. If I swap the Geforce2 out for the old Rage128 I have lying about, that works flawlessly in Linux too, 3D, AGP and all, but it's a lot slower than the Geforce. Oh, and I'm using stock Linux kernels, no distro-specific stuff or strange patches. The only option that I could see in the kernel that might make a difference is using the local APIC on the PIII as opposed to using the XT-PIC, as this can mess with the interrupt delivery timings and delivering an interrupt which the driver isn't expecting might wedge it, but I tried it both ways with the same results. It ought to just work though, right?

Therfore, the only conclusion that I can draw is that the nvidia Linux binary driver is buggy, particularly with regard to its handling of AGP. I don't think I'm alone in reaching this conclusion either - I have heard plenty of fairly similar bug reports. I can't begin to debug it myself because I don't have the source to the nvidia driver. I've reported it to nvidia. I haven't bothered pestering the kernel developers with it because it's plainly not their fault and there is nothing they can do to rectify the situation.

I admit I've not tried it in another motherboard, but why then does it work in Win2k flawlessly? Ok, Win2k is also using binary drivers - but then, when was the last time you mailed an NT kernel developer with a driver bug report? You don't, you mail the driver developer if they give you an address or simply sit tight if you don't have one. That's all the Linux developers are asking too.

Put simply, the reason the Linux kernel developers tell you to piss off if you're using the nvidia binary driver is because 99% of the time that is the problem, and if you're too stupid to be able to realise that and attempt to reproduce it without the nvidia driver loaded, then you're too stupid to provide a decent bug report and your mail might as well go straight to /dev/null. Most kernel developers are drowning alive in email as it is, and that's email that's got useful stuff in it. They have better things to do, like fixing bugs in code that they have the possibility to fix.

(*) Please don't flame me for calling Linus a racist.

I'm not. I'm flaming you for being stupid and not understanding the issues involved.

Re:Perhaps now

[TheAwfulTruth]

Would you care to elaborate on your "out of the ass" phrase "Windows is paying a huge price for backwards compatibility"? In fact Windows is paying a very small price. In fact the ability to run DOS or Win16 executables is also a very very small price.

The way it looks to me is that ALL of Linux pays a very large price for this constantly moving target of Kernel and GUI API changes. Not to mention constant and complex liscencing issues. The original user was right. MS makes it easy on both the user and the developer. Linux is extremely hostle to both. I mean the facts speak for themselves. Whitness the graveyard of quality user-level Apps on linux Vs Windows or Mac. It's been going on for over a decade and it still show no sign of changing. If Linux is to compete at all, then it can't go on as it has been.

Not good from a strict GPL standpoint

[Wateshay]

A lot of people are complaining that the new binary module licensing changes are too restrictive, and reduce people's freedom when writing drivers (and I won't argue with that). Something else to think about, though, is whether the new changes are really the best thing to do from a purely GPL standpoint, where the end goal is to have as much software as possibly be free. As the GNU project points out in their discussions on licenses, it is sometimes a better idea to allow binary software. There are other operating systems than Linux (I hear there's a company in Redmond that makes one that's quite popular). If Linux discourages or forbids binary only drivers, the driver manufacturers won't make drivers for Linux (since, in many cases, they are bound by licenses that won't allow them to release open source drivers). If Linux doesn't have hardware support, then fewer people will be willing to use it, and thus fewer software companies will release Linux versions of their software. So far, Linux hardware support has been very good, but slow. New devices are often poorly supported. However, commercial drivers (binary and open source) have been starting to gain momentum, new hardware is more likely to have support, often from the manufacturers of the hardware themselves. I hope that the new 2.6 kernel won't stall that advancement, and seriously slow widespread adoption of Linux as a viable OS.

Re:Not good from a strict GPL standpoint

[DeathPenguin]

>> If Linux discourages or forbids binary only drivers, the driver manufacturers won't make drivers for Linux (since, in many cases, they are bound by licenses that won't allow them to release open source drivers).

Exactly. This is especially true with video cards.

Re:Pre-emptive Kernel?

[mccalli]

Omigod, they've reinvented Mac OS 9!

Err....pre-emptive is exactly what MacOS wasn't. It used co-operative multitasking - you called the yield() function every so often to ensure that other processes had a decent slice of the action.

Cheers,
Ian

What the hell are they thinking???

[DeathPenguin]

No binary modules? What self-rightous idiot thought of that? That would alienate all major support for video cards. For all you purists, get it through your thick skulls: Patents exist on OpenGL and many other technologies (Such as S3TC) that are required for many applications (Such as Unreal Tournament 2003). Check other threads with nVidia-related information and you'll find more detailed information on nVidia / SGI / Microsoft / etc. patents on widely used industry standard OpenGL technologies.

And besides, imagine the hypocrisy of the Linux kernel devs taking away choices from the people that use their kernel. I mean, I thought Linux was supposed to be for people who actually wanted control over what goes into their kernel.

Re:What the hell are they thinking???

[DeathPenguin]

>>Hey, here's a suggestion: Why don't you read the article again? Who mentioned no binary modules?

Second sentence in the last paragraph on the first page:
"This may very well break some rather expensive commercial Linux products, but that doesn't seem to bother most kernel developers."

Ok, it doesn't say "no" binary drivers. But to "break some" certainly doesn't imply full functionality and compatibility now does it?

>>Restrictions are not exclusions.

Perhaps not, but they're a pain in the ass that I believe will make Linux support less worthwhile for companies who actually have to pay people to write drivers.

>>Those patents are ridiculous - they don't provide differentiation, don't protect hardware secrets, and should be pressured into release.

By a bunch of ungreatful pissants who probably aren't doing much for anyone's bottom line anyway? Riiigghht.

Re:What the hell are they thinking???

[dvdeug]

Patents exist on [...]

And what's the first thing you have to do with a patent? You publish the details of how it works! What's the point of keeping it hidden, if you've already revealed it, and have the law keeping people from using it without your permission?

the hypocrisy of the Linux kernel devs taking away choices from the people that use their kernel.

This isn't BSD; there have always been restrictions on the use of Linux, in order to encourage people to share their changes back with Linux, instead of every two-bit propretary distribution having their own secret patches.

Indeed, but the difference I am trying to show

[Chuck Chunder]

Is that if MS make such a policy change they are dictating to everyone as no-one else has the rights required to forge another route, it's their way or the highway

No one is in such a forced dependancy relationship with the Kernel developers. We may depend upon them by choice, but if what they do really is seen as unacceptable then the rights given to us all by the kernel licence protect us from being completely at their whim.

Question for Scheduling Knowledgeables

[ender's_shadow]

"Fundamentally this is a simple change but it requires a large-scale reimplementation of code to protect concurrency. Thankfully, the kernel's SMP spin locks already provide the large majority of this protection. So these spin locks are used as markers of where to temporarily disable preemption, to avoid mangling shared data. It works and everyone is happy."

Is this a hack? It sounds like a workaround, but maybe it's just creative use of existing tools.

Can anyone tell me if this is how other systems do preemptive multitasking? I really don't know. Is this similar or analogous to Intel's new chip that acts like a multiprocessor?

Agh no.

[TheLink]

"I think hackers in general really need to work on getting their ideas across to the more average person, otherwise most people have no reason to get excited by new releases unless they enjoy growing numbers!"

Why should the average person be excited about new kernel releases? That sounds like Marketing Department talk to me.

Marketing people love trying to get the average people excited by inventing new symbols/acronyms for them - e.g. Quantispeed, PMPO.

As far as I can see, those who need to be excited have no difficulty understanding what the new features mean to them - better threads, better scheduler.

As a tech person I prefer a situation where if I don't understand something, it is actually something new to learn, NOT some stupid bullshit or LIE Marketing thought of.

Yes I know there may be cases where even the average tech person doesn't know what the developers are doing. But often that's a transitional case - maybe the developers aren't sure either - changing/testing stuff. And in other cases the average tech person doesn't need to know either. For example: if the developers do most of their stuff correctly, we won't need to know what a particular lock is for. Coz the reason why we would ask, probably means they screwed up somewhere: deadlock.

Re:Agh no.

[Telex4]

"Why should the average person be excited about new kernel releases? That sounds like Marketing Department talk to me."

If you're using an operating system, and the core component has a major new version released, you'd be interested to hear what it has over previous versions before you think about upgrading. To non-tech people that means a clear and simple explanation of what the changes are (not some market-droid nonsense). At the moment, tech people like us get the opportunity to learn our way into finding these things out. Not everybody can do this.

Re:Agh no.

[TheLink]

I still don't see why the average person should upgrade his/her kernel on a major kernel release.

Let Suse, Debian and Redhat tell the average people why they should upgrade their O/S or components of it. Without marketdroidisms hopefully. No need for kernel developers to do that.

average person distro kernel developers.

This would in fact save the average person a lot of trouble. The distros do the regression testing, custom patching etc, to make sure crap like 2.4.x-2.4.y doesn't hit/hurt the users too badly. Some distros did a pretty decent job despite the various kernel disasters.

The average person probably doesn't want to know. They'd probably prefer their box prompts them and updates itself for critical updates.

Clean up help, and group by function

[mindslip]

I'd love to see a kernel release with *complete* help and descriptions in the "make Menuconfig" system.

It's trivial to power users, but you've got to remember that a "serious" Linux newbie will get a lot of knowledge by playing with, and compiling, new kernels.

To truly understand what each feature does, the first place they usually look is in the "Help" button in Menuconfig. Not in the Readme's, and certainly not in the code.

If we actually make these help screens useful, and a little less condescending ("If you don't know what this does, say N here") we'd make the learning curve less steep.

It would also be nice to see a little more grouping by functionality. USB is a good example... it's a logical grouping by type of device. Perhaps though, USB, PCMCIA, etc. could be under "Removable hardware" (again, for the newbie and for ease of use) while network shaping could be under just that, and shaping/drivers/network file systems, etc. could all be under "network".

Trivial to you and I, but really important to the one group of people who count most: Future power users.

mindslip.

Stable API

[guacamole]

Why can't Liunx kernel developers come up with an API for binary kernel modules and keep it stable at least between minor kernel releases so that users could use third party kernel modules withfout having to recompile them for each kernel upgrade?

Look at Solaris. It's quite possible to take even certain kernel modules that were built for Solaris 2.6 and use them on Solaris 8 without recompiling. I am not even mentioning that kernel modules don't break at all between minor kernel releases (or patch levels) on Solaris.

Re:Stable API

[DarkMan]

They have an API (Application Programming Interface).

However, what your asking for is an ABI (Application Binary interface). That requires explict consideration of the compiled code, as wel as the source. The Developers don't want to do that, in addition to all that they currently do, because the only gain is for binary only modules.

It is possible, but take effort. No one either a) wants to do it, or b) is getting paid to do it.

Linus wouldn't include any such work anyway, so you'd have to host your own kernel.

Re:Stable API

[psamuels]

Why can't Liunx kernel developers come up with an API for binary kernel modules and keep it stable at least between minor kernel releases so that users could use third party kernel modules withfout having to recompile them for each kernel upgrade?

They could - but it's not worth it. This may sound heartless, but there are tradeoffs involved. To fix Bug Foo, you can either (a) apply a band-aid fix that maintains full backward compatibility, but looks ugly, sacrifices a tiny amount of performance, and possibly hides other bugs ... or (b) rethink the design and update the various bits in the kernel that use the old design - thereby breaking any external module that happens to rely on the same old design. (Scenario exaggerated a bit.) So which do you do?

If you're a Windows kernel programmer, you almost always do (a). There is a large customer base that rely on the ability to use third-party drivers seamlessly and cannot be depended on to even have a C compiler available (since you didn't bundle one with your OS!) and backward compatibility is paramount.

If you're working on AIX or Solaris, you usually to (a), but probably not always. Once again, customers are depending on this, and the culture is that black-box kernel modules are OK, because the kernel itself is a black box so who cares anyway. Device drivers aren't a biggie because the hardware is vertically integrated, typically - but Oracle for example ships a couple of AIX kernel modules that provide facilities for application-specific optimisations.

On Linux, it depends on the development cycle. Between stable series, they almost always go with (b), because great importance is attached to clean code, clean design, and minimal baggage. Within a stable series, sometimes option (a) is better in that it is often a less invasive change with less short-term potential for causing other bugs. However, unlike AIX, Solaris or Windows, Linux has a userbase accustomed to having a C compiler installed, and accustomed to having kernel source available. Thus, since we all treat the kernel as the open book it is, we are much less tolerant of other core components being binary-only than are users of other platforms. Besides, the driver support that ships directly with the Linux kernel is second only to Microsoft's - the commercial Unix vendors don't even come close - and in many cases Linux ships with a driver for something Windows doesn't. (Microsoft can get away with this because for anything they don't directly support, they can count on the hardware vendor providing a driver.)

In any case, since almost all of the core of a typical Linux installation is free software, there is little need to be overly concerned with the needs of those hardware and software vendors unwilling to play the game. In other words, the fact that source is almost all freely available gives the developers the freedom to fix things correctly rather than concentrating on minimal ABI disruption.

Contrary to popular Slashdot opinion, this attitude quite often actually helps the Linux driver scene: vendors who try providing closed-source drivers for their hardware often see that this is a losing and pointless game, and open up their specs and/or their in-house drivers. For each hardware vendor you name that has been driven away from Linux by the hassle of binary module support, I can name several that either provide and support open source drivers on their own dime, or at least give out spec sheets and answer questions in a semi-cooperative manner.

It is a curious fact of life that many companies, given the choice, will keep their driver (and other) source locked away as tightly as possible ... but if you hold a hard line and say "open source or else suffer various support headaches with closed source" they figure out a way to make it happen. Even the reviled NVidia did this once upon a time, back in '96 or so - after much wrangling they donated a Riva TNT driver to XFree86. (That was a fiasco at first. They initially released obfuscated source code - that is, partially preprocessed code that was intentionally difficult to read in certain places - but later rectified this by posting their "real" source. Speculation at the time was that the obfuscation was done to hide evidence: a major competitor (3Dfx? I can't remember now) had sued them for theft of IP and the suit was still in progress.)

nvidia drivers

[antistuff]

The kernal part of the nvidia drivers are provided in source code form and wont be affected. The proprietary part is the X11 drivers.

Sorry if this is redunent as far as I read nobody brought this up.

Re:Free Software for hardware?

[tempfile]

It's not only not wise for ATI & NVidia to put out GPL drivers, it's nearly impossible. The trade secrets you mentiond are often enough third-party licensed features. S3TC is an example. The licensors would simply not allow to have their code released under GPL, even if NVidia wanted.

As a libertarian...

[squarooticus]

...I'm waiting with some amusement for calls to nationalize the Linux source code and imprison the current kernel developers.

"It doesn't matter if it's someone's homebrew project: simply by virtue of distributing it and acting like they had over the prior 10 years, they lulled us into a false sense of security. Then, WHAM! Bait and switch."

"We the users should have full rights over the development of this kernel. After all, this is a public works project."

"Linus, Alan, and everyone else use the roads to get to work, right? Or, if not, they buy food that is transported by the roads. Or, if not, they enjoy the smell of the asphalt. In any event, they are enjoying a public resource, which means we all have a right to the fruits of their labor."

I laugh whenever I hear these arguments applied to anything. I truly hope you're laughing to hear these arguments applied to Linux.

Works both ways, don't you think?

[Walles]

So the Linux kernel sometimes break compatibility with proprietary kernel modules. This is arrogant.

Companies sometimes write binary modules that work only with one exact version of the kernel for one architecture, thus preventing their customers from upgrading both their OS and hardware.

How is this any better? Why pick on the kernel developers but not on the binary modules creators?

Kernel hacking, and hardware sales models

[phorm]

Last time I checked there were a lot of wrappers for kernel compiling that made it somewhat simple, except for checking for things like your boot-loader would fine the new kernel, etc - which some people overlook. Is it simple a disable option... allow_binary_kernel_linkage etc?

Some people whine that they would like the source so they could mod their video card properties, but it's still a hell of a lot better than having no driver at all, for which many more people will whine unless they cannot get their video card to work without going through a huge hassle.

Then we have people whining about how the binaries can violate GPL. But maybe we need a clause for video drivers.
If the drivers are released as free to the public - not with source, but without cost, then that would make 90% of the users happy.

You also have to consider that things like video cards don't work exactly like software from a marketing perspective. Software like mySQL etc can market their troubleshooting and/or programming, as well as enhanced-feature licenses while still making their base-produce free and open source.

How many people would pay for a troubleshooting contract for a video card brand? The profit is in the sales, and the sales are based on that it works. I know very few people who would begrudge NVidea for releasing compatible drivers, even if they are only binaries. Making the hardware work is one more step towards making linux a more accepted o/s, and that's a good thing!

Re:17 people will install 2.6

[Abcd1234]

Umm... who said *any* of the kernel developers "dream of the average person using this OS"? There are certainly a lot of people up on soap-boxes about this particular issue, but I've never once heard, for example, Linus push this view. I know I couldn't care less if Linux was on every desktop. As a developer and general powe-user, it works great for me, and that's what matters.

Long-Winded Explanation of Preempt Mode

[psamuels]

Is this a hack? It sounds like a workaround, but maybe it's just creative use of existing tools.

Creative use of existing tools.

It sounds like you're a little confused about what preempt mode is and isn't. So here goes - HTH. It isn't the ability to preempt a running job in favor of scheduling a new job. That's called "preemptive multitasking", and Linux has had it since Day 1. It also isn't multiprocessing - running multiple jobs simultaneously via multiple CPUs. Linux has had that since, oh, 1995, I think (kernel 2.0).

Preemption, in this context, means interrupting one job to schedule another while the first job is busy running something within the kernel itself. You see, most processes ("jobs") run part of the time in user space where they are executing their own instruction streams, and part of the time in kernel space where the kernel is working on their behalf - reading disk files, sending messages to other processes, etc. Now, while the process is in user space, it can be preempted at any time, whenever the scheduler decides it has used its fair share of CPU and it's someone else's turn. (This is preemptive multitasking. MS-DOS and MacOS 9 didn't have it - on those systems, a single process can run as long as it wants, and is only stopped when it voluntarily gives up the CPU.)

Kernel space is another matter. If you ask the kernel to, say, read a disk file, it will usually put your process to sleep until the file comes back from the disk, and will schedule other processes in the meantime - but for various other work the kernel does on your behalf, it does not normally interrupt itself periodically to make sure you still have time left on the clock, as it were. Thus, if a process makes heavy use of kernel facilities, there may be (relatively) long periods of time where the process should "in fairness" relinquish the CPU but it won't because it's "in kernel mode".

The reason for this rule - the reason the kernel scheduler never jumps in and preempts other kernel code - is that by doing so it would be quite easy to corrupt the state of kernel variables. This one is hard to explain if you haven't learned about locking primitives in programming courses, and unnecessary to explain if you have. Suffice it to say that arbitrarily grabbing the CPU and switching to another task is prone to basically the same failure modes as having multiple CPUs running different tasks simulatneously - i.e. SMP mode.

So, what's the problem with not preempting kernel code? Say you have another process doing highly interactive things, like a game, or an MP3 player, or even the X server tracking your mouse movements. Ideally you want it to react to new events (keyboard and mouse input, for example) as quickly as possible, so your system feels "snappy". Which is a problem if another process happens to be taking its own sweet time in kernel mode while you impatiently wiggle your mouse for half a second, wondering if the system is frozen.

Note that if you have multiple CPUs and use an SMP kernel, this "latency problem" is not nearly so bad. Since any one of your multiple CPUs may be available to service your all-important "main snappy application", the chance of seeing unacceptible delays is greatly reduced.

With me so far?

So here's what the preempt patch does. It changes the above-mentioned rule so that the scheduler is allowed to interrupt other kernel code without explicit permission, just as it does with user-mode code. If the kernel happens to be in a critical section (another technical term hard to explain to those who don't already know it), it should already have taken a lock in the SMP-mode case, so preempt-mode just redefines the lock/unlock operation as "disable preempt mode" / "reenable preempt mode". Thus, the kernel can sit and do all the work it wants to, and as long as it isn't holding any locks, the scheduler can pause it and run something more important (like letting your MP3 player trickle a bit more music into your sound card so the sound card won't run out, at which time you'd hear a skip).

I guess the terminology is really up to the reader, but in my opinion, while this is a "hack" in the sense of "clever program snippet", I think "creative use of existing facilities" is a good description. The key here is the realisation that the problem of how to preempt the kernel in arbitrary places is very similar to the problem of letting multiple copies of the kernel run at once on different CPUs, and since the latter is basically a solved problem (it was, in fact, probably the biggest difference between the 2.0 and 2.2 kernels), Robert Love was able to reuse this infrastructure to solve the vast majority of the problems with the former, in one fell swoop. Of course, preempt mode had other problems which had to be solved other ways, but SMP support was the major thing that paved the way.

(By the way, this wasn't Robert Love's idea originally. Linus Torvalds expressed it some time around the 2.4.0 era, but didn't feel like doing the work himself. I don't know if it was his original thought or if all this has been done before. I suspect Solaris, at least, uses a similar trick.)

Is this similar or analogous to Intel's new chip that acts like a multiprocessor?

Completely different. Intel's HyperThreading mode uses cooperative (not preemptive) multitasking implemented within the chip itself. At least that's my guess. Each virtual CPU runs until it hits whatever Intel deems a good stopping point, then changes hats and lets the other virtual CPU have a go. It works because a lot of facilities in the CPU can go underutilised because of bottlenecks elsewhere (fetching memory into L1 cache, for example), so by simulating two CPUs you can often keep these resources busier.

Re:Long-Winded Explanation of Preempt Mode

[ender's_shadow]

Thanks. That cleared things up quite a bit.