Sorry to jump into a thread I don't fully understand , but is this about having blobs in coreboot that get silently copied into the EPROM ?
If I understood it correctly up to now any blob had to be opted in through Kconfig, I don't really know if the idea is to avoid Kconfig for certain binaries but the user still has to place them on the tree (so nobody is using blobs inadvertently) or are there going to be parts of coreboot without source in the svn (so someone might be using sourceless code without knowing).
If the later I don't like the idea and at least I would like a huge warning "BLOBS IN HERE !!!" at the end of the make output.
Again, sorry at not fully following the thread or the patch.
On 15.12.2010, at 11:17, Xavi Drudis Ferran xdrudis@tinet.cat wrote:
or are there going to be parts of coreboot without source in the svn (so someone might be using sourceless code without knowing).
I think the idea is just to allow blobs being handled locally instead of in the main architecture makefile.
If the later I don't like the idea and at least I would like a huge warning "BLOBS IN HERE !!!" at the end of the make output.
You will be able to see the blobs in the cbfstool print output at the end of a build right now.
Do we need some 'tainted image' flag in cbfs? Or maybe a license field for each file?
Am Mittwoch, 15. Dezember 2010, um 20:17:18 schrieb Xavi Drudis Ferran:
If the later I don't like the idea and at least I would like a huge warning "BLOBS IN HERE !!!" at the end of the make output.
I avoid the term "blob" for two reasons: 1. "BLOBS" (in this context) is an FSF scare term. Free and Open Source software had to endure FUD long enough, we should know better than to participate in that. 2. "blob", as used by the FSF, is not cleanly defined, and their use of that word or its predecessors changed over the years. It used to be that their main issue was with binary components that are run by the CPU, but now it encompasses much more.
I prefer the OpenBSD definition of "blob": binary components that run on the CPU. That a clear line drawn in the sand, and a useful distinction, too. Unfortunately GNU/blob spoiled that.
<rant> Applying the current FSF use of the word, a graphic rendered to png or jpeg without the source material (vector graphic, gimp image with multiple layers, ...) shipped with it is a blob. We're lucky that we never added a default bootsplash image to the tree!
I had to debate with GNU developers if the S-Boxes in AES are "blobs", and if there's a "preferred format" for them (ie. if they could be calculated). They can't be calculated (there are a couple of formulas to verify if an S-Box is valid, but many are), but if you pick the wrong "valid" one, you get a different (and probably less safe) algorithm. The FSF meaning of the term only scares the same people who use it that way. </rant>
That there aren't any binary components in the tree is simply for the fact that they're not redistributable: We usually scrap them from vendor BIOSes, and they're not separately available. That won't change. (It would spark quite a debate when storing binaries in the tree would actually be proposed, but we never even got that far for the stated reason)
The other fact: Hardware relies more and more on update-able components in flash, without any knowledge of what this is. Maybe it's 8051 code, maybe it's VHDL stuff of some sorts, maybe a table like the S-Boxes, or a JPEG image. There is no preferred format, there's usually no disassembler for the data, or documentation that can be read outside the high security area at the vendor (and very likely only in 5pt print, orange glyphs on red paper in the area, to prevent anyone from making copies), but there's a single invariant for most of them: Without the data around, your system won't boot - it's useless as a brick, with the only feature that it sucks power.
For this reason, I'm thinking about adding a "thirdparty" directory, which contains only a script. That script contains a list of hash values and "real file names", and renames files within that directory which match a hash to the assigned filename. The script would be a tool to simplify handling for users who have to scrape their binary parts from BIOS images: Fetch the data, put it in the directory, run the script. If the data is known, it's automatically available for the board or chipset that needs it.
If you prefer to live without the file, simply don't put it in there. Your board might be less useful than a brick, but that's your choice. 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. It's also a safe default from an operation perspective, as the build will break by default (we might have to tweak the buildbot a bit to be tolerant of that, for example by seeding the thirdparty directory on the buildbot with empty files of the right names and sizes)
This patch won't change anything in this regard. The plan with the script I outlined is only where I see where this project is heading, for technical reasons. What this patch does is eliminating a bottleneck: Right now we have to maintain a list of files that can be added to the CBFS image at a central location, and that won't scale in the future. Nothing more, nothing less. No feature at coreboot runtime (or misfeature as you'd probably see it) is added or dropped, it's just build system magic.
Patrick
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Patrick Georgi Sent: Wednesday, December 15, 2010 03:08 PM To: coreboot@coreboot.org Subject: Re: [coreboot] [PATCH]Allow components to add files to CBFS
]That there aren't any binary components in the tree is simply for the fact ]that they're not redistributable: We usually scrap them from vendor BIOSes, ]and they're not separately available.
Thanks for explaining. I always wondered why uma video option roms were not included with coreboot. Microcode patches should be put into this same category. The supplied AMD patches are not the latest, if I am not mistaken. It wouldn't be hard to automate the process of extracting AMD patches from a BIOS binary.
Thanks, Scott
]Patrick
]That there aren't any binary components in the tree is simply for the fact ]that they're not redistributable: We usually scrap them from vendor BIOSes, ]and they're not separately available.
Thanks for explaining. I always wondered why uma video option roms were not included with coreboot. Microcode patches should be put into this same category. The supplied AMD patches are not the latest, if I am not mistaken. It wouldn't be hard to automate the process of extracting AMD patches from a BIOS binary.
Getting AMD to supply the latest is the preferable method for me. There are several cases where there is no "vendor BIOS" for the board. There would be more if we could figure out some of these problems.
Thanks, Myles
* Scott Duplichan scott@notabs.org [101215 22:33]:
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Patrick Georgi Sent: Wednesday, December 15, 2010 03:08 PM To: coreboot@coreboot.org Subject: Re: [coreboot] [PATCH]Allow components to add files to CBFS
]That there aren't any binary components in the tree is simply for the fact ]that they're not redistributable: We usually scrap them from vendor BIOSes, ]and they're not separately available.
Thanks for explaining. I always wondered why uma video option roms were not included with coreboot. Microcode patches should be put into this same category. The supplied AMD patches are not the latest, if I am not mistaken. It wouldn't be hard to automate the process of extracting AMD patches from a BIOS binary.
Actually we can redistribute Intel and VIA option ROMs. I asked ATI and then AMD a lot of times, but I never got a definite written answer on whether they're no-lawyer-involved happy with us putting up copies of their oproms. If they were, I'd gladly add their images to our oprom repository on coreboot.org.
Scott, can you (or Marc?) get anyone at AMD to make a binding statement? It would help the coreboot user experience a lot.
Also, where do we officially get amd microcode files? I don't think extracting them from some UEFI image is the way to go. Again, for Intel it's fairly easy. Can we get AMD to catch up here?
Stefan
On 12/15/2010 05:23 PM, Stefan Reinauer wrote:
- Scott Duplichanscott@notabs.org [101215 22:33]:
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Patrick Georgi Sent: Wednesday, December 15, 2010 03:08 PM To: coreboot@coreboot.org Subject: Re: [coreboot] [PATCH]Allow components to add files to CBFS
]That there aren't any binary components in the tree is simply for the fact ]that they're not redistributable: We usually scrap them from vendor BIOSes, ]and they're not separately available.
Thanks for explaining. I always wondered why uma video option roms were not included with coreboot. Microcode patches should be put into this same category. The supplied AMD patches are not the latest, if I am not mistaken. It wouldn't be hard to automate the process of extracting AMD patches from a BIOS binary.
Actually we can redistribute Intel and VIA option ROMs. I asked ATI and then AMD a lot of times, but I never got a definite written answer on whether they're no-lawyer-involved happy with us putting up copies of their oproms. If they were, I'd gladly add their images to our oprom repository on coreboot.org.
Scott, can you (or Marc?) get anyone at AMD to make a binding statement? It would help the coreboot user experience a lot.
Also, where do we officially get amd microcode files? I don't think extracting them from some UEFI image is the way to go. Again, for Intel it's fairly easy. Can we get AMD to catch up here?
Yes most of the Intel oproms (vga bios blobs) are publicly downloadable from the Intel website (just look for the developer drivers). I think we should have a section in the tree for the blobs. I think the only discrepancy Intel has is they do not want hacked/cracked copy's of their blobs re-distributable...
On Wed, Dec 15, 2010 at 10:07:50PM +0100, Patrick Georgi wrote:
Am Mittwoch, 15. Dezember 2010, um 20:17:18 schrieb Xavi Drudis Ferran:
If the later I don't like the idea and at least I would like a huge warning "BLOBS IN HERE !!!" at the end of the make output.
I avoid the term "blob" for two reasons:
I don't quite dislike "blob", but any meaningful alternative would do for the warning. I'm not sure the name of the file alone would do, some sort of taint flag, or license info would be ideal. In fact the best I can dream of is the name of each file, the license and the availability of source (linux has parts nominally under GPL without source code).
But of course source code would need a definition. I seem to intuitionally feel I know it (the GPL definition), but then I find cases of people disagreeing, and they may not all be in bad faith.
I prefer the OpenBSD definition of "blob": binary components that run on the CPU. That a clear line drawn in the sand, and a useful distinction, too. Unfortunately GNU/blob spoiled that.
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.
<rant> Applying the current FSF use of the word, a graphic rendered to png or jpeg without the source material (vector graphic, gimp image with multiple layers, ...) shipped with it is a blob. We're lucky that we never added a default bootsplash image to the tree!
I don't get your rant. Whether there is source or not does not depend always on the format. If your bootsplash was made with gimp it would be better to include the source (it would be easier to combine with the logo of the hardware owner company, for instance, or adapt to other resolutions...), if it was made with a camera, maybe it's not so necessary to include the raw image and settings.
I had to debate with GNU developers if the S-Boxes in AES are "blobs", and if there's a "preferred format" for them (ie. if they could be calculated). They can't be calculated (there are a couple of formulas to verify if an S-Box is valid, but many are), but if you pick the wrong "valid" one, you get a different (and probably less safe) algorithm. The FSF meaning of the term only scares the same people who use it that way.
</rant>
I think the discussion may have been less interesting to you than to them because you knew the algorithm better, but I think it was a relevant question. For me it would give insight on "where the security comes from" if I had time to learn AES. Must be similar to DES. I've never understood what makes those permutations secure or others less secure.
That there aren't any binary components in the tree is simply for the fact that they're not redistributable: We usually scrap them from vendor BIOSes, and they're not separately available. That won't change.
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.
(It would spark quite a debate when storing binaries in the tree would actually be proposed, but we never even got that far for the stated reason)
Ok. I'm happy to avoid that debate until the choice comes. For me it's enough now to know there won't be binaries in the tree so users will have to opt in. I tried to change the subject header because it's no longer about the patch.
The other fact: Hardware relies more and more on update-able components in flash, without any knowledge of what this is.
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.
Maybe it's 8051 code, maybe it's VHDL stuff of some sorts, maybe a table like the S-Boxes, or a JPEG image. There is no preferred format, there's usually no disassembler for the data, or documentation that can be read outside the high security area at the vendor (and very likely only in 5pt print, orange glyphs on red paper in the area, to prevent anyone from making copies), but there's a single invariant for most of them: Without the data around, your system won't boot - it's useless as a brick, with the only feature that it sucks power.
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.
If you prefer to live without the file, simply don't put it in there. Your board might be less useful than a brick, but that's your choice.
That brick would at least be useful to develop free replacements for the missing parts :)
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 ?
This patch won't change anything in this regard. The plan with the script I outlined is only where I see where this project is heading, for technical reasons. What this patch does is eliminating a bottleneck: Right now we have to maintain a list of files that can be added to the CBFS image at a central location, and that won't scale in the future. Nothing more, nothing less. No feature at coreboot runtime (or misfeature as you'd probably see it) is added or dropped, it's just build system magic.
Thanks for explainig. Yet build system magic may hide important info from the user _if_ binaries are distributed. So as long as they are not, I'm 80 % happy with it (sorry, an old joke from the swpat EU directive). 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.
* 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
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.
xdrudis wrote:
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.
Do you mean propietary BIOSes don't work ?
I think what Stefan means is that it already takes a quite significant effort to make one board work perfectly with coreboot, because many vendors choose not to work together with the project - with AMD being a great exception!
It is fairly important to keep adding support for new hardware to the project, and we can not really afford to rule any board out, even if supporting it means that we must depend on a blob to do some things. There is a greater good in the short term, which is to make coreboot more widespread. It's very difficult, even for coreboot, to bootstrap the firmware liberation; each and every step is very important, and I would say that today has been a very good day, where the project has taken several leaps forward!
//Peter
-
Joseph Smith -
Myles Watson -
Patrick Georgi -
Peter Stuge -
Scott Duplichan -
Stefan Reinauer -
Stefan Reinauer -
Xavi Drudis Ferran -
xdrudis