ergethaxsd

> "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."

Only, this process could be made more clear and more readily configurable (as I suggest, for example, a libre verbosity level, and noblob params). It is also not hypocrisy to fight battles in order of proximity - rather, it is strategy.

> "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.

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.

(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.

Choice, like mutation and sexual reproduction, accelerates evolution. More options means better options over less time.

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).