Slashdot Mirror

...or not:

* https://www.linuxfoundation.org/blog/the-2-6-32-linux-kernel/
* http://www.kroah.com/log/linux/longterm-proposal-08-2011.html
* https://marc.info/?l=linux-kernel&m=122375909403298

The 2.6.x series is still actively and heavily used in a commercial embedded router sector (ex. Asus, Netgear, Tenda, Linksys (now Foxxcon, was Cisco/Linksys), Huawei). Broadcom is still maintaining/updating wireless binary blob drivers for 2.6.22 and 2.6.36, both for MIPSr1/MIPSr2 and ARM/ARM7 archs.

There seems to be one "bad actor". Just one. But he's only a bad actor in terms of a completely voluntary community norm which nobody is compelled to follow, rather than the law.

Minimize and excuse while attacking the "posturing" companies for following the community norm? Surely you're better than that, Bruce.

Also, these companies would be practicing what they preach if they extended cure periods to their proprietary licenses. Which I doubt they do.

Apple and oranges, Bruce. Their proprietary licenses do not "terminate" so that it becomes impossible to become licensed by purchasing the commercial product. The GPLv2 purports to do so. Having represented clients in BSA audits, I have firsthand knowledge that their "trolling" consists of demanding a small multiple of the retail price of the missing licenses. That is a far cry from McHardy's shenanigans

Unless you can identify specific and deleterious differences between the RedHat approach and the Community Enforcement Statement, this is merely a cheap shot against corporate contributors to GPLed projects. 99% of individual contributors to projects never assert their copyright either. Am I to assume that you'll attack those that sign on to the Community Enforcement Statement for "posturing" as well?

There are a few different types of APIs involved with Linux, so it is more than the public API:
http://en.wikipedia.org/wiki/L...

Consider:
http://www.kroah.com/log/linux...
"For Linux, we don't have a stable internal api, and for people to wish that we would have one is just foolish. ... Here's an example that shows how this all works. The Linux USB code has been rewritten at least three times. We've done this over time in order to handle things that we didn't originally need to handle, like high speed devices, and just because we learned the problems of our first design, and to fix bugs and security issues. Each time we made changes in our api, we updated all of the kernel drivers that used the apis, so nothing would break. And we deleted the old functions as they were no longer needed, and did things wrong. Because of this, Linux now has the fastest USB bus speeds when you test out all of the different operating systems. We max out the hardware as fast as it can go, and you can do this from simple userspace programs, no fancy kernel driver work is needed."

And:
http://www.helixsoft.nl/blog/?...
"Linux pioneered that model: they call a stable API nonsense. The interface between drivers and the kernel changes all the time. If the Linux developers think of a better, more consistent or more efficient way to interface with the drivers they go ahead and make that change."

Thinking up "a better, more consistent or more efficient way" to interface sounds like creative work to me.

I had a similar disagreement with Alan Kay who argued that programs are mathematical. Given that for our Garden Simulator my wife spent over a year full time translating badly-named spaghetti Fortran code from EPIC to well-structured Delphi code that did essentially *exactly* the same thing, but now was understandable and maintainable, I see *enormous* benefit in naming functions, parameters, and structures well and know how long it may take to do that.
http://www.kurtz-fernhout.com/...
http://www.kurtz-fernhout.com/...

If you don't believe well-named APIs have great value, try, say, reverse engineering compacted JavaScript code. It's possible, but it takes an enormous amount of time. From another angle, most of what is written in fiction is about the same old thing -- human conflicts, human emotions, human behavior, and so on; what differs is often mainly the nuances of how things are described or the sequence they are described in. Why should Disney get a copyright on "Snow White" (the movie) just because it attached some specific names and faces to seven dwarfs when the story itself was public domain at that point? What difference is there in that case from giving names to functions and parameters for Java when the general notion of calling into a virtual machine is also effectively in the public domain?

However, I still think you have missed my point because you say I desire copyrighted APIs. I'd rather see copyright rolled back entirely or at least greatly restricted like along the lines Richard Stallman proposes. What I am saying is that as long as one supports copyright as it is now, and as it is being expanded, then you have to accept APIs should be copyrightable. In that sense, if you believe in the value of copyrighting computer software, Linux should *not* have been legally made ignoring that copyright violation sued to be mostly just a civil matter until recently it became criminal, and that the UNIX copyright holders would have had to chosen to purse Linux in court).

I think we probably agree on the moral an economic aspects of FOSS. My point is that we should not be trying to carve out special exemptions for APIs when the whole copyright edifice is maki

It's Apple's fault. http://www.kroah.com/log/linux/hardware.html

Says the guy writing the drivers that don't work.

It's Apple's fault.
http://www.kroah.com/log/linux/hardware.html

