You're telling me that you think that because some application developer that you meet on a plane, makes a comment that the company doesn't care about licensing issues, that Sony's policy is to violate the GPL.
Someone involved in the project should contact Palm and Sony in order to get this resolved. Give Sony a chance to fix this before you get too up in arms. Mistakes happen.
That's because you aren't interested in truely giving something away for free. You want something back, some kind of return on your investment for your time. The BSD license allows someone to write something and give it away. All the developers get is possibly some limited recognition, and the knowledge that the code they wrote may make the software that people use better.
Choose the license you like. Seems that GPL works for you in some cases, and writing closed source helps pay the bills.
There's a lot of countries where that poor farmer is far from illeterate. Vietnam comes to mind as an example. They have a very high literacy rate. Of course $200 is still to high of a price for most of their population, but it's getting closer. Of course the fact that the OS is Linux doesn't matter much for them since they don't have any copyright laws there anyway.
If you had a union, then this probably wouldn't happen to you, however you might have other problems. First of all, unions cost money. You have to pay dues for them to represent you. Through collective bargining you may get payed enough to make up the difference, or even get payed more, but in the end your company's biggest expense, labor, goes up. In the end you may make more now, but your company may not be competitive in the long run and go out of business. The US steel industry has some good examples of this.
Another problem is that Unions usually force very strict rules upon employers, which don't allow the employer to take the circumstances into account when resolving problems. This can allow smart but lazy employees to exploit the system. In the end that means that either you're working harder to make up for those who aren't pulling their own weight, or your company becomes unproductive. Of course poor management in a non-union company can also cause this same problem.
The other thing I don't like about unions is seening the money you pay in dues being spent by the unions on political candidates that I can't stand. If being a member of a union is a requirement for my job, then unions shouldn't be allowed to spend my dues on political contributions.
In some circumstances unions make things better for their employees, and the expense of maintaining the union is worthwhile to it's members. Personally, I'll bargain for myself. If my opinion alone isn't enough to change managment's way of doing something, then I can join with several other key employees to make our voices heard. If that doesn't work, then I can always find another job. My job is far from perfect, but when there have been major issues in the past we've been able to have our voices heard, and get major problems changed. A couple times it has taken people leaving in order for managment to change, but they have changed.
Microsoft may want the version of UTICA that they originally supported. The "UCITA" law in Maryland is far from uniform with other states, or even the original UTICA. State legislators did what they always do, they tacked on ammendments, and changes parts. In the end, the one benefit to consumers, having uniform laws from state to state, is lost. What we end up with are a bunch of inconsistent laws, which cause everyone problems. Microsoft doesn't want to have lawyers consider 50 different state laws for the licensing agreements on their domestic products alone. Consumers don't have much of a chance of knowing all the laws, or even which ones apply. Legislation is usually a compromise, and as with many compromises, in the end no one is happy.
When did you use it, was it before Nov 1996? This patent took 4 1/2 years to get approved, so it may have been unique when they were developing it and writing up the patent.
Where I work we are supposed to keep engineering notebooks. When we come up with some idea that might be unique and patentable, we are supposed to have someone else in the company who understands the concept witness and date the notebook. My understanding is that this is to show when we came up with the idea in case we patent it and it gets challenged. If this is really how it works, then the actuall date the patent is filed or when Quake was released is less important then when they can prove they came up with the idea.
I must be getting old, and my memory must be fading, but I don't remember hearing stories of kids dropping anvils on other kids heads after watching too many loony toons. There has always been violence in the media. I happen to agree that you should shield younger children from too much violent content. The problem is that the video game manufacturers are putting ratings on the games already, but parents are still letting their children play those games.
It is not the games industry's job to raise your children. It's not even their job to raise the children of those people you think are doing a bad job of raising their children. If society feels that selling these games to children under 17 is that bad, then they should lobby their politicians for a law preventing the sale of that material to children.
What bothers me is the increasing trying to sue and finacially harm companies which are selling legal products in a legal manner. This lawsuit should be dismissed, and the Sanders' should have to pay the legal fees of the game companies.
The Sanders' families suffered a great loss, but it's not the game companies fault. They and their greedy lawyers shouldn't be allowed to distort the court system in order to get some kind of warped revenge for this tradegy.
My first reaction what to think "what is this guy smokin?", but Apple has been pretty forward thinking where busses for personal computers are concerned. The Apple Desktop Bus, for example, was actually a really good idea for it's time. There are some things that Apple does very well.
I think the original intention was to use only optical on the interface cards. The disks have a copper interface and plug into disk chassis. THe chassis then has either a copper or optical interface. They usually have a copper DB9 interface, and a MIA is used to convert it to shortwave or longwave optical.
As you can imagine, cable lengths using this technology are very limited...
Since it's a serial interface cable lengths for 1 Gbit copper aren't as short as you might think. A card with a copper HSSDC interface can use cable lengths up to 30 meters. With a shortwave laser interface this increases to 300 meters, and with a longwave laser it's 10 kilometers. There aren't a lot of applications where you need to have your storage 10 km from your computer, but they do exhist. Latency does become a bit of an issue when you start running that much fibre though.
If you can afford the resources to work on the hardware (Analyzers, scopes, CAD tools), then you can probably afford the nominal fee to join the trade association and join in the standars making process. The specifications are already open, and people are already building Linux on top of it.
I agree that it only makes sence to use copper wires for short distances, but it's kind of misleading to say that optical is slower over small distances. The amount of time spent converting from optical to a voltage just isn't significant. There are 10 Gbit optical transceivers available. They are EXTREMELY expensive, but you can get them. 2 Gbit ones are finally comming down to a reasonable price, but they still cost in the price range of an average PC motherboard.
You commet about optics not being able to provide power is also a good point. No one wants a mouse that you have to connect a power supply to seperately.
There are some companies that like to play with parallel fibers (Vitess comes to mind for some reason), but copper busses still have a good number of years yet.
Actually, they're seperate PCI busses. You can only have on 64-bit 66MHz slot per bus, or 2 64-bit 33MHz slots. When you see on 64/66 slot, two 64/33 slots, and several 32/33 slots, there are actually 3 PCI busses on the system. If your're really lucky the busses aren't all bridged together and sharing 532 MB/s worth of bandwidth.
Maybe that's all you need, or will need for a while. I have friends that are completely happy with their Pentium 133 computers and see no need to upgrade.
Right now I'm wrestling with the problem of finding inexpensive test systems with 64-bit 66MHz PCI so I can test our FibreChannel products. UltraSparc 60s are just a little expensive to set up even a small SAN testbed. You can get X86 systems, but they are usually Xeon systems which raises the price too high. I've found motherboards, but half the time when you try and order one, they don't really exhist, or they only have one 64-bit 66Mhz slot. Or they bridge all the busses together serially which limits your overall bandwidth.
I can understand that you really don't need more than 32-bit 33MHz PCI at home, but the bandwidth that's required for servers becomes cost effective for the home in only a few years. CPUs are getting faster, and memory bandwidth is going up, but if you want to stream high res video to your hard drive in a couple of years then you're going to need more bandwidth on your PC.
That works fine in a simple Apple Macintosh which only has a couple of expansion slots and doesn't have very many devices that need interrupts. It's just not reasonable to limit the number of devices to the limited number of interrupts available. It's also not reasonable to require the computers to have a vast number of interrupts available in case someone want to use them. These resources can be safely and efficiently shared. The reason plug and play doesn't work is because of crappy hardware and driver development. I write drivers for FibreChannel boards, and my drivers can share interrupts and still perform well. Don't try and tell me that some ethernet card has to have it's own interrupt. It's simply a poor implementation.
That's true only to a certain extent. Economies of scale mean that the development and setup costs are spread out over more units. However, the raw materials and the equipment for the optics are still considerably more expensive than copper wire. You can't lose money on each unit and make up for it on volume. This is something that many of the internet companies are just learning.
I can't tell you why they have a NDA on their firmware spec, but they aren't alone. I know of no vendors in their market that don't. It may be that they are trying to hide some of their IP from their competitors. Most likely they are trying to hide the limitations of their products from their competitors, so their competitors can't exploit them or market their products at those weaknesses. You can say that they shouldn't design products with weaknesses, but everyone has to make design decisions, and no product is perfect. A large percentage of the time spent on driver development is working around limitations or flaws in hardware. It's amazing what you can fix in software, and with the speed of today's processors, a few extra clock cycles doesn't effect performance. If you use dma and write your software well, you can keep the cpu load low, and still saturate the PCI bus with data.
First off, I think you're talking about the driver for NVidia's family of GPUs...
We're not in the graphics market, but the issues may be similar.
So why don't they, and why don't you publish that which you can publish and ship only the NDA'd stuff binary? (which would also aid the reengineering effort because then there's a lot less to work on).
I really don't know why the ASIC vendor doesn't publish their spec. The firmware specification which tells us how to interface with their ASIC is under NDA, but a lot of that information can be determined from the GPLed Linux driver, but definately only a subset of the functionality that we use. Since the material under NDA is at the core of the driver, it wouldn't do users much good if we released the source to the rest of it. It would however help our competitors which have access to the NDA information.
By releasing the source, we risk having the software we developed stolen and used by our competitors, but what do we gain. In our particular market the hardware our board interfaces with is very expensive. The average open source developer doesn't have $100,000 worth of equipment sitting around. Because of this our market just doesn't lend itself well to open source development. We do have certain partners who do have access to the source. We had to execute a 3 way NDA with the ASIC vendor to give them access, but it is possible.
You of all people should know that a chip isn't done when the VHDL is done. Even if people get it to work on a FPGA (and they're sometimes more expensive than purchasing the device!) all they l get is an underpowered version of the real thing.
That depends a lot on the product. When you aren't talking about huge volumes, then FPGAs are a reasonable and even cost effective solution. Rolling an ASIC is very expensive, and mistakes mean rolling it again. With a FPGA you can change how the hardware works across the PCI bus, while the board is in the system. We have two products which perform significantly different tasks, on which the only differences are the parts externel to the FPGA and the VHDL. You can actually populate the board with parts for both functions and change what it does while it's in the system.
As for a FPGA being an underpowered solution, this is completely untrue. There is no reason that a FPGA solution is inherrantly less powerful than an ASIC solution.
Your comments on FPGAs being expensive it very true, especially at higher densities. However, you can save money if you can split the design into a couple less dense chips.
One more thing, I'm also aware that making the device available with only proprietary closed software to use it with also has the advantage of controlling what functionality/features of the device are available to the end-user. That way, you can keep people from exploiting the hardware of the device to the point that it prolongs the product's lifecycle and thus possible impedes sales of a successor device.
We are a small company that's trying to put our the best product we can with the most features we can in the shortest time we can. We aren't holding back features for the sake of our next generation products. This may be true of other companies, but I can say that it's not true of ours.
The ASIC vendor does have an Open Source driver which has a portion of the functionality of our driver. If that driver suits your needs, then you can buy the hardware from whoever you want.
Production Costs != Development Costs
It doesn't take a huge development effort slap an ASIC into a reference design card. If the driver is simple, then the software effort isn't that great either. However, our driver is about 30000 lines of code and runs on six OSs, and multiple hardware platforms for many of those OSs. Yes, we do support Linux on the PPC. Developing and testing the software is a huge development effort and required a large investment by our company. In order to pay for that we have to charge $$$ for our products.
Our cards are more expensive that the ASIC developers cards, however you get more for your money.
The ASIC maker would sell more hardware if there was an open source version of the driver and people didn't have to pay your 90% markup.
The ASIC manufacturer has decided that there are some markets they aren't interested in because the customres require special features or additional support that they aren't interested in providing. We provide additional features in our software, and more personalized support to those customers that need it. We can't just sell the support seperately, because that's not the way the business works. Customers, especially the government want COTS (Comercial Off The Shelf) products. However, a large percentage of our customers don't want the common off the shelf product, they want something a little bit different. They don't want to develop it themselves, because that would be way to expensive. Me make products that fit those niches, and have the experience to make our products work in non-standard environments. We add value the the product that the ASIC vendor cannot or will not provide.
Now, the ASIC vendor could just fully publish their specs and let the open source community provide drivers. However, many of the non-mainstream projects just never reach a high level of quality control, and most open source developers really can't afford the hardware we need to properly test and develop our software.
The other issue is that developing sowtware costs money. Most of our ASIC vendors customers don't need the software we develop. They don't need our specialized protocols or a driver for a PPC single board computer. Why should all the vendors customers have to pay more for their boards to pay for development of software they don't need. Let the people who need our software pay us for our software.
Free software has a place. We do have a hardware product to which we have always provided the source to the driver. For that product there is a definate benefit to the customer to having source, and it uses our own custom ASIC, so we make our money off the ASIC in that case.
The sell the hardware, but all software should be free also bothers me because it's getting harder to define what's hardware and what's software. We have a product that is mostly implemented in a FPGA. VHDL is just software to me. You compile it, load it into the FPGA, and you have a hardware product. Change the VHDL and you have a significantly different hardware product. Should that be free too? How do you expect developers to recoup costs? Where do you draw the line? How can companies make money so they can pay for the development tools, and pay their employees? There's lots of people pushing for free software, but how does it work as a business model when you aren't talking about a mass market product. How does free software address a complicated, software product that has relatively few people that need it?
Guess it's off to the computer show to pick up some more OEM (for sale only with a new computer) software. After all, I stuck in that extra memory DIMM and loaded the OS, that makes me an OEM, right?
It's not like there's a good way around making it kernel dependent. They can't release the source to the CSS code, and I'm sure the their licensing agreement for CSS requires copy protection such as Macrovision. Therefore it has to be a closed source binary. The problem is that Linux doesn't have a binary driver interface. You have to include a bunch of kernel headers, which change from one kernel to another. They also often change when someone applies a kernel patch, so you either have to have some kind of open sourse interface layer for your driver that can be recompiled, or if someone patches their kernel you driver doesn't work anymore.
We've run into this problem where I work. Our hardware uses an ASIC produced by someone else. We developed our software with information on the ASIC that we received under NDA, so we can't make the entire driver open source. Not to mention that other companies could just slap the ASIC on a card, use the software we developed, and undercut our price, since they'd save 90% of the development costs.
The code for the binary driver can't call kernel functions directly. It goes through a layer which is open source and contains the kernel headers. That layer needs to be recompiled every time the kernel is recompiled to ensure the driver works with the new kernel. It's a pain for our customers, and it makes Linux the most difficult (and therefore the most expensive) OS for us to support. Fortunately, we have enough customers using Linux to still justify supporting it, but tech support really dreads getting calls on our Linux products.
As for InterVideo's particular choice of going with a binary only approach, they really don't have a choice. The MPAA dictates the rules of the licensing agreement, there choices are a closed source LinDVD or no LinDVD.
I've never seen an API that was well completely documented. If using "undocumented" api calls violates Apple's license agreement, then why develop for their OS. You just run the risk of them calling out their lawyers and having all your work go to waste. Just don't develop any software for their platform and let them shrivel up and die. A consumer OS is no better than the applications that are available for it. If Apple is stupid enough to drive off developers, then they go out of business.
Releasing the software under GPL could get you into some interesting legal trouble. If your employer legally owns the rights to the software, how can you legally release it under GPL. It might be taken as giving away something that doesn't belong to you. I'm not sure what this means to the thousands of people working on GPLed software in their free time, but I suspect there are a lot of people violating their employment agreements.
Slashdot Mirror
You're telling me that you think that because some application developer that you meet on a plane, makes a comment that the company doesn't care about licensing issues, that Sony's policy is to violate the GPL.
Someone involved in the project should contact Palm and Sony in order to get this resolved. Give Sony a chance to fix this before you get too up in arms. Mistakes happen.
That's because you aren't interested in truely giving something away for free. You want something back, some kind of return on your investment for your time. The BSD license allows someone to write something and give it away. All the developers get is possibly some limited recognition, and the knowledge that the code they wrote may make the software that people use better.
Choose the license you like. Seems that GPL works for you in some cases, and writing closed source helps pay the bills.
FTP is a protocol. FTP applications are applications. They are not part of the tcp/ip stack any more than KDE is part of the Linux kernel.
There's a lot of countries where that poor farmer is far from illeterate. Vietnam comes to mind as an example. They have a very high literacy rate. Of course $200 is still to high of a price for most of their population, but it's getting closer. Of course the fact that the OS is Linux doesn't matter much for them since they don't have any copyright laws there anyway.
If you had a union, then this probably wouldn't happen to you, however you might have other problems. First of all, unions cost money. You have to pay dues for them to represent you. Through collective bargining you may get payed enough to make up the difference, or even get payed more, but in the end your company's biggest expense, labor, goes up. In the end you may make more now, but your company may not be competitive in the long run and go out of business. The US steel industry has some good examples of this.
Another problem is that Unions usually force very strict rules upon employers, which don't allow the employer to take the circumstances into account when resolving problems. This can allow smart but lazy employees to exploit the system. In the end that means that either you're working harder to make up for those who aren't pulling their own weight, or your company becomes unproductive. Of course poor management in a non-union company can also cause this same problem.
The other thing I don't like about unions is seening the money you pay in dues being spent by the unions on political candidates that I can't stand. If being a member of a union is a requirement for my job, then unions shouldn't be allowed to spend my dues on political contributions.
In some circumstances unions make things better for their employees, and the expense of maintaining the union is worthwhile to it's members. Personally, I'll bargain for myself. If my opinion alone isn't enough to change managment's way of doing something, then I can join with several other key employees to make our voices heard. If that doesn't work, then I can always find another job. My job is far from perfect, but when there have been major issues in the past we've been able to have our voices heard, and get major problems changed. A couple times it has taken people leaving in order for managment to change, but they have changed.
Microsoft may want the version of UTICA that they originally supported. The "UCITA" law in Maryland is far from uniform with other states, or even the original UTICA. State legislators did what they always do, they tacked on ammendments, and changes parts. In the end, the one benefit to consumers, having uniform laws from state to state, is lost. What we end up with are a bunch of inconsistent laws, which cause everyone problems. Microsoft doesn't want to have lawyers consider 50 different state laws for the licensing agreements on their domestic products alone. Consumers don't have much of a chance of knowing all the laws, or even which ones apply. Legislation is usually a compromise, and as with many compromises, in the end no one is happy.
When did you use it, was it before Nov 1996? This patent took 4 1/2 years to get approved, so it may have been unique when they were developing it and writing up the patent.
Where I work we are supposed to keep engineering notebooks. When we come up with some idea that might be unique and patentable, we are supposed to have someone else in the company who understands the concept witness and date the notebook. My understanding is that this is to show when we came up with the idea in case we patent it and it gets challenged. If this is really how it works, then the actuall date the patent is filed or when Quake was released is less important then when they can prove they came up with the idea.
The patent was applied for in 1996.
I must be getting old, and my memory must be fading, but I don't remember hearing stories of kids dropping anvils on other kids heads after watching too many loony toons. There has always been violence in the media. I happen to agree that you should shield younger children from too much violent content. The problem is that the video game manufacturers are putting ratings on the games already, but parents are still letting their children play those games.
It is not the games industry's job to raise your children. It's not even their job to raise the children of those people you think are doing a bad job of raising their children. If society feels that selling these games to children under 17 is that bad, then they should lobby their politicians for a law preventing the sale of that material to children.
What bothers me is the increasing trying to sue and finacially harm companies which are selling legal products in a legal manner. This lawsuit should be dismissed, and the Sanders' should have to pay the legal fees of the game companies.
The Sanders' families suffered a great loss, but it's not the game companies fault. They and their greedy lawyers shouldn't be allowed to distort the court system in order to get some kind of warped revenge for this tradegy.
My first reaction what to think "what is this guy smokin?", but Apple has been pretty forward thinking where busses for personal computers are concerned. The Apple Desktop Bus, for example, was actually a really good idea for it's time. There are some things that Apple does very well.
I think the original intention was to use only optical on the interface cards. The disks have a copper interface and plug into disk chassis. THe chassis then has either a copper or optical interface. They usually have a copper DB9 interface, and a MIA is used to convert it to shortwave or longwave optical.
As you can imagine, cable lengths using this technology are very limited...
Since it's a serial interface cable lengths for 1 Gbit copper aren't as short as you might think. A card with a copper HSSDC interface can use cable lengths up to 30 meters. With a shortwave laser interface this increases to 300 meters, and with a longwave laser it's 10 kilometers. There aren't a lot of applications where you need to have your storage 10 km from your computer, but they do exhist. Latency does become a bit of an issue when you start running that much fibre though.
If you can afford the resources to work on the hardware (Analyzers, scopes, CAD tools), then you can probably afford the nominal fee to join the trade association and join in the standars making process. The specifications are already open, and people are already building Linux on top of it.
I agree that it only makes sence to use copper wires for short distances, but it's kind of misleading to say that optical is slower over small distances. The amount of time spent converting from optical to a voltage just isn't significant. There are 10 Gbit optical transceivers available. They are EXTREMELY expensive, but you can get them. 2 Gbit ones are finally comming down to a reasonable price, but they still cost in the price range of an average PC motherboard.
You commet about optics not being able to provide power is also a good point. No one wants a mouse that you have to connect a power supply to seperately.
There are some companies that like to play with parallel fibers (Vitess comes to mind for some reason), but copper busses still have a good number of years yet.
Actually, they're seperate PCI busses. You can only have on 64-bit 66MHz slot per bus, or 2 64-bit 33MHz slots. When you see on 64/66 slot, two 64/33 slots, and several 32/33 slots, there are actually 3 PCI busses on the system. If your're really lucky the busses aren't all bridged together and sharing 532 MB/s worth of bandwidth.
Maybe that's all you need, or will need for a while. I have friends that are completely happy with their Pentium 133 computers and see no need to upgrade.
Right now I'm wrestling with the problem of finding inexpensive test systems with 64-bit 66MHz PCI so I can test our FibreChannel products. UltraSparc 60s are just a little expensive to set up even a small SAN testbed. You can get X86 systems, but they are usually Xeon systems which raises the price too high. I've found motherboards, but half the time when you try and order one, they don't really exhist, or they only have one 64-bit 66Mhz slot. Or they bridge all the busses together serially which limits your overall bandwidth.
I can understand that you really don't need more than 32-bit 33MHz PCI at home, but the bandwidth that's required for servers becomes cost effective for the home in only a few years. CPUs are getting faster, and memory bandwidth is going up, but if you want to stream high res video to your hard drive in a couple of years then you're going to need more bandwidth on your PC.
That works fine in a simple Apple Macintosh which only has a couple of expansion slots and doesn't have very many devices that need interrupts. It's just not reasonable to limit the number of devices to the limited number of interrupts available. It's also not reasonable to require the computers to have a vast number of interrupts available in case someone want to use them. These resources can be safely and efficiently shared. The reason plug and play doesn't work is because of crappy hardware and driver development. I write drivers for FibreChannel boards, and my drivers can share interrupts and still perform well. Don't try and tell me that some ethernet card has to have it's own interrupt. It's simply a poor implementation.
That's true only to a certain extent. Economies of scale mean that the development and setup costs are spread out over more units. However, the raw materials and the equipment for the optics are still considerably more expensive than copper wire. You can't lose money on each unit and make up for it on volume. This is something that many of the internet companies are just learning.
I can't tell you why they have a NDA on their firmware spec, but they aren't alone. I know of no vendors in their market that don't. It may be that they are trying to hide some of their IP from their competitors. Most likely they are trying to hide the limitations of their products from their competitors, so their competitors can't exploit them or market their products at those weaknesses. You can say that they shouldn't design products with weaknesses, but everyone has to make design decisions, and no product is perfect. A large percentage of the time spent on driver development is working around limitations or flaws in hardware. It's amazing what you can fix in software, and with the speed of today's processors, a few extra clock cycles doesn't effect performance. If you use dma and write your software well, you can keep the cpu load low, and still saturate the PCI bus with data.
First off, I think you're talking about the driver for NVidia's family of GPUs ...
We're not in the graphics market, but the issues may be similar.
So why don't they, and why don't you publish that which you can publish and ship only the NDA'd stuff binary? (which would also aid the reengineering effort because then there's a lot less to work on).
I really don't know why the ASIC vendor doesn't publish their spec. The firmware specification which tells us how to interface with their ASIC is under NDA, but a lot of that information can be determined from the GPLed Linux driver, but definately only a subset of the functionality that we use. Since the material under NDA is at the core of the driver, it wouldn't do users much good if we released the source to the rest of it. It would however help our competitors which have access to the NDA information.
By releasing the source, we risk having the software we developed stolen and used by our competitors, but what do we gain. In our particular market the hardware our board interfaces with is very expensive. The average open source developer doesn't have $100,000 worth of equipment sitting around. Because of this our market just doesn't lend itself well to open source development. We do have certain partners who do have access to the source. We had to execute a 3 way NDA with the ASIC vendor to give them access, but it is possible.
You of all people should know that a chip isn't done when the VHDL is done. Even if people get it to work on a FPGA (and they're sometimes more expensive than purchasing the device!) all they l get is an underpowered version of the real thing.
That depends a lot on the product. When you aren't talking about huge volumes, then FPGAs are a reasonable and even cost effective solution. Rolling an ASIC is very expensive, and mistakes mean rolling it again. With a FPGA you can change how the hardware works across the PCI bus, while the board is in the system. We have two products which perform significantly different tasks, on which the only differences are the parts externel to the FPGA and the VHDL. You can actually populate the board with parts for both functions and change what it does while it's in the system.
As for a FPGA being an underpowered solution, this is completely untrue. There is no reason that a FPGA solution is inherrantly less powerful than an ASIC solution.
Your comments on FPGAs being expensive it very true, especially at higher densities. However, you can save money if you can split the design into a couple less dense chips.
One more thing, I'm also aware that making the device available with only proprietary closed software to use it with also has the advantage of controlling what functionality/features of the device are available to the end-user. That way, you can keep people from exploiting the hardware of the device to the point that it prolongs the product's lifecycle and thus possible impedes sales of a successor device.
We are a small company that's trying to put our the best product we can with the most features we can in the shortest time we can. We aren't holding back features for the sake of our next generation products. This may be true of other companies, but I can say that it's not true of ours.
The ASIC vendor does have an Open Source driver which has a portion of the functionality of our driver. If that driver suits your needs, then you can buy the hardware from whoever you want.
Production Costs != Development Costs
It doesn't take a huge development effort slap an ASIC into a reference design card. If the driver is simple, then the software effort isn't that great either. However, our driver is about 30000 lines of code and runs on six OSs, and multiple hardware platforms for many of those OSs. Yes, we do support Linux on the PPC. Developing and testing the software is a huge development effort and required a large investment by our company. In order to pay for that we have to charge $$$ for our products.
Our cards are more expensive that the ASIC developers cards, however you get more for your money.
The ASIC maker would sell more hardware if there was an open source version of the driver and people didn't have to pay your 90% markup.
The ASIC manufacturer has decided that there are some markets they aren't interested in because the customres require special features or additional support that they aren't interested in providing. We provide additional features in our software, and more personalized support to those customers that need it. We can't just sell the support seperately, because that's not the way the business works. Customers, especially the government want COTS (Comercial Off The Shelf) products. However, a large percentage of our customers don't want the common off the shelf product, they want something a little bit different. They don't want to develop it themselves, because that would be way to expensive. Me make products that fit those niches, and have the experience to make our products work in non-standard environments. We add value the the product that the ASIC vendor cannot or will not provide.
Now, the ASIC vendor could just fully publish their specs and let the open source community provide drivers. However, many of the non-mainstream projects just never reach a high level of quality control, and most open source developers really can't afford the hardware we need to properly test and develop our software.
The other issue is that developing sowtware costs money. Most of our ASIC vendors customers don't need the software we develop. They don't need our specialized protocols or a driver for a PPC single board computer. Why should all the vendors customers have to pay more for their boards to pay for development of software they don't need. Let the people who need our software pay us for our software.
Free software has a place. We do have a hardware product to which we have always provided the source to the driver. For that product there is a definate benefit to the customer to having source, and it uses our own custom ASIC, so we make our money off the ASIC in that case.
The sell the hardware, but all software should be free also bothers me because it's getting harder to define what's hardware and what's software. We have a product that is mostly implemented in a FPGA. VHDL is just software to me. You compile it, load it into the FPGA, and you have a hardware product. Change the VHDL and you have a significantly different hardware product. Should that be free too? How do you expect developers to recoup costs? Where do you draw the line? How can companies make money so they can pay for the development tools, and pay their employees? There's lots of people pushing for free software, but how does it work as a business model when you aren't talking about a mass market product. How does free software address a complicated, software product that has relatively few people that need it?
Guess it's off to the computer show to pick up some more OEM (for sale only with a new computer) software. After all, I stuck in that extra memory DIMM and loaded the OS, that makes me an OEM, right?
It's not like there's a good way around making it kernel dependent. They can't release the source to the CSS code, and I'm sure the their licensing agreement for CSS requires copy protection such as Macrovision. Therefore it has to be a closed source binary. The problem is that Linux doesn't have a binary driver interface. You have to include a bunch of kernel headers, which change from one kernel to another. They also often change when someone applies a kernel patch, so you either have to have some kind of open sourse interface layer for your driver that can be recompiled, or if someone patches their kernel you driver doesn't work anymore.
We've run into this problem where I work. Our hardware uses an ASIC produced by someone else. We developed our software with information on the ASIC that we received under NDA, so we can't make the entire driver open source. Not to mention that other companies could just slap the ASIC on a card, use the software we developed, and undercut our price, since they'd save 90% of the development costs.
The code for the binary driver can't call kernel functions directly. It goes through a layer which is open source and contains the kernel headers. That layer needs to be recompiled every time the kernel is recompiled to ensure the driver works with the new kernel. It's a pain for our customers, and it makes Linux the most difficult (and therefore the most expensive) OS for us to support. Fortunately, we have enough customers using Linux to still justify supporting it, but tech support really dreads getting calls on our Linux products.
As for InterVideo's particular choice of going with a binary only approach, they really don't have a choice. The MPAA dictates the rules of the licensing agreement, there choices are a closed source LinDVD or no LinDVD.
I've never seen an API that was well completely documented. If using "undocumented" api calls violates Apple's license agreement, then why develop for their OS. You just run the risk of them calling out their lawyers and having all your work go to waste. Just don't develop any software for their platform and let them shrivel up and die. A consumer OS is no better than the applications that are available for it. If Apple is stupid enough to drive off developers, then they go out of business.
Releasing the software under GPL could get you into some interesting legal trouble. If your employer legally owns the rights to the software, how can you legally release it under GPL. It might be taken as giving away something that doesn't belong to you. I'm not sure what this means to the thousands of people working on GPLed software in their free time, but I suspect there are a lot of people violating their employment agreements.