ubuntuusers.de

Laut Presse soll Windows 8 mit einem eigenen BIOS kommen, für einen ähnlichen Bootprozess wie beim Chromebook. Das heißt wohl, dass man auf einem Computer, der min Windows 8 ausgeliefert wird wohl kein Linux mehr installieren kann, genausowenig wie auf einem Chromebook, weil auf dem Computer dann das Microsoft-BIOS ist, welches mit dem Betriebssystem verknüpft ist. Damit hätte Microsoft ja was es schon immer wollte, ein vollkommen hardwaregebundenes Betriebssystem. Was werden dann Selbstbauer tun? Werden dann Mainboards gebündelt mit einer Windows 8-Lizenz verscheuert? Wird es dann noch Mainboards mit gewöhnlichem BIOS geben? Oder muss man dann falls das Mainboard unterstützt wird ein freies BIOS flashen? Dann könnte man zwar Linux installieren, aber kein Windows mehr. Dual-Boot wäre also auch nicht mehr möglich. Was meint Ihr dazu? Oder sehe ich das möglicherweise falsch.

Tuxogereo schrieb:

Was meint Ihr dazu? Oder sehe ich das möglicherweise falsch.

Richtig, du siehst das falsch. ☺

http://www.youtube.com/watch?v=GDQWiD4nxMM bzw. http://windows8news.com/2011/06/04/microsoft-unveils-windows-8-video/

Grob gesagt, UEFI nur zwangsweise bei ARM-Geräten oder bei Festplatten über 2TB, wenn davon gebootet werden soll.

Zudem haben wir das grob selbe Thema hier: http://forum.ubuntuusers.de/topic/uefi-und-ubuntu/ schon mal, und da klingt das so als sei UEFI eh nicht wirklich unmöglich umzusetzen. Also kein Grund zur Panik...

Hab mir vor einem Monat einen neuen Rechner gegönnt (Intel Core i7 2600K auf einem Asus P8H67-M Pro). Das Mainboard besitzt bereits ein EFI-Bios und zumindest Arch rennt darauf wie eine eins. Ich weiß jetzt aber nicht genau, worin der Unterschied zwischen EFI und UEFI liegt. Könnte das jemand mal kurz erläutern?

Wikipedia sagt: UEFI ist Nachfolger von EFI (u = unified / vereinheitlicht). EFI hat wohl nur mit Intel funktioniert, UEFI funktioniert mit mehr (AMD ist da auch Teil des Konsortiums).

Windows Vista / 7 x64 konnte man auch schon unter UEFI installieren! Es geht denoch nebenbei Linux zu installieren! Schwieriger wirds (Unmöglich) ein anderes (älteres) Windows zu installieren!

siehe heise.de: http://www.heise.de/ct/meldung/Abschied-vom-PC-BIOS-1254437.html

Linux ist der einzige Kernel, der alle Biose, Partitionstabellen usw. und alle Permutationen davon unterstützt. PC-Bios ist schrott und der einzige Grund warum es so populär ist, ist Windows. PC-Bios in Rente zu schicken ist vielleicht der netteste Zug, den Microsoft je gemacht hat. Wir sollten uns bedanken.

adun schrieb:

Linux ist der einzige Kernel, der alle Biose, Partitionstabellen usw. und alle Permutationen davon unterstützt. PC-Bios ist schrott und der einzige Grund warum es so populär ist, ist Windows. PC-Bios in Rente zu schicken ist vielleicht der netteste Zug, den Microsoft je gemacht hat. Wir sollten uns bedanken.

+1!

PC-BIOS ist uralt und wird seit Jahren mit Krücken am Laufen gehalten und ist einer der Gründe für die vielen Limits die es heute immer wieder gibt und zwischenzeitlich gab. Das trifft insbesondere z.B. immer wieder die Addressierbarkeit von Festplatten bestimmter Größe. Einst waren > 6 GB für BIOS ein Problem heute sind es > 2 TB.