I'm not sure how you got "a pcie bridge over wires rather than on board connectors" from "Expose devices as hotplug PCI-E". Presenting devices to the operating system as PCI-E hotplug in no way implies they actually are PCI-E devices or are in any way electrically similar (much like how "file descriptor" hardly means "file").

In short, I agree with everything you said in the second paragraph, and I think it supports my point. The OS (local CPU) only gets involved with the Thunderbolt controller for communication relevant to it. The controller chip hides all the complexity of packet switching and routing etc. Unless you're on a Mac, which takes all that brilliant design and says "We're going to require the kernel to manage everything the controller chip should be doing for us".

Source: same as before, from someone who has read the relevant spec and implemented a driver - http://www.kroah.com/log/linux/hardware.html

Actually, Thunderbolt on Macs deviate from the specification a fair bit. The Thunderbolt spec is simple: Expose devices as hotplug PCI-E, let the BIOS do everything.

Thunderbolt Macs go out of their way to... not that. Read more at http://www.kroah.com/log/linux/hardware.html.

3.10 is the next LTS kernel by Linux standards. The existing long term kernels are 2.6.32 (as used in RHEL6, Debian Squeeze, Ubuntu LTS 10.04), 2.6.34, 3.0, 3.2.50 (used in Ubuntu 12.04 LTS), and 3.4.59.

*Sigh*. I guess I'll just have to post this for the millionth time:

http://www.kroah.com/log/linux/stable_api_nonsense.html

If you don't agree with the decisions in that link, please do us all (and yourself a favor), and go use something besides open source kernels. If you can't even be bothered to read (at least!) the executive summary in that link, then please stop posting.

This question has been answered. Many times. You know this. I know this. I know you know this. You know that I know that you know this...well perhaps not but I'm sure you can ascribe opinions to me regardless.

I'm sure you can count this as being another example of how rude linux supporters are. If your question (and criticism) were in good faith, you would get more polite answers. As is, you simply manage to annoy people -- unless you're involved in writing drivers (and we know that you are not), this is a non-issue.

As someone who has heretofore defended your right to an opinion, even a contrary and disparaging opinion, please, on this issue: Shut. The Fuck. Up.

It certainly isn't Canonical, which never contributes anything back to any upstream Linux projects.

*Never* is just plain wrong. The standard criticism is that canonical does not contribute *enough*.
E.g. see this:
http://www.kroah.com/log/linux/lpc_2008_keynote.html
which shows that canonical is a small but not completely insignificant kernel contributor.
It also makes at least some upstream contributions to a selection of other projects.

Your argument isn't new, and has been dubunked by respected kernel engineers. See Greg Kroah-Hartman's OLS 2006 keynote and stable_api_nonsense.txt. At best, allowing old drivers to load might provide compatibility for a few minor revisions of the kernel. It's a short step from that to proposing a regular (annual?) ABI update, and then you have drivers that might work for, say, 12 months, but are always ultimately going to break. (I say *might* because who is going to test these old drivers on new kernels? Even with hypothetical ABI compatibility, the reality is that changes in kernel behavior, scheduling, etc. can break a driver). The only way to ensure that a driver gets updated is to have the source. Even with Windows there is no complete compatibility, Microsoft releases a new baseline kernel every couple of years, and your old drivers will not work any more. It is common for companies to not update their old drivers for new Windows releases, which isn't really that useful when you have deployed systems still using that hardware.

Calling this article FUD is clearly unfair. It is a great writeup of the advantages given both to holders and users of GPLv3. Such as this paragraph:

When we wrote GPLv2 in 1991, we didn't imagine that a free software project might have hundreds of copyright holders, making it so difficult to get a violator's rights restored. We want it to be easy for a former violator to know that they're still allowed to change and share the software; if they stop distribution because of legal uncertainty, fewer people will have free software in the long run. Hence, we created new termination provisions for GPLv3. These terms offer violators a simple method to earn back the rights they had. Parties who violate the license have their rights restored provisionally as soon as they come back into compliance, and permanently if no copyright holders terminate those rights within sixty days of the last violation. Furthermore, first-time violators will have their rights restored permanently if they come into compliance within thirty days of receiving such notice.

Someone should go into their phone provider and ask for a copy of the GPL'd portions of their phones source and see how far that gets them - and then be led into this discussion with an appropriate perspective on Android and the GPL. Also: another article on Linux and Android relevant to this discussion.

For starters, I think you missed my point considering that you turned around and made it, but seemingly as a positive for Google.

Secondly, I think you might be interested in this blog post by Greg Kroah-Hartman entitled Android and the Linux kernel community.

Right now, a bug in the nVidia kernel driver on Linux could compromise the security of the entire machine, or crash the entire OS, or flip some bit in some other unconnected kernel system (or userland process), and it's hard enough to debug these things when you do have source code. So wanting an untainted kernel makes a lot of sense.

