Diskussion:Unified Extensible Firmware Interface

Wichtig wenn ihr einen Kommentar schreibt immer mit ~~~~ beenden.--EaPoe 18:08, 17. Jan. 2008 (CET)

Ist kein Gesetz, keine zwingende Vorschrift in der Wikipedia, sondern lediglich eine höfliche Geste. --88.73.31.50 09:48, 8. Sep. 2008 (CEST)

UEFI (Unified Extensible Firmware Interface)

Das Teil heißt seit einiger Zeit nichtmehr EFI sondern UEFI (Unified Extensible Firmware Interface). Vielleicht sollte der Titel und Inhalt entsprechend geändert werden. (Nein ICH mach das nicht, ich hab weder Ahnung von der WikiTechnik noch von UEFI)

Hmm, also bei den Weblink-Quellen wird immer noch EFI genannt. --Muvon53 08:26, 7. Dez 2005 (CET)

Auf den alten Seiten schon, aber: http://www.uefi.org/

In der Presse ist überall nur von EFI die Rede 01.02.2006

Nicht ganz: UEFI ist eine Weiterentwicklung von EFI. Windows Vista x64 (bzw. ein Major Update von Windows Vista) wird UEFI unterstützen, ditto Windows Server "Longhorn". EFI wird in Zukunft wohl nicht mehr unterstützt. Evt. ist aber UEFI irgendwie zu EFI kompatibel, d.h. UEFI-Support impliziert EFI-Support. In diesem Fall sollte der Artikel in United Extensible Firmware Interface umbenannt werden. Falls nicht kompatibel, sollte ein neuer United Extensible Firmware Interface-Artikel angelegt werden und alle relevanten Informationen verschoben werden. Die Verwendung von EFI in den Medien ist meist ungenau bzw. fehlerhaft. -- 62.178.136.129 13:29, 3. Sep 2006 (CEST)

Habe mal Informationen zu UEFI eingebaut Oefe 17:39, 4. Feb. 2007 (CET)

Der Artikel enthält unsaubere Informationen. So wurde OpenFirmware z.B. schon Ende der 80er Jahre von Sun (ich glaube in der Sparc Station 1) verbaut. Das bedeutet, dass EFI viel jünger als OpenFirmware ist.

Nach meiner Kenntnis ist UEFI ein EFI-Dialekt von Intel. -- 2010-07-20 12:36 Tgerke

EFI und Windows Vista

Die Behauptung, dass Windows Vista und EFI nicht zusammenarbeiten werden ist wohl nicht richtig.
"Windows Vista soll ebenfalls mit EFI kooperieren" [1]
"Bisher hieß es bei Microsoft, dass sich Unterstützung dafür in der nächsten Windows-Version namens Vista fände." [2]

Ich bitte darum dies zu überprüfen und den Artikel anzupassen.

[1]Christof Windeck: "Wohngemeinschaft" Ct'Magazin, Heft6; S. 146 Abschnitt "Weiche Parallelen" ganz hinten
[2]http://www.heise.de/newsticker/meldung/70670

P.s. Ich hoffe der Kommentar ist in Ordnung, wenn nicht entschuldigt bitte. Ich habe mich mit dem Wikipedia-System bisher nicht befasst.

Dein zweiter Link belegt doch, dass Vista nicht EFI unterstützen wird. Die Server- und die x64-Version werden es irgendwann mal tun. Das kann man vll aufnehmen. Aber die normalen Endanwenderversionen werden es definitiv nicht, zumindest nicht in absehbarer Zeit. Es war mal geplant, aber MS hat es sich im Frühjahr anders überlegt. --Halbm0nd 23:30, 3. Jul 2006 (CEST)

Heise liegt auch oft genug falsch. Ich hab mal auf die neueste Vista Beta geschaut und dort findet sich neben bootmgr auch ein bootmgr.efi. Und ein efi-Verzeichnis mit ein paar Dateien...

Also auf meinem Apple MacBook (hat kein BIOS mehr, sondern nur noch EFI), konnte ich Windows Vista Business nativ also ohne BootCamp, welches für Windows XP ein BIOS simuliert, installieren. Außerdem ist auf der Install-DVD ein Ordner namens EFI. Es ist also FAKT, dass Vista EFI unterstützt!

Vista wird (U)EFI erst mit dem Service Pack 1 unterstützen.--EaPoe 18:09, 17. Jan. 2008 (CET)

Und warum konnte er Vista Business RTM ohne SP1 auf dem MacBook installieren? es gibt zu EFI-Unterstützung in Vista RTM keine echten Quellen, sondern nur irgendwelche Journalistenmutmaßungen, die alle auf eine Pressemitteilung von microsoft zurückführen, nur sagt diese Pressemitteilung vielleicht weniger aus, als allgemein angenommen wird. Wenn deine Analyse von der Empirie widerlegt wird, muss deine Analyse irgendwo falsch sein - egal wie logisch sie ist. Irgendwelche Blogger (ich will die jetzt nicht als Quelle aufführen und auch jetzt nicht den Artikel verändern) hatten auch mal als Neuerung mit SP1 aufgeführt, dass Vista jetzt EFI "auch über Netzwerk booten kann" - woraus man folgern könnte, dass laut deren Meinung Vista auch vorher schon auf EFI, aber nur lokal, booten konnte. Wer weiß, vielleicht hat Microsoft damals nur behauptet, die Möglichkeit von EFI zu starten gestrichen zu haben, damit die Boardhersteller den Wechsel auf UEFI 2.0 forcieren und ihn nicht auf die proprietäre Spezifikation EFI 1.x (die Vista Entwicklungsversionen auch offiziell unterstützten) machen und dort stehen bleiben. Es könnte auch in Microsofts Interesse liegen oder gelegen haben, UEFI gegen EFI durchzusetzen, da Microsoft ja im UEFI-Forum mitsprechen darf. --SvenEric 21:03, 2. Aug. 2008 (CEST)

"C als Programmiersprache (bei BIOS: Assembler)"

Das ist doch Quatsch!? Dem BIOS ist es doch völlig egal, ob es in Assembler oder in C geschrieben wird, im EPROM steckt doch sowieso das Kompilat! Was hindert einen daran, ein BIOS in C oder C++ zu schreiben? Ob BIOS oder EFI, in welcher Sprache man das schreibt sollte doch herzlich wurscht sein? --Afrank99 15:59, 15. Sep 2006 (CEST)

