Letölthetővé vált Windows 11 ISO ARM64 eszközökhöz a Microsofttól

Avagy, Redmondban is egyre komolyabban veszik az ARM irányt:

[ Download Windows 11 Disk Image (ISO) for Arm-based PCs ]

Hozzászólások

Igen. M1 Mac alatt Parallels segítségével használtam először ARM Windowst, akkor még Windows 10-et (ehhez regisztrálni kellett a Microsoftnál, hogy megkapjam a preview példányt), aztán ez frissült 11-re (kérdés nélkül, mondhatni ez a preview program hátránya), viszont onnantól sírni kezdett, hogy nem felel meg a Win11 követelményeinek (akkor minek frissített rá? :D), aztán az újabb Parallels már emulálta (vagy átadta?) neki a TPM 2.0-t, és helyreállt a világ rendje. Jelenleg vmware Fusionnal fut, és nem rinyál, szóval valamit a vmware is csinál.

Remélem ez közelebb hozza a Linux-ot ARM-ra, mert ami ott megy évtizedek óta a boot loaderekkel az egy borzalom.

Nem a Linux az oka annak, hogy ARM platformon nincs szabványosított BIOS UEFI megfelelő. Habár Raspberry Pi-n a VideocoreOS pont ezt a szerepkört látja el. Arra van is Linux, windows, fooBSD, AROS, RiscOS meg minden. 

Idézet az XDA cikk végéről:

"Apart from that, the Ethernet port on your Raspberry Pi won't work due to driver issues. The same holds for the GPIO pins, PWM fan controller, and the PCIe express connector. You're also likely to encounter performance hiccups on the low-powered SBC. So, if you want a fast and stable operating system for your Raspberry Pi, you should stick to Ubuntu, DietPi, or Raspberry Pi OS instead."

Ereje lenne hozzá, szándéka viszont szerintem nem. Ha tehetné addig csavarná a gyártókat, hogy végül semmi más ne induljon el ARM-en mint a Windows. 

Akinek ez megérné szerintem az Nvidia. Egyszer már fel akarták vásárolni az ARM Holdingot, amit nem engedtek meg neki. A Broadcomm felvásárlásával viszont az Nvidia tulajdonába kerülne a "pc-sített" ARM platform, aminek ma nincs nagy jelentősége azon túl, hogy RPi lapkákon úgy lehet eljátszani különböző operációs rendszerekkel mint egy PC-n. Ami ehhez kell, az a Videocore gpu és a hozzá fejlesztett VCOS, azaz VideocoreOS. Mindkető Broadcom tulajdon. Tehát ebben nem kellene osztozkodnia. Második GPU-ként hozzá tudná adni saját AI király és 3D-ben is csúcson levő GeForceait, ami tökéletesen kiegészíti a nagyon alacsony fogyasztású, de videolejátszáson kívül jelentős gpu teljesítménnyel nem bíró Videocore gput. 

Most az Nvidia értékében megelőzi a Microsoftot is, lenne pénzük. 

Nem akarnék az UEFI kapcsán hosszasan sikongatni a rémülettől boldogságtól, de az azért elgondolkodtat, hogy a nagy tervekkel induló projekt vajon minek hatására jutott el oda, hogy ha default beállításokkal indítok egy modern X64 oprendszer telepítőt, többszáz megás FAT(!) partíciót gyárt, rajta néhány megás betöltővel. Még egyszer mondom: FAT! Mindez a biztonság és a megbízhatóság jegyében, ofkórsz. Hogy a Mikroszoftban megvolt a jóakarat egy tényleg modern megoldásra, azt egy percig sem kétlem :-)

Nem kell nagyon csodálkozni.

Ugyanaz a "díszes társaság", akinek először a PnP-t, majd az ACPI-t "köszönhetjük". Előbbivel még nem is volt annyira sok gond, de hogy öt évig senki nem tudott egy épkézláb ACPI implementációt csinálni... az UEFI-vel meg mégjobban túltolták.

vajon minek hatására jutott el oda [...] Még egyszer mondom: FAT!

Erre konkrétan tudok válaszolni, mert azokkal az emberekkel dolgoztam, akik (korábban) eldöntötték. Az alábbiakat emlékezetből írom, úgyhogy elnézést az esetleges pontatlanságokért.

Amikor valamelyik kezdeti UEFI (talán még csak EFI) specifikáción dolgoztak, akkor kellett egy filesystem. A résztvevők közül senki sem akart teljesen új fs-t tervezni és implementálni. A Microsoft felajánlotta a FAT-et. Senki sem erősködött (sem a csoporton belül, sem azon kívül), hogy (pl.) ext2 legyen, a munkacsoport pedig örömmel elfogadta a felajánlást.

A felajánlás a Microsoft részéről azt jelentette, hogy nyilvánosságra hoztak egy FAT specifikációt, amely a felhasználási feltételeiben kikötötte, hogy csak UEFI driver írására lehet felhasználni. Az edk2-ben (= EFI Development Kit II; UEFI referencia implementációban) eredetileg nem is volt FAT driver -- egy külön repo-ban volt egy speciális "3-BSDL + additional terms" FAT driver, amely ennek a Microsoft specifikációnak az alapján készült, és így a kódot a Microsoft spec. feltételei kötötték.

(Itt azt kell észben tartani, hogy a UEFI munkacsoport számára a UEFI egy ABI, nem pedig API spec; tehát a munkacsoport elsődleges célja az volt (és ma is az), hogy olyan szoftverfejlesztők moduljai tudjanak szépen együttműködni, akik kizárólag zárt forrással dolgoznak.)