This. Anyone who thinks binary drivers are a good idea needs to read the above. And in case that doesn't convince them, they need to read this. If they are still not convinced, well they need to go write their own OS where proprietary drivers are okay, because we Linux users don't want them.

Stable API?

Oh please don't tell me you're another one of those going on about stable kernel API nonsense.

Calm down. I'm joking. It has gotten better. Just the occasional, changing of the name of constants.

Oh good. Well, you could just always go the route of getting your driver into the mainline kernel. Or hell, if that's too much trouble, ask them to write it for you. What's that you say? You want a binary interface so you can write closed source drivers? Well in that case, fuck off. It's called "open source" for a reason.

Stable API?

Oh please don't tell me you're another one of those going on about stable kernel API nonsense.

Calm down. I'm joking. It has gotten better. Just the occasional, changing of the name of constants.

Oh good. Well, you could just always go the route of getting your driver into the mainline kernel. Or hell, if that's too much trouble, ask them to write it for you. What's that you say? You want a binary interface so you can write closed source drivers? Well in that case, fuck off. It's called "open source" for a reason.

The OSS community has innovation upside down. We let upstream teams (In this case Gnome or Nokia) stand in the way of innovation as gate keepers. We need to switch to a model more similar to Android, where any innovator can share their work quickly, without having to jump through hoops and waiting years. A new package system in Ubuntu could take the innovations we see in the Android app store, and build on them. It could enable not just apps, but libraries to be shared, with apps running in app jails, and with the exact libraries they were compiled and tested against. We need to enable innovation from individual coders, by promoting their work immediately, and freeing them from the hassle of convincing large upstream teams to adopt their changes. That would enable us to say "There is an app for that" about Ubuntu. As it is, OSS land is mostly a bunch of coders practicing mental masturbation, because there is little chance for most coders to share their work widely as simple installable packages available in Software Center. Instead, we have to copy source files from sourceforge or github, and paste them into our projects, with no system to push improvements upstream.

Mark Shuttleworth is mad because upstream didn't simply include all is work quickly, and without having to fight for it. I guess he knows now what it is like for the vast majority of coders who just want an app in Ubuntu. Similarly, Google is mad at Linux because Linux removed Google's Android contributions.

There should never be a gate-keeper on innovation. The setup we have now in OSS land is unacceptable. And, it's fixable.

Many of the links in that article are actually quite useful, especially if you skip the internal references. One of them, from the 2008 Linux Plumbers Conference, which is dedicated to the lower-level aspects of the operating system (mostly the kernel, GNU, and X), was of particular interest as it talks about how Canonical isn't carrying its own weight, falling well below any other backer of a commercial distribution (or other Linux-depending company) on pretty much any metric and even well behind community-driven distros like Debian and Gentoo as well.

However, Canonical doesn't care about that layer of the OS; they want to improve the user experience, and have therefore focused almost all of their attention on the user interface. (It is interesting to note that the init subsystem rewrite is a salient counter-example, though its speed improvement still correlates to user experience.) From day one, Ubuntu and GNOME have been bedmates. Shuttleworth and therefore Canonical have therefore focused their efforts on GTK and GNOME while relying upon Debian and friends to care for the rest.

This arrangement seemed to work well for everything but the company's bottom line, which is where the value of this article really comes into play. They are in trouble as an unprofitable company built upon a for-profit model. (Easy solution: file for nonprofit status...)

