Why is it important that linux drivers have source available but we don't worry so much about seeing the firmware source? Should we be pushing to see firmware source too? Instead should it not matter about seeing driver source? I'd love to hear your perspectives.

We're talking about on already-general-purpose PCs. Alternative firmware is very useful on artificially limited devices like phones, and apparently routers

...And on graphics cards where they've been known to be artificially limited in order to boost the price of an only slightly better model.

Personally, I won't rest until every last ounce of source-code is available for my machine. Direct Memory Access (DMA) + Firmware Binary Blobs == Unknowable behavior. This is one reason I applaud AMD's support for CoreBoot. [wikipedia.org]

No, I'm not paranoid, but, yes, we probably should be -- I've just been burned too many times by MFGs dropping support for things to enforce art

Their "support" of coreboot is only for show. We had to drop using linuxbios/coreboot on our quad core systems because it wouldn't boot correctly (read: at all.) We had the same problem with the previous gen dual core systems -- for unknown reasons 7% would not work. Only after buying a source license for AMI(?) BIOS ($$$$$) did we find them flipping several undocumented, reserved bits which were the difference between unstable/unbootable and a fully functional system. [ALL of them work perfectly when bo

That doesn't mean firmware can not do evil things. Or does not need any quality vetting or so.

The BIOS is a kind of firmware too, and there exist viruses that can exploit certain BIOS firmwares and to all kinds of bad things to your computer. Not sure about this specific piece of hardware but I'm quite sure that the trend is towards more and more reprogrammable firmwares, if only to fix bugs after release.

Anyway I'd say the firmware is about as important as the OS driver. And having the source of the firmware will no doubt provide information to driver developers on how the device really works.

So you've really asking why we can't see all firmware code for all devices and peripherals, including BIOS, but also firmware for all devices in our computers like optical drives, HDD's, video cards. What about keyboards and mice, which probably also have some firmware code in them too by now?

And the question on why we can not see (most) firmware source code will probably the exact same answer as why we can't see (most) driver source code: patents, copyrights, proprietary algorithms, DRM, whatever.

Yet the biggest risk lies in the devices where firmware can be changed ("flashed"), and where the device and its software must provide certain security against that happening unauthorised. There exist at least proof-of-concept BIOS viruses, maybe also actually malicious BIOS viruses. There is no reason why such viruses could not target other parts of the computer, such as hard drive firmware to hide themselves.

Often the firmware is what turns a bunch of cheap standard parts into a real product. Unless you want to go open source hardware, too, you need to keep your firmware proprietary, because most of the engineering is actually part of the firmware and pcb layout is just a small part of your product. And it is easy to do a compatible pcb from the scratch.

I'm sure I'll probably get hate for pointing this out, but it is also why you can get card X for cheaper than card Y, just as with Win 7 Starter (which is actually a damned nice low resource OS and I wish they'd sell it as an OEM) through Ultimate having the same code just with different parts turned off. This lets the manufacturers sell the same device with different feature sets thus making it so those of us who don't need Y-Z can only pay for X.

Legal Shmegal, the bigger question is...does anybody care? The Indian working the phone for MSFT does he care? he don't care he just wants to get you off the phone ASAP to keep his metrics high, which is why I have NEVER had a problem activating Windows. Does MSFT care? not according to Ballmer, which I'm sorry I can't find a transcript but I saw an interview shortly after he became CEO where he said "I don't care about the kid that puts a pirated copy of XP on his PC. What I DO care about is that boatload

I've read somewhere (I don't have the citation handy) that some versions of the OEM agreement tie the license to the case to which the PC maker attached the certificate of authenticity sticker. I've read that other versions of the OEM agreement tie the case to one motherboard.

What is good (i.e. increases profit) for the producer is not necessarily good for the consumer. And likely, as another poster pointed out, it has also to do with small defects in the chips, just like AMD and Intel are testing processors and then selling them at different clock speeds dependent on what that individual processor can do.

I used to think the same thing, that turning off features is an evil thing.

But now, I realise that is what allows us to get cheaply hacked hardware that's about 5-10% better than what we paid for. The richest subsidises the rest of us. If all they do is change firmware, instead of tracecutting or burning fuses, then we can have what they do.

So go ahead, it gives us cheaper, better hardware. Or buy open source hardware like in article.