(U)EFI kann für Linux die Situation nur verbessern, weil damit Ende mit Betriebssystem-spezifischen Treibern ist. Das OS kommuniziert über (U)EFI mit der Firmware der jeweiligen Hardware.

Damit wird viel auffälliger werden, dass die Hardwarehersteller schlampig arbeiten und es weit weniger oft am OS liegt als heute häufig angenommen.

Gruß, Martin

(U)EFI kann für Linux die Situation nur verbessern, weil damit Ende mit Betriebssystem-spezifischen Treibern ist. Das OS kommuniziert über (U)EFI mit der Firmware der jeweiligen Hardware.

Heist das im Klartext, dass nur noch über das Bios mit der Hardware kommuniziert wird? Das würde ja bedeuten, dass es nie wieder Treiberprobleme mit Linux geben würde. - Geil 😀

-schumi- schrieb:

(U)EFI kann für Linux die Situation nur verbessern, weil damit Ende mit Betriebssystem-spezifischen Treibern ist. Das OS kommuniziert über (U)EFI mit der Firmware der jeweiligen Hardware.

Heist das im Klartext, dass nur noch über das Bios mit der Hardware kommuniziert wird? Das würde ja bedeuten, dass es nie wieder Treiberprobleme mit Linux geben würde. - Geil 😀

Ne, nicht über das BIOS sondern über (U)EFI, dass an die stelle des PC-BIOS tritt, wird mit der Hardware kommuniziert. Zumindest eröffnet EFI diese Möglichkeit. Inwieweit das umgesetzt wird, bleibt abzuwarten, aber eigentlich wäre es für alle Beteiligten ein Vorteil.

Und Hardware-Probleme wird es natürlich auch weiterhin geben, dann eben mit schlechter Firmware, anstatt schlechten Treibern.

Gruß, Martin

-schumi- schrieb:

(U)EFI kann für Linux die Situation nur verbessern, weil damit Ende mit Betriebssystem-spezifischen Treibern ist. Das OS kommuniziert über (U)EFI mit der Firmware der jeweiligen Hardware.

Heist das im Klartext, dass nur noch über das Bios mit der Hardware kommuniziert wird? Das würde ja bedeuten, dass es nie wieder Treiberprobleme mit Linux geben würde. - Geil 😀

Könnte stark von Vorteil sein, da Treiber jetzt im EFI-Byte-Code geschrieben werden können und diese vom OS unabhängig sind. Inwieweit das realisiert wird, ist eine andere Frage. Ich befürchte eher, dass dies so nicht geschehen wird. Treiber werden weiter für Windows spezifiziert! Siehe DirectX ... das ist und bleibt MS! Eher sowas wie Minimale Treiber würden entstehen!

Heist das im Klartext, dass nur noch über das Bios mit der Hardware kommuniziert wird? Das würde ja bedeuten, dass es nie wieder Treiberprobleme mit Linux geben würde. - Geil 😀

Ne, nicht über das BIOS sondern über (U)EFI

Das meinte ich ja ^^

Newubunti schrieb:

(U)EFI kann für Linux die Situation nur verbessern, weil damit Ende mit Betriebssystem-spezifischen Treibern ist. Das OS kommuniziert über (U)EFI mit der Firmware der jeweiligen Hardware.

Du meinst Treiber als EFI-Bytecode? Möglich ist das zwar, aber tatsächlich benutzen will das eigentlich niemand, wenn das OS dann mal geladen ist. Ein betriebssystemspezifischer Treiber ist eigentlich immer vorzuziehen, wenn er vorhanden ist. Sun hat es ja tatsächlich mal fertig gebracht, einen Treiber für den Framebuffer einer Sparc-Workstation in diesem Forth-Dialekt für OpenFirmware zu schreiben und als Bytecode (FCode) auszuliefern. Das war natürlich stinklangsam. Immerhin gab es diese Möglichkeiten auf anderen Plattformen schon vor 10 Jahren. Auf x86 müssen wir uns bis heute mit den Altlasten schon damals kaputter Prozessoren samt Drumherum herumschlagen. Hoffentlich hat das bald ein Ende.