Das denke ich auch. Ob Software nun Kompiliert wird(wie z. B. C, Pascal, Basic), oder gelinkt(wie Assembler). Als Resultat erhält man immer den Maschinen Code. Die Verwendete Programmiersprache ist dem System völlig egal. Habe den Stickpunkt entfernt. 213.39.216.143 00:46, 11. Jun. 2007 (CEST)

Laut den Aussagen der Entwickler (Buch: "Beyond BIOS: Implementing the Unified Extensible Firmware Interface with Intel's Framework", Intel Press) ist C als Sprache vorgesehen, da es die nötigen Anforderungen für systemnahe Programmierung erfüllt. Zudem ist UEFI als Source auf Plattformunabhängigkeit ausgelegt (die APs natürlich nicht, aber auch diese werden in C implementiert), dies wäre in Assembler wohl kaum möglich ... Also: Nein! Es ist nicht egal und auch kein Quatsch! Bitte nicht mit Halbwissen um sich werfen. Es ist ja in Ordnung zu hinterfragen, ob etwas stimmt, aber einfach ohne Plan zu löschen finde ich persönlich dreist. Quelle: "Beyond BIOS: Implementing the Unified Extensible Firmware Interface with Intel's Framework describes a set of robust architectural interfaces, implemented in ->C<-" ( http://www.intel.com/intelpress/sum_efi.htm ) Diesen Nachweis zu finden hat circa 1 Minute gedauert .. aber erstmal löschen, ne? Ansonsten noch: http://www.uefi.org/learning_center/

Nuja, dass Intels unter GPL freigegebene Standard-Implementierung in C ist und Intels Systementwickler C empfehlen, bedeutet trotzdem nicht, dass eine andere Firma nicht sonsteine Sprache verwenden könnte. Dass C recht hardware-nah ist, ist 'ne Binsenweisheit, es wurde ja zur OS-Programmierung erfunden. Und dass einige Basisroutinen wohl praktisch immer in Assembler sein müssen, jaaaa. --arilou 11:56, 20. Jan. 2011 (CET)

EFI und Bootloader

Das EFI bietet die Anwahl für Betriebssysteme und startet diese, damit sind Boot-Loader überflüssig.

Ich habe den Satz etwas präzisiert, denn die einzelnen Betriebssysteme brauchen schon noch ihre eigenen Bootloader, z.B. Elilo bei Linux oder boot.efi bei Mac OS X. --Prolinesurfer 10:28, 24. Mär. 2007 (CET)

Nicht unbedingt. Ein EFI Bootloader müsst halt die Spezifika zum Booten der jeweiligen Betriebssysteme kennen, oder natürlich die Betriebssysteme halten sich an einen Standard wie zB. MBI. Zum Beispiel kann GRUB alle Unix-Derivate booten, die MBI-compliant sind. GRUB bootet zwar auch Windows-Derivate, aber die eben nur über Chain-Loading, indem der Windows-eigene Bootcode geladen wird. Letzteres könnte ein EFI Loader aber auch tun.

Mich interessiert insbesondere die Unterstützung von multi-boot-Umgebungen. Beispielsweise 3 verschiedene Windows-Installationen auf einer einzelnen Festplatte. Aufgrund einiger Beschränkungen in den Betriebssystemen mussten bisher GRUB, LILO (etc.) verschiedene Tricks anwenden. Dazu gehörten beispielsweise: Verstecken von Partitionen, virtuelles Drive Swap (bei mehreren Festplatten) usw. Wird das von einem EFI-System ebenfalls unterstützt? [FrancoisL] 2008-02-07

Kritik

Evtl. sollte noch auf Kritik an EFI eingegangen werden. Siehe z.B. [1] --84.138.198.72 10:32, 18. Apr. 2007 (CEST)

Gibt es denn wirklich etwas zu kritisieren? Eigentlich nur, dass EFI immmernoch nicht etabliert ist, was vorrangig an den Hardware- und BIOS-Herstellern zu liegen scheint, und daran, dass Microsoft bisher keinen Anreiz gab. Die IT-Industrie unterliegt ja leider einer Diktatur. :-/

Da stimme ich zu. Im Gegensatz zu einem abwiegenden Vorteil/Nachteil hat eine (meist subjektive) hingemotzte Kritik nichts in einem Nachschlagewerk zu suchen... (Schreibt doch jemand mal hin "Intel ist sch***e", nicht gerade hilfreich, oder? ^^) --Carminox 21:48, 20. Sep. 2007 (CEST)

Erster Beitrag: 100% ACK. Bleibt abzuwarten, wie MS seinen Einfluß nützt. Man stelle sich vor: Linux könnte mit vom EFI geladenen Treibern nicht nur die gängigste, sondern _jede_ HW unterstützen, traumhaft! Für mich ein Hauptgrund, Linux von Zeit zu Zeit zu probieren, dann aber wg. nicht vorhandener Treiber entnevt wieder fallen zu lassen (selbst USB kann u.U. Probleme machen -> was soll das?).

meine 2 cent, bis dann

Es ist aber auch zu befürchten, dass einige Unternehmen ihre Monopolstellung durch UEFI ausbauen würden/könnten/werden. Siehe: http://www.freesoftwaremagazine.com/columns/uefi_and_windows_8_bad_news_gnu_linux -- 178.7.2.126 21:54, 31. Okt. 2011 (CET)

EFI ist doch auch open source! der letzte Satz aus der Kritik ist so nicht 100% korrekt! 95.208.111.159 19:56, 2. Feb. 2012 (CET)

Der Standard ist offen. Die Implementierungen durch die HW-Hersteller etc. allerdings nicht zwangsläufig.--Mlorer 14:25, 5. Feb. 2012 (CET)

Nachteile des BIOS

Abschnitt "Geschichte": "... heutigen Anforderungen der Computergenerationen als nicht mehr gerecht empfunden werden."

wieso? Weil ein BIOS 16Bit ist, im Real Mode läuft, langsam ist?

Abschnitt "Techniken und Möglichkeiten": Es wird von den _Nachteilen_ des BIOS gesprochen. Auch hier wird nicht weiter erwähnt, welche das sind.

Ich schlage vor, daß ein eigener Abschnitt mit den Nachteilen des BIOS angelegt wird, oder diese zumindest in einem Satz konkretisiert werden.

• langsam (Liegt das am Real-Mode? Oder sind die alten Methoden der Hardware-Erkennung nur so lahm?)
• schlecht wartbar
• nicht erweiterbar
• fehleranfällig
• beschränkte Möglichkeiten (wegen Real-Mode und ROM Größe, nehme ich an)
• bietet viele Funktionen, die nicht mehr gebraucht werden
• bietet viele Funktionen nicht, die gebraucht werden könnten
  • zB. Netzwerk-Unterstützung
  • mehr Informationstabellen für das Betriebssystem
• unschön (kein Grafikmodus)

Bitte die Liste erweitern, wenn jemand etwas weiß.

Dies ist nicht der Artikel vom BIOS also sollte (wenn überhaupt) ein Abschnitt mit den Vorteilen des (U)EFI's gegenüber des BIOS gegründet werden.--EaPoe 18:19, 17. Jan. 2008 (CET)

Nachteile des BIOS (2)

Am meisten irritiert mich das Heruntermachen des (IBM-)BIOS, sowohl in der Wiki, als auch in der Presse. Es fehlen Begründungen, warum das BIOS nicht mehr herhält und warum es nicht erweiterbar ist. Es in einem Artikel einfach so zu behaupten, ohne einen winzigen Satz über die Begründung loszulassen, ist alles andere als informativ... :/ Carminox 21:43, 20. Sep. 2007 (CEST)

Das BIOS kann bspw. nicht übers Netzwerk gestartet werden, was zwar Heimnutzer wenig interessiert, aber in der Industrie durchaus wichtig sein kann. Für den Heimnutzer ist interessant, dass das BIOS nur mit Hilfe eines proprietären Installers, der auf einem vom Mainboardhersteller ausgewählten Betriebssystem (DOS oder Windows) gestartet werden muss, installiert werden kann. So braucht ein Linuxnutzer eine DOS-Bootdiskette um sein BIOS aktualisieren oder fehlerbereinigen zu können. EFI sieht eine eigenständige Update-Möglichkeit vor, die den Nutzer des EFI-Computers unabhängig von bestimmten Betriebssystemen macht. Dazu kommt dann noch, dass das BIOS Betriebssystemstarter nur von MBR-Datenträgern starten kann, was in nicht mehr so ferner Zukunft ein Problem sein wird, weil der MBR maximal 2 GiB große Datenträger (Datenträger, nicht Partitionen) verwalten kann. EFI kann Betriebssysteme auch von GUID Patition Table Datenträgern starten, die wesentlich größer sein können. --88.73.43.218 12:02, 7. Sep. 2008 (CEST)

"Dass das BIOS Betriebssystemstarter nur von MBR-Datenträgern starten kann" ist Quatsch! Das BIOS lädt einen Bootsektor (der AFAIK nicht einmal im ersten physischen Sektor sein muss) und führt ihn aus. Das Partitionsformat ist dem BIOS dabei egal - ganz im Gegensatz zu UEFI, das auf einzelne Partitionen zugreift und weit komplexere Dinge auf der Platte machen möchte. Viele der anderen Punkte unter "Techniken und Möglichkeiten" im Artikel sind ebenfalls nicht UEFI-eigen, sondern genauso mit dem klassischen BIOS möglich. Das ist eine Liste der Eigenschaften von UEFI und keine Liste von Vorteilen gegenüber dem klassischen BIOS! -- 84.178.126.63 11:13, 10. Jul. 2013 (CEST)

Wo ist das EFI gespeichert?

Wo sind das EFI, die Treiber usw gespeichert? Flashspeicher? Auf der Festplatte?(Der vorstehende, nicht signierte Beitrag stammt von 62.47.132.68 (Diskussion • Beiträge) 12:47, 17. Sep. 2007)

Da wo auch das BIOS gespeichert war, also im ROM.--EaPoe 18:17, 17. Jan. 2008 (CET)

EFI vs UEFI

Also jetzt will ich mal wissen was dafür und was dagegen spricht den Artikel UEFI zu benennen.--EaPoe 18:36, 17. Jan. 2008 (CET)

Also da es EFI ja nicht mehr gibt und es jetzt UEFI heisst und auch so verbreitet wird schlage ich vor den Artikel zu verlegen. Da ich aber nicht die Wahrheit für mich gepachtet habe und jeder mal Fehler macht bitte ich euch um eure Meinung (und es ist ja nicht der Fall das hier nichts passiert), anderenfalls werd ich den Artikel verschieben.--EaPoe 23:07, 20. Jan. 2008 (CET)

Naja, Apple Incorporated nutzt in seinen Computern nach wie vor die (veraltete) proprietäre EFI 1.x Spezifikation von Intel, nicht den jüngeren UEFI-Standard. Vielleicht wird Apple irgendwann auf UEFI umstellen, vielleicht aber auch nicht, damit auch UEFI-PC-Hardware ein wenig inkompatibel zu OS X bleibt. Solange Apple Inc. EFI und nicht UEFI verwendet, kann EFI meiner Meinung ruhig der Titel bleiben. --SvenEric 21:06, 2. Aug. 2008 (CEST)

Trusted Computing

Warum liest man weder im Artikel noch hier bei den Diskussionen, dass es fuer dieses Bios seitens der Industrie moeglicherweise eine ganz andere Motivation geben koennte und die beworbenen Vorteile es den Leuten nur schmackhaft machen und ueber andere Ziele hinwegtaeuschen sollen?

EFI wird als Grundlage fuer TC benoetigt. Solange TC kein "owner override" bietet, muss man an den vorgegeben Zielen stark zweifeln. Es stimmt auch nicht, dass DRM nur ein Nebenprodukt ist, wirbt die TCG im Business-Umfeld genau damit. Es kann jedenfalls nicht sein, dass die Industrie die Kontrolle ueber meine Systeme uebernimmt!

Mehr zum geforderten "Owner Override": http://www.eff.org/wp/trusted-computing-promise-and-risk

Ein Kurz-Film, der das grundlegende von TC erklaert: http://www.lafkon.net/tc/

--Tichy 12:35, 20. Jan. 2008 (CET)

Hast du da irgendwelche brauchbaren Quellen? In dem Text steht zu EFI jedenfalls nix. --TheK? 12:41, 20. Jan. 2008 (CET)

Boot Camp (Software)

„Die Beta-Version von Boot Camp, die auch auf Mac OS X 10.4 lief, ist inzwischen nicht mehr lauffähig.“ – Sicher dass das stimmt? Bei mir läuft die Beta-Version nämlich noch einwandfrei. Sie ist zwar nicht mehr kostenlos auf der Apple-Website verfügbar (da kein BETA-Status mehr besteht), aber sie funktioniert immer noch. –Ph. Immel 15:20, 31. Jan. 2008 (CET)

Stimmt wohl. Ich selbst habe zwar leider keinen Intel-Mac mit Tiger drauf, aber ich kenne jemanden, der das hat(te) und bei demjenigen die Beta-Version von Boot Camp auch weiterhin funktionierte. ‣Andreas•⚖ 09:21, 28. Sep. 2016 (CEST)

Kritik #2

Da ohne Diskussion und ohne für mich ersichtlichen Beleg jetzt ein neuer Kritikabsatz in den Artikel gewandert ist, stelle ich mal hier die Frage, ob es für die dortigen Behauptungen wie bspw.: "da etwa mit dem implementierten Netzwerkstacks die theoretische Möglichkeit besteht das etwa Daten unbemerkt vom Betriebssystem an eine beliebige Adresse versendet werden können." irgendeinen Beleg gibt. Ein Link unter dem man nachprüfen könnte, ob das mehr ist als ein Gerücht, wäre schon schön. ;-) --SvenEric 19:36, 12.09.2008 (UTC)

