Talk:Unified Extensible Firmware Interface
|↓||Skip to table of contents||↓|
|This is the talk page for discussing improvements to the Unified Extensible Firmware Interface article.|
|This article is of interest to the following WikiProjects:|
|This talk page is automatically archived by Lowercase sigmabot III. Any threads with no replies in 120 days may be automatically moved. Sections without timestamps are not archived.|
According to this presentation from WinHec 2004 (page 15), the EFI System Partition (ESP) is FAT-32: EFI And Windows "Longhorn"
And Microsoft just won the case about the FAT patents: Microsoft's file system patent upheld
So to use FAT you need to license the IP from Microsoft: Microsoft FAT license (Broken link?)
But you can do that for free if you are implementing EFI, here:
The standard doesn't say anything about other partitions than the ESP, so that doesn't rule out MacOS.
"Ideally, the EFI development model will move the concept of hardware drivers from the operating system back into the lowest level of the PC structure: the hardware itself."
Does anyone else have a problem with this sentence? I edited the article to include sections and made some minor grammatical changes. I wanted to change this sentence, but I let it stand.
The problem that I see is that it makes it sound like the author is proposing that OS-level drivers are bad and EFI-level drivers are good. That debate is probably beyond the scope of this article. If the sentence stays, it should probably be worded to sound less like an opinion.
Agree with above. Also I found it a little confusing, since the article makes clear that EFI seems to make it easier to update the 'bios' level then before.. And then comments about it being in the hardware. Some clarification would be great. 188.8.131.52
EFI: BIOS replacement?
I don't see the point here, EFI has nothing to do with the statment:
(EFI) is a system developed by Intel to replace the BIOS..
EFI is only a specification aimed to put a new standard in the Interface of the system Firmware; i.e: how a Specific software like an Operating System should deal with system Firmware functions, It has nothing to do with 'BIOS replacement'
The section about intellectual property should either be removed or cleaned-up, as it is totally not NPOV, and makes false claims:
- According to Ron Minnich, the lead developer for LinuxBIOS
Is the 'lead developer for LinuxBIOS' an authority on this case? I would say he would be pretty biased. Why would I (or anyone seeking EFI information) want to know his opinion?
- one of the stated goals of EFI is to “protect hardware vendors’ intellectual property”.
Good, so we have hearsay here. Nowhere on the UEFI website can this 'stated goal' be found.
- This raises security concerns
For whom? Who is doing the raising? Weasel word alert!
- and notably makes creating a free software implementation impossible.
Why? Can a free software implementor not sign the "the UEFI Adopters' Agreement"? Since the specs are free to read, why would an implementation not be distributable by BSD license?
Note: you can't implement UEFI firmware without signing the UEFI Adopters' Agreement (it goes against the conditions you agree to before viewing the specification). However, nothing in the UEFI Adopters' Agreement prevents your implementation from being open source, and anyone can sign the agreement without paying fees, etc. In addition, Intel and UEFI already supply a large part of the code needed for UEFI firmware (AFAIK it includes everything except chipset specific parts) that is distributed under the BSD licence (see http://tianocore.org). Despite what Ronald Minnich said, a firmware manufacturer could easily attach open source chipset specific code (which is beyond the scope of UEFI) to the open source Tiano code (instead of attaching "binary-only BIOS code provided by a vendor"). —Preceding unsigned comment added by 184.108.40.206 (talk) 12:29, 10 December 2007 (UTC)
- EFI could be used to create a “DRM BIOS”
Sure, but so could any BIOS implementation. Modern non-EFI BIOSes contain SMM code that can do stuf without the OS knowing, including simulating or blocking devices. Has nothing to with EFI whatsoever.
- thus letting vendors build computers which limit what the user can do.
Damn, I really want to play the latest 3D games on my old P1 266MHz with a Tseng ET4000. What do you say? Not possible? Has anyone limited what I can do? Really, even without the sarcasm, that's a sorry sentence...
- EFI is not open source.
EFI is a specification, not source code. EFI is not a car either. Or a gorilla. Do we really need to state the obvious here?
- Its specification is not publicly viewable
This is downright false, see http://www.uefi.org/specs/
- and EFI site suggests that it is a supporter of the Trust Computing Group.
Which is a well-known El-Qaeda affiliate? And where does it 'suggest' (weasel word alert!) Come on people, NPOV please!
Ok, I'll stop ranting. If anyone wants to clean up the section, please do so. If noone does, I'll do it, but then don't start wining it's non to your liking. Jalwikip (talk) 10:11, 10 December 2007 (UTC)
- Ok, based on reading the interview with Minnich and the comments of the anonymous user above, I decided to remove the entire section. Minnich did not claim there were 'stated goals' but says he heard it from not mentioned persons. Also, the discussion about the security issue was condensed to much in the section, and has on top of that not much to do with the 'intellectual property' of the section header. Jalwikip (talk) 15:04, 7 January 2008 (UTC)