4 ms·

(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

(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.
- ergethaxsd 11y ago
  I don't think it's counterproductive at all and we actually agree in a sense. In a sense, opaque blobs are the default license category. Moving past that, if we can acknowledge that unambiguously (positively-stated) non-proprietary licenses are worth favouring, it is worth differentiating as a means to an end of open hardware. For example, I would appreciate a "noblob" kernel option. If my system doesn't boot, I may reverse that choice, but I can also (still) hope for, and request, useful information along the way so I can choose the closest to ideal (for me) from the options available. At some point it becomes a "if you don't like it, submit a patch" scenario, which is fine. It is more likely to lead to that when the response isn't overwhelmingly dismissive or insulting.
  - seba_dos1 11y ago
    You already have such option. On Linux, you simply don't install or remove stuff from /lib/firmware However, ideologically it doesn't make any sense, since when your kernel is booted you're most likely already past the loading of lots of non-free blobs in lots of chips. Kernel deals only with the ones that don't have internal memory to store them.
seba_dos1 11y ago
> (I'm saddened that you can't imagine ever needing to load FPGA, NAND, or VRAM "firmware" to boot a GPU.) That's clearly not what you were talking about. It's true that drivers usually also contain firmwares, or microcodes for GPU. However, removing them will most likely prevent you from using GPU at all, not just "fast 3D". And even if it doesn't, because the most important parts of that non-free firmware are already sealed in memory on the card, it's no different from, let's take the easier example, any HDD out there. So either your blob-free system works almost perfectly, cause you only take the software running on main CPU into account, or your blob-free system doesn't work at all, cause you actually removed all firmware blobs and basically nothing works anymore, including HDD, CD drive and motherboard.
- ergethaxsd 11y ago
  > "And even if it doesn't, because the most important parts of that non-free firmware are already sealed in memory on the card, it's no different from, let's take the easier example, any HDD out there." On the contrary, the mere fact that it is a series of bits under user control - pure software for which there is a user-initiated loading mechanism - is precisely what makes it a the subject of peoples' libre software goals. Furthermore, it is because it is required that the user perform the initialization to use the main features that the user is constantly reminded about the proprietary dependency. Hard drives, for example, aren't a big focus for advocates because the drives generally don't forget they are hard drives between boots. It is true that they CAN be re-flashed, but it is not conventionally necessary to run, and that places them on a much more remote wish list. The main responsibility of the kernel in such cases is to prevent unauthorized firmware changes coming from userspace (ex, the NSA, over the network). Boot-time firmware is qualitatively different from hardware that ships with working firmware, just as the latter is a different beast than ROM-based blobs.
  - seba_dos1 11y ago
    You still cannot be sure that WiFi blob isn't being reflashed over the air. Sure, it's harder to mess with reflashable firmware stored inside the device. However, it's only just like you said - a change on priority list, nothing else. Differentiating this in terms of freedom is a hypocrisy. Anyway. Kernel just provides you an interface to load such firmware into your device. When the firmware is freely redistributable, it's also included in the kernel source tree. Nothing more, nothing less. It's up to you to decide what to do with it - you can easily look up all the needed info and remove unwanted firmware files. For me there's no difference where it's stored. Closed firmware is closed firmware. We either have to accept it or not use PCs at all. In the meantime, we should rather focus on producing stuff that increasingly stops requiring it, instead of aimlessly fighting with kernel developers.

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.

ergethaxsd 11y ago
I don't think it's counterproductive at all and we actually agree in a sense. In a sense, opaque blobs are the default license category. Moving past that, if we can acknowledge that unambiguously (positively-stated) non-proprietary licenses are worth favouring, it is worth differentiating as a means to an end of open hardware. For example, I would appreciate a "noblob" kernel option. If my system doesn't boot, I may reverse that choice, but I can also (still) hope for, and request, useful information along the way so I can choose the closest to ideal (for me) from the options available. At some point it becomes a "if you don't like it, submit a patch" scenario, which is fine. It is more likely to lead to that when the response isn't overwhelmingly dismissive or insulting.
- seba_dos1 11y ago
  You already have such option. On Linux, you simply don't install or remove stuff from /lib/firmware However, ideologically it doesn't make any sense, since when your kernel is booted you're most likely already past the loading of lots of non-free blobs in lots of chips. Kernel deals only with the ones that don't have internal memory to store them.

seba_dos1 11y ago

> (I'm saddened that you can't imagine ever needing to load FPGA, NAND, or VRAM "firmware" to boot a GPU.) That's clearly not what you were talking about. It's true that drivers usually also contain firmwares, or microcodes for GPU. However, removing them will most likely prevent you from using GPU at all, not just "fast 3D". And even if it doesn't, because the most important parts of that non-free firmware are already sealed in memory on the card, it's no different from, let's take the easier example, any HDD out there. So either your blob-free system works almost perfectly, cause you only take the software running on main CPU into account, or your blob-free system doesn't work at all, cause you actually removed all firmware blobs and basically nothing works anymore, including HDD, CD drive and motherboard.

ergethaxsd 11y ago
> "And even if it doesn't, because the most important parts of that non-free firmware are already sealed in memory on the card, it's no different from, let's take the easier example, any HDD out there." On the contrary, the mere fact that it is a series of bits under user control - pure software for which there is a user-initiated loading mechanism - is precisely what makes it a the subject of peoples' libre software goals. Furthermore, it is because it is required that the user perform the initialization to use the main features that the user is constantly reminded about the proprietary dependency. Hard drives, for example, aren't a big focus for advocates because the drives generally don't forget they are hard drives between boots. It is true that they CAN be re-flashed, but it is not conventionally necessary to run, and that places them on a much more remote wish list. The main responsibility of the kernel in such cases is to prevent unauthorized firmware changes coming from userspace (ex, the NSA, over the network). Boot-time firmware is qualitatively different from hardware that ships with working firmware, just as the latter is a different beast than ROM-based blobs.
- seba_dos1 11y ago
  You still cannot be sure that WiFi blob isn't being reflashed over the air. Sure, it's harder to mess with reflashable firmware stored inside the device. However, it's only just like you said - a change on priority list, nothing else. Differentiating this in terms of freedom is a hypocrisy. Anyway. Kernel just provides you an interface to load such firmware into your device. When the firmware is freely redistributable, it's also included in the kernel source tree. Nothing more, nothing less. It's up to you to decide what to do with it - you can easily look up all the needed info and remove unwanted firmware files. For me there's no difference where it's stored. Closed firmware is closed firmware. We either have to accept it or not use PCs at all. In the meantime, we should rather focus on producing stuff that increasingly stops requiring it, instead of aimlessly fighting with kernel developers.