P.S. Insbesondere würde mich interessieren, warum die Herren von LinuxBIOS bzw. Coreboot bei ihrer Kritik an EFI nie die gleichen Kritikpunkte an Open Firmware richten, obwohl das auch einen Network Stack haben kann. Und während jetzt laut diesem neuen Kritikabsatz Banken angeblich Probleme mit EFI-PC haben sollen, weil der Network Stack nicht vom Betriebssystem überwacht wird und deshalb Daten versenden kann, ohne dass das OS das merkt (mal Klartext: ein OS kann auch Daten versenden, ohne dass eine Bankanwendung etwas davon bemerkt), habe ich noch nie gehört, dass Banken Macs, die über zehn Jahre auf OFW liefen und seit einiger Zeit auf EFI laufen, aus diesem Grund ausschließen würden. --SvenEric 19:52, 12.09.2008 (UTC)

Naja, EFI ist nicht so schön offen, wie es aussieht, es ist proprietär. Und da kann man halt alles reinpacken.

Das Unified EFI ist erstmal im wesentlichen eine Implementation eines offenen Standards vom UEFI-Forum. Die BIOS aller Mainboardhersteller sind dagegen durch und durch proprietär, da kann man dann eben auch alles reinpacken. In diesem Punkt gibt es also faktisch keinen Nachteil durch EFI gegenüber BIOS. Was es gibt, ist ein Unterschied der technischen Möglichkeiten - die aber alle auch bei Open Firmware existieren. Ich kann sehr wohl bspw. ein DRM-System für OFW schreiben und das von OFW laden lassen, bevor irgendwas anderes geladen wird. Deswegen würde mich halt mal interessieren, was die Coreboot-Geeks da nun als großen wichtigen Unterschied sehen, den sie ja sehen müssen, da sie es gutheißen, Coreboot dazu zu verwenden, Open Firmware zu starten (wozu man dabei auch immer Coreboot nötig haben sollte) --SvenEric 12:33, 31. Jan. 2009 (CET)

