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.

Ld. http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt, "Motivation" fejezet mindjárt az elején.

(Azóta a Secure Boot támogatás is "production level" q35 machine type-on, bekapcsolt SMM emulációval. A cikk majdnem 10 éves már; azóta nagyon sok minden történt.)

Azért FAT az EFI partíció, mert a FAT egy jól dokumentált, nyílt fájlrendszer, nem kell a működtetéséhez komplex kód (szemben egy ext4-gyel vagy ZFS-sel), mindenféle eszköz támogatja. Ne feledd, hogy ez nem komplett OS alá kell, csak egy bootloader alá, és ott is csak annyi erejéig, hogy egy pár megás fájlt indítson. Pont azért esett erre a választás, mert az egyik legprimitívebb, legegyszerűbb fájlrendszer, ami közös nevező.

Egyébként meg nehogy azt hidd, hogy 100-200 megás FAT partíció overkill. Ha Windowst használsz csak, annak tűnhet, de ha multibootot, meg pl. Linuxot, ami tárolhat rajta több kernelverziót is, ott már vészesen tud fogyni a hely. A biztonság sem szempont, mert azt a Secure boot, meg aláírás garantálja, nem a FAT.

Másrészt meg a hagyományos BIOS boot még szarabb volt, eleve csak MBR partíciós táblát használhattál, ahol 4 elsődleges partícióra volták szorítva, ha ez nem volt elég, lehetett kiterjesztett, logikai partíciókkal zsonglőrködni, meg bootflag-ekkel szórakozni, és ha multibootot akartál, akkor az OS-ek egymás alatt átírták az MBR-ben az indítókódokat.

Egyébként az senki nem írja ám elő, hogy több száz megásnak kell lennie a FAT partíciónak. A szabványban nincs megszorítás, lehet EFI partíció akár egy FAT12-es floppy is, nem viccelek. Ez csak a modern OS-ek gyakorlata, hogy kicsit biztonsági tartalékot hagynak rá, hogy nehogy azért lehetetlenüljön el a rendszer működése, mert az EFI partíción elfogyott a hely, mert valaki spúr barom képes volt 100 megán spórolni a mai terabájtos olcsó tárolók korában. A másik oka a FAT32-nek, hogy a FAT12, FAT16-on a hosszú fájlnevek nem lennének támogatva.

The world runs on Excel spreadsheets. (Dylan Beattie)

Főleg h. idei baki a mikroszoftnál h. a windows 10 / 11 recovery particiót is túl kicsire vették (talán 256 MB volt eddig) és egy update nem tudott feltelepülni, mert egyszerűen nincs annyi szabad hely ezeken a particiókon gyárilag. Shrinkelni kellett a diszken a nagy particiót annyival, h. ki lehessen tágítani a recovery particiót 512 megásra.

Annyi mentségükre legyen írva, hogy meg volt kötve a kezük, mikor bevezették az EFI partíció használatát a Vista/Win7 időszakában, az emberek már akkor lázadtak, hogy minek, jajj, elveszik 100 mega, az a világ vége. Ennek tükrében nem nagyon merték emelgetni, csak a legminimálisabb mértékben.

Nálam 500 MiB az EFI, és van rajta egy Win10 indító, és 3 darab Arch kernel (6.6.x LTS, 6.10.3 egyedi Arch fórumos build, 6.11.9, initramfs-estől, AMD microcode csomag, sedutil-cli NVMe titkosításfeloldó bináris, ezzel már nyakára is léptünk 240 megának, és még ez egy soványabb rendszer manapság, ha valaki nagyon halmozza a multiboot élvezeteket, vagy sok kernelt hagy fent, simán 500 mega környékén kiköthet, főleg, ha GRUB meg egy csomó minden ott van még ezen a partíción. Ezért nem éri meg rajta spórolni, lassan már ott fogunk tartani, hogy 1 gigát se nagy pazarlás ráhagyni.

Nekem már kb. majdnem 20 éve minden gépemben van 500 giga tárhely, 9 éve kb. mindegyikben 1 tera (és ezek már mind SSD-k voltak), kb. 5 éve mindegyikben több, mint egy tera, a mostaniban 2,5 TB, most ki a rákfenének az élete múlik +/- 200-300 megán. Akinek annyi hiányzik, azon múlik az élete, annak úgyis bővíteni kell, nem az utolsó kenyérmorzsákon kihúzni. Ma már egy Windows vagy Linux rolling update sok giga, böngésző sok gigákat cache-el a háttértáron, egy játék simán 100-200 giga, egy HD film 20-50-100, egy flatpak akár 100-200 mega, nehogy már akkor ilyen 0,1-1,5 gigán múljon az élet.

The world runs on Excel spreadsheets. (Dylan Beattie)

vm-en torlom a recovery particiot, mert ha novelem a disket, windows partition managerben nem tudtam megcsinalni, hogy a vegere mozgassam a recovery particiot, es megnoveljem a windows particiot. szeretnem, ha ezt a disk managerben meg tudjam csinalni, neha jol jonne.

neked aztan fura humorod van...

ezt mar irtad maskor is, debiannal nem az efi particion van a kernel, initramfs, hanem a /boot-on. az efi a /boot/efi es csak shimx64.efi, grubx64.efi, stb van rajta, ami osszesen 6MB. mi a celja annak, hogy az arch az efi-n tarolja a kernelt, initramfs-t?

neked aztan fura humorod van...

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?

Szilikon Macre natívan telepíthető?