* xdrudis xdrudis@tinet.cat [101216 01:53]:
I don't care where it runs. For me it's more whether it's been derived from some other form and what's more useful to touch if you want to change it. There's also the question of whether it can be replaced, but if it couldn't it wouldn't be included, of course.
While that last conclusion might sound logical, loading something at runtime rather than onto a masked rom or FPGA or ASIC does not necessarily mean it can be changed or makes sense to be changed.
I hope it does not change even if one day vendors start giving permission to distribute sourceless binaries, as happens in linux or elsewhere. In fact there's already CPU microcode, but I'm not sure what would be "source" for that, so it may be ok.
Yes, we are already including microcode, and I think it would make sense to separate it more obviously (also, putting it in some CBFS file instead of linking it into RAM stage)
And that drove me to coreboot. This is why the project would lose all interest for me if this market trend would be accepted as an excuse for including sourceless stuff. But I guess that the project wouldn't lose much from my loss of interest in it.
Actually the direction is to move stuff that was previously done in an ASIC to some kind of firmware. The situation didn't really become more closed than it was before, just hardware became more complex. Not sure how that makes coreboot less interesting. It still enables you to experiment with opening more parts of it while having a large quantity of code already open sourced. So, how much of the code running in tomorrow's system firmware depends on you and every other contributor. Cutting down functionality just because it is not open sourced yet only makes limited sense (in some very specialized scenarios)
I'm not arguing the usefulness of hardware without binary stuff in those cases, I'm just arguing the usefulness of free firmware lacking source for components that do have source but it is not public.
Following your reasoning a free operating system running on a closed bios would not be useful either. Or a free firmware running on a closed hardware. (Or, only when the hardware is an FPGA? What about an ASIC?) Not sure we generally want to draw a line here.
That brick would at least be useful to develop free replacements for the missing parts :)
Unfortunately coreboot depends also on people using it, not only those developing for it. I wish more people would appreciate bricks the way you do, though :-))
The default will be to not ship those files, both because we aren't allowed to redistribute them, and to have a safe default from a license perspective.
Default ? or policy ?
Right now we do distribute microcode files. And there's a separate repository with some option roms that are allowed to redistribute in coreboot context. I hope we can increase the number of redistributable binary code needed for "the best possible coreboot experience", and at the same time not forget the goal to provide an as open solution as possible. My guess is that we will never see a "source" representation of stuff like CPU microcode and stuff like EC firmware will make a completely new project (like OpenEC) to go side by side with coreboot but it might well be out of our scope. (VGA oproms, too)
Thanks for explainig. Yet build system magic may hide important info from the user _if_ binaries are distributed.
Right now all binaries have to be specified in Kconfig, and we might keep a lot of it that way. If you build a coreboot rom without, coreboot will usually fail to find the "blob" in flash and try to continue as good as it can. On some systems (like Geode) you will not be able to boot without the "blob". On those Geodes the source code for the blob is out there, but can only be compiled with some old DOS assemblers, making it hard to integrate it into coreboot as a non-blob.
Still helping users install non free software is not nice (as stated in the GNU free system distribution guidelines, for example), although I'd say coreboot users are not so naive as not to notice. Coreboot is not exactly as easy to install as Ubuntu.
I certainly don't agree with the GNU free system distribution guidelines from a usability perspective. Yes, non-open source stuff might end up in the binary automatically (like cpu microcode), but given that most PCI cards have a non-open source option rom on them makes the distinction between a blob-free and blobby coreboot somewhat artificial.
The question is, do most users want a working system, or would they prefer a free brick. And how much thinking can we expect from someone who prefers a free brick in comparison from someone who just wants a working system. My impression is that if someone wants the extra freedom to run without blobs they are smart enough to change the open source code of coreboot not to include the blobs. That said, freedom does not usually come for free. There's always some work involved.
While the open source loving part of my soul might disagree, I firmly believe that we need to provide something that works before we can sit back and do philosophical discussions.
Stefan