Ganz einfach das eine ist quelloffen und deshalb überprüfbar das andere nicht weil nur mit Mühe reassembliebar. das ist der unterschied liebe UEFI-, Content und Microsoft-Geeks. 37.5.16.73 22:08, 1. Jan. 2016 (CET)

Übrigens jeder darf quelloffene Software implementieren sie GNU-Lizenz. 37.5.16.73 22:09, 1. Jan. 2016 (CET)

Eierlegende Wollmilchsau EFI

Je mehr man sich die neueste Spezifikation UEFI 2.2 durchliest, desto weniger wirkt EFI wie ein einfacher BIOS-Ersatz. Einerseits versucht sie "nur eine Umgebung für den Pre-Boot" zu harmonisieren, andererseits sind ganze Netzwerkstacks bis zu OSI Layer 4 (von ARP über VLAN bis hin zu FTP) und neuerdings auch iSCSI-, PCI-, USB- und Benutzeridentifizierungs-Schnittstellen vorgesehen. So ein Environment entspricht dem Funktionsumfang einer vollwertigen Laufzeitumgebung ähnlich Java oder .NET Framework. Letztenendes könnte man EFI mit einem Root-Kit vergleichen. "Apokalyptische" Sicherheitslücken, Überwachungsskandale und massive Virenbefälle sind vorprogrammiert, spätestens wenn EFI das alte BIOS vollständig vom PC-Markt verdrängt hat, da bin ich mir sicher. --Carminox 03:58, 10. Feb. 2009 (CET)

Fühle mich gelangweilt von deiner Wiederholung der seit Jahren selben "Bedenken". Ob es in älteren Spezifikationen schon drin stand, weiß ich nicht, aber dass das EFI auch aus dem EFI heraus aktualisiert werden können soll, wird seit ettlichen Jahren beworben und Preisfrage: Wie überträgt man wohl die Aktualisierungsdateien? Hmm - doch nicht etwa mit einem FTP? Und warum es verkehrt sein soll, dass EFI Datenträger über USB, SCSI, PCI usw. direkt ansprechen kann, damit ich es aktualisieren kann, ohne für das Aktualisierungsprogramm ein extra Betriebssystem einrichten und booten zu müssen, würde mich auch mal interessieren. Das BIOS, dieses alte ach so sichere Ding, kann von jedem Betriebssystem aus überschrieben (geflasht) werden, wenn für das jeweilige proprietäre BIOS der BIOS-Hersteller das BIOS-Update-Programm für das jeweilige Betriebssystem zur Verfügung stellt - in der Regel gibts sowas im PC-Markt nur für Windows und DOS, wobei DOS-BIOS-Updates von Diskette bei den meisten ausgestorben sind, weil kaum noch jemand Bock hat, extra dafür ein Floppy-Laufwerk anzuschaffen, sodass heutzutage das BIOS in der Regel von Windows aus aktualisiert, also überschrieben, wird. BIOS-Viren, die vom Betriebsystem aufgerufen das BIOS überschrieben, hats schon früher gegeben - EFI ändert daran nichts. Deswegen langweilt mich diese Panikmache. (mit Absicht ohne Signatur - ich bitte darum, dass es so bleibt - weder Datum noch Person oder IP-Adresse haben in diesem Diskussionszweig Bedeutung) P.S. ich hatte gesagt mit Absicht ohne Signatur, die Richtlinnie ist zwar eine Richtline, aber eben keine feste Regel und wenn die Wikipedia die Signatur befehlen will, dann soll sie 1. als feste regel und nicht nur Richlinie definieren und 2. sie gefälligst automatisieren - danke für das Verständnis, falls es welches geben sollte.(nicht signierter Beitrag von SvenEric (Diskussion | Beiträge) 03:04, 2. Mai 2009 (CEST))