Ez volt az oka annak, hogy Fedora-ba és RHEL-be 2016 előtt nem kerülhetett bele az OVMF (az edk2-ben lévő Open Virtual Machine Firmware platform) csomag (amely arra jó, hogy QEMU/KVM virtuális gépeket ne legacy BIOS-sal (SeaBIOS) indíts, hanem UEFI-vel (OVMF)). Ugyanis a FatPkg fent körülírt licence -- az OVMF-be foglalt modulok közül egyedüliként -- korlátozta a felhasználási területet, így nem adta meg a nulladik szoftverrel kapcsolatos felhasználási jogot ("tetszőleges felhasználás"). Például a FAT driver-t nem lehetett volna arra használni, hogy annak alapján egy teljesen független OS-hez FAT driver-t írj. Konkrétabban: ütközött a Fedora csomagolási feltételeivel. Egy ideig ezért az OVMF csak a RHEL (6 vagy 7, már nem emlékszem pontosan, régen volt) "Supplementary Channel"-ben volt elérhető, amely nem volt támogatott, viszont nem csak open source csomagok lehettek benne.

Aztán az Intel leült tárgyalni a Microsoft-tal, és szívós munkával 2016 tavaszára meggyőzték őket, hogy konkrétan a FatPkg-t oldozzák fel a kötöttségek alól. A FatPkg-t április elején beolvasztották a külső repóból az edk2-be, BSD licenc alatt. Azóta van minden Linux disztróban OVMF. Mi anno éveket vártunk erre a Red Hat-nél (én 2011 novemberében kezdtem OVMF-fel foglalkozni), és amikor megtörtént, virtuálisan pezsgőt bontottunk.

Azt persze megtehettük volna, hogy az OVMF-et úgy fordítjuk, hogy nem tesszük bele a FAT drivert. Ezzel az volt a baj, hogy egy ilyen firmware bináris nem felelt volna meg a UEFI spec-nek (attól függetlenül, hogy valami más filesystem-hez egy szabad driver-t esetleg bele tudtunk volna-e tenni -- ha utóbbi létezett volna, vagy megírtuk volna). Ugyanis maga a spec követeli meg a FAT-et (más file-rendszereket lehet támogatni, és azóta már létezik pl. ext2 és UDF driver is, de a FAT muszáj).

A korlátozott felhasználású driver-t itt találod:

https://github.com/tianocore/edk2-FatPkg/tree/278d45c7f6c05cc3443126964…

A mai napig olvasható a licencben, a 3-BSDL után:

Additional terms: In addition to the forgoing, redistribution and use
of the code is conditioned upon the FAT 32 File System Driver and all
derivative works thereof being used for and designed only to read
and/or write to a file system that is directly managed by Intel's 
Extensible Firmware Initiative (EFI) Specification v. 1.0 and later 
and/or the Unified Extensible Firmware Interface (UEFI) Forum's UEFI 
Specifications v.2.0 and later (together the "UEFI Specifications"); 
only as necessary to emulate an implementation of the UEFI Specifications; 
and to create firmware, applications, utilities and/or drivers.

Ezzel összehasonlítva, az edk2-be már így került be (2-BSDL):

https://github.com/tianocore/edk2/commit/b9ec93308b33#diff-dbcde8440cd4…

diff --git a/FatPkg/License.txt b/FatPkg/License.txt
new file mode 100644
index 000000000000..2740e4dcacd1
--- /dev/null
+++ b/FatPkg/License.txt
@@ -0,0 +1,11 @@
+Copyright (c) 2006, Intel Corporation
+All rights reserved.
+
+This program and the accompanying materials are licensed and made available
+under the terms and conditions of the BSD License which accompanies this
+distribution. The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+

 

Szósz: ld. "Acked-by: Laszlo Ersek" a commit message végén.

Remélem ez közelebb hozza a Linux-ot ARM-ra, mert ami ott megy évtizedek óta a boot loaderekkel az egy borzalom.

Attól függ, mit értesz ARM alatt. ARM64 szerverek 2014-2015 óta UEFI-jal indulnak. Az érintett ARM spec eredeti nevére nem emlékszem, ma már úgy hívják, hogy "Arm SystemReady SR" (SR = ServerReady). A követelmények között szerepel az SBBR (Server Base Boot Requirements), amely pedig megköveteli a UEFI-t és az ACPI-t. (ARM-on máshogy nincs is ACPI definiálva csak UEFI-on keresztül; legalábbis amikor legutóbb ezzel foglalkoztam, akkor még úgy volt.)

https://developer.arm.com/Architectures/Arm%20SystemReady%20SR

https://uefi.org/sites/default/files/resources/TPE-C6_Dong%20Wei_Server… (PDF prezi)

A baj inkább az (volt?), hogy nagyon sokáig nem volt otthonra is megfizethető, megbízható, "készre csinált" ARM64 alapú laptop vagy desktop *hardver* (főleg úgy, hogy UEFI lett volna rajta). Kizárólag a szerverekre és a vállalati felhasználásra fókuszáltak eredetileg a UEFI vonatkozásában. (Még a Linaro-nál is úgy hívták az érintett csoportot, hogy LEG: Linaro Enterprise Group.) Nálam volt egy ideig rack-be való APM Mustang; jól lehetett rajta fejleszteni, de a hűtése borzasztó hangos volt; minden tekintetben kísérleti hardver volt.

Már várom a gagyi Aliexpresszes handheld Windows 11 -es "ultra mini notebook" -okat.

Pocsék vason bloat oprendszer, garantált siker. :-)

Forgathato kormany, nyithato ajtok. :)

u-boot?

hunludvig-nak válasz (valamiért nem engedi a válasz gombbal)

es akkor vajon lesz bootcamp M-procis mac-ekre is?