4 ms·

While it is naive to imply closed blobs could ever fully or easily be replaced, it is also naive to blame the kernel user for having bought the hardware. For ad

While it is naive to imply closed blobs could ever fully or easily be replaced, it is also naive to blame the kernel user for having bought the hardware. For add-on cards, sure, but the line is not always that clear. Many are simply making do with the hardware they were gifted, or that is embedded, and so it's an all-or-nothing scenario. The closed blob in question may be getting loaded for something the user can't unplug or replace. Everything costs money, and not everyone can afford to throw away an imperfect choice and start again. I can typically blacklist things, but I need to know they are there to begin with so, to me, the problem boils down to the kernel, and other software, potentially doing things that I don't want. Since closed kernel blobs are clearly controversial, something as simple as highlighting their loading and making it as easy as possible to prevent it from happening on future boots may be enough. If the process is in place, it can be a simple lack of orientation - but Theo's response certainly doesn't help with that. As for running blob-free in general... It's not that hard, really. Often the only loss is fast 3D. Debian does a good job of separating free from non-free - and really, that is enough, since adding non-free items then becomes a conscious act (there can be other ways of making the distinction though).

seba_dos1 11y ago
See, even you are confused. If you give "loss of fast 3D" as an example of running blob-free, you didn't understand what Theo is talking about. 3D drivers run in user or kernel space, there is a clear policy about how to deal with stuff like that in basically any serious operating system that labels itself free and open. This mail was about firmwares. The little blobs your OS has to upload into memory of your WiFi card, Bluetooth controller, sensors, camera... and that's all it has to do with it. The rest happens on completely different CPUs - the ones that live inside your WiFi card, Bluetooth controller, sensors, camera... Even if your hardware seemingly doesn't require the blob to be loaded, it's most likely because it simply has a on board memory to store it. Some don't (obviously, that's cheaper way) and require user to load their firmware before they can operate. And nowadays, basically anything has such a firmware. Even microSD cards. From OS point of view, the only sensible approach to differentiate between free and non-free firmwares is to ask a question "is it freely redistributable?". If you go deeper than that, you enter the Open Hardware territory - which comes with its own set of principles and pandora boxes.
- ergethaxsd 11y ago
  (I'm saddened that you can't imagine ever needing to load FPGA, NAND, or VRAM "firmware" to boot a GPU.) > "the only sensible approach to differentiate between free and non-free firmwares is to ask a question 'is it freely redistributable?'" Is it? That's the question. It may not be when not differentiating between licenses, as shown by the current conversation, is differently important to different people. I'm still convinced that it's just a disagreement over log verbosity. It is perfectly appropriate for a kernel to support loading non-free anything... It's even a feature. I just want to know what it's doing, and show me a line based on a license that I fully acknowledge the kernel doesn't need to differentiate between other than for clear logging. I am simply hoping, as a user, to get the information I need to make informed choices, including the ability to turn feature X on or off as I see fit. I can only know to buy different hardware when I am told about the blob, and I can only see the effects of my goals if I can progress towards them (by disabling binary loading). I shouldn't have to guess, the feedback and levers should simply be presented clearly. I will stop tilting at this one, for lack of OpenBSD-specific examples, but I'm really just advocating for better information - not reducing hardware support or anything so nonsensical.
  - seba_dos1 11y ago
    How can you be sure that the firmware blob you got for some chipset is really some software compiled from source code and not a hand made initialization structure for some registers needed for it to operate properly? Or maybe you need some custom, proprietary solution to compile it that even the company that developed this hardware have no rights to redistribute? Or maybe even the company you bought that hardware from has no idea about the source code or firmware, because they simply used some chipset available on the market? Or... It's really counterproductive to differentiate it in this way. It doesn't help the cause at all. The license of firmware blob is really not a kernels issue. It's a lower layer - you can go for that when you start requiring all your hardware to be open. Otherwise, it's like bashing Mozilla due to Firefox not providing an option to load only Creative Commons or similarly free content from the Web. The kernel is here just to upload a bitstream to memory of some device. For kernel, it doesn't matter if it's open or not. It's just set of bits needed to be sent somewhere, nothing more, nothing less. It not like a typical software, as it's not even executed on your system.

seba_dos1 11y ago

See, even you are confused. If you give "loss of fast 3D" as an example of running blob-free, you didn't understand what Theo is talking about. 3D drivers run in user or kernel space, there is a clear policy about how to deal with stuff like that in basically any serious operating system that labels itself free and open. This mail was about firmwares. The little blobs your OS has to upload into memory of your WiFi card, Bluetooth controller, sensors, camera... and that's all it has to do with it. The rest happens on completely different CPUs - the ones that live inside your WiFi card, Bluetooth controller, sensors, camera... Even if your hardware seemingly doesn't require the blob to be loaded, it's most likely because it simply has a on board memory to store it. Some don't (obviously, that's cheaper way) and require user to load their firmware before they can operate. And nowadays, basically anything has such a firmware. Even microSD cards. From OS point of view, the only sensible approach to differentiate between free and non-free firmwares is to ask a question "is it freely redistributable?". If you go deeper than that, you enter the Open Hardware territory - which comes with its own set of principles and pandora boxes.

ergethaxsd 11y ago
(I'm saddened that you can't imagine ever needing to load FPGA, NAND, or VRAM "firmware" to boot a GPU.) > "the only sensible approach to differentiate between free and non-free firmwares is to ask a question 'is it freely redistributable?'" Is it? That's the question. It may not be when not differentiating between licenses, as shown by the current conversation, is differently important to different people. I'm still convinced that it's just a disagreement over log verbosity. It is perfectly appropriate for a kernel to support loading non-free anything... It's even a feature. I just want to know what it's doing, and show me a line based on a license that I fully acknowledge the kernel doesn't need to differentiate between other than for clear logging. I am simply hoping, as a user, to get the information I need to make informed choices, including the ability to turn feature X on or off as I see fit. I can only know to buy different hardware when I am told about the blob, and I can only see the effects of my goals if I can progress towards them (by disabling binary loading). I shouldn't have to guess, the feedback and levers should simply be presented clearly. I will stop tilting at this one, for lack of OpenBSD-specific examples, but I'm really just advocating for better information - not reducing hardware support or anything so nonsensical.
- seba_dos1 11y ago
  How can you be sure that the firmware blob you got for some chipset is really some software compiled from source code and not a hand made initialization structure for some registers needed for it to operate properly? Or maybe you need some custom, proprietary solution to compile it that even the company that developed this hardware have no rights to redistribute? Or maybe even the company you bought that hardware from has no idea about the source code or firmware, because they simply used some chipset available on the market? Or... It's really counterproductive to differentiate it in this way. It doesn't help the cause at all. The license of firmware blob is really not a kernels issue. It's a lower layer - you can go for that when you start requiring all your hardware to be open. Otherwise, it's like bashing Mozilla due to Firefox not providing an option to load only Creative Commons or similarly free content from the Web. The kernel is here just to upload a bitstream to memory of some device. For kernel, it doesn't matter if it's open or not. It's just set of bits needed to be sent somewhere, nothing more, nothing less. It not like a typical software, as it's not even executed on your system.