Bla, bla, bla... Besser sich vorher informieren, bevor man Argumente im PC-Zeitschriften-Niveau ins Board klatscht. Der kleine Satz in diesem Artikel, nämlich "EFI gilt [...] in sicherheitskritischen Einsatzumgebungen wie etwa in Banken als ein mögliches Sicherheitsrisiko, da etwa mit dem implementierten Netzwerkstacks die theoretische Möglichkeit besteht, Daten unbemerkt vom Betriebssystem an eine beliebige Adresse zu senden." ist nämlich so real, dass man bei der Recherche dauernd auf Aussagen stößt, dass Banken und große Anwaltskanzleien nicht auf Systeme mit EFI umrüsten und teilweise sogar coreboot benutzen. Das Argument DOS-BIOS-Update ist insofern unwichtig, da man seit geraumer Zeit das BIOS per USB-Stick direkt über das BIOS-Menü updaten kann. Und dazu braucht man kein BIOS. Die Frage ist, ob du überhaupt weißt, wie ein BIOS überhaupt funktioniert, um solche Aussagen zu machen. -- 02:03, 18. Jun. 2009 (CEST) (ohne Benutzername signierter Beitrag von Carminox (Diskussion | Beiträge) )

"Bla, bla, bla" Belege? Achso "recherschiere mal", schon klar... tut mir leid, aber solange hier kein beweis dafür steht - und zwar etwas anderes als die Aussage eines coreboot-Entwicklers, bleibt das für mich massivstes FUD gegen UEFI. Aber ganz bestimmt nutzen die coreboot - auf was für Rechnern denn bitte auf dem Toaster oder fernseher für dessen embedded-Board coreboot schon Betastatus angemeldet hat? Das ist so realistisch, wie ein Einsatz von GNU Hurd in Banken. --SvenEric 20:22, 18. Sep. 2009 (CEST)

Meine Begründung habe ich bereits im ersten Post dargelegt. Einen Beleg zu verlangen, dass komplex konzipierte Systeme nicht fehleranfällig wären, ist doch etwas grenzwertig. Ein Indiz dafür, dass EFI unter Umständen mehr Probleme macht als welche löst, könnte man an den Intel Boards selbst sehen: Das Firmwareimage ist 16 MB groß, fast jeden Monat gibt's ein Update und bei einigen Modellen lässt sich Windows 7 nachwievor nicht im EFI-Modus installieren, trotz offizieller UEFI-Unterstützung (bei mir das Board DP43TF mit aktuellster Firmware). Ein weiteres Indiz wäre, dass die gesamte Spezifikation umfangreicher ist als die vollständige für x86 und x86_64 zusammen. Das wirkt so, als ob die Bootumgebung komplexer ist als eine ganze Prozessorarchitektur. Außerdem, Kritik ist kein FUD. Und wer nicht das Werbegeschwafel hinterfragt und darüberhinaus jegliche Kritik versucht zu annullieren, geht vom Verhalten her leicht als Fanboy durch. --Carminox 23:10, 27. Jun. 2010 (CEST)

---

Kann das "GRAPHICS OUTPUT PROTOCOL" von (U)EFI auch noch nach dem Booten verwendet werden, so wie das VBE-BIOS der Grafikkarten?

Gibt es eine Unterstützung für secondary display devices, damit auch der zweite Monitor den Inhalt des zweiten Framebuffers zur Anzeige bringt und läßt es sich steuern ob dabei der clone-mode, multi-mode, span oder extended mode verwendet wird?

Können auch refreshrate controlled Videomodi mit einer CRTC-Parameter-Tabelle verwendet werden, oder muss man sich bei hohen Aulösungen mit 60hz refreshrate begnügen?

Sind die Modenummern für die Videomodi bei (U)EFI einheitlich genormt, oder wird immer nur die Modenummern-Tabelle aus dem Bios der jeweiligen Grafikkarte entnommen, deren Nummern und Auflösungen sich von BIOS zu Bios unterscheiden können?

..

Und die wichtigste Frage: Wann können endlich quanterverschränkte Wollmilch-Eier über die firmware genutzt werden, um darüber ein Bios-Update zu machen? (nicht signierter Beitrag von 85.177.172.81 (Diskussion) 11:48, 26. Feb. 2014 (CET))

Bildbeschreibung fehlt bei [[Bild:Efi-simple_de.svg|thumb|right|320px|]]

Der Artikel enthält ein Bild, dem eine Bildbeschreibung fehlt, überprüfe bitte, ob es sinnvoll ist, diese zu ergänzen. Gerade für blinde Benutzer ist diese Information sehr wichtig. Wenn du dich auskennst, dann statte bitte das Bild mit einer aussagekräftigen Bildbeschreibung aus. Suche dazu nach der Textstelle [[Bild:Efi-simple_de.svg|thumb|right|320px|]] und ergänze sie.

Wenn du eine fehlende Bildbeschreibung ergänzen willst, kannst du im Zuge der Bearbeitung folgende Punkte prüfen:

• Namensraum Datei: Bilder sollte im Namensraum Datei liegen. Bitte ändere die alten Bezeichnungen Bild: und Image: in Datei:.
• Skalierung: Außerhalb von Infoboxen sollten keine festen Bildbreiten (zum Beispiel 100px) verwendet werden. Für den Fließtext im Artikelnamensraum gibt es Thumbnails in Verbindung mit der automatischen Skalierung. Um ein Bild/eine Grafik in besonderen Fällen dennoch größer oder kleiner darzustellen, kann der „upright“-Parameter verwendet werden. Damit erfolgt eine prozentuale Skalierung, die sich an den Benutzereinstellungen orientiert. --SpBot 22:21, 1. Mär. 2009 (CET)

Marktdurchdringung

Mir fehlt da der Punkt, dass seitens der Mainboard-Käufer die GUID Partition Table gefordert wird, damit man von >2TB -Platten booten kann. Afaik kann das nur (U)EFI. Oder gibt's "normale BIOSse", die GPT unterstützen? --arilou 12:09, 20. Jan. 2011 (CET)

Stand 7.Feb.2011:

• ASUS - keinerlei Erwähnung von UEFI
• MSI - haben 7 Boards, alle für Sockel 1155 / Sandy Bidge
• ASROCK - nur Fatal1ty P67 (Sandy Bridge)
• BIOSTAR - keinerlei Erwähnung von UEFI
• FOXCONN - keinerlei Erwähnung von UEFI
• GIGABYTE - keinerlei Erwähnung von UEFI
• SAPPHIRE - keinerlei Erwähnung von UEFI
• TYAN - keinerlei Erwähnung von UEFI
• ZOTAC - keinerlei Erwähnung von UEFI