Yes. It costs the same to produce either way, so it should cost the same to buy. If ATI had to sell the same card to everyone at the same price, they'd have to sell it at a reasonable price for everyone or they wouldn't sell any.

You are naive AND you want what is best for the consumer (actually, usually this means what is best for you, but I'll let that point be). The two aren't mutually exclusive, but if you can come up with a plan that allows ATI to be better for the consumer (both short and long term) I'm sure they'd be happy to do it.

Unfortunately, your armchair naivety doesn't work in the real world. When you finish growing up and you realize the world isn't black and white, and the easy thing isn't often the best thing, per

An open source driver for this is great news because it means the driver, and therefore the card, can be rebuilt for different architectures, can be enhanced over time, can do all the stuff that's great about open source. Not to mention serving as a learning aid for others.

Open firmware would be a bonus because then people have the ability to alter the behaviour of the card itself. Some people do care about this stuff so you have projects like Openmoko's Neo phones. There are also sometimes license problems related to distributing closed firmwares if the OS needs to load them into the device.

Driver source is more important IMHO, for now, because without it (or reverse-engineered OSS drivers) some of my projects with linux on ARM would not have been possible. One example was a wireless USB card attached to an NSLU2. Windows drivers through the old ndiswrapper were no good, it's only when open source drivers were available I could proceed.

Depends on the device but the firmware may well be something that isn't very accessible to users. For example if the device uses an FPGA, which many do, then the firmware might be the FPGA programming. Ok fair enough, but do you have the Xilinx development software and hardware, not to mention expertise, to mess with it? Not nearly as easy or cheap as firing up a compiler and messing with a driver.

Even if not, if the firmware is just code for something onboard kinda like a BIOS/UEFI on a PC, it could still be pretty difficult for users to deal with.

There's also the issue of bricking the device. Messing with the driver might screw up the OS if done badly enough, but the device should be fine. However messing with the firmware could render the device unusable, and depending on how bad it was messed up could render it unfixable in that you couldn't flash a stock firmware back on it.

Too much risk for not much reward overall, which is probably a big reason not to do it.

Look, the device needs to have a way to update its own firmware, right? Usually this is in code, in the firmware. If you overwrite the firmware, and you fuck this part up, you can't update over your FUBAR custom firmware. The general public considers this "bricked" because they don't want to start soldering stuff to the JTAG terminal or whatever.

Consider this wild notion:Allow all the firmware except the bootloader to be overwritten by the bootloader. Then if you brick it, you can still use the bootloader to fix it.

But others do and may wish to play with it, may even do some cool stuff. Of course they may also do risky things, brick devices, burn them out, whatever else.

This is where "disclaimer of warranty" comes in, IMHO. Perfectly fair to say something like - "Here's the source for the firmware, if you change anything and flash your own version your warranty is over. Happy Hacking"

Personally I don't have the experience to do such programming, and I guess that accounts for most (almost all) people on/.. I don't even know how to hack my own driver. I can barely understand a simple C program.

Still I think it's a good thing to have the source available. People can often do really cool things with it - lots of creative minds wanting to do crazy things the device maker never thought of, or simply want to scratch an itch, and the greater public (including me) can benefit from that.

Personally I don't have the experience to do such programming, and I guess that accounts for most (almost all) people on/.. I don't even know how to hack my own driver. I can barely understand a simple C program.

I don't even know where I am! What's this big glowy panel in front of me? Does this button do something?

A lot of the more complex devices (WiFi, Bluetooth, programmable NICs, etc) often run another OS to manage them. There's often no license to distribute the necessary source, nor is there any way to rebuild it without requiring the proprietary development environment.

It's usually some sort of RTOS. So no, firmware isn't just a simple program that starts at main() and handles requests from the host - it can often be handling real-time processing and many other tasks sim

Why is it important that linux drivers have source available but we don't worry so much about seeing the firmware source?

When your operating system changes in a way that breaks the driver (or you want to use the card on a completely different OS), you can adapt the driver to your new system. From this perspective, it does not matter what is in firmware and what is in hardware.

The firmware is platform neutral and is a part of the card itself. If you have the card, you have the firmware and as long as you have a driver, you can use it. If you don't have the card, the firmware doesn't matter much.

OTOH, it is entirely possible to end up having the card, but not having a driver for your OS. In that case, you mights as well not have the card either.

Meanwhile, if you update your OS, and you have a GPL driver, you can update it as needed. The firmware won't get in the way.

AFAIK, Windows isn't released with any firmware on the release CD either.

On what do you base this claim? afaict many drivers contain firmware and windows contains many drivers (most of which afaict were not written by MS) so i'd be very surprised if their wasn't firmware on the windows CD.

Make one. We have rich tool-sets for compiler development. The specs are all we really need -- Give us the hardware specs (instruction tables, register layouts, etc) and we can build compilers. Having to reverse engineer a processor, and then build firmware for it is a pain in the ass. It would be nice if the MFG just shared their tools & sources with us -- then they could benefit from our improvements, but hey No one ever accused them of being benevolent and customer friendly.

That's difficult when the CPU core you licensed uses an instruction set that is "proprietary and confidential", or the revenue from additional sales to Linux users wouldn't cover the cost of developing free build tools.

It would be nice if the hardware vendors stopped worrying about software "thieves" so much

And it would be nice if people got a bonus check from the government just for being outstanding citizens, like in Lilliput, but that's not going to happen in this system of things.

Hint: I buy the hardware, it should come with the source code to make it work

That's difficult if your hardware product is essentially a DSP and FPGA on a board little different from the chip

Exactly for what stupid reason the CPU core instruction set are "proprietary and confidential"? The point that VortexCortex is making is that it is for the wrong reasons. The reality is that the vendor is ok to have you locked-in with whatever type of usage they feel happy with. The confidentiality is just bullshit. As for the additional sales for Linux users, well, fuck that! Let's don't use that hardware maker then.

Now, I don't think anyone asked for the source code of the FPGA. That one is more to be s

As for the additional sales for Linux users, well, fuck that! Let's don't use that hardware maker then.

Sometimes people don't have the choice not to use that hardware maker. For example, if all makers of one kind of component of home PCs act this way, such as all makers of mobile broadband cards, is one supposed to just not buy and not use that kind of component? Or they might be using donated hardware, such as a birthday/Christmas gift or a charitable in-kind donation to a no

At Debian, we do care about binary blob firmware without source. We put them in "non-free", and we don't consider it's part of the OS (it wont go in the released CD, etc.).

Does your installer still insist on installing grub onto the memory stick typically used to provide such firmware for your netinstall CDs instead of the hard drive, or can I finally stop cursing under my breath every single time I'm trying to install a DL360 and I forget to remove the memory stick ?

That is perhaps my biggest complaint about Debian, which is to say that it's been a positive experience for the most part.

"Update: June 7th, 2011 - Several important things to note, the BC-H series H.264 cards do not have at traditional firmware that is loaded. Everything is accessed directly from the driver / user space applications. Secondly, we report sales of each encoder to MPEGLA and pay any necessary patent fees for the sale of each encoder, meaning that any cards purchased from Bluecherry already have the patent protection from MPEGLA for the device level encoder."

So, in this case the discussion is moot - this card doesn't need any shady things to run on my computer - i am getting one!

From the site:
Update: June 7th, 2011 - Several important things to note, the BC-H series H.264 cards do not have at traditional firmware that is loaded. Everything is accessed directly from the driver / user space applications. Secondly, we report sales of each encoder to MPEGLA and pay any necessary patent fees for the sale of each encoder, meaning that any cards purchased from Bluecherry already have the patent protection from MPEGLA for the device level encoder.

Update: June 7th, 2011 - Several important things to note, the BC-H series H.264 cards do not have at traditional firmware that is loaded. Everything is accessed directly from the driver / user space applications. Secondly, we report sales of each encoder to MPEGLA and pay any necessary patent fees for the sale of each encoder, meaning that any cards purchased from Bluecherry already have the patent protection from MPEGLA for the device level encoder.

Why is it important that linux drivers have source available but we don't worry so much about seeing the firmware source? Should we be pushing to see firmware source too? Instead should it not matter about seeing driver source? I'd love to hear your perspectives.

Every device in my machine that does anything particularly useful is going to be largely or wholly proprietary. I appreciate it when the hardware (by way of its firmware) can provide an interface to the OS that isn't needlessly complicated (technically or legally) to reimplement for various OSes and platforms. This makes it much easier to get a driver in source form - which in turn makes it a lot easier to carry support for the device up to a new version of the Linux kernel (since Linux doesn't have a stabl

Why is it important that linux drivers have source available but we don't worry so much about seeing the firmware source? Should we be pushing to see firmware source too? Instead should it not matter about seeing driver source? I'd love to hear your perspectives.

Device A has an open source driver, proprietary guts, and a firmware blob loaded by the driver on boot.

Device B has an open source driver, proprietary guts, and a firmware blob hidden in an immutable ROM on the device that you don't know about.

For some reason, Debian scorns Device A and praises Device B, even if the firmware blob for Device A allows unlimited redistribution. For the most part I like Debian, but that policy is just silly: Device A is the one that has the greater potential for end-user hackability.

My understanding, from TFPR, is that the card does h.246 encoding onboard(and the manufacturer of the card has paid their protection money to the MPEG LA) so the driver has no h.246 related duties, it just configures the card and collects the encoded output.

Obviously, since the output is h.246, it'll need to be decoded for use, which does raise the patent issue; but not at the driver level.

My understanding, from TFPR, is that the card does h.246 encoding onboard(and the manufacturer of the card has paid their protection money to the MPEG LA) so the driver has no h.246 related duties, it just configures the card and collects the encoded output.

It is not "protection money."

It is a royalty.

It is royalty that maxes out at 20 cents per unit after the first 100,000 units you sell each year.

Unless your are producing on an industrial scale, the custom boards you are buildi for the academic and hobbyist market aren't of the slightest interest to the MPEG-LA.

I see how the fees for codec products (in OSes or Apps) could be a problem for open source. The Freebie there only applies to the first hundred thousand units. There's no way to limit the number of units in an open source product.

But in addition there are freebies for services and encoding for broadcast:

- Encoding as a service for a fee pays only if the encoded "title" is 12 minutes or longer. (At first I thought that might be related to YouTube's (former) 10 minute limit but the Wikipedia

How does the patent pool get in the way? The manufacturer of this pays all the relevant royalties to the MPEGLA for the consumers thus there are NO patent issues at all for the end user. But don't let pesky things like those facts get in the way of your rant.

Update: June 7th, 2011 - Several important things to note, the BC-H series H.264 cards do not have at traditional firmware that is loaded. Everything is accessed directly from the driver / user space applications. Secondly, we report sales of each encoder to MPEGLA and pay any necessary patent fees for the sale of each encoder, meaning that any cards purchased from Bluecherry already have the patent protection from MPEGLA for the device level encoder.

The REAL issue with Linux/FOSS video right now is the total lack of support for Cable Card and Tuning Adapters. Without them, there is no way to make an effective Linux DVR other than just over-the-air recordings. Gone are the days of "cable ready", analog, and in-the-clear digital.

Of course, that is not the fault of Linux, but of the media giants and cable companies who are just terrified of someone sharing/ripping their content.

Ceton makes a 4-tuner internal CableCard device (already available), and Silicon Dust makes 3-tuner and 6-tuner network attached CableCard devices (available at end of July). Both devices will work under linux. The Ceton will have support in the next version of MythTV, and the Silicon Dust devices are already supported in the current version. The only downside is that they are limited under linux to only recording shows marked "Copy Freely". What this means will vary from cable company to cable company, and

Cable cards in general are not what they are hyped to be. Many people have been waiting on them longer than some of us have been using alternatives (namely the Hauppauge HD-PVR). PC Cable Card tuners have been somewhat vaporous while you've been able to get older Silicon Dust products and the HD-PVR at places like Frys and Microcenter for quite awhile now.

The point is, they are here now and usable (in at least some circumstances) under linux. If you are in a situation where you CAN use one of these devices, then it works out to be superior to the HD-PVR. With a CableCard device, you pay under $300 for the device up front, you only have to rent one cablecard for about $2-4/month, and it only consumes about 10 watts or less of electricity. This will get you 3-4 tuners. To get 3 tuners with HD-PVRs, your up front cost is going to be more than $500 (maybe $400 w

> The point is, they are here now and usable (in at least some circumstances)

Really? Do you have one? I had an HD-PVR as soon as it was possible to have oneafter it was released. It was released on time and there were no delays in the releaseof the product or extreme backorder delays as have been common with Cable Card tuners.

> under linux. If you are in a situation where you CAN use one of these devices,> then it works out to be superior to the HD-PVR....probably not.

> The point is, they are here now and usable (in at least some circumstances)

Really? Do you have one?

No I don't. I've been waiting for the Silicon Dust device (which as I said previously, will be available at the end of July), but the Ceton has been available and usable under Linux for several months now.

The ugly spectre of DRM raises it's ugly head and makes it very unlikely that a Ceton card is going to be as useful in Linux. This DRM causes problems and imposes limitations even with non-Linux solutions.

Like I said, it depends on your situation. In my case, my cable company (not a monopoly here, BTW...we have competing providers) provides everything that I am interested in "Copy Freely" form, which means there are absolutely no restrictions on the recordings (I can keep them forever, send them to anybody

Of course, in my previous post, I forgot to add the following: You might be confused, because these don't appear to me to be just regular video capture cards. They appear to only work with security cameras. So the CableCard thing is a little off topic.

An effective Linux DVR is possible. I know it is not ideal, but you can use an HD-PVR in Linux to capture (in 1080i) the output of any device that provides component output. That's what many MythTV users do... rent the cable company box and just capture the output. Like I said, not ideal, but it is possible, and many are doing it.

It's OK for a final distribution codec as long as you have the horsepower to decode it, but it sucks rabid weasel scrotums for acquisition and editing. With common hard drives at 3 TB, ubiquitous gigabit ethernet on LANs, and incredibly fast internal and external bus speeds, there's simply no reason to use an interframe codec or high compression ratios for anything but web delivery.

Well, my 1080p consumer camera saves directly to H.264 - if your ambition is not higher than that, I'd say it's fine. Sure, if you're going to throw in lots of effects and filters and whatnot it's not ideal but two rounds of loss, one in acquisition and one in final print is not that horrible. It's not much point using a worse lossy codec, and if you go lossless those 3TB will be gone rather quickly...

The thing that makes H.264 bad for editing is not that it is lossy, it is the interframe compression. DV cameras use a variant of MJPEG, where each frame uses JPEG-like compression, but is compressed independently. This means that you can slice the video between any pair of frames without reencoding. If your source is H.264, then it has bidirectional interframe compression, meaning that every frame between key frames depends on the contents of the frames before and after it. If you slice the video anywh

The thing that makes H.264 bad for editing is not that it is lossy, it is the interframe compression.

You do realize that almost none of the formats used as intermediates are lossless, right? ProRes, DNxHD, etc are all lossy as well. Secondly, you can encode H.264 as intraframe only and still get better compression ratios than most of the other competing intermediate formats and you can easily edit it. You post smacks of knowing absolutely jack and shit about what you are talking about.

How so? H.264 intraframe for doing editing and for an intermediate is pretty darn awesome. Using something like x264 with a pretty decently low CRF value you can beat pretty much any of the "pro" codecs for the same work. And it's funny you whine about the "horsepower" but most of those other intermediate codecs are usually just as intensive if not more so than working with H.264 (which in most cases you are using a hardware accelerated solution so it's all moot anyway).

I would say world would be better with reasonable time with patents. Like you have 2-3 years time to start commercial use with the patent or loose it. From the patent day (day 1) you have 5 years to use it, if you got commercial use for it. And then it comes free (not public domain but something like GPL).

Without patents you would not have copyright either and so on no GPL or any other license than just public domain and that means there are no protectin

Without patents you would not have copyright either and so on no GPL or any other license than just public domain

BULLSHIT

Patents and copyrights are very different and there is no reason you can't have one without the other. Software has been copyrighted for far longer than it has been patented. In particular copyrights protect a particular implementation of a method but there is nothing to stop someone else implementing the idea themselves. Patents protect the method itself which can mean there is no way to implement a standard format without giving into the patent holders demands (which are often incompatible with th

Actually....patents are supposed to protect only a particular implementation of an idea. Software patents have expanded to the point where they are encompassing the idea itself and that is the problem.

The geek can be entirely self-absorbed, seeing nothing beyond his own pre-occupation with computers and the Interenet.

But standards like can H.264 evolve and take root in very different environments. They can serve very different constituencies --- and when they gain traction on the web, they can take him by surprise.