Slashdot Mirror
Why Don't Companies Release Specs?
Mhrmnhrm asks: "With the recent activism by the OpenBSD crew focusing on release of documentation from the likes of Adaptec, Intel, and others, I'm left to wonder: why do companies insist on believing that by denying access to the specs, they somehow gain an advantage? It's not like telling a programmer how to communicate with the underlying hardware is going to tell them how it (the PCB/silicon) was designed, so why make this information secret?"
Apparently /. feels the same way Adaptec and Intel do.
The Doormat
If you're not outraged, then you're not paying attention.
Because it would cost them money to (1) write coherent and complete documentation and (2) review that documentation to make it safe and legal for public consumption. Why would they spend all the extra time and money to do that when it doesn't bring them any more profit?
Companies exist to make money, not to be good samaritans.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
Hardware Co. Rep.: That's right, Bill--figured it would be hard to go wrong increasing our potential market, at no cost to us. It's not like they can use the interface specs to build a card.
Bill: That's nice. You know, it'd be a real shame if your driver couldn't be WHQL certified, and users had to see a warning box when they ran with your card. Or worse, if there were mysterious blue screens . . .
Harware Co. Rep.: OK, I get your point, Bill. We'll cancel the release of the specs.
Call (206) 338-5780 COLLECT for information about a genuine BA, BS, MA, MS, MBA, or Ph.D.
To the people that pay them enough.
RTFA again for the best results.
It's all about control. The company's business model is to control the use of their product. In my opinion, a now failed business model.
You can't talk about Wikipedia's flaws on Wikipedia
For one, I really suspect they presume (or seem to), the implementation details can be deduced from the API's. Or at least that someone might reverse engineer their hardware, making one that's similar and compatible.
I don't know.
I think it just has something to do with protecting information. I think people find it easier to compare products when the specs are right out in front. It may not be the correct way, but if i saw two products natually i'm going to go with the one that has better specs. But what if the programing or something that is does specially on the board that changes the way it functions and it's actually faster. Most companies don't want to share their hard earned secrets.
The less they tell me, the more I want to reverse engineer it...
why do companies insist on believing that by denying access to the specs, they somehow gain an advantage?
The reason is that the ones with pointy hair are running the show and they don't really understand.
sudo eat my shorts
Greed, Uncertainty and Doubt.
Nough said!
... the more common problem is that the hardware people paid to have their drivers and stuff written for them and that a great deal of their product's functionality is, in fact, within the driver rather than within the device or firmware. These drivers are then restricted by the agreement between the driver-writing entity and the hardware maker... or so they claim. ATI apparantly has this difficulty which is why we can't get really good drivers for Linux just yet.
they dont want the world to see how crappy their design is...
...I think it's just called "covering all ends." They don't want the chance out there that something they release to the public is going to somehow come back to bite them in the butt. If someone DOES find out that they're using "something" that's not as good as "something else," there could be a marketing blitz to undermine that company... That's just one of a lot of scenarios.
Broadcom is also a big fan of not releasing much in the way of specs, even to its customers. My company has used some of their demodulator chips for years and had to beg to get some detailed specs on how to interacts with a chip in ways that it was not explicitly advertised as capable of doing (even though they admitted it was fully capable of what we wanted it to do for us)... later, when that chip became obsolete, they released a drop in replacement for it... a drop in replacement provided you were using the advertised features, things we were using, but plenty more things too suddenly went into limbo. The documentation on the new chip is ~ 1/4th the size of that of the original, so quite often we go back and forth between them, trying things that worked in the old one, hoping they still work in the new one.
Oh yes, demodulators are hella fun!
Help Brendan pay off his student loans
A portion of the manufacturers who usually come under fire for this kind of behaviour are those who make wireless LAN cards. In their case, at least, it seems to be insufficient control built into the hardware to prevent use of the radio device in ways that would make the product violate FCC codes (or other 'bad' effects). Because they costcut by moving functionality into the software winmodem style, making the hardware more straightforward for design and manufacture, the secrecy of the specification and interface is neccessary.
Business Voyeur
1. sometimes the companies don't even have documentation because they've never bothered to write it themselves
2. the company has gotten itself locked up into some NDA bullshit
3. the hardware sucks so bad they don't want people to have documentation proving how shitty it is (as is the case with Adaptec)
vodka, straight up, thank you!
Because they don't want people to buy their products!
Now try a harder question.
When they do publish datasheets, why do they omit important parameters, and get the dimensions wrong?
Sent from my ASR33 using ASCII
You can't even do that right.
I don't think that it is so much a matter of people being belligerent, as not wanting to be the guy left holding the bag.
Do you imagine that the person who makes this decision in a typical case is an MBA or a EE? Your argument about specs and silicon means little to this guy.
Unless and until there is a big, juicy piece of profit to be made there is little incentive to "give away" any of the companies property.
-Peter
...everyone would have hard-ons and no one would make money!
"It's not rocket science, Smithers! It's only brain surgery!" --Mr. Burns
their PC business is stronger than ever
The IP that they are trying to protect is 1) largely in the driver software and 2) any driver that doesn't use the technique is likely to suck. So, either these companies give up trade secret protection (not likely), they provide closed source drivers (nvidia), or the flip OSS the bird.
It's not like this is some great mystery it's just people trying to what they *THINK* is best for themselves.
You might argue that they're wrong about the conclusion but it's no great mystery as to how they arrived at the conclusion.
You are not a beautiful or unique snowflake -- but you could be if you got off your ass.
My purely uninformed guess (which is at least as good as the guesses of many) is that companies consider such things trade secrets. (Why? Who knows?)
It must be Windows. It needs half a gig of RAM and a hardware-accelerated graphics card just to run Solitaire.
Maybe because you asked slashdot instead of hardware companies? :P
It's because of fear of lawsuits, not a desire to hide their chip interfaces. There are just as many bad hardware patents as bad software ones. By controlling spec release with an NDA they stop the law firms from searching for violations of these bogus patents.
The damage from keeping hardware specs out of open source hands is tiny compared to getting a $400M judgement for patent violation.
Trade secret laws prevent law firms from forcing spec releases without pretty good proof of a patent violation.
Thoughts that occur:
1. Fear of the costs involved in supporting a bunch of people contacting them with questions which can't be answered by your typical "pot plant with a script" they sit on the helpdesk.
2. They don't have a problem per se, but there are so many licensing issues tied up with the hardware itself and its drivers that to release the specs would be a legal minefield.
3. Cynical view: their hardware's very nasty, they know this, they don't really want the rest of the world to see the number of workarounds for this they've had to write into the driver.
4. Even more cynical view: Their hardware doesn't actually do much, it depends on the driver to do almost everything. A bit like WinModems, only applied to other addons.
Open Source is just a gesture unless it's on open hardware. Make your own computer components! It's easier than you think!
I had to work with the technical support department of a printer manufacturing company (the names have been excluded to protect the un-innocent). Upon asking for specs so that I could write a ghostscript driver, the tech advised me that I could download such a driver for USD $9.95 -- after all, they make money selling software. When I responded that I had already fattened the company's coffers by buying the printer I received a "you wanna download the driver, or what?" kind of response. Thankfully, googling the printer manufacturer/model got me the information I needed for free (along with a ghostscript driver all ready to be built into ghostscript). Score: google,1 printer mfr.,0.
Free Specs!.
Similar in nature.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The most convincing argument I've heard against releasing specs are that it leaves the manufacturer all the more liable to a legal suit from a competitor, or a patent shakedown artist.
This being SlashDot and all, I'm sure you know the party line when it comes to (bogus) patents, intellectual property, and lawyers.....
And while we're on the topic:
Q: What's black and brown and looks good on a lawyer?
A: A doberman.
It's not like telling a programmer how to communicate with the underlying hardware is going to tell them how it (the PCB/silicon) was designed
Can you verify this? I'll be honest in saying I have no idea one way or the other, but unless you can give a 100% guarantee that it won't be possible, then you'll have to live with the fact that almost every hardware company does tons of reverse engineering to find out how their competitors do things (unless they're patented... and in the case of usabilty/look/feel, it's hard to patent that). And it works... look at how many knock-offs of generic designs there are out there.
Same thing in the software industry... for example, thought seems like a daunting effort, but SAMBA says to have RE'd the SMB protocol without any internal docs.
So it's possible (to lose your design), and company officers (CxOs) who are BOUND BY CHARTER to maximize the companys profits must say they did appropriate due dilligence to try to prevent any possible "loss". Note, that in FOSS, there is no charter like that, and so you see a lot more "cross pollination". Perhaps the entire future of innovation is bound to places where there is isn't a charter to "maximize profits at all costs"... or investors that are smart enough to let officers do the right thing (yeah, as if that'll ever happen!)
Make sure everyone's vote counts: Verified Voting
a lot of hardware vendors dont provide full documentation probably because Microsoft doesnt want them to. the last thing they need is some linux hacker coming up with a competetive driver.
-- Betting on the survival of the media industry is a serious risk. I advise investing elsewhere.
How long ago was this? Didn't Intel and AMD just sign a new patent-sharing agreement extending the previous 25-year-old agreement that allowed them access to the features each one developed?
I don't recall Intel ever getting mad about AMD using anything more than the chip names.
You can never go home again... but I guess you can shop there.
It's not like telling a programmer how to communicate with the underlying hardware is going to tell them how it (the PCB/silicon) was designed, so why make this information secret?
Not only that, it would make the hardware more useful in the long run, and thus, more appealing.
I also wonder why don't they open-source the firmware.
For example, my Sony digicam.
There are a lot of improvements that could be made to the interface, the camera could be a lot better with an community-improved firmware. One example: I would like to setup it to take one shot every seconds. Another: mass resizing photos. To delete, you have the option to select the thumbnais of the photos, then delete them all at once. If my memory fills and I need to take more shots, resizing down existing photos is a good workaround, but doing so one by one is a pain.
They sell hardware, not software.
Because marketing their hardware to the open source operating system market is NOT part of their current strategy. It's that simple.
I can't resist adding another reason from personal experience. Some years ago, I took a new job as an IT manager at a financial services company. (Names are omitted to protect the guilty.) One of the branch offices was developing a new trading system for international derivative securities. I thought that was quite interesting, and asked to see the data base schema (derivatives being sort of a specialty of mine).
I got a lot of run-around, and was told it was highly confidential since "if someone sees the design, he'll be able to figure out our trading strategy." ME thinks, "This must be some data base."
I eventually got a copy. They were right to keep it confidential: anyone who saw it and knew anything about the business would have realized immediately that they didn't know what the fuck they were doing (apart from spending money like a bunch of drunken sailors). We closed that operation a few weeks later.
I'd tell you, but then I'd have to kill you.
Liberals call everyone Nazis yet they are the closest thing to it.
Now, if you're not Microsoft or Novell or RedHat but merely Jow Blow, it's not easy to even get into the position where you can sign an NDA.
What you could do is have business cards printed and stationary printed and pretend you are an OEM manufacturer in the embedded systems market or something.
But they see through that fairly quickly.
For instance, Intel will come to any meeting with four people (one technical guy, one marketing guy, one legal guy and one product manager) and it looks kind of funny if you're sitting there by yourself.
Also, usually they will want to come to you and it doesn't look too good if invite them into your office, your office being the rec room in your parents' house.
Dedicated Linux servers (root access) $45 p.M.
This criticism assumes these companies have "the spec." They may not give it to you because they don't have it.
You would be surprised how poor the documentation is at many companies.
Video and sound card vendors need documentation from MS to write drivers. MS would ordinarily want big bucks for that, and the vendor wants to have something he can offer MS instead of money. So he keeps his interface a secret and offers that information in exchange. So MS and the vendor both sign non-disclosure agreements and exchange documents. It makes the vendor feel good to know he is involved in an equal exchange with MS, and not just a supplicant/customer. This benefits MS if it slows open source driver writers but I don't know how much effect there is. It might be small since Linux/*BSD machines are mostly servers, and don't have fancy video cards or sound cards. On the other hand, it may have helped keep Linux off the desktop and out of the home.
At the moment only the network card vendors lose anything from keeping the interface secret, and they don't lose much since the Linux kernel usualy ends up with decent drivers anyway, and if it doesn't most users can't tell the difference anyway.
Knowledge is power? And it removes some of the dependancy on that company. Open the Word format fully, and up would spring fully interworking Word clones in months.
Get your own free personal location tracker
I have often wondered about this myself, back in the day of the Apple IIs and TRS-80s there were almost always hardware specs available because that was what you used to program your application with. There were no drivers or OS abstraction layers, there wasn't enough memory or speed to do that so your program just talked directly to the hardware.
The first time I realized there was a problem was back in the 90s when my brother was trying to load up Linux on one of his machines and complaining that his video card wasn't supported because the people who made it (Diamond Multimedia?) wouldn't release any specs and people were having to reverse engineer how it worked. That seemed crazy to me. Back then it wasn't just a Windows world either, OS/2 was still around and DOS apps were huge. It boggled my mind that anyone would hold back information like that because releasing programming specs would encourage third party application development that made use of their hardware and ultimately boost their sales!
Sadly these days no one seems to care as long as the vendor has a Microsoft Windows XP(TM) driver available, even if the driver is half-assed and crashes some times.
In many cases there is a silicon bug or other hardware bug, and one of the advertized features of the part does not work as it should (or at all). The driver compensates for this bug by jumping some hoops if it can. If your ethernet card doesn't support jumbo-frames correctly, would you notice? Probably not. If your video card doesn't do blitting in the negative direction of overlapping segments with alpha transparency, and the driver works around it, you'll likely never know. But if Tom's Hardware Guide tells you that this product doesn't support some feature which is a standard, you'll probably look elsewhere.
In some cases, the bugs are such that there is no safe way to work around them, and the driver just tries a best-attempt to fix it. In this case, the company has the choice of scrapping their current crop of products, or just not telling you about it. If you as an end customer knew that under such and such conditions (which will probably never happen), this device will do something bad, you may not be so willing to buy it.
The more you specify, the more you want to support. Most ICs today have lots of modes and hidden features, and sure it would be fun to enable them, but once they are documented then company gets stuck supporting the features, worrying about backwards compatibility, etc.
The other point is that for most IC companies, revenues are driven by a couple large customers, which are of course supported well. The cost of supporting the remaining 80% of customers is rarely justifiable.
If you can't get a full spec, I bet you aren't a >10% customer!
But it sure as hell will tell a hardware designer.
What a machine does is how it's made.
KFG
Even if they don't mind AMD using them, what about all other companies?
I have a really elegant proof for Fermat's last theorem. If this sig was only a bit longer...
Does anyone seriously doubt that they DO?
Andy Grove (ex CEO of INTEL) described how MS prevented INTEL from including certain features in H/W. Andy's reaction was life is too short to spend it fighting MS. This was INTEL not some much smaller niche player.
At places I've worked there are usually 3 reasons.
1) Design documents are written pre-release as marketing info before silicon is made. And no one wants to spend the money to go back and fix the document to how the silicon was really built.
2) A lot of silicon designs are rented IP. And there are contractual reasons for not releasing the disign information.
3) Support costs. It costs money to keep documents current and respond to document errors.
<rant>
With that said, we actually do get decent specs on individual chips or chipsets, they are always in just paper of PDF form. Even the most complex devices (UARTs, ethernet controllers, etc.) simply come with a Rosetta stone of diagrams. Then we start the regular cycle: I take the diagrams, decode them, build up a low layer of software to talk to the thing, add more stuff to exercise the features we want, test it, and finally integrate it into a WinCE/Linux/Tornado/whatever driver that does what we're using. All this despite the fact that they ship development kits with binaries (usually Windows or DOS programs) that already talk to the stupid things.
On several occasions I have told the sales guys at hardware vendors that providing source code to some chunk of software that simply does some basic communication with the part would give it big brownie points in the selection process - save us a month of programmer time and you bet we'll think hard about your chip. When I ask if they could part with some of the stuff to help us skip steps 1-3 above, they always give a uniform NO. It doesn't matter what NDA we've signed or a if we are willing to take the code stripped of features and with no warranty. Sometimes I'll get sympathy from application engineers instead of sales droids, but whenever they try to get approval up the food chain they get shut down.
I understand that source code is an incredibly valuable asset (heck, I write the stuff), but why don't hardware/chip vendors realize that handing out or (or selling it cheap) helps sell chips? After all, the stuff's worthless unless you actually get your hardware out there to be used!
</rant>
Whew! That feels better. Anyone from the hardware manufacturing end want to chime in?
"Prepare for the worst - hope for the best."
I only buy hardware that comes with specs and open source drivers. In terms of quality that's usually better hardware anyways. The only exception I've ever made is my Nvidia card. If we all stick together and only buy products that comes with specs and drivers this will teach manufacturers a valuable lesson and we'll see all products become open and well documanted very soon.
Among -many- reasons...Company A writes a driver and designs a video card, publishes the specs- Company B comes along, designs a card that works with that spec, and gets driver development for free.
I find it hard to believe that OpenBSD developers don't understand this. I think it's more likely that they're playing dumb to portray hardware developers as "evil". If they don't feel like sharing their toys with OpenBSD, fine, it's a free country...but for god sakes, stop whining about it. Theo comes off as an egotistical bastard when he posts (grossly paraphrasing), "look at how IMPORTANT we are. HOW could you POSSIBLY not want to work with us. See, I'm going to get you in TROUBLE by telling anyone who will listen, just how UNFAIR it is that you won't give us specs on your hardware." My favorite bit is when he starts talking about X million dollars in sales Adaptec could have had, and how it's "their loss!" Guess what, Theo? It's a double-digit BILLION dollar market. None of the major players really give a hoot about OpenBSD.
One wonders if Theo spends a lot of time telling women's answering machines how great he is and why said women should be dying to go out on a date with him- and when he gets a call back saying "fuck off", his response is "your loss" ;-)
Please help metamoderate.
You're telling me that they don't have internal documentation anyway?
Internal documentation is written for people who already have secret clearance within the company, not for publication. It would take a lot of effort by highly paid lawyers and technical writers to clean up a secret document for public consumption.
With wider compatability, they allow their marketability to improve.
More than likely, the lost profits from not reaching the <10 percent of the market willing to pay only for devices with public documentation are less than the lost profits from incurring the expense of cleaning up internal documents.
I currently have no clever signature witicism to add here.
I have experience with a few different companies that make chips for PCs. I've found that the most common reason for keeping specs proprietary is patent liability. Areas like computer graphics are minefields with thousands and thousands of patents held by unfriendly entities. If you publicly release a detailed spec for your graphics chip you are inviting these unfriendly patent holders to look for potential litigation.
It's not like nVidia and ATI are looking for reasons to sue each other, it's more about some no-name holding company looking to litigate something like Cadtrak's XOR Cursor patent.
This might also be a competitive thing for Microsoft since they own a big pile of 3D graphics patents from SGI. Microsoft might take legal action against a chip supplier that publishes a spec for a 3D graphics chip that violates one of the old SGI patents.
In my experience most tech companies are now pretty hip about linux and free software, but the potential downside holds them back from releasing specs to the community.
jeff
The ISA (Instruction Set Architecture) is the specification that is needed before writing an OS, compiler or any other low-level software for a given CPU. It's no secret, especially for a very widely used architecture like x86.
In fact, there's this.
Don't a good number of companies give what are essentially specs ( possibly bundled with a few easily reproduced tools ) under the guise of a licensed developer program or some such?
The advantage is that opening up the underlying data actually promotes buyer lock-in. If they integrate, they are happier, and make the seller happier by locking in more.
More mindless Slashdot anti-Intel FUD. Intel is very eager to provide anyone with complete documentation of their ISAs for all of their processors -- X86, Itanium architecture, XScale, etc.
In fact, last I checked, they even offer to ship you printed and nicely bound books for FREE.
It's the same with any processor manufacturer.
I worked for one of the companies mentioned in the article lead-in, Adaptec, and tried to get an in-house linux driver released for on of their ethernet NICs. Always their answer (pretext?) for not releasing specifications was the same -- that to release specs without "support" would somehow be wrong or bad for the customer and reflect badly on the company. (Exactly how it would could so this was never very clear to me. It was almost taken as a truism.) Thus I faced this paradox. Free software developers were asking me for specifications, but my managers at Adaptec were refusing, in the name of "support." I still don't get it.
I'm not writing documentation, but seldom help with some technical details and help with translations.
Guys, just to understand the problem you have try first write something. Writing good documentation would require someone who can think straight and clearly. And as you can imaging if company got such guy/girl - s/he will be busy doing product itself, rather than documentation. That's first.
Second. On PC market change of technologies occurs every half of year or something like that. Writing documentation, getting thru all bureaucracy for confidential document to be released will be precisely about this half of year. In other words, when documentation is ready - it is already outdated. You can btw notice that industries with longer release cycles normally end-up with decent documentation - they have time and money. Having no money you cannot afford longer release cycle. Telcos are good example of that. Industrial automation is another one.
So PC industry is sort of its own worst enemy. Tight competition force producers to save where possible - e.g. optional component such as documentation. If you have some bright heads, producer can manage to update product line more often - edging against competitors - but again bright heads will be busy with product release, rather than its documentation.
Having dedicated personnel to handle documentation is just expensive.
P.S. One more problem is when product is partially based on some licensed third party development. Most small producers have to license things, since they cannot develop everything in house. Than it happens that documentation ends up with hell a lot of copy'n'pasting from third party one. To release that you have to get a permission from third party: but in most situations you will find out that third party has licensed some parts itself. In the end no-one just want to risk releasing the documentation, especially in litigious U.S.: most companies when finding their parts in someone's else released products may start asking for fees. With all consequences. Hiring experienced attorney for going thru all this licensing mess - and getting clearance from all involved parties - will cost a lot money, most producers just not able to afford.
All hope abandon ye who enter here.
It's not like telling a programmer how to communicate with the underlying hardware is going to tell them how it (the PCB/silicon) was designed, so why make this information secret?
Granted things like video cards and ethernet cards and stuff are significantly more complicated than say, guitar stombox effects and amplifiers, but electronics are electronics. It is not entirely impossible to look at the part itself and map out all the traces on the board (gets harder on multilayer boards, but it's still not impossible). Parts are parts, in the case of resistors, capacitors, diodes and stuff, and they're all marked and/or measurable. Lots of circuits have common subcomponents that are 'universal'- no different than linked lists or binary trees are to programming. Maybe you'll see a proprietary IC, but its manufacturer might have the specs available- I haven't seen an IC data sheet yet that doesn't have an internal schematic of the IC. You might be able to buy them from that manufacturer directly, or build the equivalent from other ICs and parts.
Far as I can tell though, most ICs are pretty standard and available.
So then... releasing their specs or not, it makes no difference on whether or not someone could figure out how their card works and/or clone it.
Yes I realize this takes a lot of work and man-hours to do, but surely this happens in industry of all sorts all the time.
do() || do_not();
Unless and until there is a big, juicy piece of profit to be made there is little incentive to "give away" any of the companies property.
How about having people pledge to purchase a total of several hundred units of a piece of hardware on the condition that sufficient documentation is made available to create and publish a Free driver?
(I do IT work in the medical field)
We do have the formula to that, and probably every other drug.
I belive it works like this:
They get a patent. and no one else can make the drug for so many years. and so they keep the price high to both make money and to make back the research and testing money. After that, the patent expires and then all the cheaper version come out.
Viagra is really a drug called "Sildenafil". comes in strengths of 25, 50 or 100 milligrams.
A quick google shows wikipedia to have the best answers.
Sildenafil
Chemical formula
C22H30N6O4S C6H8O7
_JS
WHO CARES!?
8======D ~~~~~~~
Company B makes improvements in their product in order to make theirs more appealing, changing the open-sourced driver slightly to make it work. Company A makes improvements in their product in order to make theirs more appealing, changing the open-sourced driver slightly to make it work. Company B makes improvements in their product in order to make theirs more appealing, changing the open-sourced driver slightly to make it work. Company A makes improvements in their product in order to make theirs more appealing, changing the open-sourced driver slightly to make it work. Company B makes improvements in their product in order to make theirs more appealing, changing the open-sourced driver slightly to make it work. Company A makes improvements in their product in order to make theirs more appealing, changing the open-sourced driver slightly to make it work. Company B makes improvements in their product in order to make theirs more appealing, changing the open-sourced driver slightly to make it work. Company A makes improvements in their product in order to make theirs more appealing, changing the open-sourced driver slightly to make it work.
:/
There's no way the lameness filter will let that by, is there?
-- 'The' Lord and Master Bitman On High, Master Of All
Because it would cost them money to (1) write coherent and complete documentation and (2) review that documentation to make it safe and legal for public consumption. Why would they spend all the extra time and money to do that when it doesn't bring them any more profit?
Close, but also consider that driver development is a significant part of the cost of a piece of hardware. If the hardware specs were freely available, then a clone manufacturer could simply make their hardware perform according to the spec and thereby be able to utilize the drivers for the original hardware, cutting out a large expense on there part. Thus allowing the "clone" manufacturer to undercut the original manufacturer. This is a real problem and given this, it's not too hard to understand why they are so protective.
Not to say there aren't other reasons already mentioned here, but the most common situation I've seen (and I got quite a few specs released out of DEC in the early '90's), is that the specifications often have a mixture of information considered proprietary (e.g. detailed logic design) and the programming information.
Seldom were there a nice set of documents, partitioned between programming and logic design.
So you have to track down the right documents, edit out the stuff that hardware folks are worried about, and get the right sign-offs. And you therefore have to deal with whatever random document preparation system was used by the engineers to do the documents.
This all turns out to be a fair amount of time, trouble and hassle.
So even if there aren't other paranoid concerns, it is harder than one might naively think.
I'm not even going to respond to the inflammatory word "threaten". But I do want to point out that asking people not to include a feature in their product -- one that you may find actively harmful or disruptive to your own customers or yourself -- is different from asking people not to publish documentation.
...there are no specs.
Often products are created & sold based on some back-of-a-napkin drawing that a manager handed to development. I've been fortunate in my career -- I've been lucky to get them on notebook paper. It's much nicer than trying to figure out what was drawn through the martini condensation stains...
Chip H.
Among -many- reasons...Company A writes a driver and designs a video card, publishes the specs- Company B comes along, designs a card that works with that spec, and gets driver development for free.
Company A then sues B for copyright infringement for using their drivers.
If they don't feel like sharing their toys with OpenBSD, fine, it's a free country...but for god sakes, stop whining about it.
This is called applying public pressure - give us what we need so we can interoperate with your stuff or we'll go play with this other company that will.
My favorite bit is when he starts talking about X million dollars in sales Adaptec could have had, and how it's "their loss!" Guess what, Theo? It's a double-digit BILLION dollar market. None of the major players really give a hoot about OpenBSD.
You'd think that Adaptec would be willing to spend a few $10k in order to gain $5M in revenue. Hell, I'd do it.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
That means companies like Broadcom (they tend to not have any drivers for linux) won't get chosen by anyone wanting to run Linux, and thus will lose money as people will chose non-Broadcom hardware.
I'm not sure about all hardware, but I'm sure part of the reason Broadcom doesn't openly document their WiFi hardware is because they use software radios, where all of the channel number to frequency conversion is done in the driver and not in the hardware.
This would mean that someone writing an open source driver would have to properly tell the hardware what frequencies to use--something that shouldn't be a problem.
However, it also means that you could easily tell the radio to broadcast in frequencies (and possibly powers) that aren't within the spectrum their FCC license covers. IE, people could do things they aren't supposed to and maybe Broadcomm is worried about law suits.
--
Don't fight Firefox! Let FireFox fight YOU!
What. The. Fuck?
We recently went over this in my computer organization class.
You need to leave whatever school you're going to.
Immediately.
Seriously. It's obviously a complete waste of money. Do it now before your head gets any more messed up.
Intel is reluctant to release their ISA documentation
Nooooo they aren't.
Without releasing ISA documentation, people can't program your fucking CPU. Yeah, I'm sure that's exactly what Intel wants -- nobody to code for it. Great business plan. Where do I sign up?
Interesting? Jesus christ on a cracker, the mods are fucked up today.
The answer is because the Linux market is too expensive to support for the increase in sales that it would generate. The cost to create open documentation, and then support it, is much higher then the small increase in sales that it would generate. I'm sure closed hardware companies would release specs if they were paid, but such a cost would be prohibitive to the hobbist Linux programmer. (For those of you who are too young to be professional engineers, it costs roughly $100 / hour to get an engineer to work on something. Just providing open documentation and support would require at least 40 hours of an engineer's time.)
When I asked this question to a bunch of suits they told me a story (no idea if this is true) about a time when Sun accidently released the .h file to the driver for their high end video card. Six months later some no-name company released an exact cheap clone of their video card. Apparently they were able to reverse engineer the chip from just knowing what registers where what based off the header file.
While fears like no longer apply to chips as complex as we use now, stories like this don't seem to ever die when passed from one CEO to another.
Who says that spending that money elsewhere doesn't mean more profit for them elsewhere? If they spend X dollars on Y, that's X dollars they could have spent on Z. If they think Z will be greater than Y, guess where the money gets spent?
It is -supremely- arrogant to assume you know more about marketing than people who have studied it, put it to use, and are good enough at it to be working for a major international corporation. I'm not saying they're perfect, but it's kind of like sitting up in the middle of an operation and saying to the surgeon, "hey, isn't that cut a little deep?"
Please help metamoderate.
Developing winmodems, winprinters, etc is not cheap - it requires throwing away a lot of the company's IP for a start - and eliminates the Unix market (which is not insignificant), so is unlikely to be an idea coming from modem/printer manufacturers.
How much support does Windows have for MCA, EISA and other busses? For that matter, has Microsoft's firewire driver ever really worked properly? Compare that with their response to USB and "plug & pray" technologies. Isn't it pressure on hardware manufactuers, when they know that Microsoft gets to decide what 98% of all home users can use?
Microsoft pulling support for the Itanium 2 and going with the AMD Opteron is also driving a specific path. They've got a working 64-bit compiler for the Itanium 2, if code is 64-bit clean and is designed for their compiler, then a 64-bit system is a 64-bit system is a 64-bit system. Supporting both is as easy as recompiling. If they distribute on DVDs, there won't be that many more disks to cover both processors than you have now using regular CDs.
No, Microsoft has considerable control over what the hardware market is willing to do, whether it exercises that control openly or in secret, directly or indirectly. All take their orders from Redmond.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I've worked on a few projects with this level of HW/SW co-design, and the truth is that actually knowing what's going on at that interface certainly could be useful to competitors. That's not true in all cases, but it is is some.
Then there's the time taken to actually produce documentation that's understandable to someone outside the company. This is a big deal. Releasing really poor documentation would be a P.R. disaster. You might be looking at more than a month of highly-paid engineer's time.
You're also faced with the possibility of having to support the people who try to read the documents.
Companies aren't evil. They just don't see the return-on-investment.
Of course, I mean the openess of Intel back in the 80s, when all hardware vendors were 100% proprietary and Intel made this cheap thingy nobody cared about called PC releasing full specifications for anybody to implement peripherals and even shipping kits so you could assembly it yourself.
All those proprietary vendors didn't even laugh at Intel, they didn't even noticed. Today, Intel is the leading chip vendor (or was, till some years ago).
I believe the main thing that makes corporations not release drivers is FEAR, big vendors have a lot to loose, they FEAR to loose it. Intel when it was small didn't have much to loose, so, there wasn't much FEAR in "trying to do something different and see if it works". Furthermore there's FEAR of making Bill angry and I know see that there's FEAR to stupid patents.
Pupeno
Company A then sues B for copyright infringement for using their drivers.
The point of this argument is that better OSS drivers could be produced with open specs. It'd be kinda hard to get a judgement from someone who explicitly allows distribution.
Even if they were to not use an OSS driver, as long as they didn't ship the driver with their hardware and just said "d/l it from company A's site here", they'd be in the clear criminally. The only offense they might have done is an EULA violation.
Of course, this ignores any patents that might cover the card.
You'd think that Adaptec would be willing to spend a few $10k in order to gain $5M in revenue. Hell, I'd do it.
But spending that few $10K (if that cheap) comes with the risks of giving competeing companies the extra bit of information they need to improve their product (at the expense of product A), etc.
See other posts about the economics for other risks some companies would face. (If revealing the spec would reveal they've violated someone's patent or agreement, expose a vulnerability, etc.)
- If you can make money without releasing specs, then why do it?
- If you release specs, then you have to make sure that everything you sell fits that spec exactly. Pretty bad idea to voluntarily decrease the sellable ammount of what you produce by setting unecessary rules for yourself. I think this is this is generally more true for commodity hardware, whereas you generally see better documentation for more expensive items - commodity products are (economically) more sensitive to yield issues.
- There will be lots of people who still don't get how to use the device, and you'll get all sorts of crap communication from people who think your spec is wrong, when really they just can't figure it out. Limited release of documentation ensures that, for the most part, only people with some sense get access to the stuff.
Now, speaking of intel, they're actually a hell of a lot better than VIA when it comes to documentation IMHO. I was working on a project last summer where I needed to access some of the chipset's boot-time functionality. Intel's documentation for their chipsets are easy to download, but VIA? Nothing unless they approve you first (and they probably wont unless you commit to buying a lot of product).`which fortune`
If you publish your protocols, you show the weaknesses. Much weak stuff is made, 'cause it just does it's job.
Because most times product doesn't match specs.. then you can fall into liability issues.
Whoa. Whole lotta anger there. Easy on the personal attacks; we're just talking about software.
If I'm to be a customer of a hardware vendor, I need to be able to run their hardware on the OS I'm deploying - which for me in many cases is OpenBSD. If hardware vendors want to hit the market I'm in - that is, non-commercial-OS servers usually in security- and/or performance-critical environments - they'll release their spec so a driver can be written for the OS I deploy. If they don't, that's fine - no lost sleep. I'll just pick another vendor.
This isn't a question of good and evil, as we so often forget; it's just a question of business decisions and preference.
All I know is that my Adaptec 2400 card on Sarge works, but I can't check for failed drives unless I reboot. Rebooting once every 3-4 months on average, this presents a problem. Raid 5 with hot spare may save my ass, but with previous experience with IBM deathstars having multiple failures within days of each other, I'm more than a little worried.
Took a look at the online docs for Adaptec on Linux a few days ago, that's what killed my latest uptime. Tried to modprobe a module as suggested by the docs so raid tools or whatever monitoring app works, but it caused my system to freeze. Run reiserfsck on multiple partitions/multiple drives, then leave it alone instead of messing with it. Just can't see the condition of the array or hot spare.
From what I've seen elsewhere on Adaptec and community support, and from what I'm reading about with Adaptec and OpenBSD, its obvious I made a mistake in choosing my raid solution. Probably go with a different company next time for hardware raid (raid 5, bootable), and Linux raid for raid 1 or non-bootable, non-system raid.
If better access to the info helps this situation, go team!
They don't release the specs because the hardware is generally full of bugs that they work around in their drivers. Different versions of the hardware have their own bugs and work arounds. Sometimes I think they're too embarassed to release the specs for fear the would would see what a dogs breakfast some of their work amounts to.
Further most of them have "specs" which barely qualify for the name -- often driver writers will go read the RTL, or talk directly to the hardware guys to figure out how something works -- often much of it is not written down, and usually not in one coherent document that could be called a spec.
I know this for a fact about several producers of hardware that serves various purposes -- who, for obvious reasons, I shall not name.
Others are anal about getting things right and writing great specs -- even if they never publish them -- But I think they're in the minority.
Ian Ameline
Have two sets of APIs, a proprietary, protect-yourself-from-lawsuits-and-imitators layer available only by non-disclosure, and a higher-level, perhaps slightly-less-functional, API which is public.
Put a translation layer in an on-chip ROM. Calls made to the published interface will work, just not blazingly fast and maybe not all features.
As a bonus, other chips, particularly similar chips made by the same vendor, can use the same "public layer" so that new chips can use old drivers, albeit without new functionality. This gives you built-in long-term compatibility with OSes retired before the new chip comes out.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Wow, you're pretty hostile for someone who doesn't know what he's talking about. May I ask where you got your Ph.D. in computer architecture?
Intel used to diligently guard some of the features of the Pentium series, the famous secret "appendix H" for example. People were eventually able to reverse-engineer the information in the appendix (and these sorts of trade secrets have a way of diffusing outward in spite of NDAs), but nevertheless these features were not implemented in competing processors because the information wasn't widely available. I believe the Cyrix chip didn't implement 4MB pages, for instance. There are other proprietary features documented in the appendix like virtual mode extensions.
With great power comes great fan noise.
i think the other fault in the whole argument is that designing a video card (or most other hardware) to be perfectly compatable with drivers for someone else's card would be far more expensive than writing your own drivers.
Snowden and Manning are heroes.
Companies get sued if someone else finds out that a patent is being infringed. Adaptec, NVidea, et al would be exposing themselves to patent suits if they described how their stuff works. One of the hidden advantages of being proprietary is that then no one knows how you're doing what you're doing, so it's then hard for outsiders to put together a patent infringement lawsuit.
I was about to mod you insightful, but then I realized what the grandparent was probably talking about... the microcode. The microcode is a lot more important for recreating details. Pentium processors have a limited ability to fix silicon bugs in software. The microcode is in volatile memory, so it must be loaded on every boot by either the OS or the BIOS. It's top-secret, but access to this lower-level info might let you write a custom instruction (or not, I don't know how much the mechanism can change the operation)
An example microcode fix is for "High Temperature and Low Supply Voltage Operation May Result in Incorrect Processor Operation"
HIV Crosses Species Barrier... into Muppets
> ... the more common problem is that the hardware people paid to have their
> drivers and stuff written for them and that a great deal of their product's
> functionality is, in fact, within the driver rather than within the device or
> firmware. These drivers are then restricted by the agreement between the
> driver-writing entity and the hardware maker... or so they claim. ATI
> apparantly has this difficulty which is why we can't get really good drivers
> for Linux just yet.
As a former ATI employee (working on HydraVision some 3-4 years ago)
I can tell you that ATI's drivers are written in-house.
As a matter of fact, the formula for viagra is well-known. Even the synthetic pathway is not a secret. Pharmaceutical patents are never a patent on the drug itself, only a patent on a particular process to make the drug. Until the patent runs out, other companies cannot use the same process (although if they can find another way to make it, they can release the same product under a different name).
Software: "Oh, that'll be a hardware problem."
Hardware: "It looks like a software problem."
If a hw company invests tons of money into the controlling software (say, like a graphics card accelerator stack), it would be really dumb to release the hw specs because people would then clone the chip and leverage the originating company's software stack against them...
If the chip is simple, no big deal, but some of these "simple devices" have millions of gates nowadays, and tons of hours into optimizing the software that operates it at maximum efficiency. It would be sure stupidity to publish the hw specs so a runner up company could clone the chip.
That being said, I do believe that if a chip is dropped from a company's driver stack, the specs should be released. Of course, this is my personal opinion...
TurboD
The grandparent refers to the ISA, which is NOT the same as the microcode. Have an obligatory wikipedia link:
http://en.wikipedia.org/wiki/Instruction_set
Nope.
Intel has never published details on microcode except how to load it.
The grandparent explicitly stated ISA , and the fact that AMD and everyone else copied it.
There's no microcode system for any AMD or Cyrix or any other x86 clone for that matter, but that hasn't stopped anyone from doing what the grandparent was posting about - copying the ISA. Microcode is completely irrelevant to the discussion.
Yes it does. Haven't you ever read a datasheet that revealed something cool about the way a device works?
Sometimes, for performance reasons, the device interface cannot be too abstract. The API will often end up mirroring a device's internal architecture, possibly exposing something novel that competitors haven't figured out yet. Nat Friedman, in an interview, commented on how graphics card manufacturers are understandably reluctant about providing open source drivers because more and more magic is being done in software.
One possible solution would be to move the magic into the firmware (though some people would consider this unacceptable) and present an abstraction to the OS driver. This might work. Then again, this might be just as inefficient as creating the abstraction in hardware.
Another solution would be to make it easy for vendors to ship binary-only drivers. You don't even really need a completely stable ABI for this, because companies like NVidia get by fine with their compilable wrappers around binary drivers. Dell's DKMS might help out here.i think the other fault in the whole argument is that designing a video card (or most other hardware) to be perfectly compatable with drivers for someone else's card would be far more expensive than writing your own drivers.
Agreed. The way it usually works is that a chipset is created, along with a reference implementation. Manufacturers then use those drivers or modify them/add to them for their particular product. The only real exception i can think of is the generic VGA vards that proliferated shortly before windows took off.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
I just spent the entire afternoon looking for a webcam that we could use with linux for a project.
I tested just about every model avaliable... and none met the requirements, wich are work with linux and be recognized by Java Media Framework.
I know that there is a standart for USB MassStorage devices, so is just a matter of implementing ONE driver that will be compatible with every hardware that implements this standart.
Standarts make easy for developers to create drivers, and for vendors to make compatible devices. There are lot's of success cases out there, so why keep on creating non-standatized devices!?!?!
---- You know how some doctors have the Messiah complex - they need to save the world? You've got the "Rubik's" complex
I suppose that the company that developed the product will be more than happy to give the spec to a competitor so that competitor will not have to spend $10,000.00 - $1,000,000.00 developing their own spec.
Jesus christ on a cracker, the mods are fucked up today.
So is your choice of language.
this nation, under God, shall have a new birth of freedom. -- Lincoln, Gettysburg Address
It doesnt take a Ph.D to understand that both grandparent and you are both completely wrong.
Grandparent claimed Intel is (present tense!) reluctant to release ISA documentation because AMD and other x86 clonemakers duplicated their ISA in the past.
Wrong.
Intel is not (that darned present tense again!) reluctant to release ISA documentation.
Implementing the "secret" extensions in Appendix H wasn't required for a fully functional and even nicely competetive x86 clone.
And apparently Intel has learned their lesson -- if you dont document your chip, nobody will use those features. So, big freaking advantage it gets you. Woo woo, supar sekrit extensions nobody uses!
And if anyone does use those supar sekrit features, they will soon be revealed by anyone browsing through the disassembled object code, which happens often.
Two minutes penalty for correct use of "it's"! Unacceptable on /. !!!!
Looking through Google, it appears you are correct (thanks for that, didn't know about that one). However, the grandparent states:
Intel is reluctant to release their ISA documentation
In present tense, suggesting that Intel currently does not release any of their ISA documention, which is clearly wrong and quite misleading. So you can see where the confusion comes from.
Oh, I agree... I didn't mean my post to be construed in support for the overall argument...
If someone buys product X, and tries to use it under - say - Linux, and it:
doesn't work:
figures "tough luck, next time I'll research more - stupid me stupid me. Still, it works great under those supported OS's!"
it works:
thinks "great, kickass - this is awesome, this company is pretty cool. Oh, it was written by a third party - still cool"
it works - sorta / mostly / woops data corruption:
thinks "mother&!^$@( I'm never buying X again - screw company Y!" and the product is returned.
Yes - it's nice to provide support - but the first option costs them nothing and they make their sale. The other two cost - either in support, published public docs, or lost buyers.
cyn, free software and *nix operating systems enthusiast.
Dear bani,
I found your post insightful and interesting.
Unfortunately, you wrote "the mods are fucked up today". Today? Clearly, you are either insane or delusion, maybe both. Please get a referral from your primary physician.
Otherwise, terrific post.
Sincerely,
The one and only AC
R&D Costs for driver development can't be recouped
When BusLogic came out with their AHA1540/AQHA1542 compatible SCSI controllers, they did several things:
(1) They leveraged Adaptec's R&D effort on driver development so that they didn't have to spend their own money developing drivers.
(2) They avoid the effort of convincing Microsoft to ship with the drivers as part of Windows; never underestimate the barrier to entry a separate driver disk represents: for NT 3.51, you had to install the driver disk twice during the installation process, and a third time post-install to use a third party disk controller, and it was not well documented where or when NT 3.51 would reference the disk, not find it, and simply crash (you "just had to know").
(3) By making the card's interface compatible with an existing card, they avoided all the R&D necessary to get from a concept to a working interface.
So basically, BusLogic got a free ride on Adaptec's dime in a number of areas, and Adaptec was left holding the bag, having to charge a higher amount to recoup their R&D investment, leaving BusLogic to undercut their prices and steal their market.
That's not to say that I totally agree with Adaptec, or that bad designs which can't be safely exposed without risking physical damage to the devices (Diamond Multimedia video cards[*]) or legal repercussions (Oscillator/PLL tuned WiFi cards that don't have hard-wired frequency bands) don't exist, but I can certainly understand the position of companies who don't want to sacrifice hard-earned product lead-times, OS vendor relationships, or actual R&D results on the altar of public domain.
[*] Diamond, in particular, pisses me off, since any halfway decent software engineer could have separated the model and view from the controller, and made their cards both Open Source friendly and non-x86 architecture friendly, and the EE who wrote the firmware didn't.
-- Terry
I work for a hardware company that has experience with both releasing specs (AND drivers!) open source, as well as not releasing specs (or drivers) for other products - much to the gripe of the community.
I've recently asked the responsible person (I'm "only" an engineer) why we don't release the specs (or even drivers) for all products. The reasons were very different from what most assume here.
The baseline is, as a hardware company, you can't win! It's not as black and white as most open source advocates assume.
Once you release drivers (or specs) as open source, you are commiting to those specs (or drivers). People will expect the product to always work within those specs. This will prohibit the company to make changes to a product down the line without regard to compatibility or spec compliance. Thus a business decision (cheaper part etc) cannot be made anymore and the company cannot be as flexible with their products as they may be otherwise.
Also, as others have noted, writing specs (AND/OR drivers) is effort. I.e. it costs money. Once the specs are released, supporting those specs/drivers also costs money and puts strain on the company. As our experience has shown, there is not much of the often touted community involvement there. Instead of getting code/patches/comments back, often all we get is support requests and loud gripes when a product doesn't work exactly as it used to two years ago.
Lastly, the specs of some devices may allow driver developers to use the device in unapproved ways. This may pose a liability to the company that cannot easily be avoided.
This all makes giving away drivers/specs uneconomical and even more frustrating for hardware companies like ours.
On the flip side, there's not much income. As long as no large OEM (HP, Cisco etc.) has a business case for needing our chips to be open source, there is no incentive for us to spend money or effort into releasing the specs or drivers.
I'm personally affected by this (my notebook uses a chip from our company without open source drivers... I run Gentoo...), so I understand both sides of the story. But honestly, I found no way to refute the problems that are very real to our company.
It's a "damned if you do, damned if you don't" proposition. Release specs/drivers and you're yelled at for support or when things need to change. Don't release specs/drivers and you're yelled at because you don't help out the open source community.
I'm surprised nobody has mentioned the fact that competitors could read the specs, figure out what bugs (and workarounds) are present in the HW, and write benchmarks that make the hardware look bad (and theirs, good).
Fred Brooks tells us that software should be the implementation of the documentation. That is, write the documentation *before* the software and then code to that. There should be no functionality in the software that is not present in the documentation.
When I was a kid, we only had one Darth.
Independent of what Intel is doing, on a general level an ISA can justifiably be put under an NDA. Whatever leaks out by looking at the chip behavior can't be stopped but why release specs when the people you care about (compiler vendors) will sign that NDA. Now since the behavior will eventually fully leak, you could also argue that the NDA is not required at all. The NDA still buys you time.
You might ask why doesn't MS release full specs for the XBOX and their encryption algorithms. The only people they care to give it to are game developers or their partners. Again, why release it if you don't have to.
"why do companies insist on believing that by denying access to the specs, they somehow gain an advantage?"
I've worked for a couple hardware manufacturers and the reasoning behind avoiding open source and open specification support seems to vary slightly from place to place, but I thought I'd add these two points which I've personally experienced. While I don't agree with their justifications, I do understand their reasoning:
1) Closed specifications help hardware manufacturers hide flaws in their hardware design. Flaws that can be quite costly to resolve in hardware can be much more cost effectively addressed with software work-arounds that avoid triggering the flaw. Not wanting to admit to engineering imperfect hardware, the mfr. would rather keep both the flaw and the work-around a secret. They will list the new version as a "bug fix", but the public will never know exactly what the cause of the bug was. In the mfr's eyes, bugs are expected by the public and can be addressed with patches without raising any eyebrows, but known hardware defects can yield a weak opinion of the mfr's product line and overall capability.
2) Closed specifications help hardware manufacturers maintain control over their product's public image/reputation and support. The mfr would rather have a reputation for not being open-source-friendly than to have a reputation for having hardware which works questionably due to arbitrary programmers from around the world writing shakey code which causes the product not to perform up to par with specifications. The mfr also avoids getting stuck with answering questions from end-users who "downloaded such-and-such driver which should work, but doesn't - why?" The mfr is able to save money by not providing support for platforms that it does not specifically develop for, and is able to maintain their product's reputation by consistently demonstrating its full functionality and performance in the relatively controlled environment of supported platforms.
So is there something to gain? Yes: PR damage control, and a lower bottom line through reduced development and/or support overhead.
Hi,
Companies don't even need to bother with documentation. They could just release the Windows source under the BSD or LGPL license.
Of course this doesn't fix up the patent / NDA bullshit.....
If they don't release specs that usually means that you don't get good/tested drivers. That means you get (if you get at all) binary shitty drivers on some uncomfortable license.
So why to use it? Just choose something else - it is like common hardware (I presume from your statement).
If you run your favourite OS, which is the best and most valuable tool you can always switch the hardware. The hardware now is cheap and you have a broad choice. So if some company is offering a shitty hardware (what for you need HW without proper drivers?) just screw it and choose another company that fits you best.
Simple as that.
Think of your last software project: deadlines, last minute bug fixes, etc. Are API specs for your software ready in releasable form along with your software?
Well, it's no different for a lot of hardware: just because a company got silicon and just because someone managed to hack together a Windows driver that (barely) works doesn't mean they have anything approaching releasable specs that others can use to build drivers.
Corporations should be able to do anything and everything to make a buck, and unless enough consumers can organize a large enough boycott to hurt them financially, *AND* be lucky enough that the morons running the company realize this is why they are hurting financially, nothing should be done about it?
Corporations are given their charters to benefit society. When they are a detriment, it is the responsability of government to regulate them. Consumer protection prevents companies from selling me broken products, why shouldn't it prevent them from selling me products that I can only use in conjunction with other specific products? Or products which I cannot use anymore once they decide they don't want to write drivers anymore for new OSs?
Grandparent is just plain wrong.
The Open Graphics Project
> Goody for you. When you and your friends who think like you are enough of a market share for them to care, their practices will change. Have fun.
I can't believe that a comment as clueless as yours was modded up, but there it is, currently at "Score:5, Insightful." Amazing!
If you were to take the time to learn what was happening in the industry, then you would know that, according to recent statistics, Linux is present in 60% of Windows environments. In fact, from the same source, 20% of all servers run Linux.
Therefore, at least 20% of the hardware sold for servers must be compatible with Linux. And as much as 60% of all PC buyers may be including Linux compatibility as part of the criteria they use in choosing their hardware, for both servers and desktops.
And you're saying that it's not worth it for PC hardware companies to document their specs??? You're saying that those companies would rather lose up to 60% of their potential business, than to pay one guy for six months to gather, organize, and publish the specs??? Get real!!!
I think it is much more likely that those companies either 1) are afraid of doing anything that might upset Microsoft, or 2) are taking advice from people who, like yourself, are not aware of what is happening in the market.
Take your ridiculous words and shove them into someone else's mouth.
Corporations are given their charters to benefit society.
Oh, that's right, it's Troll Tuesday, I forgot. What a laughable statement. While I'd agree it'd be nice if that were true in the real world, sadly it isn't the way it is.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
The submitter evidently assumes that specs have actually been written independent of the design, as would be the case if the product was created through an organized engineering process.
Ha.
Hahaha.
HAHAHAHAHAHA!
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
A huge number of these sorts companies either have no specifications to provide or their specifications are merely comments in their code. Sound insane? That is the reality. I'd be willing to bet that the number of closed source projects that have specs are about the same as open source projects that have them: very few.
This is one of those days I wish I could take the mods over 5. I even have points today too. C'est la vie. Anyway, that was abso-fucking-lutely great.
Your basic problem is that you aren't thinking like a hardware person. Hardware people just fundamentally don't get how software people think there is an important distinction to be drawn between the software and the hardware that runs it--and, to be fair to them, they have a point.
An awful lot of what hardware vendors are selling these days is a hardware platform for their expensive proprietary software. Take wireless network interface cards, for example. When you buy a Wi-Fi AP from some company, e.g. Apple, the price you pay includes the cut they have to pay to the vendor of the wireless interface card they use in their products. What they probably get from the hardware vendor is more than just a steady supply of hardware to its factory line-- it's the chips, plus a code drop for the driver, a maintenance agreement, and a bunch of other goodies that are all rolled up in the contract at once. The price the hardware vendor charges is divided between a per-unit total, a per-calendar-interval total and sometimes an upfront charge. The accountants have a field day.
Remembering who is paying for what helps here. You are never going to get specifications for the hardware you buy at retail, because the people who make it are never in control of the whole package from sand to plastic wrap-- they have to buy and integrate pieces from other companies, who are providing more than just chips and a few pages of programming guide. As I said, those guys are providing a hardware platform for their proprietary software and they won't let the vendors of retail systems redistribute their crown jewels. It's really that simple.
jhw
Let's send some email to Linux magazines like Linux Journal and others, asking them to interview a few companies like nVidia, ATI, Broadcom and others about this question. Maybe if they think there's enough publicity pressure, they'd give useful answers. Then instead of wondering, we'd *know*.
What would you do when you saw Jesus Christ on a cracker? There was a recent news about someone actually finding just that! Confound my search, I can't find it, but someone else found Jesus...a cracker jack...
Stop the Christ Cracker Slave Trade!
Jesus H. Christ on a pogo stick! I want to see that!
Dude, Jesus is l33t. He's been everywhere; even on urinal targets.
without prejudice
Fine, YOU pay for what should be.
I, like many others get paid for doing what the customer/employer wants, and guess, what? They want stuff done, and often don't care too much about nice docs, as long as the product does what they are thinking right now. Of course the specs will change next week too, by the way.
I know that good documentation would be nice, but, I get paid by the hour, and if the paying customer wants to allocate my hours to some other task... well, the customer is always right!
This issue is a bit more complicated than you think.
In essence, it's the "patent" argument. All information may be "free", but the first person who spends money creating it is the loser, as the other parsites sponge off their work and don't need to recoup those dollars.
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
Why would a company promote a proliferation of device drivers for which they will have no control of the quality? When the third-party driver crashes and corrupts the users machine, the now highly pissed off customer will likely go back to the hardware manufacturer regardless of who wrote the driver. The reputation of the company is damaged as a result. Also, supporting external developers is a pretty heavy burden.
There are a few reasons I have seen based on RE drivers. I'll name a few here in no particular order.
Embarrassment. Sometimes they don't want to tell you that it's necessary to reset the chip repeatedly until it just happens to initialize correctly (probably due to a design flaw).
More embarrassment. They don't want to admit that many of the so-called 'hardware features' are really implemented (poorly) in the driver. Many IDE "RAID cards" are just a bunch of IDE co ntrollers. The RAID is in the driver. The driver's RAID implementation is not generally anywhere near as good as the Linux soft raid device.
Closely related to the above, for (snake oil) security devices, they don't want to document that flipping bit 5 of the 3rd register will bypass all protection.
The IP isn't theirs. The product is just relabled.
Their default answer to anything is NO, and they haven't (and probably won't) give it any thought.
In the case of some graphics cards, they don't want the public to find out the driver has hacks in it to cheat the benchmarks.
If you don't use your own chips, you don't write drivers for them, either.
Contrary to the popular belief, there indeed is no God.
..if there is a strong interface, you don't learn much about the underlying implementation. But hardware isn't always like that: we get thin interfaces that do tell us about the design descisions the company made.
how many times have rob maldacore banned me off, bitchslapped me, etc?
who knows. here is my +1 assholes
They already provide hamburgers to an open standard. Their product interfaces in the same way as all other hamburgers, directly with the mouth port.
Very fancy restaurants have proprietary interfaces: You are required to use specialized hooks (salad fork, etc.) to interface with the food which must be used in a specific way.
Chinese restaurants use the most difficult interface of all, but it's fairly simple and often fully documented on the chopsticks package.
Can you be Even More Awesome?!
Uh huh. Never in the history of mankind has a company bought a processor from A, a ADC from B, a USB controller from C, and never had to write a driver to make that custom integration hang together.
We're not talking chips, we're talking about talking to devices that actually do something, and.... never mind. I'm talking to an idiot.
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
It's because of fear of lawsuits, not a desire to hide their chip interfaces. There are just as many bad hardware patents as bad software ones. By controlling spec release with an NDA they stop the law firms from searching for violations of these bogus patents.
Everything developed by anybody is now a "violation" of some part of somebody else's submarine patent due to the way the USPTO has fucked up the entire engineering and technology world over the years..
Here is how capitalism is destroying civilization. They want everything to have patent and copywrite that never run out. Any slight twist, any microscopic advance in technology is some corporations private property. But then this tiny bit of work they've achived is nothing compared to the work of those who's shoulders they stand on.
This insanity just allows the existing business to destroy competitors before they can ever form. As much as I like to see someone profit from their genious, but the reality is at somepoint technology has to become part of general pool of knowledge. If not then eventually advancement will be impossible.
Try designing a highend graphics card and writting its driver, if you didn't have language. Oh, you want people to communicate, and work together. Well, for a 10% share of your profits the Queen of England will give you a liscense for your workers to speak and write english to eachother. As a free-bee they can even use it in their spare time!
Maybe there will be a future price war, where you can get a cheaper price on Mandrin or Hindi. And where the guy who invented Esperanto will get sued by SCO after they buy up the rights to the Romance languages.
Death to Capitalism!
There was a sound card company once that decided that the PC speaker was just not enough, and decided to add multi-voice synth capabilties to PCs. You might remeber that company for its "Ad Lib" line of cards. They were simple and easy to reverse engineer, so Creative Labs did just that, and also expanded on the concept. For whatever reason, Ad Lib went out of business rather than sue or counter-innovate.
A few years later, Creative sued another sound card company - I think it was Essoniq, but I am not sure, it might have been Aureal or somebody else - and lost the court case (their case was flimsy from the outset), but the legal battle so weakened the target company that Creative bought them out, then basically axed their technology (or maybe the good engineers left and no-one knew how to duplicate it).
The moral of that long rant is that perhaps hardware companies are a bit paranoid about these things. They have reason to be, unless they have a really spanking legal team.
Anyway, it's fairly trival to make organic chemicals through different processes. The real economic barrier is discovery and approval. Production is cheap. If what you suggested were true, the pharmaceutical industry would cease research into new drugs, because there would be no short term monopolies afforded by patents.
Whereas I agree that legal liabilities are one reason to close source drivers, I think one of the often overlooked reasons is that the product is not well engineered. I am continously amazed at lack of engineering for many large projects. With smaller projects the temptation to skip the engineering step is even greater. To release documentation for poorly engineered products a manufacturer would need to: 1. Fix the more embarassing hardware flaws currently compensated for in the driver. 2. Create (not just reformat) engineering documents as many likely do not exist. To see glaring examples of this look at the comments in many of the drivers for FLOSS OS drivers. In my mind that is a more likely reason "cheap" hardware often does not provide documentation.
That argument is absurd. If the hardware is capable of significant output on unpermitted frequencies, what's to stop a corrupted driver download, or bug in the official firmware, from doing that? Wireless cards are complex systems that are certainly prone to bugs.
What if a disgruntled employee leaks the docs? Will the company have its FCC certification immediately revoked? If so, why would management build hardware that exposes them to that risk?
What if someone reverse engineers their hardware and writes a fast-propagating worm that programs it to jam law enforcement frequencies? Or microwave users' balls?
If the FCC was truly anal about theoretical interference, it would not certify software transmitters at all.
Several chips from the previous 802.11b generation are heavily documented. Some of them allow sw to increase power output to >=250mW, which combined with a large directional antenna will exceed FCC allowable output. Wait... why aren't these companies being raided by the FCC and DHS?
Frankly "Blame the FCC, we're their bitch" is just a vendor cop out created by competetive paranoia, lawyer power trips, and corporate inflexibility.
They're trying to get the BSD nerds to f*ck off while they sell to the trillions of Windows users that don't mind a silicon-induced lock up twice a week.
Hey, I'm not bitter.. I'm right.
Go to ViaArena. Click on "Open Source", and go from there. Source for drivers for their Ethernet and graphics chips is provided.
When the number of device driver writers for your part numbers in single digits, you don't need super great docs. When you try to write good docs, the next thing people will complain about is the quality of the docs!
"This mission is too important to allow you to jeopardize it." -- HAL
...of getting in trouble with MS...
...maybe it is paranoia...
shouldn't it be
if x = ignorance and y=1/ignorance as x->infinity then y ->sanity
Yep, you're right.
I see a lot of people assuming that we're still in the 90's, the hardware does everything, and the software does nothing more than output the commands to the right ports. E.g., how Glide worked on 3dfx cards.
Then again, even in the 90's there were things like software modems. So the technique to offload as much work to the CPU as possible to keep the silicon small and simple, existed already.
What's happening is that usually:
1. The _whole_ functionality is in the software. E.g., if you buy a Promise IDE-RAID card (and they cost a pretty premium over similar cards from others), they're really software RAID like everyone else. The silicon is just an (obfuscated) ATA/SATA chip, arguably nothing better than a Silicon Image one or a Via that costs 1/10 of the price.
2. The whole difference between their differently priced models is in the drivers. E.g., Promise again: the difference between a RAID and a non-RAID card is purely whether the BIOS and drivers activate the RAID functionality.
3. Or, indeed, at the other end of the spectrum are graphics cards, which nowadays are basically more and more like a CPU. And the drivers are becoming more and more like a compiler and optimizer for it.
So someone like ATI genuinely has a lot of edge to lose if they showed the world at large, including their competitors, how they do that. I'm sure not only Nvidia (which already has a lot of their own people on the problem), but also minor players like SiS, Via/S3, Trident and Matrox would love to be just given a way to squeeze more performance out of the silicon they produce. Complete with source code.
Even if those small players can't out-compete ATI in the higher end, the real money is at the lower end of the market. For every X800 XT Platinum or 6800 Ultra sold, there are something like 100 sales in the class of 9200 SE. So showing Trident how to outperform those on cheap silicon is not something you really want to do.
A polar bear is a cartesian bear after a coordinate transform.
Sigh... Another post falls victim to slashdot mods confusing wry, profane humor with flamebait.
Would someone kindly reply with an entertaining and legitimate counter-argument while they siphon away my karma?
I have several personal project running on a protected mode only 200Mhz 80386 processor with AMD ethernet and raid IDE for banks of compact flash.
Before you go off on the "So what, big deal" thing, keep in mind that all the hardware with the exception of the analog stuff is all located on a single large Xilinx FPGA.
So where did I get the cores for the 386 and the ethernet and the highpoint compatible raid IDE?
Well, I visited the Intel web site, downloaded the 80386 programmers reference, visited the AMD website and got the PCNET datasheets, and visited the Linux kernel and got the source code to the highpoint HPT374 driver.
Ok, well I had to do the majority of the work myself to make the cores and only implemented the features that I needed, but I wanted to make an embedded system that was 100% compatible with a specific VMWare session (+ RAID) so I would be able to make true emulation sessions for real time simulation.
Could I also make a SCSI controller compatible with the adaptec cards, well, probably not, they're really really really advanced, but I could make something that implements the components that interest me at least.
Also, there are issues where there is far more than just the basic driver included with these types of boards, often the drivers have code optimized for the specific operating system that is uploaded to the processor on the board, so for example, there is i960 firmware optimized for use with the Linux kernel as the host OS and firmware optimized for use with the Windows kernel.
I personally would not want to release the i960 code for the controller and in most cases would imagine from past dealings with Adaptec that unless you actually perform these additional optimizations, then the controller isn't really that good. So they would in fact have to give away the whole thing in source form to make it happen.
The best option is to try and convince Adaptec that there is in fact a lucrative market for this product or try and form a company that works under NDA with Adaptec to produce binary drivers for the card.
This isn't a dissagreement or agrument here, but some interesting, related stuff.
Coke-A-Cola (TM and all that) got it's name from one of it's ingredients that they later got sued over removing to replace with Caffiene.
Of course Coke can no longer put coke in it's Cola, but I find it interesting nonetheless.
I've been told one of my aunts (now deceased) was mildly addicticted to coke-a-cola back then, but the change kinda weaned her off it though.
Mycroft
https://signup.leagueoflegends.com/?ref=4c3ed6600b6ea
It's very simple: back in the old days, when there was no monopoly, many chip manufacturers gave away thick, printed databooks. It was expensive for them, but they needed developers to use their products.
Now, however, there is a monopoly. You don't need to attract developers. The only concern is to have a driver for Windows, and having that driver included with the Windows install disk, so that your device, be it a soundcard, graphics card, or whatever, is "easier" to use. I wonder if there is a "dark hand" behind it...
Some years ago I sent a proposal to the European Comission: banning the sale in Europe of peripherals for which there is no public interface information available. It should not hurt the manufacturers, as the information can be made freely available in Internet (it's cheaper than shipping huge printed manuals), but it would have a side effect: the driver advantage for Window could disappear.
Good stuff - be sure the check out the incompatibility list at http://leenooks.com/ next time you want to know what *not* to buy!
http://www.welton.it/davidw/
- A windows driver provides at least 80% (probably closer to 95%) of the sales. There isn't much money on the remaining 5%, so efforts to make that work are also minimal (and usually based on personal championship. For those I've worked with during that time, _thank you_).
- Docs frequently aren't cleaned-up - there's no need. One manufacturer used to build network cards that had two methods of driving them. The Internal doc I got mentioned both, but had a sticky yellow note on it (from my hardware/doc contact) saying only to use DMA - PIO mode would be obsoleted. The Linux croud built a 'driver' using the obsolete PIO mode, and all hell broke loose when the PIO mode was removed to save silicon real estate. This resulted in a lot of bad press.
- Docs sometimes also list future, not-yet available features on successor chips. In several cases, I had the docs and early silicon and wrote code for a not-yet-released new card. I then had to wait for customers to start complaining that things don't work, find out that the new card had been released, and then release the updated driver I wrote earlier - I could not do so earlier as it would give away news about new hardware releases!
- Manufacturers don't like to be bad-mouthed. Let's face it, all hardware has bugs. Part of the aim of the driver is to make the hardware work. Page-size docs explaining hardware bugs (that easily can, and should be worked around by the driver) only cause customer confusion. The "us" that represent the 5% of the market simply don't warrant that kind of effort.
- By not releasing the specs, other manufacturers can't make hardware that uses the same API. That's a hardware lock-in, if you use the hardware and build a driver, then you need to make a new driver if the hardware changes
- Open source, unfortunately, has a mixed history of code quality and the ability to follow-up. When you create a partnership with a manufacturer, then all problems the customers may have are _yours_ and should not leak back to the manufacturer. Be the quiet 5% - if you're noisy they you're too much effort.
So there's many reasons. So it goes.Geert Jan de Groot
former developer of a now-defunct commercial *BSD operating system
I never understood that argument. I agree that from a pure quantitative perspective it is easier to make the hardware operate out of the authorized specs if you do have the driver source code. However, any more-than-average hacker can decompile a binary driver and replace the adequate values directly in the code. Hacking the source requires very similar programming skills.
Is there some jurisprudence somewhere which states that if you provide source instead of binary to someone, you are breaking the law if that person can later on change the source code to break some regulations ? That would be damn precise and subtile from our beloved law people.
--
Go Debian!
Would it be possible to develop a standard conversion tool that translates or at least helps to translate Windows driver source code to Linux driver source code, which would then be releases as binary only? So that HW manufacture could produce a binary Linux driver easily without too much expensive Linux experience work and without revealing their (perhaps legally hazardous) specs to outside community?
Note that IF a company wants to release HW specs it is mainly because they want to have Linux drivers available and a Linux market. It is not that releasing specs would be ever ba an end itself, but rather an unpleasant means.
Generally, wouldn't it be a time for Mr. Torvalds to start thinking about making life easier for proprietary driver development (like freezing the driver binary interface between minor kernel releases).
On the other hand, why is open source hardware development not catching on? Is it again this patent isssue? If the OSS community would provide nice open blueprints for hardware, I don't see why the chinese wouldn't be more than happy to print millions of chips for the consumer market, with manufacturing costs only, no development costs at all.
Anssi Porttikivi / app@iki.fi
When open-source developers go through all the trouble to reverse-engineer hardware and write drivers, but don't bother to document their results properly.
garble
Company A then sues B for copyright infringement for using their drivers.
But B wouldn't have pretend that they wrote the driver, or even publish it. As long as A has managed to get their driver on the Windows Install CD, all B has to do is to release a product that will work with that driver. The customer already has it, and telling the customer to "use driver for product Z by company A" is not illegal.The topic is about open specs, not open source. The idea is that opening the spec, that is, making the interface of the device public knowledge, will allow community to write open source drivers and provide support for them. Keep your drivers closed source if you want, just give me the neccessary info to make my own open-source ones.
In any case, I suspect that ten thousand dollars would be pocket change compared to the cost of developing the hardware in the first place. If so, it might be more expensive trying to develop hardware that matches a given interface than to make your own interface and drivers.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Does any sort of registry exist for unsupported hardware where folks could sign up to indicate that if linux support where available, they would buy this product. Purchasing managers could indicate how many units/etc.
Companies would have to guess the probability of an actual sale, but over time a reputation for follow-through could be developed.
Also provides a good marketing mailing list when the drivers are available.
Anything we could do to help them quantify the size of the risk/reward of releasing specs I imagine would go a long way towards getting results.
This might not be that obvious but all of this "hoopla" could be perpetuated by non other than Microsoft themselves as an attempt to lock the market up and make it difficult for "competition". For example, the spec's could be made available... for a small fee. Say; $2 mil or so!. Only large corporations; ie Micro$oft would be able to handle that fee in order to author underlying code in an OS to support that hardware.
:-)
I'm still amazed however at the blatent monopolistic tactics that are going on right now, and mostly being handled by corporate litigators and where most of it is quietly kept under the tables. But it isn't just Mr's Balmer's doings alone. I see Sun, Apple, and many others doing "just like Mr. Bill".
This is all going to fall apart in a really big way in a year or two. I hope to Not have a whole lot of percentages to these companies in my portfolio! A market shift is on the horizon, and it does involve open source.
If you can't see all the desparate moves that the likes of Mr Balmer (el stupido), Mr. Bill (el desparado), and some of the other corporation heads are doing to lock in their industry, you've got to be blind,.. or your reading this entirely out of random hit!
Cheers.
All content in this message is copyright (c) 2008. All rights reserved. RIAA is prohibited here.
Invoke your Common Law Property Rights. If you own an article such as a piece of computer hardware, then -- by sole virtue of the fact that you own it -- you are automatically privy to any secret embodied in that article. What is more, you would be permitted to use "reasonable force" in the pursuit of this inalienable right.
It already is law, but maybe it needs a special new law. The specifications of a piece of hardware are not proprietary secrets but form part of the owner's documentation and must be released gratis to owners of that hardware on request.
As to the idea that it may be possible to program, say, a radio transmitter to work on unlicenced frequencies, or a POTS modem to do things the phone company would frown on -- well, duh! What people do with the products they own is no concern of the manufacturer, who already waived all rights and disavowed all responsibilities associated with the device when they sold it. Are breweries responsible for drunk-drivers?
Je fume. Tu fumes. Nous fûmes!
Now lets see how this works in reality..
I have here two low-end pci wireless lan cards.
One turns out being a reference board from Texas Instruments, the other one from Ralink.
I have a pccard wireless network card, oops, its just a Ralink reference board relabeled..
Video? same story, all the boards I have here turn out being reference boards with a nice label. ALl of them use reference drivers from the guys who indeed integrated some components and wrote drivers, and in all cases that is also the one who made the chipset for the card (ATI, Matrox, NVIDIA etc.)
Ralink decided to come with a GPLed driver, resulting in their cards being very well supported regardless of platform (almost), the Texas Instruments board has no GPLed drivers available, and no specs, and while there is an ongoing project to support it, its not well supported outside the windows world.
ATI has published enough specs for some cards and they are well supported on virtually any p[latform. For their latest cards they didn't do that, and those are by far not as well supported.
I have a wireless router from X-micro here.. opening it up turns out that it is a Sigma Designs reference board. Looking around some more turns out that it runs Linux, but no GPLed firmware for it around..
Those who write the drivers are almost without exception in 1 of 3 categories:
- They got hired to do so by a chip or device maker
- They make some chipset
- They integrate some hardware onto a board.
Just looking around at very common pc hardware tells me that in almost all cases it is the company who made (one of) the major chips on a device.
At least, when I used to do device drivers (ok, it was around the time the earth's crust cooled) you really had to know how to trace connections and decode explanations of chip logic, since that's really all there was.
Given the short product cycle times, few product developers have the time to figure out what their product really does before it is shipped and then replaced with a new and different model.
I design hardware for my company and write the software for it, and you know what? there are ALWAYS specs written for both, such that others can pick up on the work at a later time, EVEN if it's just a test fixture. (For example, the contract programmers and hardware designers I supervise to do some of the subsystems.) Is this rocket science, or can anyone who has a mere moiety of a clue do the same and make life simpler all around?
(Well, OK, in this case it IS rocket science, 'cause that's what I do, but it isn't DIFFICULT. I even write decently full specs for my hobby projects; it's actually easier overall than just cowboy-coding everything, even when it's just for my use. It's a habit the better grade of engineers get into.)
No, the problem you're bewailing is neither poor programmers nor clueless hardware designers. The problem is companies with bad development practices and bad attitudes. (Would YOU allow a development project to be released to manufacturing without good documentation? If so, you had better be able to outrun your mistakes...)
"My strength is as the strength of ten men, for I am wired to the eyeballs on espresso."
Some day all you Info Wants To Be Free warriors are going to finally understand that Open Source and Free Software (capitalized to indicate the name of the ideas) are based on philanthropy, not entitlement.
For those of you who skipped your English and history classes, that means a company which releases their hardware spec for use by Linux or BSD or whomever is giving you a gift. They present you with something they made themselves, at considerable effort and cost, for you to use. This gift may well be motivated by self interest, as they hope you will buy their hardware, but this does not alter the fact of it being a gift freely given.
So banging on Nvidia or ATI to release their hardware spec is like banging on some random stranger's front door and demanding a free lunch.
It is a moral distinction I'd like to see made much more often in these discussions. We the public are NOT entitled to the intellectual property of private companies or individuals, pretending otherwise is really quite rude. Rude behaviour ought not be rewarded.
Software developer.
Mistakes of the kind even a mediocre professional software developer would never make...they package drivers from these closed interface hardware shops, written by hardware engineers without the first clue about software development.
Hmmm, I see you've owned an ATI video card at some point as well? Seriously, security issues aside, bad drivers are one of the big reasons windows can perform like crud. With more than one ATI card I've had the choice of:
a) Use MS certified driver and sacrifice functionality
b) Use ATI drivers and sacrifice stability.
If the company does not want to issue the specs, so that good drivers can be developed on open source solutions, I push back IT budgets.
Most corporation go through a vendor approval task with a vendor management group. Finance then approves those groups budgets and makes sure they make sense.
If I am over seeing a budget, and I see request for hardware that is not open source friendly, I push back. Most of the time the vendor and IT guys have a strange look on their face when I say that I don't want to sign off on a budget using Intel products or Broadcom products.
I even had to bring up vendors the IT folks had never heard about such as SysKonnect as a good replacement for Broadcom crap.
The future of finance groups is that they will be more tech savvy. Everyone in my current group knows how to code in a few languages and codes in their spare time. We are all MBAs, not computer science people. But we have to know the computer stuff to make sense of the IT budgets.
What this means is that finance groups will continue to push back on hardware that is not open source friendly. Why? Because as finance guys, we know that open source solutions are cheaper than close source ones most of the time. We also recognize that windows will remain the dominate PC for users, but *nix based system will dominate the server market.
But we need those *nix based servers to have good hardware support, so we know we need to push back to make sure our desktops that run windows are using as much open source friendly hardware as possible -- even though this doesn't matter on these boxes.
It's cheaper to customize an open source solution then a closed source one in house. Contractors cost way too much! Cutting out the contractors is where you save money on your bottom line.
For the most part, in the WLAN card business the drivers are provided by the chipset manufacturers.
The guys who build the cards (ODMs with names you've likely never hard of like Global Sun), at the behest of the OEMs (DLink, USRobotics, etc), take the drivers from the chipset manufacturer (Broadcom, TI, Atheros) and add pretty logos and graphics but change none of the functionality.
So, your argument that ODM A will build a card with chipset X, and ODM B will also go out and build a card with chipset X and steal ODM A's drivers doesn't fly. They both get the drivers from chipset X's manufacturer.
...to the legal argument. It was a response to the "Oh, it's too hard to write documentation because we don't have anyone to write it for us" argument. I understand that there are also legal requirements that need to be met for any documentation as well, but that was an afterthought in the original poster's comment... it seemed to me that his main excuse for not writing documentation was because it was too hard.
And no, I don't work in the hardware industry, which gives me the ability to look beyond the way things are, and think about how they should be. It's a little thing I like to call 'abstraction'. You know, where you ignore some of the details to get a better look at the problem? I realize that may be difficult for some people, possibly including you, but sometimes you can get too close to a problem to see a solution that's obvious. And the obvious solution is to write user-ready documentation as you build the product, and turn it over to the lawyers to vet when you're done. If nothing else, you have a good reference to use internally. You don't need a separate documentation team, nor should you even really want to isolate that task anyway.
LRC, the best-read libertarian site on the web
which sharp cpu would that be? the licensed arm7 one or the licensed arm9 one? aka sharp's "bluestreak" 16 and 32 bit MCUs.
both are very well documented with very well understood and widely supported ISAs.
If a secret, undocumented feature WERE to be used by, for
instance, Microsoft, from an Intel CPU, this would be
prima facie evidence of collusion in restraint of trade.
It's illegal in this country for one or two companies to get
together in an attempt to freeze out (for instance) Linux
or any other 'competitor'. Intel giving extra bennies
to Microsoft (and excluding Lindows) is worth a lot
of attention from federal prosecutors.
Similarly, if a card maker communicates his requirements
to one or more 'other' companies, he HAS to give similar
information to ALL other companies,
So, the legal department insists (quite properly, in their
limited view) that the tech departments NOT give out info
except for a strict known package.
What IBM did with the original PC, that made it popular,
was to give out EVERYTHING in that known package, the
Technical Reference volume, of the Personal Computer
Hardware Reference Library.
And what made the PS/2 machines such a commercial flop,
was that it wasn't similarly supported. No one could make
cards except by 'partnering' with IBM.
They are not asking for the source to the driver.
They are asking for the documentation to be able to write their own driver. All they want is the API documentation that tells them what values to poke into which registers to get a signal emitted from the device. That's it.
Let the companies release their own drivers for whichever OSes they want to officially support. Then let them release the documentation needed to write drivers, so that others can write the needed drivers to support the other OSes out there.
Voila! Instead source of new revenue, as new users using other OSes will be able to use the hardware. If someone calls the support number, they get billed $X / call to be told, "We don't support that OS. Call the driver writer."
Sorry, that was Toshiba. The specific model I was unable to obtain ISA documentation for was the TLCS900H.
LRC, the best-read libertarian site on the web
strange, the developer of neopop claims the documentation was easily available.
i would assume he was able to get the ISA documentation -- after all, neopop emulates the cpu.
the tlcs900h is also one of the target architectures of sdcc so i assume they were able to get documentation also.
If you can show me where such a document can be obtained, I will retract my argument.
LRC, the best-read libertarian site on the web
I suggest you contact the neopop and sdcc developers. Although this particular architecture appears completely dead now.
You got it wrong about patent disclosures.
.. the amount of disclosure considered enough for someone to "work" the invention is too little.
The bar is set too low
Companies are getting their monopoly with not enough information disclosed. If it doesn't allow for interoperability, then they've not disclosed enough in my view. This is a contract between the people and the corporation, we should be demanding more.
If it's a cell-shading algo for a video card, in my view the spec should divulge (or refer to public docs that give) enough info that you can send the docs to a chip-maker and they can recreate the working hardware. At this level of disclosure drivers should be a no-brainer for these super-genius reverse engineering Linux d00dz.
And it also buys you complete incompatibility with GCC, which makes your chip act slower for anyone who uses software compiled with GCC. For example, if Intel licensed their ISA under an NDA but AMD made theirs freely available, anyone with half a mind would use an AMD chip in their server, since GCC would be much better optimized for it.
As long as there are commonly used open source compilers, it's necessary that chip vendors release their specs for free. Otherwise, other chip vendors will.
His point was that the grandparent stated ISA, but meant microcode. I believe if you re-read his post you will notice that he does make a distinction.
http://www.computerworld.com/networkingtopics/netw orking/story/0,10801,102635,00.html?source=x10
So when a NIC is made for linux first, this is how much is costs.