Ob GPT oder MBR ist dem BIOS völlig egal. Dieses lädt einfach den ersten Sektor und führt ihn aus. Wie der Rest der Platte aufgeteilt ist, ob da nun GPT oder was auch immer drauf ist oder wie groß diese ist, ist dabei völlig egal. Das geht auch prima ohne UEFI. Hier boote ich z.B. von einer ST3000DM001-9YN166 (3TB HDD, mit GPT) an einem GA-880GMA-UD2H (Mainboard mit klassichen Award BIOS). Viele der anderen Punkte unter "Techniken und Möglichkeiten" im Artikel sind ebenfalls nicht UEFI-eigen, sondern genauso mit dem klassischen BIOS möglich. Das ist eine Liste der Eigenschaften von UEFI und keine Liste von Vorteilen gegenüber dem klassichen BIOS!! (Einzig Windows mag nicht von einer GPT-Partition via BIOS booten, das ist aber eine Eigenschaft von Windows und nicht dem BIOS geschuldet!) -- 84.178.126.63 10:55, 10. Jul. 2013 (CEST) (11:22, 10. Jul 2013 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Marktdurchdringung 2

Diese Aussage sagt doch irgendwie gar nichts aus. Es muss doch seitens der Hardwarehersteller noch andere Gründe geben ausser "Wir möchten es nicht" oder bezieht sich das auf die Punkte die unter "Kritik" stehen? --Lastwebpage 00:28, 5. Jun. 2011 (CEST)

Vorteile vom echten BIOS

Also, hier liest man ja so einige Haarsträubende Sachen, also nun mal die Wahrheit.

• Das BIOS läuft (zumindest nach dem Start des Betriebssystems) im Real-Mode, ist somit schneller (Lest euch mal die Intel-Handbücher durch, da sieht man, das bei vielen Befehlen eine "Zeitstrafe" für Protektet Mode dazukommt(weil nämlich immer erst geprüft werden muss, ob Zugriff erlaubt ist).
• Das BIOS ist weniger Störungsanfällig, da es seit 30 Jahren immer weiter Perfektioniert wurde.
• Das BIOS wurde von Menschen geschrieben, das EFI wurde vom C-Kompilierer geschrieben. (Disassembliert mal ein C-Programm, es sträuben sich einen die Nackenhaare, was Kompilierer für einen Stuss fabrizieren)
• Das BIOS ist vor Zerstörung durch Schadprogramme sicher. (ROM kann mann nicht schrieben. Bei Flash-rom geht das nur unter DOS. Klickibunti-Schadprogramme haben also keinen Zugriff).
• Das BIOS ist Kinderleicht zu verwenden, das es im Real-Mode läuft, und Parameter über Register übergeben werden.
• Das BIOS ist UNIX-frei
• Die Schnittstellen zum BIOS sind hervoragend und auch sehr verständlich dokumentiert. Wenn man es Verändert, macht Man Jahrzehnte von Literatur und Bildung unbrauchbar. Milliarden von Menschen wären nicht mehr in der Lage einen Rechner zu benutzen.
• Das BIOS wurde von echten Programmierern geschrieben und Dokumentiert, die Ahnung von dem Haben was sie tun, und wird auch von solchen verwendet.
• Das EFI ist was für Schwuchteln, die Objekt-Orientierte oder Dekriptive Programmiersprachen benutzen, abstrakte Ausdrücke benutzen, kleinschreibung verwenden UNIX (windows NT) benutzen, grafische Benutzeroberflächen brauchen und wohl noch nie einen Lötkolben in der Hand hatten.
• Das BIOS hat schon immer funktioniert, und es gibt gar keinen Grund für irgendwelche Veränderungen. Und alle wirklich Sinnvollen Dinge, die man mit einem Rechner tun Kann,(Büro, Wissenschaft, Ingenieurwesen, Programmierung) konnte man auch schon vor 20 Jahren machen, sogar noch viel besser. Heute scheinen Computerspiele, und Videos zum Selbstzweck zu werden. Wofür braucht man das Alles ? Ein Rechner ist ein Arbeitsgerät, und das ging mit DOS/BIOS, einem 386er und einer EGA-Grafikkarte wesentlich besser als heute. Den ganzen scheiß wie Digitalkameras und Hohe Auflösungen bräuchte es doch gar nicht. Dann würden die Kinder auch wieder drausen im grünen Spielen, wie früher und die ganzen Hartz-4-Empfänger würden anstatt dauernd Pornos- und Facebook runterzuladen sich eine Arbeit suchen und das Internet würde wieder für Sinnvolle Dinge, wie das Verbreiten von Wissen verwendet werden, und nicht zur Unterhaltung oder zum Kommerz, und man könnte auch ohne dieses scheiß Windows darauf zugreifen. Diese Wirtschaftsschwuchteln, die im Internet Leute abzocken und Anglizismen wie "E-Commerce", "Briefing" oder "Buismess" benutzen wären doch gar nicht in der Lage ordendliche Rechner zu bedienen ohne Maus und den ganzen Klicki-Bunti-scheiß geschweige denn ihn zu reparieren. Wer wirklich Ahnung von Programmierung hat der Kann mit einem Befehlszeileninterpreter und Assemblierer umgehen und sieht auch das an dem IBM-Rechnern keine Änderung mehr nötig ist, seit Ende der 80er. (Der vorstehende, nicht signierte Beitrag stammt von 93.243.57.104 (Diskussion • Beiträge) 18:39, 4. Jul. 2011)

erinnert mich irgendwie an "Real programmers don't use Pascal" oder noch davor "Real programmers don't user Fortran" :) --Nobby1805 20:03, 5. Jul. 2011 (CEST)

Was für ein ausgemachter Blödsinn, ich weiß garnicht wo ich anfangen soll. Hast du schonmal was von Fortschritt gehört? Gerade wenn man sich mit IT beschäftigt sollte das kein Fremdwort sein. Was du forderst ist ewiger Stillstand. 30 Jahre sind in der IT eine Ewigkeit und kaum ein Teil der Systemarchitektur hat so lange überlebt, zu recht. BIOS ist nicht die total sichere Festung auf dem Mainboard und kann sehr wohl zerstört werden. Schon 1999 gab es Viren die das schafften. Und gerade erst ist ein neuer Virus aufgetaucht der BIOS infiziert. Ich kann ein BIOS Update ohne Probleme aus Windows aufspielen, dann ist das auch für Schadprogramme kein Problem. Was glaubst du eigentlich wieviele PC User auch nur von der Existenz von BIOS wissen? Glaubst du für die wird sich irgendwas verschlechtern? Und wer BIOS bedienen kann der schafft das auch mit EFI, will ja nicht jeder gleich sein eigenes schreiben. Nur weil du von modernen Entwicklungsmethoden keine Ahnung hast brauchst du hier nicht so rumzuflamen. Man kann die riesigen Programmieraufgaben für heutige Programme nicht mehr wie vor 30 Jahren bewältigen. Wenn dir das nicht passt lad DOS auf deinen alten 386er und sei glücklich damit. Ob du damit allerdings hier noch deine "weisheiten" verbreiten kannst bezweifle ich, aber vielleicht wäre das ein Segen für die Wikipedia. --MrEnglish 18:17, 12. Sep. 2011 (CEST)

Wozu willst du ein überladenes EFI, wenn das BIOS seine Sache genauso gut, aber noch schneller als EFI macht? EFI sorgt nur mit der Netzwerkanbindung + DRM für den FORTSCHRITT hinsichtlich Überwachung der Nutzer. Das geht ja leider mit dem guten alten BIOS nicht, oh wie schade! Ergo, EFI ist der totale Rückschritt: langsam, hässlich und Big-Brother-zertifiziert. Und einfacher als das BIOS kann man die Bedienung nicht machen (abgesehen von der zusätzlichen Steuerbarkeit mittels Maus). (nicht signierter Beitrag von 74.115.0.36 (Diskussion) 15:31, 16. Dez. 2011 (CET))

Sorry, aber das ist faktisch schlicht falsch. Durch einen kompletten Umbau des Treibersystems unter UEFI (bzw. überhaupt erst der Neu-Einführung eines Systems) sind wesentlich schnellere Boot-Zeiten im Vergleich zum Legacy BIOS möglich. Und das ist nur einer von vielen Vorteilen, die u.a. auch mit der Umstellung von Assembler auf C mit einhergehen. Außerdem hat EFI im ersten Schritt auch erstmal nichts mit Netzwerkanbindung und vor allem DRM zu tun. Das ist ungefähr so wie wenn du der Programmiersprache C(++) den Vorwurf machst, dass sich damit auch DRM-Systeme programmieren lassen. Nur weil EFI im Vergleich zum bisherigen BIOS einige weitere technische Möglichkeiten anbietet, liegt es immernoch im Ermessen der einzelnen Hersteller welche Features damit umgesetzt werden. Und letztlich hat es dann der Käufer in seinen Händen, welche Systeme er mit seinem Geld kauft.--Mlorer 15:38, 19. Dez. 2011 (CET)

Ich würde dir ja 100% zustimmen, wenn du nicht die Verbesserung der Bootzeit in einen Zusammenhang mit dem Umstieg von Assembler auf C gebracht hättest ... oder habe ich da einen falschen Bezug hergestellt? --Nobby1805 20:18, 20. Dez. 2011 (CET)

Die Verbesserung der Bootzeit hängt indirekt natürlich schon mit dem Umstieg von Assembler auf C zusammen. Ich gebe dir aber natürlich recht, dass man theoretisch in Assembler wesentlich schneller und effizienter ablaufenden Code schreiben kann als in C. Der Geschwindigkeitsvorteil beim Booten liegt aber nicht darin begründet. Die meiste Zeit beim Starten des PCs geht für die POST Tests und die Initialisierung der Hardware drauf. Und das bisherige BIOS ist dabei nicht in der Lage zu wissen welchen Teil der Hardware wann genau benötigt wird. Deshalb wird einfach alles was vorhanden ist initialisiert und getestet (wobei der genaue Ablauf und Umfang der POST Tests wieder Sache der einzelnen Hersteller ist und es dabei durchaus zu einigen Unterschieden in Umfang und Laufzeit kommen kann). Das braucht natürlich jede Menge Zeit. Durch den Wechsel der gesamten Infrastruktur hin zu UEFI (und das ist in diesem Stil auch nur mit einem Umstieg weg von Assembler möglich), "weiß" die Firmware welche Bestandteile sie wann laden muss oder was auch erst später ggf. vom Betriebssystem geladen werden kann (bzw. wenn bestimmte Ressourcen angefordert werden, können die entsprechenden Treiber einfach "nachgeladen" werden).--Mlorer 13:29, 21. Dez. 2011 (CET)

"Und letztlich hat es dann der Käufer in seinen Händen, welche Systeme er mit seinem Geld kauft." Nicht _der_ Käufer, sondern der Durchschnittskäufer. Und wenn nun ~90% der Käufer einen bestimmten Nachteil gerne mit kaufen, weil er ihnen egal erscheint, haben die restlichen 10% der Käufer durchaus mit dem Pech zu kämpfen, dass sich die Industrie zu 100% auf den Nachteil einstellt, weil die 10% ihnen völlig egal sind und es für _jeden_ gewinnbringender ist, sich auf die 90% zu konzentrieren. -- 84.178.126.63 11:22, 10. Jul. 2013 (CEST)

Artikel umbenennen in UEFI (Unified Extensible Firmware Interface) (erl.)

Ich möchte jetzt doch nochmal anregen den Artikel von EFI in UEFI umzubennen und eine Weiterleitung von EFI nach UEFI zu setzen. Außer den alten, noch laufenden Implementierungen, die auf EFI 1.x basierend, gibt es in diesem Bereich keine Weiterentwicklung mehr. Die Weiterentwicklung wird durch das UEFI Forum ausschließlich an der aktuellen Version 2.3.1 der Spezifikation vorangetrieben. Beleg dafür: Chapter 1, Seite 7 aus Beyond BIOS: Implementing the Unified Extensible Firmware Interface with Intel's Framework (Computer System Design); Zimmer, Vincent; Rothman, Michael; Marisetty, Suresh [ISBN 978-0974364902].--Mlorer 09:52, 21. Okt. 2011 (CEST)

Dann aber besser gleich nach „Unified Extensible Firmware Interface“ umbenennen, damit der Artikel wenigstens (wieder) einen aussagekräftigen Namen bekommt (auch wenn dieser nur englisch ist). In diesem allgemeinen Lexikon hier, also in der deutschsprachigen Wikipedia, lesen nämlich nicht nur IT-Spezis. --92.226.62.90 09:09, 29. Okt. 2011 (CEST)

Der Artikel wurde heute (endlich) umbenannt. Danke. --92.224.250.40 22:05, 6. Jan. 2012 (MEZ)

Vielen Dank dafür!--Mlorer 20:46, 8. Jan. 2012 (CET)

logisch / Logik

"Es sitzt logisch gesehen unterhalb des Betriebssystems" mit logik hat - unterhalb - nichts zu tun. unterhalb, oberhalb hat wohl eher etwas mit raum zu tun oder völlig unverständlich mit reihenfolge. (nicht signierter Beitrag von 89.0.149.16 (Diskussion) 16:41, 21. Dez. 2011 (CET))

Erst einmal habe ich den Kommentar in ein eigenes Kapitel verschoben ... das hat mit EFI bzw. UEFI nicjts zu tun

logsiche Schichten oder Blöcke sind in der Informatik allgemein verbreitet http://de.wikipedia.org/wiki/Schichtenarchitektur und was mit oberhalb bzw. unterhalb gemeint ist ist aus der direkt darunter stehende Zeichnung klar ersichtlich --Nobby1805 21:02, 21. Dez. 2011 (CET)

Kritik #3

Seit dem Bekanntwerden der universellen Überwachungsbestrebungen von NSA & Co durch Edward Snowden bin ich kritischer geworden: Wer oder was könnte Kontrolle über meine Hardware übernehmen. UEFI liefert alles, was sich ein Fremder zur Kontrolle meines PCs wünschen kann:

• agiert nach außen unsichtbar... in einer Art "Stealth Modus"
• hat eigene Ressourcen*: Prozessor und internes RAM/ROM: siehe INTELs QuarkX1000 als SoC (System on a Chip)
• hat Treiber + Vollzugriff* auf meine Peripherie (Video, RAM, USB, PCI, ... und damit auf HD, Video, Micro,..)
• bleibt auch nach dem Boot-Vorgang aktiv

Quelle: 329678_IntelQuarkCore_HWRefMan_002.pdf via Google zu finden

Ich möchte die Kontrolle über meine persönliche Hardware nur ungern einem komplett ausgestatteteten INTEL-Pentium-PC innerhalb meines PCs geben. Booten find ich gut :)... Aber kann jemand die Frage beantworten, was UEFI nach dem Bootprozess macht bzw. potentiell machen könnte? z.B. meinen Hauptprozessor mikrosekundenweise anhalten, um DMA-Zugriffe zu machen?? Solche "potentielle Gefahren" müssen doch auch in die Kritik rein.

