On 04.10.2010 02:11, Warren Turkal wrote:
On Sun, Oct 3, 2010 at 10:58 AM, phorsyon phorsyon@gmx.net wrote:
I consider myself as enthusiast and would like to share my thoughts about coreboot certification and PR as a person from outside the coreboot project. I hope this will help you to see this project from another perspective and therefore helpful for your plans and further actions. Let me say I would really appreciate it, if vendors would ship their products preloaded with coreboot. ;-)
We are not vendors, and AFAIK no hardware OEM vendors ship with coreboot pre-loaded.
I think a few vendors ship some systems with coreboot if you ask nicely, but they are either in the server or embedded space, not general consumer space.
To make coreboot popular, it needs (a) a feature people want, (b) major vendors to deliver it and (c) available documentation for all components to make it work with most boards. These requirements are interdependent and must be solved as whole. To get c vendors must be convinced to want b and therefore coreboot needs a. So what's a? It surely is fast boot up, but depending on what your target audience is, it might also be boot non-free OSes and works with proprietary drivers. If you want to make vendors want b it's definitly required to target the average user.
I do not believe that (c) is strictly required in that you don't need detailed bios developer guides once the code is available. It would be useful, but I don't see it as being required.
We also need to be realistic. OEMs are not taking up coreboot in mass right now. We need to set the certification bar at the point that it would be useful for the coreboot project. I believe that setting the certification bar allow a more rapid development of coreboot code would be much more productive that pie-in-the-sky arguments about what to do with all the OEMs that want to ship coreboot.
OEMs want fire-and-forget solutions without functional regressions. coreboot can serve as fire-and-forget solution, but if we certify consumer mainboards which can't run Windows, the certificate will be essentially worthless.
Remember the complaints about "Designed for Windows Vista" and the machines which were too slow to be useful? People still remember that marketing disaster years after it happened. If we ever certify some hardware without caring about Windows, we should make that explicit, and call it a feature. "Coreboot certified board for the anti-closed-source movement, will refuse to run Windows". The variant which can run Windows would be "Coreboot certified board". Except for niche vendors, nobody will care about the anti-closed-source certification, making it moot.
Vendors do not ship coreboot yet.
AFAIK Artec, Tyan, Technexion, MSI and some other vendors ship coreboot for specific systems on request. Not sure about the current state, but AFAIK they did that in the past.
I believe that we only have the community at this point. Given that fact, we need to do what we can to get vendors interested. I believe that maturing the coreboot codebase is probably the most effective way to do that.
Booting Windows 7 on recent consumer boards is probably the best way to show vendors that coreboot is a viable BIOS replacement. This needs porting work, and of course it needs testing.
For the record, I believe that Linux probably has a mature enough ACPI stack and other systems to be pretty good barometer of compliance short of having an independent test suite.
Ummm... Linux will tolerate absolutely crappy ACPI code, and not even complain loudly if it has to fix stuff. Given the current market share of Linux, there is no money in verifying ACPI code under Linux for any consumer mainboard.
What about calling it "Coreboot: Developer's Choice". Also freely available documentation would be a nice core requirement for that.
I actually don't like "minimal." However, I also don't like "Coreboot: Developer's Choice." What would you think about "Coreboot beta test"?
For me, "Developer's choice" implies that the board already works perfectly fine, and has all the hardware features which make it easy to test new coreboot versions. I believe in honest advertising, and if the machine barely works, we should not certify it, but we could list it as "fun project if you want to finish a port".
- Add-on components most importantly Nvidia/ATI cards
I don't believe that we should bias toward some particular class of add-on card or some vendor of add-on card.
Nobody is going to test with Tseng Labs graphics cards because they are no longer on sale (actually, they haven't been on sale anytime in the last 12 years). Nobody is going to test with Intel graphics cards either unless you can actually show that such cards are on sale for mere mortals. So basically you have ATI(AMD) and Nvidia for external graphics, and maybe Matrox in niche markets. Intel and S3 and others are only available as onboard options.
- The OS of choice (BSD, Linux, Windows)
While I agree with this sentiment, we can't test everything. I think that we should agree on a standard test OS. That OS needs to be freely obtainable to make the testing bar very low.
So FreeDOS would be OK for you? Small, free, and it will probably run just fine even if major parts of the board are malfunctioning because the port is unfinished.
Frankly, I don't think that we are aiming for average users at this time. We are aiming for the developers that can advocate coreboot's use in OEM hardware or folks who see enough of an advantage to pay for a port to their hardware. These are very sophisticated users.
But OEMs won't care unless we can make average users happy. If you want an OEM to ship coreboot by default, you better make sure the OEM won't fall into the Linux netbook trap where people returned lots of machines because they expected to be able to run Windows applications. OEMs are also extremely cost-conscious, and if they can save a few cents per board without risk, they will do it. The key words are "save money" and "no risk". Given the per-mainboard licensing cost for BIOS, coreboot can serve as an alternative if there is no risk involved.
Regards, Carl-Daniel