Open Sourcing Closed Sourced Drivers? 262
AnonymousIntern asks: "I'm interning at a company where I've signed all kinds of privacy agreements, so I'd ask that you not name me (nor use my id). The company I'm interning with sells a suite of software, along with various boards. Their software got ported to Linux a couple of years ago, but the Linux drivers for the boards (open source) don't have most of the capabilities found in their windows (closed source) counterparts because the company fears releasing a piece of technology in the chips that they've developed. Many people in the company are very level-headed proponents of open sourcing the whole driver (thus giving Linux users the same power they can get running the windows version), but fear releasing their tech. Can anyone suggest a course of action? I know this issue has come up before, but I feel it needs to be continually addressed." Now I'm all for opening driver sources, but if it came down between the choice of more driver support for Linux and Open Source code, I'd be torn. This is a subject I'm sure many of us feel strongly about, so please share your opinions.
Re:YEah (Score:1)
Hmm...
AC
Sorry. It's illegal in Netherlands too. (Score:1)
Re:If you opened the specs... (Score:1)
Okay, it's time this NVidia thing was more fully explained. In fact, I daresay the NVidia situation would make an excellent Slashdot feature, assuming we could get anyone at NVidia to go on record. I, sadly, must remain off-record, since we're trying to get this very information out of NVidia so we can support their chips, and I wouldn't want to upset them. However, I also think a more complete picture of the situation -- at least, as I have come to understand it -- may help Slashdotters and Open Source advocates understand the situation more fully and allow youse guys to direct your intellect and zeal in a more constructive manner.
First of all, the Big Book Of NVidia Register Definitions won't tell you a thing. NVidia's design philosophy is very unlike any other graphics chip. Everything, including rendering context maintenance, is dealt with at the hardware level. In reality, a lot of duties get thunked off to software via interrupts, but by taking this approach, NVidia can migrate functionality into and out of the hardware at will, and all client software will continue to work (that's the theory, anyway). Thus, to write an effective driver, you need considerably more information than a register list since, in actual fact, half the time you aren't dealing with real registers.
I have it on reliable authority that this information isn't really written down anywhere; unlike Intel, NVidia does not have a technical documentation division. The design philosophy remains primarily in the engineers' brains. If you want to become a customer of NVidia (that is, a board OEM), they'll give you enough access to their brains so that you can customize your board offering. In terms of NVidia's engineering time, this is not cheap, which is why they charge OEMs handsomely for this privilege.
So, without access to NVidia engineers, the register spec is of little aid to a driver-writing effort. Fuhgeddabouddit. The lowest level they're willing to document at all is the virtualized hardware interface and, as it happens, all that information can be found here [nvidia.com].
Another reason NVidia is so protective of their specs is partially due do historical accident. Several of the principals at NVidia used to work at Sun Microsystems, where they developed the GX graphics accelerator. One of the SunOS releases inadvertently contained a single #include file detailing the GX registers. Using that file, a debugger, and a logic analyzer, Weitek managed to develop a clone of this chip in a mere six months. The clone was so good that Sun's own drivers worked on it. Needless to say, this left a bad taste in their mouth.
Astute observers will note that Weitek is now dead dead dead , but NVidia has more recent experiences to keep them gun-shy (Gnu-shy? :-) ). It seems that NVidia is of the opinion that the few Open Source releases they've made have directly resulted in getting hit with patent infringement suits. Apparently their competitors (who evidently have nothing better to do :-) ) download their source release, pick through the code, make some reasonable conclusions about the underlying hardware implementation, and start filing suits. Yes, it's bullshit, but if you're a cost-based accounting kinda guy (and most accountants are these days), NVidia's Open Source releases have been hideously expensive, and haven't resulted in the sales of additional chips.
These two last points (fear of cloning and fear of lawsuits) are the two big sticking points for NVidia at the moment and, sadly, I don't see them changing any time soon. Personally, I think their chip is so monsterously complex to design and fabricate that their fear of cloning is virtually unfounded. The patent thing, however, is another matter. Perhaps they might choose to hook up with Jeff Bezos in his stated intention to pursue patent reform. But that seems unlikely, since it could distract them from the very important job of staying ahead of 3Dfx, S3, ATI, and Matrox.
Keep sending them kind, polite notes of encouragement toward an Open Source release. But be prepared for a long, long wait.
Re:Why not both? (Score:2)
And if the vendor didn't do a full source release in the first place, they may well sue the person who did the reverse engineering, even if he did everything legally. Basically, having to reverse engineer features is a huge PITA.
Re:Question from a non-guru (Score:1)
Electric All wheel Drive? (Your on Crack.) (Score:2)
Hehe (Score:1)
Re:Gee.... (Score:1)
Re:It's about freedom, and peace of mind (Score:1)
Can you post a message and ask for free help? Can you write a check? Both are possible ways to get fixes if you have the source. Remember that with free software, you have a significant number of people whose motivation is more in getting things working right than in profit.
I Disagree: I'll take the source please Bob! (Score:2)
- you have to download and re-install the drivers every time you change kernel versions
- this means you can't upgrade a kernel (or upgrade, and lose sound for a while) until the binary-only release for your version is available
- you better have the same libc as the sound drivers, or Bad Things Happen
- if Opensound ever goes away, then no more driver support for me!*
I'd much rather have the source, and I'd rather that source become part of the official kernel distribution, where I can count on it being compatible with my system under all circumstances.
Or to put it another way, distributing binary-only drivers means you are now in the Linux tech support business, where your drivers must keep pace with kernel development. Release driver source, and it's likely that someone else will do the maintainence for you - at least as far as API changes etc. go.
*OK, bad example, there are now working proper source drivers for my soundcard in the kernel, so I do have an alternative these days. For increasingly obscure or convoluted tech though (video cards) reverse engineering open source drivers may not be as feasable. If the company providing binary-only drivers decides to stop doing so, you're pretty well screwed come kernel recompile time.
Re:You are no better then a petty thief (Score:1)
Because I'm a prospective customer? Damn right! They don't have to open their source, I don't have to buy their product! What's more, I'm just as free to discourage other people from buying it, too.
A free market cuts both ways, my friend.
Re:You are no better then a petty thief (Score:1)
Re:Question from a non-guru (Score:2)
1) It commits the kernel to support something he doesn't believe the kernel should commit to, at least at this point. The kernel does provide a standard external user-space interface (at least in combination with libc). Kernel internals, however, are kernel internals, and he wants the freedom to be able to change kernel internals as needed to improve the kernel.
The kernel internal interface is not part of the POSIX definition, anyway, so there's no standard to worry about upholding.
2) Stability. Buggy user space code can crash an application, but it won't crash the system. Buggy code in the kernel -- driver or otherwise -- can crash, lock up, or corrupt the entire system. It can be very hard to trace down where the corruption comes from (I speak from moderate personal experience dealing with the kernel in various UNIX-type operating systems).
Encouraging a situation where people are at the mercy of third parties for their systems' stability is not something Linus (or anyone else) particularly cares to encourage.
Drivers don't have to be compiled into the kernel; modules work just fine for the purpose of runtime loading.
Re:Question from a non-guru (Score:2)
Try reading linux-kernel -- you might be surprised by how much stuff Linus rejects on the grounds of poor design. The kernel is definitely not hacked together, but it does have to evolve, and forcing it to maintain a fixed internal interface gets in the way of that. Maintaining a supported external interface, in combination with libc, seems to be the best compromise between stability and progress.
Re:the choice is obvious (Score:2)
Oh, really? I would argue that it's the very pickiness of the Linux community that has gotten it as far as it has. There are also a lot of people who believe fervently that if Linux were to give up this "pickiness" it would mean losing the very thing -- guaranteed freedom -- that makes it so desirable in the first place.
Nobody's forbidden to release closed-source software for Linux. That doesn't mean that it particularly needs to be encouraged.
Re:You are no better then a petty thief (Score:2)
Re:Why Open Source? (Score:2)
It's not that easy to separate a kernel version from the low-level user interface (libc, and some of the tools), for one. Also, suppose I need two pieces of hardware, and the supported kernel is different for both pieces?
Re:Pros Cons (Score:1)
the product is computer authorisation algorith (eg ACE-server & Securid card). Opening up the source exposes the driving algorithm for public (read cracker/hacker) viewing. IF there is hole in the algo and someone finds it the company is screwed.
Re:Pros Cons (Score:1)
opening up the aglorithm destroys its main strength - obscurity. (ok as we know this is generally a bad idea, but lots of people still make lots of money out of 'snake oil':-)
This seems easy enough. (Score:2)
Yes, these aren't fool-proof, but they might satisfy your average PHB whilst still keeping in the spirit of having as much of the tech Open Source as you can.
There is actually one further option, which would allow for a TOTALLY Open Source driver - write a meta-driver, which handles the raw communication but does NOT contain the h/w API. Then have an external "driver script" which programs the driver with the translations between the external API and the H/W API. Give any given script the option of being encrypted, and the translations for that section of the API would be visible only to the driver.
There's a _big_ problem with binary only drivers. (Score:1)
Either the company in question is going to be willing to pony up the resources to keep up with the kernel development (an ambitious task- but NVidia seems to be willing at this point in time...) or open the source and the technical details to be able to fix the same. While they're making that decision, they should understand that unless there's some magic mojo involved in their tech, they're not going to benefit at all from opening the source and tech data. They should also realize that if they have some special magic that it's VERY likely that a potential competitor would be reverse engineering the stuff and unless the company in question has patents on the software and hardware, there's going to be clones and knock-offs eventually (rather soon, I'd suspect...). Plainly speaking, security of "IP" through obscurity is no security at all. It's almost totally in their best interests to open it all up.
Re:There's a _big_ problem with binary only driver (Score:1)
They will benefit from an opening of the info and driver source.
(Shouldn't post to
Re:No Problem: Steal The Source and Gnutella It (Score:1)
Poor sampling techniques get poor consistancy. It is very possable that the people tht say "don't steal code" are not the same people tht say "steal music". (of corse it is possable that people are inconsistant)
Slashdot does not speak with one voice. Not even the same parts of slashdot read the same stories!
Re:Question from a non-guru (Score:2)
That depends on who you talk too.
Some people like Open Source because it tends to reduce the bug level. Release a mostly bugless closed source driver and they will be happy.
Some people like Open Source because it provides an alternitate means of support when bugs are found (either they are programmers and will fix it themselves, or they will hire a consultant to do it). This might only be important to them if they think the compony will fold, or if they think the componies support level won't be good enough. Provide them with source code escrow, and a way to get the code NDAed if they think they found a "show stopper" bug that you don't think of as a priority.
Other people like Open Source because it give them freedom. It might be the freedom to port to another OS (say Plan9, or NetBSD on the PCI baised SPARCs). It might be the freedom to add new features (wow, with all this DSP stuff, I bet I can turn this card into side looking sonar....). Some of them might be happy enough with source under NDA, but many won't.
Others like it because it normally also means free programs. This is kinda a non-issue for drivers because they are almost allways free with the device.
Others like it for a combonation of the reasons listed above. You will need a combionation of approches.
There are still others where it is a end unto itself. They will not be satisfyable with non Open Source (RMS qualifyes here, ESR does not appear to).
Pretty diffrent. But if you don't need a lot you can minimise the pain. Here are a few things to look out for:
Diffrent VM system (important if you want to do zero copy DMA operations), NetBSDs provides some features Liunx's doesn't (as far as I know) like Page-Loanout. In fact the 4 BSDs (counting BSD/OS) all hae diffrent VMs (well OpenBSDs may be the same as the old NetBSD one...and I think some NetBSD platforms still use the old VM system, not sure if it assumes things that are hard to do on some MMUs, or if some of the less popular ports are just lagging).
BSD systems stull use mbufs. Some of them have fixed a long standing 4.4 external memory mbuf bug, others havn't. Some allow arbratary pullup's and splices in the middle of the buff, not just at the front (makes life a lot simpler for protocalls that need contigious headers larger then a single mbuf). Linux doesn't have the same set of functions. If you look at the KAME project I thik they have a set of functions that abstracts out what they need into another interface that sits on top of both.
NetBSD and FreeBSD have a similar but diffrent interface to talking to devices that might live in a number of places and have a number of endianesses. For example the same NCR SCSI part can be found on a x86 PCI card (little endian machine, PCI bus), a SPARC SBus (big endian SBus), a SPARC PCI bus (big endian, PCI bus), and so on. A single driver can support all three (I think the probe function has to know how to probe all the bus types though -- which isn't a big deal for the SBus and PCI bus, but is for other busses). OpenBSD may have the same interface as one of the others, lack it entirely, or be a bit diffrent again. I donno. BSD/OS doesn't appear to have one at the moment, but I expect that is one of the things they wanted from buying Walnut Creek/FreeBSD.
And porting to NetBSD, FreeBSD, OpenBSD, and BSD/OS on the Intel CPU alone isn't the end of the story. BSD/OS runs on SPARCs as well, can I have a driver there? NetBSD runs on the Alpha, on PCI Macs, and around 40 other machine types, some of which have PCI busses and could take your hardware. Can you compile me up a version for them?
And hitting all the BSDs on all the archatectures isn't enough. BSD/OS and FreeBSD are doing fine grained SMP. That can require locking in the device drivers. Will you be supporting that as it moves forward?
And hitting all the BSDs not and in the future isn't enough. What about Plan9? What about university research projects?
These things may all represent very small markets (NetBSD supports the pc532, there were fewer then 250 of them new, and assuming all the ones still running run NetBSD, it's still a tiny market -- and it'll only work there if your device is SCSI attatch, or ethernet). But Open Source would make all of those people happy.
Even if you just stick to the "larger market" systems, there are still at least three intresting BSD systems, and two or three non-Intel CPUs. Assuming your hardware product is something an ISP would want at least. Answer may be diffrent if only a video production house would want it, or only a hardcore gamer.
From a bisness standpoint you have to decide. Is getting support on more platforms, and free bugfixes worth the cost of making it simpler for competitors to reverse engnear my hardware, or take tricky driver bits for their own? Is the kind of hardware I have actually going to inspire lots of people to hack on the drivers for free for me, or is it just not a sexy device (or in a overcrowded segment, and not a standout)?
I happen to beleve that people are better at reverse engenring closed source systems then people think (look at DeCSS, or the number of cammeras that gphoto authors had to reverse engenar specs for to make work, or...), so just for the sake of keeping ahead in hardware is probbably not a big issue unless you are in a fairly slow evloving segment of the market (say LCD charactor gennerators, or slow low density network gear).
If you have some nifty stuff in your drivers that is relitavly independent of the device, well then you have a real trade off to make. How much is that chunk of code worth? Is it really relly valuable? Do you take pains to ensure your programmers won't go to a competier and write that code again having seen it once? Might the GPL be "strong enough" to guard it? (after all if your compitetor takes it from a GPLed program they either have to release all their secrets, and they probbably have some just as good as yours...or face the potential for a big lawsuit, with large damage claims....)
Maybe there is a good bisness case. Maybe there isn't.
Pet thery warning: One thing you should be careful of though, if there is a good bisness case, you want to be the first in your market segment. The first people to the table get more followers. More people willing to hack your code even when a cheaper better card comes along (so long as it isn't that much better or cheaper). And the longer you are "first" the better your lead is (more people with time invested in learing how the driver works).
Re:Question from a non-guru (Score:2)
FYI, as of last monthish softupdates were re-released with the BSD licence.
That I agree with. Even in more idealisticly pure BSD systems a GPLed kernel module would be Ok, as would GPLed userland bits. So as long as this device isn't a boot device (like a RAID controler) your Ok.
Re:reverse engineering closed source drivers (Score:3)
Pretty much 100%. If you look at the device drivers Linux comes with I bet a few are reverse engnered. I know the Visor USB hotsync "driver" was built after looking at traces with a USB protocall sniffer for example. A lot of digicam drivers are done the same way. Bocs is also a great tool to help revese engener a driver (by observing the IO crom CPU to card). The (original) BSD Mitsumi CD ROM driver was reverse engenered (in 1991ish). Several ethernet PHYs (because they came on a card that had been supported until the vender changed PHYs without changing the box!). Roumor has it some of those were done because someone decided it would be simpler to reverse engenr the driver then to drive to CompUSA and get an exchange for a working card! Hmmmm, I can't think of more examples of the top of my head, but cd on into your source tree and start reading driver comments.
Hell, some drivers written with documentation had to do a bit of reverse engenering work to see what was really going on because the doco was wrong! (A Lucent Ethernet comes to mind here, and the bringup code for the so-called TurboSPARC maybe too...)
It ain't impossable. For some people (not me) it ain't even hard! Of corse it might be illegl now with the DMCA, but then again it might fall under the interoperability clause (it would definitly seem to me that it should).
It's hard to provide binary-only drivers (Score:1)
On lkml I once read a thread started by some one distributing a binary-only kernel module. The binary guy was experiencing some problems and some kernel hackers were assisting him in tracking down the source of the problem. What kernel version? UP or SMP? What compiler?
So, binary-only modules are pretty much guaranteed to be big hassle right now. Bigger than some people trying to distribute them realised in advance.
--
How can you be torn?? (Score:2)
The answer is the *neither*... it will be "free software", not Open Source (still TM'd? heh). Seriously, read on until the end... you can't just open the code - or not - and expect to sit on your ass reaping the benefits forever.
I am not the pure GPL type - I bought Windows. I won't even claim to be pure Linux (unlike *some* people who recently editorialized comments about Quicktime videos and Linux. *Diablo* *cough* Ahem.)
It's pretty obvious tho that even if YOU do not care about Free Software vs. Open Source, you only have to wait around for someone else to code good free software, and then you'll use it. I appreciate what the FSF has done, but not everyone does. Fine, I guess, but when someone codes "the best software" and it's GPL'd, that's it and the competition is OVER; story at 11.
By the same token, I don't program, but I love the fact that so many UNIX users do, and I can benefit by running Linux. Microsoft and APple can do some neat things when inspired (well, Apple can anyways
Back to my point, there will come a day when software is more common and stuff to power your boards will be Free Software. Maybe that day is far enough away to recoup your investment and then some, but don't expect to make it last forever. Releasing the code with too many restrictions will just FUEL some GPL'd alternative (look at Qt/KDE v. GNOME, or the FreeVM v. VMware).
Like Apple, there's a day in the future you'll have to decide if you're mostly software or hardware. Predict that day, and you can pull off any licensing you want really.
Personally I get annoyed at hardware with substandard Linux support, and I curse their management as buffoons.
Re:why open source ? (Score:4)
Second, closed source kernel drivers severely limit the user. You are limited to certain kernels, with certain options. You may not be able to apply security patches. And Linus has made it clear repeatedly that if the kernel needs to change and that breaks binary drivers, that's not his problem.
A hardware vendor providing binary only drivers relegates his hardware to second-class citizen status, because there are a lot of people who don't want to put on a straitjacket to use a certain piece of hardware.
Re:I'll take the tech please Bob! (Score:2)
Christopher A. Bohn
Free as in speech (Score:2)
Christopher A. Bohn
Re:Question from a non-guru (Score:1)
--
Pros Cons (Score:3)
1) Acceptance in the Linux/OSS community
2) The driver can be part of the linux kernel
3) If there is a bug in the drivers it can addressed quickly
4) People can create alternate solutions for devices
Cons on opening the source for the drivers
1) The cat is out of the bag
2) People can create alternate solutions for devices (Might cut into revenue of other devices)
3) Competion can create a clone of your device easier
And there are there are many more reasons That can be given these are the just a few that I thhough of any more
forest for the trees (Score:2)
Re:Question from a non-guru (Score:1)
Re:How is this a troll? (Score:1)
Speaking of moronic logic ... you have your logical implications back to front. Since many cats drink milk, anyone who drinks milk is a cat ...
Re:Because DRIVERS typically run as 'root' (Score:1)
Your company can't make a decision? (Score:2)
How much business will you lose if you release the tech?
How much business will you gain if you get the Linux market?
Which one is greater?
We would all love for you to open source the driver and release the specs for the board, but your company's decision needs to be based on the numbers. Answer the simple questions above, and the decision is made.
Re:Question from a non-guru (Score:1)
---
Joseph Foley
Akamai Technologies
Why Open Source? (Score:2)
Why not just release binary drivers as modules and specify which version of the Linux kernel is required? If people need your hardware, then they'd be delighted to run whatever version of Linux is required. (I'm talking about kernel versions, not distros.)
Just because you port something to Linux doesn't mean it has to be Open Source, or even free.
Re:Why Open Source? (Score:2)
Also, suppose I need two pieces of hardware, and the supported kernel is different for both pieces?
Then, you need to decide which piece you need more, or get a different machine for each piece.
You can also live dangerously and try loading the modules anyway. As long the difference in the kernel requirements is in the number after the third dot, you just might get away with it. Then again, your machine might just lock up. }:-)
Seriously, though, I don't see binary drivers or special kernel versions (with drivers compiled in) being a problem for folks who need the special hardware. This is exactly where the custom programming and service model of making money with Open Source comes in.
The question really becomes does linking your driver code into the Linux kernel violate the GPL if you don't distribute the source for your driver. If the answer is yes, then only support BSD and tell the Linux weanies to go to Hell. }:-)
It All Depends (Score:5)
If it's a GOOD driver, I don't have any problem using a binary driver. The problem comes in most cases when it's not a very good driver to begin with, adn poorly supported. I'll use the SB Live! drivers before they were open as an example.
They released so-so binary only drivers. They also weren't updated. Which leaves a big hole in even the number of people that can even use it. Drivers have to be compiled for every kernel version, and SMP versions. Creative assumed everyone ran a stock RedHat 6.1 install, and just forgot about everyone else. Although I aplaud Crative's opening their drivers, I would have been happy with closed source drivers that did everything their Windows counterparts do(read Liveware 4.0).
Most dont' want drivers open so they can hack them and make them better. As the case with my Live!, I couldn't even USE them unless I had the source. Since they just supported the 2.2.12 kernel that's on a stock RedHat 6.1 install, I had to re-compile it for 2.2.13-SMP.
So my point being. If it's a WELL SUPPORT DRIVER, most will use it, and like using it. The driver has to be kept right in line with everything your Windows drivers will do, and the same preformance. You also have to release a version for all the recient kernel versions. If it's some crappy hack like what Creative tossed out there before they opened their driver, that's when you'll get the backlash.
Re:Question from a non-guru (Score:1)
Linux is supposedly being installed on more servers than Novell NetWare. If you manufactured something targeted at the server market, you'd be a fool to ignore Linux (and you'd be an even bigger fool to not play by the rules and try to support a binary driver...) This is the kind of hardware that comes with support for obscure platforms like OS/2 ODI networking and Novell NetWare 3.x - Linux should be a no-brainer.
Intel proposed a cross-Unix driver API (and presumably will implement it for Linux). The conculsion of the Linux cabal was that any driver using it would be doggy dog slow.
--
Re:Question from a non-guru (Score:1)
The situation is more different than you would think. Linus (and many other kernel hackers) thinks that there is no need for supporting binary-only drivers and thus make no effort of keeping the driver interface stable over time.
Many binary-only drivers even violate the GPL by using the inline functions from the (GPLed) kernel header files. I think Linus gave only one explicit exception from this rule to some company (etinc, I think).
IMHO it is hard (if not impossible) to write (and especially maintain) the Linux driver not covered by GPL. You basically end up duplicating the changes in the kernel develoment yourself.
Speaking from the point of view of kernel driver author/maintainer [linux.cz] it is the best thing for maintainance to have your driver included in the mainstream kernel tree. Core kernel hackers often modify drivers in the kernel tree to reflect changes of the driver interface, so you don't have to track closely the kernel development.
-Yenya
-Yenya
--
Re:Open Source (Score:1)
Would go against RMS' sense of fair use, i.e. doing whatever you want to do with the source, including competing against the creator of the software.
Re:If you opened the specs... (Score:1)
shrug. i mean, really, does anyone who USES linux REALLY give a damn?
--
blue
you need this [soccerchix.org]
No Problem: Steal The Source and Gnutella It (Score:3)
Yes, this is a flame bait IP rant.
The ethics and consistency of this group (or lack thereof) amazes me. The vast majority of folks on Slashdot have no stealing music from artists but seem a bit squeamish when it comes to code.
When musical intellectual property is discuessed, the answer is that it's okay to steal it because that's the way it should be done and the music companies are living in the dark. It's RIAA's fault we're stealing music.
Yet, when it comes to source code, we wring our hands and postulate about how we can convince the source's owner that the code should be opened. Why? Shouldn't we take the same track as we did with the music? Isn't it their falut that the code is closed and isn't it our obligation to steal the source and distribute it far and wide?
I say that if the intern has access to the source code the the drivers, he should put it up on gnutella or a semi-anonymous web page and link it from Slashdot. That'll teach 'em.
Why should corporate privacy agreements be any more binding than music copyrights?
InitZero
the choice is obvious (Score:2)
Now, I like open source a lot. If there is a way to release this technology AND make it open source, then do that. But just because it ISN'T open source is no reason not to release it. In fact, if Linux is ever going to be #1, we will need companies to speak out for it. I don't see Linus on the TV pushing Linux... do you? Maybe the reason your Red Hat stock isn't doing so well is becuase THEY DON'T ADVERTISE. If they do it is in publications in which everyone already knows what they are. If the only way to get companies to support Linux is to let them release some closed-source stuff, then the method justifies the means.
If you think you know what the hell is going on you're probably full of shit. -- Robert Anton Wilson
Why is there trade secret stuff in the driver? (Score:2)
It would seem to me that the design of this hardware was made under the assumption that the driver would be closed source, and perhaps only for Windows. If I had some cool idea of a piece of hardware (like something that was faster, smarter and just better than the competition) I would put all that technology into the hardware (count the firmware that drives the onboard CPU as part of that hardware for this purpose) and let the driver be nothing more than the communication path between the abstract requests/responses the applications see, and the physical functions performed by the hardware and/or it's processor.
It's awfully easy for me to assume the driver is doing more than it should, much like the driver in the infamous winmodems that let US Robotics make the modem cheaper, eating up more of your CPU power to do stuff like compression. That was definitely the opposite of an accelerated card.
Maybe the design cycle for the next version of the hardware needs to be pushed up sooner, and this time with all the proprietary and trade secret functions hidden away in a tamper-proof chip, and a simpler hardware-to-software interface.
Re:Linux is NOT THE ONLY OPERATING SYSTEM! (Score:2)
Open Source has far more advantages than just the ability to make Linux a functional OS. As a system administrator who knows how to program, it's a means by which I can have control over, and effectively manage, the systems I need to keep up and running.
One of the assertions made by Bill Gates regarding the stability of Windows is that many of the faults (I think he was trying to suggest that it was all of the faults) for crashes lie with third party drivers (many even distributed with Windows itself). With the increasing popularity of Linux, the concept of drivers written by third parties will be seen more and more. Some will be open source and some will not be. But what I suspect is likely to happen is that a lot of it will be poorly written. Those which are open source can be reviewed and fixed, maybe by the user, and maybe by the kernel development crew. It might even get included in the standard kernels (you can be sure a binary-only driver will not be).
One of the things that I believe open source brings is quality.
Re:I'll take the tech please Bob! (Score:2)
I am tempted to suggest thet an answer would be to release two versions - a closed driver with all the proprietary bells and whistles and an open version that gives the functionality the company feels they can release. However, this then leads to an even deeper segregation problem!
The one positive effect that such a strategy *may* have however, is that if the company has a positive experience with the open version of the driver, it may encourage them to open more code in the future.
Hmm, it's a thorny problem though - and one which we have all been banging our heads against since way back
"Give the anarchist a cigarette"
I'll take the tech please Bob! (Score:5)
Having been a Linux user for years (starting with an early Slackware distro), I have to say that ease of use is *still* a priority for me - even if I am prepared to dive into config files and the like, I prefer not to. Open Source is important to me as a developer and on a more idealistic level, but in the real world, I'd rather see companies supporting Linux and giving the same level of features (or better) in their software as the Windows users get.
At the end of the day, it isn't every company who is going to take the Open Source path. Those that don't should be gently encouraged, but quite realistically we have to just get on with life and using our computers - and I want to use mine with all the functionality I can get.
"Give the anarchist a cigarette"
Nail on the head! (Score:2)
Exactly! Someone give StormReaver a beverage of his or her choice.
If your company is depending solely on the fact that their software is only distributed as object code to ensure their continued livelihood, then I recommend that you start looking for employment elsewhere. Because in short order, someone is going to disassemble the object code and use it to ruin you.
In the end, both source and object code are exactly the same thing: Instructions to the computer. The form they take makes things slightly more difficult, but no more so then keeping all your trade secrets in French does.
Likewise, if you're depending on IP law to protect you (copyrights, patents, trademarks, etc.), they will continue to do so even if you do release the source.
Closed source as security is security through obscurity, which doesn't work, regardless if you are protecting data files on your server or the source itself.
Simple solution. (Score:3)
StarOffice has been like this for years. You acquire a binary that runs reasonably well on Linux but, the source is still closed.
There are no actual requirements to go open source to have your product used on a Linux platform. That's one of the big confusions in the market. People have the mistaken belief that if they release for Linux, BSD, etc... that they have to open their source too.
OT: Socialism (Score:2)
Of course, that can be fixed by rationing food. An approach which worked so well in WWII. That's the problem with socialism. It is not very realistic. Instead of people buying as they can, it relies on a Big Brother to parcel out the goods. Of course, Big Brother (or Uncle Joe...) likes to have as much as he can for himself.
People work on incentive; it's the only way. Free Software and Open Source (which are one and the same, no matter what His Highness thinks) only work because people have an incentive to write excellent software; they wish to scratch their itch. Take that away, and we have no more free software.
Very few people have an internal desire to clean toilets or plow fields. That sort of work scratches precious few itches (although it does cause a few). Yet, these things need doing. Thus the free market. It arranges for a fully-functioning society, unlike any other scheme yet proposed.
Re:OT: Socialism (Score:2)
Energy will probably never be limitless. Even fusion requires raw materials which must be ripped out of the earth--the miners must devote their hard labour to this task. I have a nasty feeling that were solar power to produce all of the world's electricity the climatological effects would be intense. We may be someday able to release and control huge amounts of energy, but I am rather confident that, much like hard drive space, land, laws and everything else in life, the uses of energy will always remain one step ahead. Remember back when 1MB was huge? Now 12GB is tight for me...
Let us reconsider those miners above. Why would anyone be a miner when he can be an artist? Because he wants to? But how many people want to spend their days in a black pit? Or consider the case of sewer workers. These poor folks literally spend their days knee-deep in sh*t. How do you convince someone to do that? Not all jobs are fun; not all are pleasant, in air-conditioned offices in front of computers. Some mechanism for rationing the limited supply of fun jobs must be determine.
Another problem is that different things are useful in differing degrees to different people. Size 8 shoes (8 in. long; about 20 cm) are useless to me, but extremely useful to my father. I have no use for eggplant--as far as I'm concerned it is compost fodder--but to a Frenchman that aubergine might be just the thing for his ratatouille. Some mechanism must be developed to account for these differences in taste--eggplants should be rationed to the Frog while I get hamburgers.
I have shown, very roughly and in a form I am sure which would send an econ major into apoplexy and a logician into fits, that rationaing of resources and labour is necessary. I think we can agree that labour is a resource, so I will treat it as such from here on out.
There are many schemes for rationing. We could have a first-come, first-served scheme: all the grain (or electricity, or jobs or workers) is in a big heap and whoever gets there first can take all he wants. Well, if he's smart he'll take it all, or as much as he can carry. He would then take that surplus and go down to the fellow who has cornered whatever it is that our grain-hoarder really wants (perhaps pictures of Miss Portman). He would then trade the useless (to him) grain for the useful (to him) pictures. He might collaborate with several such hoarders and produce a common unit to ease the chose of bartering. Thus, with the invention of money, we are back to the current situation, except that some people have everything and everybody else starves.
The above is a utopian model: producers produce and just give stuff away to the first comer, which as we see cannot work. Well, what about a socialist system, under which a benevolent commission rations everything? Unfortunately this does not work either. The commission cannot accurately know the myriads of ways in which resources may be valued. They can set the price of beef lower than it ought to be. This is the situation in the US: the government has subsidised the production of beef and thus more beef is produced (I do not believe it would be possible to satiate the American demand for beef; I know I sure love it). The natural limiting factors (expense of grazing land, cost benefit of farming vs. ranching) thus do not apply and the end result is that we have too many cattle--we are thus inefficient. Conversely, we tax alcohol at a rate designed to cut consumption. Thus less alcoh and we inefficiently produless alcohol thatn would be desirable. No commission can possibly comprehend the full interplay of factors: people's varying desires for thing; seasonally-affected variations; regional variations &c.
And, in a socialist set-up, the commissions tend to become Big Brothers. No-one wants to be a sewer worker--the commission must force somebody to do it. Few people desire to give 90+% of their earnings away to others, but the commission makes them do it. So this non-omniscient commission forces its ill-informed opinions upon the masses? Whither right? Whither justice?
The free market, while imperfect, is a way to fix all this. No-one is forced into anything, except through economic means. The stick is eschewed in favour of the carrot for the most part. Everyone is given the hope of improving his lot and the freedom to realise that hope. How does this work?
A free market assumes a multitude of producers and consumers. Everyone is both at one point or another; I produce labour, while I also consume all sorts of goods. Any producer may sell his product to any consumer at a price the two arrange between themselves. If my work is worth at least $10/hr. to me, and my work is worth at most $30/hr. to my employer, then we can settle on a price somewhere in between. If my work is worth $30/hr. to me and $10/hr. to my employer, then I can try to find another consumer to buy my labour. If there is no other customer to buy at that price, I had better consider lowering it.
This carries over into everything. Land costs a certain amount per acre, which is an aggregation of the value it has for all uses. Land in the middle of West Texas may be near-worthless for business as it is far from big cities, but it may be worth quite a bit as ranch land. Land in Kansas may produce $10,000/yr. in cattle or $15,000/yr. in wheat. Everyone is free to produce as he will; the intelligent man produces the most efficient goods given the resources at his disposal, which means that he makes the most possible money which means that he can buy the largest posible amount of what he desires.
To try to bring this back on topic, how does this relate to software? Well, software takes time to write. The three weeks I spend writing Bob's Cool Program are three weeks that I do not spend farming, or sweeping streets, or making cars, or otherwise making money. I convert three weeks of time into an artifact, a piece of source code. Compiling that code takes little time; thinking by time alone, it might make sense to give away the binary and sell the source. But most home users do not have access to compilers. So perhaps it's a better idea to sell the binaries and give away my source. But if I give away the source then someone else may take my three weeks' work, add one days', compile the thing and sell it, gaining me naught. This is related to the problem of the BSD License that the GPL seeks to address.
Of course, if I GPL my work then the situation is the same, except that I get that other fellow's one day of work. If I can get twenty people each to give me a days' work thusly, then I have put three weeks' work into something and gotten somebody else to put four weeks' into it. I now have a work worth seven weeks of labour for the low price of three weeks. Thus the GPL is economically sound, as long as I actually value that software in the manner I described.
What if I could have made $10,000 from my software but instead end up get $5,000 worth from the GPLed programme I released? Then I have made an economically unsound decision and lost money. I have made a decision which I may find morally more comfortable, but I am worse off for it. And as far as morality goes, I have wasted $5,000; the world is that much poorer because I didn't make money--I lack $5,000 I could have spent. Remember that value is actually created; when I trade two goats for your one cow, I am better off and you are better off. When I get paid $25/hr, I'm better off and my employer is better off. When I sell a product worth $500 to you for $100, we're both better off. If I give away a product worth $100 to 100 people and get naught in return, they are better off but I am worse off. I have hurt myself and they are now able to spend their money in an inefficient manner. Thus I have hurt the economy.
So one should try to examine the cost/benefit of GPLing software. Which is what software producers are doing. RMS, OTOH, believes that it is a moral imperative so to do. I think that I have shown above how it might actually be harmful.
Re:why open source ? (Score:3)
This brings up an issue about which I ahve been thinking for quite some time now, ever since I read the circumstances which gave birth to the FSF. Stallman wanted the source to a printer driver because it was buggy. He went from that starting point to argue that all source should be free. I have often thought that his ends could have been meat by stating that source and modification are free within the community of customers. That is, if I purchase a copy of Word I have a right to the source code, and a right to share my modifications to that source with others who have bought it. But I cannot give it away to someone else who has not paid for it.
This preserves the profit motive and makes it possible to write code whose source is open and whose bugs get fixed, while at the same time enabling authors to charge for what is, after all, their work and their expenditure of resources. It is true that eventually someone's modifications could be so great that he may want to charge for it; again, he would be able to do so. Let's call the original source A and he mods B. The fellow could sell B only to those who already own A, but could sell A+B to anyone, as long as he paid the original author his due for A.
I will admit that this could get out-of-hand if everyone wanted to charge even for slight mods. But again, that could be controlled--specifying that mods of less than 100 lines or something similar must be public domain, perhaps.
I do not believe that I have ever seen anything on the FSF site explaining why something along these lines (obv. not exactly this sort of thing) is not a good idea.
Re:Open Source (Score:2)
Say you want to use the card on something other than windows, maybe in the future when the original card maker has gone bust.
Having the source code means you could rebuild the driver for say a PowerPC machine. If you don't you rely on the card maker to provide proper drivers for all platforms which usually isn't possible.
Re:No Problem: Steal The Source and Gnutella It (Score:2)
If some company (*cough*Aureal*cough*) promises to open up their linux driver source, and I buy their card on that promise, and then they don't do it, I would have absolutely no problem with "stealing" the source if I could.
-- iCEBaLM
Re:Why is there trade secret stuff in the driver? (Score:2)
The issue isn't "cracking" more that of "cloning". Any company which can realistically clone a card could simply buy a few and subject them to destructive examination. Smart card crackers tend to want a working smart card at the end of it, slicing a set up to put under an electron microscope isn't much good to them.
Re:why open source ? (Score:4)
Exactly what stops competitors from being able to do this? Closed source drivers can be examined, hardware can be taken apart. (You can protect the hardware, but you'd then have problems shipping what is effect a bomb.)
Re:why open source ? (Score:2)
It is possible to have a binary driver to work with linux, but it becomes a pain since you can't compile it when you build your kernel. And there may be problems with the driver with upgrades to the kernel.
Although I would be interested in knowing how much changes from one version of the kernel to the next regarding driver interfaces. Is it really that big of a deal. I have successfully used older versions of modules with new versions of the kernel. I just turn off that switch that checks for module kernel versions.
Steven Rostedt
We're in a similar boat (Score:2)
This has been in the suits vs. suits stage for over a year now. The lawyers are running the show.
Middle-of-the-road (Score:2)
-------
CAIMLAS
Don't just "open source it", GPL it too... (Score:2)
The other advantage is that the free software community will most likely improve it as well and the company itself will benefit as well.
I also have another suggestion. If you want to keep an edge on tech over the competition, then move more of the low-level logic stuff needed for the drivers into the hardware itself (e.g., ROM) and then the free-source drivers only need to send params into the hardware via some sort of documented interface. This makes porting and supporting various platforms a bit easier through a higher layer of abstraction and makes it more difficult for a competitor to reverse engineer anyway.
This also would seem to get the difficult blessing of the FSF as long as it isn't flash upgradable. I heard a talk by Richard Stahlman Sunday at H2K in NYC and asked him about PC BIOSes. Seems he thinks BIOSes should be free since they are programmable, but not needed if they are not flashable. Spliting hairs a bit on that one, but I don't see him advocating that Intel release the microcode for their processors, for example.
Now this last bit I tend to disagree with since a non-upgradable card BIOS means any bugs in it need a hardware swap, but it's better than non-free drivers.
Some say free-source purists are anal but think of it. You spend your bucks on some top-of-the-line vid card yet you can't use it on the OS of your choice, or your support is limited. So why is a non-free driver acceptable to many Linux people when the "driver" for the processor (the OS itself) *must* be free (as in freedom) or it's evil (like NT)?
If consumers of free software want better support for hardware, they need to speak with their wallets and purchase hardware with free-source drivers, even if it may be a notch or two below the top-of-the-line. Since companies have an obligation to make money, only then will they notice and feel pressure to release the source to their stuff.
A complete OS is far more than just the kernel. Linux is free and the tools and utilities that make it work are free. If Microsoft released a new OS based on the Linux kernel but everything on top of it was non-free, would that be fine with you? If it's OK for Office Suites to be closed-source, then why the heck does the command "cat" also have to be free then?
"Purchase the Microsoft distribution of Linux. We've removed all of those unreliable GPLed utilities in it, stripped the C compiler and X out, and added typical Microsoft-quality tools on top of it along with mesh (Microsoft-enhanced shell), which DOS users will find very familiar. By the way, if you give a copy of anything but the kernel to a friend, you will go to jail. Of course, in the spirit of the open source community, our modifications to the linux kernel are available, just don't expect anything else to be."
Re:Question from a non-guru (Score:2)
I don't see how it is the hardware vendor's responsibility to support the OS vendor's political agenda. Now, before the knee-jerk reactions start rolling in: I agree that open drivers are preferable to closed drivers. And I agree with all of your bullets about why open drivers are better (or, in some cases, the only acceptable solution for us).
But we must remember that we don't make up a significant percentage of their total sales. Because of this, all of our ranting just causes the hardware vendor to conclude that supporting us is not worth it. Who wants to be in the unhappy position of receiving support calls from these zealots? (Especially if the problem is probably the driver, which they now aren't responsible for!)
They don't understand the philosophy. And us screaming in their face every time they make a move we don't like isn't going to make them understand. And it's not going to engender any good will toward us. It probably discourages thier cooperation, as they don't have any financial reason to succumb to the wishes of a bunch of ranting lunatics.
Instead, we should encourage baby steps toward our way of thinking. That is, applaud when they do what we like, and politely deal with it when they don't. Write even-tempered letters to the vendors involved describing your decision to buy or not buy their hardware and how the relative openness of their drivers played a part in that decision. Eventually, more vendors will see the benefit of giving us what we want, and the free market will take care of itself.
I'm not sure where we, as a community, decided that we have the right to demand open drivers and expect them to jump to it. How would we react if some hardware vendor demanded that the open source community provide them with drivers?
[Since I'm replying to bero, I have to say that I think companies like Red Hat are supremely positioned to show these vendors the enlightened way and assure them that the risk they associate with opening their drivers is worth the potential benefit.]
--
Re:Obfusacte (Score:2)
For example the GNU GPL states:
"The source code for a work means the preferred form of the work for making modifications to it"
In other words, not obfuscated.
(and a good thing too IMHO)
Re:why open source ? (Score:2)
Let's imagine a new version of XFree86 comes out, promising to be the best thing since sliced bread. Lets imagine that lots of hardware manufacturers produce closed source drivers that work well and that most users are happy.
Now lets imagine that some people decide that the graphical performance of the systems they have is not good enough and they want to do something about it. Perhaps they decide it's XFree86 that is just too big and bloated and they want to write some new windowing system.
They write the fantastic new system with it's almost instant loading time, its superb anti-aliased fonts and so on, but theres a problem. It can only support VESA cards. Unaccelerated. What do they do? They want to look at the source for the XFree86 drivers but they can't. As a result the brilliant new system's performance is even worse than XFree86 on fast hardware. As a result, everyone keeps on using XFree86.
We would all effectively be stuck with XFree86 for ever, like it or not.
Linux+XFree86 is slower than Win32+directx they all say, and there's nothing we can do about it.
Okay, that's probably all a bit far fetched, but I don't care. You get my point.
Re:why open source ? (Score:2)
Simple. Nobody would pay for drivers. Think about it: I buy a new video card, it works great, I install a new sound card, and the video card's drivers keep crashing. There's no WAY I'd shell out a bunch of cash to my video card vendor to fix their software.
Sure, most other software can follow this model. Software breaks, company releases another major/semi-minor version with a couple extra features, and people shell out thousands to get the latest. But that doesn't work for drivers. People won't buy drivers.
There's more to the world than ia32/Linux (Score:2)
The reason most of the people who're using Linux today are using it is that it does certain things better than their old OS did. Now, what happens when there's a new OS that's even better for their kind of work? Think about BSD, or the Hurd, they're even free software. Maybe you can construct a compatibility layer to run those drivers, but compatibility layers are evil.
Even worse, consider switching to a different hardware platform. No one's disputing that ia32 is the worst major hardware platform currently available, and the only reason everybody's using it is
Of course, hardware support on these platforms is pretty poor even among free software drivers (has anybody had success with utah-glx for mga on the Alpha? Keeps killing my X server), but there's at least a chance that something will happen: You can either fix it yourself, or pay someone to do it for you; you're no longer at the mercy of some high-ups in some company on a continent on the other side of the planet.
And that's what free software is about: Independence. Don't let yourself be fooled by bread and games!
Open Source Drivers & Reverse Engineering (Score:3)
If the device is groundbreaking, then simply publishing its interface (which is all a driver does) can do no harm. Describing how to communicate with the chip in no way reveals how the chip works (unless the chip's functionality depends on already well known techniques).
Let's look at 3dfx: Does describing how to invoke the FSAA (Full Screen Anti-Aliasing) features of the Voodoo chip via driver code give away the inner-processes of how the chip goes about achieving that? No, not in any way, shape, or form. The FSAA is one of 3dfx's main competitive advantages, but is 3dfx worried that other video card manufacturers are going to be able to copy it just because its programmer interface is published? No. Do they think that other companies (NVidia, for example) wouldn't be able to reproduce it anyway if the driver were closed? Hell no. If NVidia thought that FSAA was a make-or-break line item on a video card, the company's chips designers would find a way to reverse-engineer the chip's functions via hardward reverse-engineering, or they would reproduce it from scratch. Is 3dfx now the major video card among Linux users -because- they opened their drivers? You betcha.
why closed source? (Score:2)
- short response times for new kernel developments etc. (the next kernel version/xf86-version (whatever the driver is for) could break the driver but that might be easily fixed with an open source driver.)
- support from the open source community will make the drivers better and even help to develop better windows counterparts etc.
- proper linux support lasts much longer, once it's running most changes are automatically (more reflecting changes in the kernel than enhancements of the drivers) and comes for free
The drawbacks are:
- 'secrets' are slightly more obscured in binary versions (but if a competitor REALLY wants to know how that driver works he'll take it apart with a disassembler anyway)
- there's anyway people working on the drivers, so open-source won't make it cheaper (but maybe better)
In that light it may make sense to keep a driver closed for some time (maybe half a year or so, true 'secrets' will either be copied or reproduced by competitors, be the driver binary or not), but in the long term opening the driver makes more sense (new driver revisions for linux come automatically, and maybe there's even some concepts to be learned for the next generation hardware and it's drivers.)
Re:Simple solution. (Score:3)
Sorry, but I have to disagree here. While binary-only applications may be okay, binary-only drivers are quite a different matter. If they're talking about drivers in the traditional sense, then that means code compiled into the kernel, or more likely as a module. Remember all the fuss caused by Creative's decision to release SB Live! drivers as binary-only - and then not recompiling for newer kernels and whatnot?
And what if I want to use these drivers on, say, a custom kernel config - like my MOSIX cluster here? insmod will, of course, fail, because the kernel version doesn't match. While I could force it to load anyway, what are the odds that it would work, without a recompile on MY system?
And then of course, there is the simple matter of alternate architectures besides ia32/x86/whateverthehellyouwannacallit. Archs like Alpha have PCI slots, and will even work reasonably well with most PC hardware. But what if the company doesn't provide a Linux/Alpha version? Guess I'm screwed then (yes, I do have an Alpha, in the form of a Multia sitting under my desk). This applies for binary-only applications as well.
While binary-only apps are okay, even tolerable, I do not like binary-only drivers at all. Maybe its just me, but they just have too many associated problems, at least in my view.
Dear my! What are those things coming out of her nose?
Spaceballs!
Re:why open source ? (Score:3)
Question from a non-guru (Score:4)
How different is *BSD from Linux as far as drivers go? Is it REALLY that hard to recompile drivers to make everyone happy?
Re:Question from a non-guru (Score:2)
Even if a company chooses to release Open Source drivers recompiling the kernel is a little beyond what you can expect from the average user. This forces hardware companies to produce several binary versions for each kernel, and maintain them for several kernel versions. This means they have to maintain these versions with bug fixes and test them all. They also have to write complicated install scripts to match the correct binary with the kernel on the user's machines, and deal with all the tech support questions which are greatly compounded by all this.
This pretty much makes Linux the hardest platform to support, and customer support is a large expense for most companies. Since the Linux customer base is still relatively small, this just gives hardware companies one more reason not to bother with Linux.
For some devices the manufacturer can publish a clear specification and a little sample source, and someone will write and contribute the driver. However, if you're targeting consumers, someone has to provide support. Someone is also likely going to have to polish the installation tools so that the average consumer can get the driver working.
We support multiple OSs in all of our drivers where I work. With a little work you can abstract our a lot of the OS specific parts of the driver. You can then write most of the driver in OS independent manner and port it easily. Most of the OS specific parts are also reusable in other drivers. Unfortunately for this to work well you need to have a reasonable device driver interface.
We currently support Linux in our drivers, but creating and testing all the binaries, and the customer support problems are already becomming an issue. It's a lot of effort, and the sales numbers just arent justifing the effort. I don't expect this to continue indefinately.
The Problem with the HURD (Score:2)
Don't expect the HURD to go anywhere. Who needs it? Linux works better now than the HURD will ever work. The MACH kernel is a fundamentally flawed thing, in concept alone. It's a great example of why we have the term "ivory towers" - it's designed by academics based on theory rather than experience and fact. It's advantage, in theory, is that it's more portable. In practice, Linux proves that a properly written monolithic kernel can be so close to it in portability as to make that a non-issue, without incurring the huge performance hit that the MACH kernel imposes by insisting on a lot of unecessary abstraction.
Given these facts, which you can easily verify for yourself, (start with this bit by Torvalds [oreilly.com] explaining the difference between microkernel and monolithic architecture from a practical point of view, and how the design of Linux enables it to meet the same goals without sacrificing performance) it's easy to see why the vast majority of competent kernel hackers are working on Linux or *BSD, not MACH, and will continue to do so for the forseeable future. The longer they do this the further behind the HURD gets and the less likely it becomes that it will ever become anything usable, let alone desirable. If by some miracle the HURD project suddenly starts moving and puts out a usable product, it still won't go anywhere, because it will still be inferior to Linux and *BSD performance wise, and Linux and *BSD are both portable enough that no one would choose the HURD just for portability.
In short, the HURD is dead, for good reason, so your entire post is irrelevant.
But, even without the HURD, there are still no shortage of good systems that people use and develop that won't work with a binary only driver.
That's nowhere near a comprehensive list I am sure, but just a few major ones off the top of my head.
When M$ claims that much of their stability problems come from poor 3rd party drivers, for once they are telling the truth. Unlike windows, linux was not designed to support binary only drivers, and it's not maintained in such a way to support them, by design and for good cause. The whole point to linux for most people is to get away from the bad things that come with windows, and binary only drivers are right up in the top part of that list. If a company won't release the source for their drivers, or at least the technical specs so that someone else can write a driver for it, I won't buy their hardware. Far better for them to release the specs and let a kernel hacker write the driver (which costs them nothing) than for them to pay a team of their programmers to produce, test, and release the best binary only driver in the world. Releasing a binary only driver isn't supporting linux, it's proving that you don't have a clue about Linux or Free Software in general.
binary != secret (Score:2)
Re:Question from a non-guru (Score:2)
Re:Question from a non-guru (Score:2)
Yes. Binary only drivers are definitely better than nothing, BUT:
Re:Question from a non-guru (Score:2)
Take a look at the FreeBSD source code. Look for "softupdates" and "math emulation".
They may not be in by default, but it clearly shows GPL code can be used in the BSD world.
Re:Why not both? (Score:2)
(And offering something for download is something they can do themselves).
Why not both? (Score:5)
Put a limited open-sourced driver up so everyone can use it and it can be included in distributions (and developed from there, chances are it will outdo the closed-source version some day), and at the same time, release a closed-source driver for download so people who need the extra functionality right now and don't insist on having everything in source form can use that.
why open source ? (Score:3)
How is this a troll? (Score:2)
Once again, some moderator has taken a response that they disagree with, and marked it down for being a "troll". How is it a troll? This person simply is stating his opinion.
This is something which has always bugged me about the moderation system here. People can't post contrarian opinions without being moderated into oblivion. Obviously moderation is needed to keep out the "first post"s and "natalie hot grits", but don't use it to silence opposing views.
Re:It's about freedom, and peace of mind (Score:2)
Re:Question from a non-guru (Score:2)
That hardly matters. If you have the hardware, you'll have the drivers. If you don't have the hardware, you don't need the drivers. The drivers don't need to be on a distro.
If they're kernel modules (which a lot of drivers are), they'll need to be updated every time you want to use a different kernel. It'll be a lot of work for the company to keep track of all new kernels, even if they support only the kernels released by the major distributions.
Granted. This is just being discussed a little further above this post.
Linux is not the only OS around. Open-sourced drivers can be ported to *BSD
True, but then you can't have it all. In theory, Windows drivers would contain enough information to write a functioning Linux driver, but you can't because the drivers and Open Source. I have yet to see anyone complain about Windows drivers not comming with source so they can port them to $OS.
A kernel driver can crash the entire system. If it's binary only, it can't be fixed by the community.
True. But then if a company is releasing the driver as an "offical" driver for it's hardware, it should already be stable and functional. If it isn't, then they have to fix it. This has been the case on Windows and other OS's for quiet some time. If the driver stinks, don't buy the hardware; you wouldn't use a peice of software that doesn't work, so why hardware?
In the end, theirs very little reason why a company can't just release binary drivers for a product, apart from the screaming zealots. Oh well.
Too many hardware releases to matter (Score:2)
I don't know how long your company spent developing the new technology, and integrating it into their boards, but I am pretty certain that other manufacturers will spend as much time copying and applying your technology as they would developing the thing for themselves.
One compromise would be to develop fully featured binary drivers for say, Red Hat, and FreeBSD, plus low-funtionality driver code for other platforms.
Include in the package an email address where people can ask for a binary for a particular platform. If there's enough support for it, then bring it out. There shouldn't be that much modification required, and the kudos you'll earn with the opensource community may be more valuable than you think.
Even that's not enough though. I won't order any hardware that I don't see in the supported drivers list. So the faster you get some form of drivers out there, the better your board will sell.
"A goldfish was his muse, eternally amused"
Re:Sorry. It's illegal in Netherlands too. (Score:2)
(Our lawyer checked this extensively)
Very similar (Score:3)
I work at a company that supports open source software, and development of open source software.
We ran into a situation where we needed to have open source drivers, as opposed to the (available) closed source drivers.
(for those interested, try searching for 'philips webcam drivers' on linuxtoday or linuxnews or something)
Links to the stories can be found here [het.net].
Our action was, to get the binary-only drivers, disassemble (reverse-engineer) them, and rewrite them, as open source.
I think the best action in situations such as these, is to try to convince the manufacturer first. Often they don't want to give away specifications, or they don't get the advantages (selling more hardware because of there is support for it in free operating systems).
In cases such as those, the only way to get open source drivers is reverse-engineering protocols or binary-only drivers.
Reverse-engineering and rewriting the driver can be a lot of work, but hey - it's worth it
As for the legal implications, we were able to do it legally. In the netherlands (and i know there are other countries with similar laws) it is legal to reverse-engineer a piece of software, and to make the information you get from it public.
In our case, releasing a complete open source driver was not possible, so we had to make an information package (wich included a basic driver as a reference).
Other people are allowed to re-use this information, and make the real driver.
As far as i'm concerned, there is always a way out, and always a way to get an open source driver for a piece of hardware.
GCC? That's not obfuscated. (Score:2)
<O
( \
Not really a choice (Score:2)
I have been through this kind of situation before and I know how frustrating it is to work in something you don't believe. All I can tell you is start looking for another job.
Re:Pros Cons (Score:2)
If it is open, more than one person is likely to find the hole and tell the company. If it is closed, most of those going after it will have malicious intent and not publicize but use the hole. Which is better?
If you opened the specs... (Score:2)
This parallels what's happening at NVidia at the moment - they've decided to release their own closed source binary set of drivers which require a dirty great 500k kernel module to be installed.
However, if they opened the register-level specs to the device, then there are enough other people out there who will take the specs and produce a set of open source drivers themselves. Witness the Utah-GLX project.
You could just release the register level specs to the device and if someone wants drivers for the thing, they'll hack em themselves. This is something I'd like to see NVidia do.
reverse engineering closed source drivers (Score:3)
While on the topic, what's the likelihood that someone with enough intent could work out the technology by reverse engineering the closed source driver, anyway?
I'm not suggesting it would necessarily be feasible since it's not really my area. Can someone comment?
===
Re:why open source ? (Score:2)
Re:Question from a non-guru (Score:2)
They figure they can use their refusal as a crowbar. If hardware wants to run on Linux, it had better have 'open sourced' driver code. If the Linux market share grows, and hardware vendors want a slice of that market, they'll be forced to disclose their proprietary details. It goes to the heart of the GNU ideology.
I don't agree with it, but they have their right to be rigid and inflexible and hold onto their vision of how software should be developed, just like Microsoft does.
Just do it (Score:2)
(End of summary, you should now go there [forbes.com]...)
Slashdotter's version: What are your executives afraid of?
Officially, that somebody would copy their technology if they put some code in the GPL?
If this is *that* revolutionary, then they could easily check that nobody copies them by scaning the concurrents' drivers.
Remember when Quake source code was stolen from crackdotcom's server, Carmack just said that nobody could use it for a new product, as there'd be no problem to have a lawyer demonstrating this copyright infringment.
IMHO, they might just fear that someone just points out that, despite the marketing guys' buzzwords, they just released a bunch of (ISO9k'ed, of course) crap, in which case it'd be better not to release any source code.
You only take one risk if you release something: Some hacker might just make it *far* better, which is gonna sell a lot of pieces of hardware.
--
Re:Question from a non-guru (Score:2)
1) Most devices require a kernel-level driver.
2) Kernel drivers may be linked with the kernel at compile time, or compiled separately and loaded at run time.
3) All kernel drivers must adhere to the driver interface required by a specific kernel.
4) The driver interface for the kernel does change; in fact, the interface has changed from 2.2.X to 2.4.0
5) When the driver interface changes, the kernel developers must modify every driver in the kernel source tree to adhere to the new interface; typically, scripts are used to simplify this task.
6) Binary only drivers would not be fixable when the interface changes; and, the kernel developers seem to be rightly against the idea of maintaining an interface translation program for every binary driver that is using a deprecated driver interface.
7) Kernel developers have the most daily exposure to kernel drivers; having the source to those drivers allows them to fix bugs that they find, and it allows them to fix bugs that they might occasionally introduce by changing other parts of the kernel.
8) Binary-only drivers would require that the kernel developers become paper pushers, forever prodding hardware companies to update their drivers to conform to new interface and to fix bugs.
I have to agree with, what I perceive to be the kernel developers reasons, for demanding open source kernel level drivers in Linux. I see no reason to unduly burden our fearless kernel developers with the administrative tasks and garbage coding required to support binary only drivers.
Now, imagine an interesting scenario: say I work for a company that refuses to release the source to their driver for reasons regarding an intellectual property issue. What will happen to me, and to the source code, if I were to slyly release the source code for the driver under the GPL license? :)
-Harold
Re:Why not both? (Score:2)