5 ms·

Isn't all my other non-free software just blobs that are loaded by my free software? Why isn't it my right as a user to choose the closed software? If hiding

by smoyer 15y ago

Isn't all my other non-free software just blobs that are loaded by my free software? Why isn't it my right as a user to choose the closed software? If hiding the blob from the user makes it okay, why not apply that thinking to drivers wrapped by the NDISwrapper?

zdw 15y ago
The problem is that binary-only drivers are in privileged locations and frequently cause OS kernel problems. As they're binary only, they've basically undebuggable, and frequently nonportable to other systems. OpenBSD is very strong on this, and often has drivers that are blob-free when other OS's don't: http://onlamp.com/bsd/2006/04/27/openbsd-3_9.html http://onlamp.com/bsd/2006/04/27/openbsd-3_9.html This isn't restricted only to free OS's either - nearly 30% of Vista crashes were attributed to buggy nVidia drivers: http://arstechnica.com/hardware/news/2008/03/vista-capable-lawsuit-paints-picture-of-buggy-nvidia-drivers.ars http://arstechnica.com/hardware/news/2008/03/vista-capable-l... In short, if you want a system you can at least have a chance at fixing when it breaks, you need the source code to your drivers. This case in particular is a firmware load into a 3rd party chip, which isn't usually as bad a a binary driver, but can be a hassle if there are restrictions on distribution of the firmware.
- Someone 15y ago
  "This case in particular is a firmware load into a 3rd party chip, which isn't usually as bad a a binary driver" In most scenarios where I think a '3rd party chip with its own firmware' makes sense, that chip can generate interrupts and/or do DMA. Both cases will (typically) allow that firmware to crash the OS on the other CPU (or bring it to its knees by DDOS-ing it with interrupts) Because of that, I do not see why a blob running on that 3rd party chip would be less of an issue than a blob running on the main CPU.
  - tedunangst 15y ago
    Why is a blob running on a 3rd party chip less of an issue than hard coded transistors on a 3rd party chip?
    - Someone 15y ago
      Good argument. I would say it is not less of an issue, but I also think it isn't less of an issue than having a blob running on the main CPU. IMO, such blobs only become problematic if they do not work properly or aren't flexible enough. Whether they are made in soft-, firm-, or hardware is immaterial for that. In the end, for almost every case (yes, you probably _can_ build your own 1kW 6502-class CPU from sand, if you are good, start young and persevere for a couple of decennia) it boils down to the fact that you will have to trust some other people. After all, you cannot reasonably verify that say a x64 CPU really behaves as its documentation states it does.
      - tedunangst 15y ago
        One reason the blob on the CPU is so different is the way it interfaces with your code. In that regard, it is almost never flexible enough and the exposed interface surface is generally enormous. Your kernel version is supported only at the mercy of nvidia or whoever. Firmware chunks have a very simple interface: load. Anybody with the firmware file and some basic documentation can make it happen.
- mseebach 15y ago
  > This case in particular is a firmware load into a 3rd party chip, which isn't usually as bad a a binary driver I'd argue that it's an entirely different kettle of fish. Once the firmware blob is loaded into the chip, the hardware widget works exactly like it would otherwise. If the firmware just lived on a ROM inside the widget, you'd never know it existed. Protesting closed source drivers I'm all behind for the reasons you mention, but closed source firmware just simply can't aggravate me.
icebraining 15y ago
Why isn't it my right as a user to choose the closed software? It's your right as the user - there's nothing to stop you from doing that. They simply won't help you with it, and any distro that does is deemed non-really-free (like Debian). Don't confuse "right to do" with "right to being easy to do".

by smoyer 15y ago

zdw 15y ago

The problem is that binary-only drivers are in privileged locations and frequently cause OS kernel problems. As they're binary only, they've basically undebuggable, and frequently nonportable to other systems. OpenBSD is very strong on this, and often has drivers that are blob-free when other OS's don't: http://onlamp.com/bsd/2006/04/27/openbsd-3_9.html http://onlamp.com/bsd/2006/04/27/openbsd-3_9.html This isn't restricted only to free OS's either - nearly 30% of Vista crashes were attributed to buggy nVidia drivers: http://arstechnica.com/hardware/news/2008/03/vista-capable-lawsuit-paints-picture-of-buggy-nvidia-drivers.ars http://arstechnica.com/hardware/news/2008/03/vista-capable-l... In short, if you want a system you can at least have a chance at fixing when it breaks, you need the source code to your drivers. This case in particular is a firmware load into a 3rd party chip, which isn't usually as bad a a binary driver, but can be a hassle if there are restrictions on distribution of the firmware.

Someone 15y ago
"This case in particular is a firmware load into a 3rd party chip, which isn't usually as bad a a binary driver" In most scenarios where I think a '3rd party chip with its own firmware' makes sense, that chip can generate interrupts and/or do DMA. Both cases will (typically) allow that firmware to crash the OS on the other CPU (or bring it to its knees by DDOS-ing it with interrupts) Because of that, I do not see why a blob running on that 3rd party chip would be less of an issue than a blob running on the main CPU.
- tedunangst 15y ago
  Why is a blob running on a 3rd party chip less of an issue than hard coded transistors on a 3rd party chip?
  - Someone 15y ago
    Good argument. I would say it is not less of an issue, but I also think it isn't less of an issue than having a blob running on the main CPU. IMO, such blobs only become problematic if they do not work properly or aren't flexible enough. Whether they are made in soft-, firm-, or hardware is immaterial for that. In the end, for almost every case (yes, you probably _can_ build your own 1kW 6502-class CPU from sand, if you are good, start young and persevere for a couple of decennia) it boils down to the fact that you will have to trust some other people. After all, you cannot reasonably verify that say a x64 CPU really behaves as its documentation states it does.
    - tedunangst 15y ago
      One reason the blob on the CPU is so different is the way it interfaces with your code. In that regard, it is almost never flexible enough and the exposed interface surface is generally enormous. Your kernel version is supported only at the mercy of nvidia or whoever. Firmware chunks have a very simple interface: load. Anybody with the firmware file and some basic documentation can make it happen.
mseebach 15y ago
> This case in particular is a firmware load into a 3rd party chip, which isn't usually as bad a a binary driver I'd argue that it's an entirely different kettle of fish. Once the firmware blob is loaded into the chip, the hardware widget works exactly like it would otherwise. If the firmware just lived on a ROM inside the widget, you'd never know it existed. Protesting closed source drivers I'm all behind for the reasons you mention, but closed source firmware just simply can't aggravate me.

icebraining 15y ago

Why isn't it my right as a user to choose the closed software? It's your right as the user - there's nothing to stop you from doing that. They simply won't help you with it, and any distro that does is deemed non-really-free (like Debian). Don't confuse "right to do" with "right to being easy to do".