Warning: long, personal, philosophical, not even very original or insightful. Read at your leisure or not at all.
On Thu, Dec 16, 2010 at 05:14:29AM +0100, Stefan Reinauer wrote:
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 only partially understand you. What it makes sense to change or not should not be a reason to stop people from changing it. What makes sense or not is not related to freedom, and what makes sense to someone may not make sense to someone else. What can or cannot be changed is a different story. Things that cannot be modified do not need to carry freedom to modify them. It's like the declaration of human rights: it would make sense to include the right of all humans to flap their wings and fly to the moon if only we could, the reason it's not there is that it's not possible, not that it would be wrong to have that right. You don't need the freedom to do something impossible but you need the freedom to do something that does not make sense (to whom?) unless there is an ethical reason to restrict that freedom.
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)
I'm not sure I understand how microcode is produced. I faintly remember some blackboard exercises at college with some toy CPUs and instruction sets where we wrote microcode by hand. There I guess microcode was source if there was any source at all. In reality microcode is possibly compiled from some source with some tool which also gives some circuit designs. Both circuits and microcode is just logic, with the difference that the microcode can be changed and the circuit can't. The microcode can be modified without changing the circuit (I guess), at least to disable some nasty feature. The question for me is whether there is a source for the microcode that can be modified without altering the circuits in order to get some change in behaviour, performance, etc. If the only source there is can't do that (because if modified it would give different microcode but also different circuits, so back to factory), then it's likely not necessary to have that source. Now the question is what about some other conceivable source which could be used with some other tool to modify the microcode and still run it on the same circuit? That would be desirable, but possibly unrelated to the microcode at question.
So the microcode would be acceptable or not depending on how it was produced, which I don't know. The fact that the vendor provides updates to the microcode that don't require to change the hardware suggests there may exist some source like we would need, but it does not prove it. If you ever know there was a source and you don't have it then you'll know you're not in compliance with GPL if you link the microcode with someone else's GPL code in a derived work. If you have an option of avoiding that, it's nice to take it. Putting the microcode in external files would possibly be cleaner legally, although it would not help much philosophically. I agree help about that may not belong in coreboot but other free projects.
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 necessarily more complex, but more general. If there are two designs for the same functionality, design A with an ASIC and design B with firmware, then the hardware (unchangeable part) is more general with design B, because it can at least do as much as A and potentially more by changing the firmware (which is not hardware). If you think of the hardware has the circuits + firmware, then it may be getting more complex, but I think the hardware may be getting even simpler (at least the logic in it, I'm not talking quantum physics or electronics here), there's just more of it, and so the increased complexity is more manageable in firmware. For those who have the firmware's source, that is.
In fact firmware is increasingly doing more nasty or undesirable stuff, like remote controlled PCs and the like, so this very trend is a reason to watch out for propietary firmware, not to accept it. And I believe the reason for the trend is simply that OSes (specially propietary OSes) are incresingly unreliable, so vendors tend to shift stuff to firmware (which does not help, it just delays the problem, propietary firmware will evolve like propietary software, opacity scales worse with complexity).
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 see your point. My view is that if I have free projects which don't include propietary parts and report support on different hardware, I have a clearer idea of what hardware I want to buy. It's also easier to pick my ethical choices when compiling. If all free projects start including propietary parts just because that's the market trend, and there's too little functionality available wiht only free software with the hadware in the market, then I have more work of finding out and separating the propietary parts.
So I guess our common ground is the more clearly separated free parts and propietary parts are, more clearly documented and more obvious in documentation and "advertising" the better.
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.
I think the line is what can be changed vs what can only be replaced. Hardware cannot be changed, can only be replaced, software can be changed. So software should be free. Hardware should be open ? Yes, but I thought coreboot was a software project.
So, personally, for the purposes that lead me to coreboot, yes, a free OS on propietary BIOS is not useful to the task of preparing a computing platform that is as free as possible for my needs.
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 :-))
You must love this planet, then. Most people use bricks to build stuff (houses, Lego artwork...) not as tools by themselves. :-)))
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)
I agree those free projects may be out of coreboot scope, no matter how interesting or difficult. I fail to see why the propietary projects would be more in coreboot scope, though. But I understand my concept of "best experience" is not the same as everybody's. For me finding out I've wasted time and effort learning and setting up stuff I thought was free to find out it was not as free as I thought is a bad experience.
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.
Great.
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.
IMHO if source is available and the corresponding binary is distributed then the source should be distributed too, no matter how difficult to compile. I see no problem with distributing binaries when there is free sorce for them, it's a nice convenience, just make the source available too. In general I tend not to put binaries in svn, but that's because they're easy to produce from sources, and svn is most useful for sources. As soon as binaries are not easy to produce from sources, I'm ok with keeping both on svn. And of course when one can choose, the easier and freer compilers the better, but that's no reason to avoid the worse when/while they are the only options.
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.
If it's a ROM it can't be changed and there's no issue, as said before. A blob it's different.
The question is, do most users want a working system, or would they prefer a free brick.
I'm afraid most users want a propietary BIOS, or more precisely they want whatever BIOS comes with their hardware because they don't want to flash anything and want it to work with "everything". So the question is what do _your_ users want?. And that comes to who are your users? And that's another way of asking what do you want to build ?.
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.
I see it the other way round. If people choose a free project they expect the community to provide free software, not a mixed bag. From then on the effort should be expected to introduce propietary components. Otherwise trust is eroded and understanding what you get is harder. I don't see freedom as an "extra". At least not in a free software project.
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
Do you mean propietary BIOSes don't work ? Only you know your reasons but I very much doubt there weren't philosophical considerations in deciding to work in coreboot. Anyway, I don't want to distract you from your work. I already said I wouldn't have believed this project possible if this team hadn't made it real. Thanks. And thank you very much for your time clarifying your views.
Xavi.