Hi.
xdrudis wrote:
Sorry for the rant, it's not aimed at any particular person, just to blobs which I don't think should get into coreboot.
I'm afraid you seem quite disconnected from the reality of PC firmware in the industry. If you haven't already read Svante's thesis on the topic then I strongly urge you to do so. Even better is of course actual OEM and ODM experience.
capital to waste when changing directions
You imply that you experience a change in direction, but as I tried to make clear already in my last email, I do not consider coreboot to have changed direction at all. The recent progress is a leap forward; as already confirmed by Andrew, coreboot is more valuable with Sandy Bridge support.
You personally, and others with you, have a different view, and thanks to coreboot being open and free you are still able to find a solution which meets your requirements.
if coreboot starts filling with blobs it will be just another BIOS, only somewhat delayed or playing catchup with some features.
I'm not sure if you realize how absurd that is. In case you didn't notice, coreboot has been playing catchup with all hardware for the first 12 years.
The progress that has been made in the project during the last few years is amazing, and instead of ranting about blobs you really should be celebrating, because coreboot is in better shape than ever before. I'm sure you agree that this is a good thing.
Your experience from hardware vendor interaction tells you that open source and free software can be challenging for many vendors, but at the same time they find it exciting because of all the benefits it brings, both inherently by being open and free, and through features which all in all make open and free totally superior to proprietary.
You may think that 12 years is a long time for a project, but in fact coreboot is only since a year or so, when AMD announced their support, starting to grow up, and even then there are many things that desperately require your contributions to increase it's success.
Ranting? Not very helpful.
Of course - if you can not support coreboot based on your ideology then you can not contribute, and that's too bad, but maybe you will discover that at some later time things have changed to where you want them to be, and then you can join the project again. Or not.
As I've already written, you could also take the blob as a challenge to implement native memory init for the platforms. I would welcome that contribution very much. I expect the hardware to have become obsolete since many years, by the time you have finished. But go ahead, prove me wrong!
Or perhaps you can find another, more productive, way to support coreboot.
In the past I've bought hardware believing it was likely to work with free firmware by looking at what coreboot supports. Recently I thought I might buy a chromebook if they finally run coreboot. But if coreboot becomes a blob loader I won't buy any hardware based on the fact that it runs coreboot.
"becomes a blob loader" is conveniently unspecific. As always with open source or free software projects: YOU are reponsible for making it work for YOU according to YOUR requirements.
OR - you can go to a vendor and pay them for the service of doing it on your behalf. Currently there exists no such service for coreboot, but the more popular coreboot becomes the more likely it is that such a service provider (or several!) will appear.
YOU have to research details to ensure that YOUR requirements are met.
Blobs do not change this fundamental fact in any way. If there are no blobs then your "zero blobs" requirement is very easy to check off the list of requirements, while other metrics such as "computational performance" or "power consumption" remain exactly as difficult to check.
You have no right to spit on coreboot (which is what you say that you would do if it became "a blob loader") just because one part of it solves problems which you do not want to solve, while other parts solve exactly the problems you do want to solve.
Further, as Ron already pointed out - and as you know from your experience with PC bootstrapping, you can't really ignore that many coreboot systems already depend on another blob during startup - the VGA BIOS. It's not really related to coreboot, but to the way the PC platform is expected to work by PC operating systems.
AFAIK there are exactly three exceptions to this:
1. Very old ATI graphics support no longer available 2. Geode LX 3. Luc's work on native init of graphics on K8M890 and similar
I think the only mainboard with the latter is the m2vmxse.
The exceptions also only hold true for very special operating system cases. You can forget about running GNU/Hurd on a system without a VGA BIOS. Isn't that ironic?
it will be like what linux has become, you no longer know much by the statement that linux runs on something. If android is free software
Who has said that Android is free software? That's stupid. If you want to discuss Linux not being free enough then you can always try to take it up with Linus.
Coreboot may choose to go that route
Third time: coreboot has never changed direction and I do not see any reason to do so in the future.
Of course your perception of reality may be different.
So the big question is really do we allow chipset support that requires the use of binary blobs in coreboot.
I try to find chipsets that don't require that.
As a user of anything, be it hardware or software, that's the perfect attitude! And it's exactly this that makes open source and free software very very valuable: It allows users to find the solutions that fit their needs. You can pretend that coreboot actually does not support Sandy Bridge and Ivy Bridge at all, and you are still golden!
I don't think such a limited port is worth people's efforts, but that's for each one to decide, of course.
Indeed it is. What you write is extremely offensive. You are disrespecting the magnitude and excellence of the work that has been contributed to the coreboot project by the Chromebook team and I just find that to be really really poor form, regardless of your reasons.
a greenwashed half baked port of something that used to be free is not a big deal.
What the fuck are you talking about? Push your free implementation of Sandy Bridge and Ivy Bridge memory controller init to gerrit.
I don't see much point in making or using a port.
That's fine. If you feel that coreboot is not for you then please do not use it and do not complain that others do. Meanwhile, consider that coreboot is not only about your system. It supports a few hundred mainboards and I hope it will support many hundred more.
Does someone else besides intel and google have permission to distribute the blobs?
Please see http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
I expect you to actually have solid knowledge of this already, since you have already sent contributions.
coreboot users have usually assumed they had permission to distribute the tree freely under GPL,
You speak for all of them? I am sure that you realize how absurd that is. Noone can claim anything on behalf of "coreboot users."
difficulty to grasp what the criteria is for accepting restricted code to enable hardware support, or for distributing the resulting material.
Ask away about anything that is unclear! Given your experience from hardware vendor interaction you will know exactly which questions are appropriate and how to ask them, as well as which questions are embarrassing faux pas, or worse, for you, and for the project.
claim coreboot compatibility with less disclosure
Reality check. Vendors are not fighting each other over who can be more compatible with coreboot. For 12 years coreboot has been chasing hardware. You need to understand the full impact of this.
I guess it's better to just stop buying hardware,
Right, better not educate yourself about your options and better not choose what fits you, but instead choose nothing. That's the perfect way to consume.
Yes you have to make a big fucking effort to be a responsible consumer OF ANYTHING so that you can sleep well at night and look at yourself in the mirror every morning. NOONE frees you from this responsibility (mind the pun) - not even the FSF.
if you can't even rely on a FSF priority project to get free software.
As I am sure that you already know, coreboot is not an FSF project.
I will not bother biting on this last piece of flame bait. I am confident that you understand that coreboot is more free than your other options. If it's not free enough for you at this time then please either go away or please help us out. In any case you are *NOT* helping by complaining.
I'm very happy that the FSF agrees with the coreboot contributors that it's important to work toward a viable open and free PC firmware.
This was always the direction of coreboot, and it has not changed!
//Peter