Dooms your hardware to be used only on the supported platform!
Actually, The real point is "Dooms your unsupported platform".
A note about "hardware specs". I think I've found that in 25 years, I have yet to meet a hardware spec for a non-trivial board that was correct enough that I could write a functioning driver for it without having close personal contact with the hw board designer.
In the world of 4-5 month board spins by the time that the errata for the board is discovered by tech support using trial and error, the board is probably commercially irrelevant.
How much support effort should a company be willing to offer to help outside folks work out the hardware glitches? The knowledge of, and access to their lead board designers?
This doesn't seem economically justified to board vendors.
On the other hand, it is economically justified to chip vendors who will turn out the same chip for years rather than months.
To the point again, ask the chip folks, not the board guys for documentation and source code.
As a commercial device driver writer, I can tell you exactly why HW Mfgr's don't publish source code, it's called "value add".
These days, most HW boards are centered around a particular chip. In network boards, it's an ethernet chip, in graphics boards, it's the accelerator, in sound cards, it's the DSP. In every market segment, there are generally only one or two market leaders for a particular chip niche. Competition between companies using the same hw design is fierce.
All silicon vendors publish "reference designs" which are unoptimized (and generally buggy) versions of code that works with the chip in known design settings.
In todays world of short design cycles, most HW board designers don't stray too much from the reference design. They don't have the time.
In order for a HW board vendor to distinguish themselves from the reference design, they have to value add. This generally means figuring out how to make the chip run faster or better using software.
If I, as a HW board vendor publish my value add, I'm allowing those Taiwanese companies that just manufacture the chip reference design to kill me.
It is a non-trivial exercise to extract value add from a chip. This represents real investments. These "value adds" are not something that casual open source hackers are going to figure out.
I'll give you 2 personal experiences (with names left out because they were clients)..
I wrote drivers for a CODEC chip. There were 3 other companies using the same chip. In the process of development, we discovered by accident a non-intutive 7!! lines of code that would cause the chip to encode at 15 frames/sec. The best that the reference design and other users could manage was 10. None of the other companies (nor even the chip mfg) ever discovered this and my client derived a great deal of money from the ability to show better video.
Another example was an S3 chip customer who was able to blow away other vendors in benchmarks using the same chip by using some interesting hacks to the chip.
If you want to apply pressure someplace, don't talk to the HW board guys, talk to the semiconductor vendors and ask them to publish the source code to their reference designs.
Slashdot Mirror
These bandwidth caps are not completely about P2P, mostly, they are a stalking horse for killing VoIP and video from third parties.
One quarter ago, 30% of Skypes calls were video-enabled.
Netflix video downloads cut into Comcasts $$$'s as does thirdparty VoIP.
Just because the bandwidth cap is 250GB today, doesn't mean it will be tomorrow. And then we move onto tiered QoS for all those services.
Dooms your hardware to be used only on the supported platform!
Actually, The real point is "Dooms your
unsupported platform".
A note about "hardware specs". I think I've found that in 25 years, I have yet to meet a hardware spec for a non-trivial board that was correct enough that I could write a functioning driver for it without having close personal contact with the hw board designer.
In the world of 4-5 month board spins
by the time that the errata for the board is discovered by tech support using trial and error, the board is probably commercially irrelevant.
How much support effort should a company be willing to offer to help outside folks work out the hardware glitches? The knowledge of, and access to their lead board designers?
This doesn't seem economically justified to board vendors.
On the other hand, it is economically justified to chip vendors who will turn out the same chip for years rather than months.
To the point again, ask the chip folks, not the board guys for documentation and source code.
As a commercial device driver writer, I can tell
you exactly why HW Mfgr's don't publish source code, it's called "value add".
These days, most HW boards are centered around a particular chip. In network boards, it's an ethernet chip, in graphics boards, it's the accelerator, in sound cards, it's the DSP.
In every market segment, there are generally only
one or two market leaders for a particular chip niche. Competition between companies using the same hw design is fierce.
All silicon vendors
publish "reference designs" which are unoptimized
(and generally buggy) versions of code that works with the chip in known design settings.
In todays world of short design cycles, most HW board designers don't stray too much from the reference design. They don't have the time.
In order for a HW board vendor to distinguish
themselves from the reference design, they have to
value add. This generally means figuring out how to make the chip run faster or better using software.
If I, as a HW board vendor publish my value add,
I'm allowing those Taiwanese companies that just
manufacture the chip reference design to kill me.
It is a non-trivial exercise to extract value add from a chip. This represents real investments. These "value adds" are not something that casual open source hackers are going to figure out.
I'll give you 2 personal experiences (with names left out because they were clients)..
I wrote drivers for a CODEC chip. There were
3 other companies using the same chip. In the
process of development, we discovered by accident
a non-intutive 7!! lines of code that would cause
the chip to encode at 15 frames/sec. The best that the reference design and other users could manage was 10. None of the other companies (nor even the chip mfg) ever discovered this and my client derived a great deal of money from the ability to show better video.
Another example was an S3 chip customer who was
able to blow away other vendors in benchmarks using the same chip by using some interesting hacks to the chip.
If you want to apply pressure someplace, don't talk to the HW board guys, talk to the semiconductor vendors and ask them to publish the source code to their reference designs.