Ich möchte

• mit einer LED sehen, ob und wann der UEFI-Pentium-Prozessor aktiv ist
• das UEFI-System nach dem Bootvorgang ausschalten können (Strom weg) ... als Option zur Laufzeit
• die Ethernet-Verbindung des UEFI auf dem Motherboard willentlich und hardwaremäßig unterbrechen können
• eine Alternative zu INTELs QuarkX-Familie haben

Bin ich der einzige, der solche Wünsche ans UEFI System hat?

An die kompetenten Autoren des UEFI-Artikels hätte ich folgende Bitte:

• Kann man eine Rubrik "Potentielle Gefahren von Uefi" einführen?
• Kann man eine Rubrik "Alternative Controller (SoCs) für Uefi" einführen?
• Kann man eine Rubrik "Kontrollmöglichkeiten des Users über Uefi" einführen?

Vertrauen (Trust) ist gut, (User-)Kontrolle ist besser! Danke :) --Matthias.Ebert (Diskussion) 14:27, 28. Aug. 2014 (CEST)

Marktdurchdringung veraltet

Der Abschnitt Marktdurchdringung scheint mir veraltet, und es scheint mir dringend angeraten, ihn auf den aktuellen Stand (2015) zu bringen.

Hier nur ein Beispielsatz, der das verdeutlicht: „Inzwischen hat mit dem Mainboard-Hersteller MSI der erste Anbieter ‚normaler‘ x86-Systeme damit begonnen, seine Produkte auf EFI umzustellen.“

