Slashdot Mirror
Microsoft Announces Project Mu, an Open-Source Release of the UEFI Core (betanews.com)
Mark Wilson writes: Microsoft has a new open source project -- Project Mu. This is the company's open-source release of the Unified Extensible Firmware Interface (UEFI) core which is currently used by Surface devices and Hyper-V. With the project, Microsoft hopes to make it easier to build scalable and serviceable firmware, and it embraces the idea of Firmware as a Service (FaaS). This allows for fast and efficient updating of firmware after release, with both security patches and performance-enhancing updates.
FaaS is something that Microsoft has already enabled on Surface, but the company realized that TianoCore -- the existing open-source implementation of UEFI -- was not optimized for rapid servicing. This is where Project Mu can help, the company says. "Mu is built around the idea that shipping and maintaining a UEFI product is an ongoing collaboration between numerous partners. For too long the industry has built products using a 'forking' model combined with copy/paste/rename and with each new product the maintenance burden grows to such a level that updates are near impossible due to cost and risk," the company said.
FaaS is something that Microsoft has already enabled on Surface, but the company realized that TianoCore -- the existing open-source implementation of UEFI -- was not optimized for rapid servicing. This is where Project Mu can help, the company says. "Mu is built around the idea that shipping and maintaining a UEFI product is an ongoing collaboration between numerous partners. For too long the industry has built products using a 'forking' model combined with copy/paste/rename and with each new product the maintenance burden grows to such a level that updates are near impossible due to cost and risk," the company said.
it's just a spelling mistake, it was meant to read "open sores".
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Other than the wave of fancy graphics found on computer set-up screens, UEFI, has brought little to the table. As someone who has assembled over one-hundred computer, I think that the old BIOS, being a very minimal, compact, low-bug, text-based setup software was a idea better suited to reliable computers than "modern" bloated, bug-filled, UEFI.
Monopoly-wise, UEFI, has given Microsoft and unfair advantage to draw a circle around all (IBM Compatible) PCs and call them their own.
https://www.youtube.com/c/BrendaEM
Open Source isn't as free as most people think it is.
Free and Open Specifications have far more value then Source Code does.
And No Open Source doesn't mean the specifications are Open automatically, There is a lot of ways to hide stuff in source code that would make comprehending the logic far more complex then just a normal reverse engineering of it. There is also a lot of system particular calls which may be the case as well.
For example a lot of old Legacy Applications will save data files by just dumping the memory structure into the file in raw binary format. I can take this code it will compile and work on a different platform but wouldn't be able to read the data files, Because how the system handled memory was different (such a using Big Endian vs Little Endian which is more common today) or just how an integer may be classified 16bit, 32bit, 64bit....
Open Source alone doesn't make it free or open. It just gives you the source code, which you may be able to alter some features without having to do a full rewrite.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Legacy is hard on closed or open, but at least with open there's a place to start. And thankfully CPU's uses to be slower, so emulation of the whole system isn't a terrible option.
Open Source isn't as free as most people think it is. Free and Open Specifications have far more value then Source Code does. (...) For example a lot of old Legacy Applications will save data files by just dumping the memory structure into the file in raw binary format.
And how many of those applications do you think have specifications that are actually current, correct and complete? Specifications are vital if you're trying to establish a standard. If you're trying to decipher a one-of-a-kind format created by proprietary software, custom-developed code or anything like that the source code is in 99.9% of the cases the only answer to what is really happening. Then you start looking through version control systems (if you're lucky), design docs, bug reports, ask the business users etc. to reverse engineer why it's happening. Sometimes we figure it out, sometimes it's still valid but often it's a solution to a problem we don't have anymore. Other times it's simply a bug or it does things differently that the users thought it did. And sometimes nobody can figure it out and you're told to just replicate it, warts and all. So if there's ever a choice between an implementation and a spec, I'll take the implementation any day.
That aside, almost any proper specification today ought to have a reference implementation and a compliance test suite both of which is code. So in order from best to worst I'd say it's:
1. Spec + code
2. Code
3. Spec
4. Binary
Unless it's a very known spec with lots of implementations and you just happen to be the 3142th FTP client ever written. But in that case get your head out of your ass and use a library. One implementation is bad but there's very few standards that benefit from more than say ten, then they're writing to the spec because the encoder x decoder or server x client matrix is too unmanageable for anything else.
Live today, because you never know what tomorrow brings
I fully agree with Microsoft that UEFI has a forking problem. But that is caused by the fact that BIOS vendors take tianocore as a baseline and extend it. The root of the issue is that tianocore itself does not provide a complete UEFI firmware implementation, it gets about 40% of the way there and expects the Silicon vendors (Intel, AMD, NVidia, Qualcomm, etc.) and BIOS vendors (AMI, Phoenix, Insyde, Biosoft, etc.) to fill in the rest with proprietary code. This problem is actually almost identical to the Android fragmentation problem. But really what Microsoft has done here is create another fork for their Surface products.
The good thing is that Microsoft has open sourced a lot of that fork and have pushed the percentage forward from 40% to maybe 50 or 60%. If you look at what they have released though it is very customized for Surface... they have come up with their own answers for a lot of stuff that the UEFI specification already has answers for; the BIOS setup menu/HII database being the most notable. The percentage gained could be much higher if they didn't insist on duplicating code already in tianocore just because they think they know better. Separately, the tianocore guys are also trying to solve the fragmentation problem. A complete open source UEFI firmware implementation is under development right now: https://github.com/tianocore/edk2-platforms/tree/devel-MinPlatform I am one of the active contributors to tianocore. It is my hope that if Microsoft is truly interested in trying to solve the fragmentation problem that they are willing to work with tianocore and contribute to it instead of building their own competing open source community.
The one thing that all of us should keep an eye on is the potential for a Microsoft attempt to use the Windows Hardware Compatibility Program to force every PC on the planet to use MU. Creating a firmware mono-culture would give Microsoft much more control over the PC industry than Windows itself already affords them. They could turn every PC into nothing more than a Surface with a different OEM logo on the lid. It's certainly one way of solving UEFI's forking issue, but it would significantly strengthen the walled garden they are trying to build with Windows 10 at the same time.
You do know there are NO OSs that use BIOS, right? Not a single one. It would take one hell of a lot more than 'understand bigger drives' to make BIOS useful, starting with running in other than real mode, and continuing with support of all the device types that have appeared in the last 35 years or so.
Yes, I do know that all OSes take over once they are loaded. Another reason why EFI is of questionable benefit.
Since all EFI and old BIOS seem to be good for is initializing the system, finding, and loading a boot loader, why do we even need to invite the new bugs and new pain from EFI? I've seen plenty of old BIOS that can load from iSCSI, USB, FC, etc.
EFI seems to suffer very much from second system syndrome as well as kitchen sinkism.