Getting back to UI, Canonical is now getting bold and stirring the pot. They are pushing Wayland as an X11 replacement, which I think is a really good move (though forecasting when it might supplant X11 in Ubuntu seems extremely unwise). However, the friction they are creating with Unity as a replacement for GNOME Shell could be too much of a step, especially in a few iterations when the demands placed by Unity and GNOME Shell begin to differ. It is clear that Canonical wants (and due to its business state, perhaps needs) to have more control and be seen as a mover and shaker, but I question the wisdom of what might fracture the GNOME development community, especially given a target market of netbooks and smaller (given GNOME's bloat).

Were I in control, I'd steer Canonical to MeeGo.

With Nokia now fully removed from the picture, AMD added, and primary driver Intel redoubled in its investment, MeeGo is ripe for the shaping. From all appearances, MeeGo's design as something end-users might ever see has completely vanished. Intel's main intent for MeeGo may have been for demos, with widespread adoption merely being one possible future (remember, they're a hardware company). MeeGo products that have hit the market so far have all had fully customized user interfaces.

Canonical's designs for Ubuntu are to focus on the netbook and play a pivotal role in its user interface while improving overall speed and efficiency (key elements to the user experience). MeeGo, with its roots in the embedded space (including tablets and netbooks), fits here perfectly. Intel, who ranks near the top of all of those plumbing contribution lists in the LPC keynote I began this post with, would then become an ally.

(Yes, I know MeeGo itself has more in common with its Intel-backed Fedora-based predecessor Moblin than it does with its other predecessor, Nokia-backed Debian-based Maemo, and the main reason I'm a fan of Ubuntu is its compatibility with Debian, but those are minor hurd

he has become the Chicken Little of geekdom.

RMS was right about Bitkeeper. He was right about binary modules in the Linux kernel and prominent developers argued the same thing years later. He might have been right about Java - we'll have to wait and see, but things certainly aren't as rosy as they appeared to be once upon a time. He currently seems to be against ACTA, and he will probably proven right in a few years when the first ACTA legislated court cases start popping up.

How many times was Chicken Little right?

Yes, Windows has its faults, but at least when I go to install something or buy something like a UPS or a printer, I can install the driver/program and just expect it to work.

Oh, you mean how like when I buy a UPS and I plug it in it just works? Oh wait, that's right, that's not Windows, it's Linux. No CD or driver download required. 99% of hardware is that way. The other 1% is shit that the manufacturer has not written a device driver or submitted the specs for a driver to be written for Linux, and that's not a Linux problem. As for software, that's not a Linux problem either; when there is already a perfectly acceptable standard software package format in the form of .DEBs available, and it's open, and it's free to use, then it's not the distro maintainers' fault when idiot developers don't use it. You think that Microsoft created the Nullsoft or Inno installer? Oh, but wait, you might try to claim .MSI's. Well, not everyone uses those, yet I don't hear you bitching out Microsoft for "not settling on some kind of standard". Linux has it's faults, but your post is hammering on shit that's either already fixed or can't be fixed by the Linux devs and distro makers.

No easy to use binary drivers equals no drivers on CDs,

You know what I do with driver CDs? I throw them out. Without even checking to see if there are "Linux drivers" on them. And how about those drivers for Windows, from some dinky hardware company, that crash the machine anytime you try to push the hardware? We've already seen those happen with binary drivers under Linux.

When I plug in hardware into my Linux machines, I expect it to just work. If it doesn't, I figure there is something wrong with the hardware. 99% of the time I'm correct. Linux has support for so many pieces of hardware out of the box that I don't even *need* a third party driver. I don't have to waste time installing a driver or rebooting. It's wonderful! And you know why this is the case? Because of Linus's unwavering dedication to the principle of eliminating bad code, whether closed source or not. You know what stable kernel ABIs get you? Windows. If I wanted to use Windows I would use Windows. Hardware vendors need to wake up and realize they aren't in the software business; they need to release their drivers as open source for inclusion in the kernel (which means ALL kernels, obviating the need for a "driver CD" and all problems with drivers for different versions). This isn't a Linux problem; I'll agree it also shouldn't be a user problem, but right now the hardware vendors are *making* it a user problem. If you make it a Linux kernel problem (through "stable ABIs"), guess what? It will still be a user problem, because "stable" kernel ABIs necessitate backwards compatibility, which necessitates supporting design decisions that may not have been wise, which leads to unstable, bloated software. Don't even get me started on the fact that most "driver CDs" contain only drivers for i386.

See http://www.kroah.com/log/linux/stable_api_nonsense.html for details.

Heh, read the stable_API_nonsense.txt file in the kernel source. Here's an html version:

http://www.kroah.com/log/linux/stable_api_nonsense.html

Except it doesn't really help anyone but them. And later it turns out that they were only doing so because they were breaking the GPL. And then later that the code was shit and has taken a bunch of effort to get into decent shape and they've been completely ignoring emails on the subject.

Just like most other companies contributing drivers to the kernel through Greg K-H's Linux Driver Project, as Greg points out himself

Microsoft puts C# and the CLI under the "Microsoft Community Promise" and trumpets as it being a win for interoperability and open source. Except it only covers the core standardized parts. All the libraries specific to Microsoft's implementation that are widely used aren't included. As a result it basically only makes it easier to move from other implementations to theirs, and not the other way around, and the only one who wins is Microsoft.

It's still better than some other industry-standard languages such as, I dunno, C and C++. Show me their standardized network, threading, GUI libraries please? When did an open-source Java become useable: before or after Microsoft came with open-source C#?

Now I hate Microsoft as much as the next slashdotter, but let's be pragmatic please. Microsoft isn't Bill Gates, it's a thousand-headed hydra. Some heads may still be stuck in the old ways, but things are slowly improving.

In the old days, C# would never have been standardized, it would've been bundled with all their applications, and dev kits would cost thousands. They would've counter-sued to oblivion anybody complaining about their linux drivers. Yeah, OOXML is one of their myriad fuckups, but please don't single out the driver issue or C#, which are actually signs that things are improving at Microsoft, even if they're not perfect yet.

Here is what Microsoft said in the initial press release:

Q: Why release the code?

A: Because we have utilized Linux code, Microsoft has an obligation to open source the device drivers. This is the process outlined by the Linux community.

Q: Why open source the code?

A: Because this is a requirement of the community, and critical in ensuring that as the Linux Kernel evolves, and as Hyper-V evolves, that the Hyper-V Linux Device Drivers evolve as well.

Source: http://www.kroah.com/log/linux/microsoft-linux-hyper-v-drivers.html

So... when was there a cover-up? Seems to me like it simply wasn't reported because no one considered it relevant to report, given that it was in the press release.

It's not something you brag about, just a reality. They wrote some linux drivers, and that's a huge waste of time and resources to maintain in a closed source fashion unless you have a really good reason (like Nvidia, who have to re-engineer much of X to allow modern graphics technology in Linux).

It's rare that Microsoft should have to touch GPL code for any reason, but now that they have to for Hyper-V, they're adhering to the GPL. At one point does this story become sinister or scary?

Sam, does this mean that this GPLv2 release was actually negotiated and coordinated with Linux kernel developers? If so, it would be interesting to hear more about that side of it. So far I have found this:

Q: Why release the code?

A: Because we have utilized Linux code, Microsoft has an obligation to open source the device drivers. This is the process outlined by the Linux community.

Q: Why open source the code?

A: Because this is a requirement of the community, and critical in ensuring that as the Linux Kernel evolves, and as Hyper-V evolves, that the Hyper-V Linux Device Drivers evolve as well.

But this is rather vague - it's not clear where the "requirement of the community" comes from; is it implied, or was it specifically talked about?

You know, this is a common retort: "Windows is hard to install, you have to install drivers after installing the OS; Linux is so easy to install because the OS comes with all drivers"

What Linux advocates forget to mention is that it's really easy to install drivers after installing windows. If you have the disks your hardware came with, it's as simple as "next, I accept, next, next, done".

Another minor detail advocates forget to mention is that, if a given Linux distribution doesn't have your drivers, you're SOL. Nor do advocates mention that each version of Linux has a different driver API/ABI (this is a deliberate decision done by kernel devs) so you can't, for example, use your Ubuntu drivers in Red Hat Enterprise Linux 5.

Linux advocates also forget to mention that the time needed to edit configuration files with arcane formats to get just one thing to work in Linux (such as, say, file and printer sharing in Samba) is far greater than the time needed to install all of the drivers to get a given Windows install to work.

Quite frankly, I would rather deal with the bother of downloading and installing whatever drivers an older version of Windows needs to work (I'm sticking with Windows XP for the foreseeable future) than being forced to install a new unstable version of Linux just so I can have drivers for my new computer.

and Linux/BSD/etc. in the last corner with poor (but slowly improving) driver support that may or may not work out of the box.

Bull. GNU/Linux supports more hardware out of the box than any other operating system ever has.

What Stallman needs to do is catch up with the biggest development in the computing world of the past 25 years: the growth of computer users who do not know anything about their computers, and do not care to know.

Absolutely. We reached technological parity with the non-free competition years ago. But that's not the end of the road, it's just the start. Because regardless of how advanced the system is, put a new user in front of it and the first time something goes wrong (and something always goes wrong, whether you're using a free system or a non-free one) it's gonna be "Well, why'd you push this freeware crap on me?!"

But in the years I've been involved with this (plenty), I've never once seen a user who really understood freedom and what it meant and why it's important, and then went back to non-free software. It's an issue of education, and there's no easy way to overcome that. Just gotta keep pushing.

Lack of a stable binary driver interface is an engineering issue, not a religious one. "Stability, flexibility, and maintainability of the Linux development model".

but then again there seems to also be a problem with the Linux method because there aren't enough motivated people willing to spend their precious time writing device driver code for every new device that comes out.

Well, you're wrong.

Linux Kernel Developers have promised to write the drivers at a very low cost. Simply make an engineer and/or documentation available. You already need a knowledgeable engineer, and you already need (internal) documentation, so really all you need is to make them available.

Lots of companies are taking them up on it, but not everyone. What Linux needs are users who are vocal, and who have the expectation that they be able to use their hardare.

I still think the solution lies in a better (and perhaps standardized) interface for writing device drivers.

Well, you're wrong about this too.

When you make an API, you can never delete it. The public (userspace) API for Linux demonstrates a remarkable amount of cruft as a result- mmap2, and setarch are great examples of necessary evils. Extending this bloat into the kernel and you'll be moving those unmaintainable, unremovable chunks of cruft into the kernel, which would only become larger and slower.

When kernel developers want to change something, they can just do it, and fix any and all drivers along the way that might've depended in the old behavior. That happens alot- Linux has been through at least three USB implementations, and many different mass-storage systems- partially due to simplifications as a result of newer, more accessible technologies (MTDs come to mind), but sometimes simply because someone comes along and uses the knowledge gained by the older implementation (libata for example).

Locking the kernel interfaces means that the same level of caution applied to adding userspace interfaces has to be applied to kernel interfaces. New drivers would require more efforts to write, and new technologies would take longer to implement- simply because if any new technology gets made, you end up with an ad-hoc approach to implementation at best, or you wait a few years for all the "closed source developers" to catch up and stop ruining it for everyone.

This happens everywhere- not just in the Free Software community- look at Windows, it has four different driver models (WDM, NDIS, Miniport, and the new certified garbage), all that work completely differently; There are still wifi adapters that want to replace the Windows wifi system.

No, the solution isn't a technical one (bind the developers hands), but a social one: Open your damn interfaces and stop trying to hurt your customers.

If people like you stop apologizing for them, they'll change. They want you to buy their hardware, and at present you will, even if it means you also have to install ndiswrapper or some other garbage. I won't, and haven't for more than a decade.

The Linux kernel<->user ABI is stable, and has been since 2.0.0. Any userland code (the kind that normally makes calls through glibc) that made its own syscalls directly to 2.0.0 will work fine with zero changes on 2.6.26. Many programs written for Linux 1.x will also work fine, as the 1.x -> 2.0 change was to do with binaries being ELF instead of a.out by default. The syscall interface did not change, or if it did, did not change significantly in that time.

It's only the kernel internals (including drivers) that are not stable, but you don't actually want them to be stable. You think you do, but you don't.

Take a look at the Linux driver project or something like GregKH's driver tutorial. You aren't alone in wanting to write drivers for Linux. The catch is that most (new) hardware with specs actually already has drivers available on Linux.

The trick is to start with simple hardware and then work your way up (graphics card drivers ARE hard especially if they have to be reverse engineered). There are also books like the fantastic Linux Device Drivers that describe how drivers can be written.

(Writing drivers is not impossible but it does take time to become good and without specs it's is a tricky trial and error process. If you're even a bit interested, dive in!)

Finally, there's no way to "partner" with Linux. Either you support it (at some level) or you don't. Who would you partner with?

Right, and support can simply mean an open hardware spec. Greg Kroah-Hartman and company are writing free drivers for companies who provide them with this information. They can even arrange to sign an NDA if necessary. So my response to a company that asks "What do we have to gain?" is "What do you have to lose?"

http://www.kroah.com/log/linux/stable_api_nonsense.html

Check out Greg KH's blog:

"To be fair to one company, Google, we were incorrectly counting their representation, keeping Andrew Morton in the "Linux Foundation" bucket instead of the "Google" bucket. That will change the list of top companies placing Google somewhere between 10 and 13, I haven't re-run the numbers yet to get the exact placement."

Who, or what, are you faulting? Are you blaming the coordinators for defining a project scope that's not as large as you'd like? The companies that are paying kernel developers to work on the project? The unpaid volunteers?

Even if a developer is being paid to work on this project, it's the employer that's volunteering the employee's time and it's up to them whether or not they want their kernel developer to spend time learning the internals of things like CUPS or gPhoto. I'm sure that the employers have no problem keeping their employees busy with work outside of this particular project. I'm sure that they have other developers working on other projects like CUPS, SANE, or gPhoto. The volunteers would be working on those projects already if they wanted to (and some probably are already). Part of the purpose of the project is to have a group of developers that would sign NDA's, but they're not getting enough cooperation from hardware manufacturers. That problem is mentioned in the article linked from the summary.

Also, there was no such claim that the Linux driver problem was overstated, at least not by the head of the Linux Driver Project. You're quoting the writer of the article, not Greg Kroah-Hartman. Here's the original post that the article references.

that's just the elitest kind of bullshit

....
All that is needed is some kind of specification that describes how your device works, or the email address of an engineer that is willing to answer questions every once in a while ......

In return, you will receive a complete and working Linux driver that is added to the main Linux kernel source tree.

Q: Can you write a driver for my [insert device name here] to get it to work? It isn't made anymore and no one has the specs for it.

A: Sorry, but this project is for devices in which we have the specification and hopefully the manufacturer's support. We don't have the time or effort that is needed to reverse engineer the device on our own, sorry.

"[a stable abi] means hardware manufacturers are far more likely to release drivers for your platform"

No it doesn't. I run Linux/PPC and I *never* see hardware manufacturers releasing drivers for their hardware on it. Heck, it's hard enough to get decent drivers for Linux/x86-64 from them. I don't see them doing decent drivers for a other chipsets that run on systems that use standard hardware interfaces (PCI, etc...) either. They're just not interested.

The only way to get a decent driver for Linux (Not Linux/x86-32, but Linux) is for it to be in the main kernel tree.

So yes, it IS running two kernels, the ESX kernel which has priority, and the linux kernel running on top of it in a VM like every other virtualized kernel, once it gets running.

The Linux kernel allows binary blobs.

Um yes.

They've made the offer, including agreeing to NDAs. http://www.kroah.com/log/2007/01/29/#free_drivers

My God... has logical reasoning gone completely out of the window???

That has to be the gayest line I've ever seen on Slashdot.

Actually, hardware vendors don't even need to write nor maintain a single Linux flavor of their driver, much less multiple versions of it. All they need to do is provide specifications for their hardware and the community will take care of all of that for them. Of course, if they want to help by providing hardware or additional developers they would be most welcome to do so.

You're never going to get your kernel driver accepted by the high priests of the Linux kernel team for a piece of hardware with half a dozen users...

Greg Kroah-Hartman's OLS 2006 Keynote says "We have drivers that I know have only one user, as there was only one piece of hardware ever made for it."

Actually, it doesn't work like that. What actually happens is that the code which is maintained poorly gets dropped.

That said, yeah, if someone notices that filesystem FooFS has been completely broken for ages and nobody has even noticed, then that's a pretty good argument for dropping it. But even then it's not just because it's unmaintained, it's because at that point you're pretty sure nobody really gives a crap about it.

It costs money to develop drivers. As soon as they will make more money from offering Linux drivers than it costs them to produce Linux drivers - they will.

That factor is no longer in play since January this year, when Greg Kroah-Hartman publicly and officially offered free Linux driver development for all takers.

So what external factors are left to *not* give those specs to the kernel developers? How can you lose, as a hardware manufacturer?

i second the good books notion and thanks for the reference to Rusling's book - I haven't heard of that one.

I can say that Robert Love's book, Linux Kernel Development (2004) is very well written and easy to read and understand. (print only)

There is also Greg Kroah-Harman's Linux Kernel in a nutshell at http://www.kroah.com/lkn/ - free PDF download.

You're automatically assuming that everybody wants one "Linux". You're wrong. It's way more complicated than that. Your push is just one more example of "if only we had control everything would be more efficient" beloved of growing bureaucracies everywhere.

Instead you should be concentrating on standards, one at a time, as many people already are. Everything from the Linux Standard Base to the Free Desktop Project to the Linux Embedded Consortium. Keep in mind that if you're going to promote standards, one at a time, that in a free market each player needs a transition path and to not to be disadvantaged by the standard. For example, if all distributions standardized on the apt package manager that would be a disadvantage for all distributions not using apt. The only way to get a standard in package managers, or anything else, is to have it sufficiently superior, technically and otherwise, so that important projects are willing to absorb the transition cost and to accept being relatively disadvantaged during the transition compared to other projects.

In any case complaints about "having to support too many distributions" are exaggerated; when you've got software packages as complex and big as open office and java running on a variety of platforms, not to mention the thousands of small projects on freshmeat running on a variety of platforms, that's an existence proof that the problems are exaggerated.

In addition, for better or worse, every business wants to "differentiate" too, just like the car industry where I can't use a Toyota spare part in a Ford. After market car parts companies probably don't want to deal with all the different cars either but they do anyway.

Some closed source embedded device driver developers are unhappy the Linux binary device driver interfaces are changeable. Linux kernel developers have already explained why that is the case ( http://www.kroah.com/log/linux/stable_api_nonsense .html ). It's pretty pointless making an open source OS if some vendors want to obviate the whole point of it by adding close source device drivers, particularly when kernel developers have offered, for free ( http://www.kroah.com/log/linux/free_drivers.html ), to support the device drivers themselves.

There's always room for improvement but you're never going to get a free market to "standardize" entirely on anything.

---

Monopolies = Industrial feudalism

You're automatically assuming that everybody wants one "Linux". You're wrong. It's way more complicated than that. Your push is just one more example of "if only we had control everything would be more efficient" beloved of growing bureaucracies everywhere.

Instead you should be concentrating on standards, one at a time, as many people already are. Everything from the Linux Standard Base to the Free Desktop Project to the Linux Embedded Consortium. Keep in mind that if you're going to promote standards, one at a time, that in a free market each player needs a transition path and to not to be disadvantaged by the standard. For example, if all distributions standardized on the apt package manager that would be a disadvantage for all distributions not using apt. The only way to get a standard in package managers, or anything else, is to have it sufficiently superior, technically and otherwise, so that important projects are willing to absorb the transition cost and to accept being relatively disadvantaged during the transition compared to other projects.

In any case complaints about "having to support too many distributions" are exaggerated; when you've got software packages as complex and big as open office and java running on a variety of platforms, not to mention the thousands of small projects on freshmeat running on a variety of platforms, that's an existence proof that the problems are exaggerated.

In addition, for better or worse, every business wants to "differentiate" too, just like the car industry where I can't use a Toyota spare part in a Ford. After market car parts companies probably don't want to deal with all the different cars either but they do anyway.

Some closed source embedded device driver developers are unhappy the Linux binary device driver interfaces are changeable. Linux kernel developers have already explained why that is the case ( http://www.kroah.com/log/linux/stable_api_nonsense .html ). It's pretty pointless making an open source OS if some vendors want to obviate the whole point of it by adding close source device drivers, particularly when kernel developers have offered, for free ( http://www.kroah.com/log/linux/free_drivers.html ), to support the device drivers themselves.

There's always room for improvement but you're never going to get a free market to "standardize" entirely on anything.

---

Monopolies = Industrial feudalism

Here is a tutorial from Greg KH from Ottawa Linux Symposium 2005 (and 2006):
http://www.kroah.com/linux/talks/ols_2005_driver_t utorial/
And sample code for a USB thermometer
http://www.kroah.com/linux/talks/ols_2005_driver_t utorial_example_code.tar.gz

Here is a tutorial from Greg KH from Ottawa Linux Symposium 2005 (and 2006):
http://www.kroah.com/linux/talks/ols_2005_driver_t utorial/
And sample code for a USB thermometer
http://www.kroah.com/linux/talks/ols_2005_driver_t utorial_example_code.tar.gz

That's why Linux hackers want all drivers in the kernel tree, so they can find anything which breaks due to an API change, and fix the problems.

And that's exactly why hardware manufacturers DON'T want their drivers to live in the kernel tree. They don't get:

• Bug fix backports: Kernel hackers apply a patch to the latest vanilla kernel, then say backports are the distro's problem. Two distros do, fifteen don't, users of those fifteen scream at the hardware companies for having buggy drivers. With an out-of-tree driver, you just need to update the driver. Windows and OSX are light-years ahead of Linux here.

I don't think I've ever heard of someone blaming the hardware company when there was a patch already available, just because their distro of choice hadn't incorporated that patch. Is this a straw man, or have you actually encountered it? Even so, how would having an open-source driver prevent them from providing patched binaries directly to the user?

Community contributions: Kernel hackers only add GPLed code; very few even allow dual-license, and certain vocal hackers are zealously GPL-only (to the extent of rewriting code JUST to make it GPLed). Which means the hardware vendor can't take a fix from a linux driver and integrate it into a Windows driver without GPLing that too. The vendor has to either GPL all drivers (Windows included), or maintain two separate trees (GPL and non-GPL), or not open drivers at all. Guess which is easiest / cheapest?

Code added to the Linux kernel MUST be GPL, that's the licensing requirement. However, contributors are still free to release their code under other, even proprietary licenses. There is nothing to stop nVidia from providing GPL and non-GPL drivers that share code. If someone makes a patch to their driver, and releases it only under the GPL, then of course it can't be re-licensed without permission. However, if there is no GPL code, they don't get any user submitted patches anyway, so they don't gain anything with non-GPL. An alternative would be to foster development on a BSD-style license, or ask for a copyright grant from the contributor so they can relicense it.

Driver API stability: a modern 3D graphics driver is a full OS in its own right, with internal threading models, schedulers, memory management, context switches, etc.; a modern driver needs more than just bugfixes. Every good developer knows the way to keep two large codebases manageable is a stable API between them; the only people who don't seem to get this are otherwise-intelligent Linux kernel hackers.

In Linux, drivers are a part of the Kernel, not outside programs. It is, in a sense, a single large codebase, not multiple large code bases. nVidia wants to be part of that codebase, without actually contributing itself to that codebase.

Kernel API freedom: Kernel hackers like stable userspace APIs (for good reason). But hardware vendors don't need to provide stable APIs if they have a shim library that actually talks to the cards (e.g. atioglxx.dll, the ATI OpenGL implementation). It's a lot easier to let the API change rapidly and only commit to a stable API at the library interface (the OpenGL API).

It's even easier to let those people who are changing the API make the changes for you, which is what the Kernel devs are asking for.

Easier work. The Linux kernel development process is optimized for making the kernel hacker's life easier at the expense of the driver developer's (hint: saying "we'll update your driver for you" clashes very badly when the HW vendor is simultaneously making changes). If kernel hackers want to see better device drivers, they need to stop treating drivers as second-class citizens. Microsoft is very good at courting driver developers; Linux is the definition of arrogance.