--My2Cents (Diskussion) 21:01, 4. Dez. 2014 (CET)

uefi anfällig für Rootkit

http://www.heise.de/newsticker/meldung/BIOS-Rootkit-LightEater-In-den-dunklen-Ecken-abseits-des-Betriebssystems-2582782.html

'Ein Rootkit, das unabhängig vom Betriebssystem operiert, sämtlichen Speicher auslesen kann und durch den Tausch der Festplatte im System nicht gestoppt wird – was klingt wie eine IT-Gruselgeschichte haben zwei Forscher nun öffentlich präsentiert. Zwei Sicherheitsforscher haben äußerst perfiden Schadcode geschrieben, der das BIOS des Rechners infiziert und unabhängig vom gebooteten Betriebssystem alle Fäden in der Hand hält. Damit lässt sich sogar eine komplett im RAM laufendes Live-Linux ausspähen. Zwar benötigt der Angreifer Admin-Rechte, um die Firmware mit den Schadcode zu flashen, dafür gehört ihm dann aber das System so grundlegend, dass selbst der Austausch der Festplatte nicht hilft.'

sollte man mit einarbeiten (nicht signierter Beitrag von 90.153.103.9 (Diskussion) 18:16, 23. Mär. 2015 (CET))

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://eu.msi.com/html/popup/MB/uefi/about.html
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Wechsel zwischen http und https erforderlichhttp://giftbot.dwl.invalid/http://eu.msi.com/html/popup/MB/uefi/about.html

– GiftBot (Diskussion) 20:15, 2. Dez. 2015 (CET)

UEFI und LINUX

"EFI wird auch von Linux unterstützt. Der stabile Zweig des Linux-Kernels bietet seit Version 2.6.25 auch für die x86-Architektur Unterstützung für EFI."

Das ist nicht einmal ganz für EFI richtig. Bei UBUNTU 14.10 ist LINUS nach mehrerenplötzlichen Festplattenfehlkonfigurationen jetzt ganz verschwunden.

Auch nach Heike Jurzik: "Debian GNU/LINUX" Bonn 2015 funktioniert besonders UEFI etweder eingeschrängt, aber meistens extrem instabil. Bitte genuer recherieren und berichtigen 37.5.16.73 21:50, 1. Jan. 2016 (CET)

Hinweis entfernen: Es sind genug Belege für Hardwareschaden angeführt

"Dieser Artikel oder nachfolgende Abschnitt ist nicht hinreichend mit Belegen (beispielsweise Einzelnachweisen) ausgestattet."

Es sind genug Belege für Hardwareschäden angeführt. Bitte Hinweis löschen 37.5.16.73 22:00, 1. Jan. 2016 (CET)