- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Vajon a KMS_VL ezt is aktiválja?
:-D
- A hozzászóláshoz be kell jelentkezni
TPM ehhez is kell? :D
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Remélem ez közelebb hozza a Linux-ot ARM-ra, mert ami ott megy évtizedek óta a boot loaderekkel az egy borzalom.
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
Nem a Linux az oka az egységes boot loader hiányának, de a Microsoftnak talán van elég ereje előre mozdítani a dolgot.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Az Nvidia SOM-ok egy ideje már UEFI-t használnak. Sajnos.
- A hozzászóláshoz be kell jelentkezni
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 :-)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
qemu/kvm virtualis gepnel, ahol nincs korlat pl. a particiok szamaban, mereteben, ott milyen elonye van az ovmf-nek? pl. gyorsabban fog indulni?
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
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.)
- A hozzászóláshoz be kell jelentkezni
jo, akkor nem rohanok lecserelni a mostaniakat.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Köszönöm a felvilágosítást és az izgalmas részleteket!
- A hozzászóláshoz be kell jelentkezni
Már várom a gagyi Aliexpresszes handheld Windows 11 -es "ultra mini notebook" -okat.
Pocsék vason bloat oprendszer, garantált siker. :-)
- A hozzászóláshoz be kell jelentkezni
Forgathato kormany, nyithato ajtok. :)
- A hozzászóláshoz be kell jelentkezni
u-boot?
hunludvig-nak válasz (valamiért nem engedi a válasz gombbal)
- A hozzászóláshoz be kell jelentkezni
es akkor vajon lesz bootcamp M-procis mac-ekre is?
- A hozzászóláshoz be kell jelentkezni
En nem orulnek neki. A hianya felporgette a virtualizacios versenyt (uj termek: UTM), meg a wine wrappereket (whisky).
- A hozzászóláshoz be kell jelentkezni
Az elavult verzios qemu jelenti a versenyt? :D
- A hozzászóláshoz be kell jelentkezni
Elavult verzios is marad, ha visszajon a bootcamp.
- A hozzászóláshoz be kell jelentkezni
Ha az elmult 3-4 evben 1x sikerult qemu foverziot lepni es meg igy is tobb foverzioval van lemaradva, akkor kb nem szamit semmit.
- A hozzászóláshoz be kell jelentkezni
Szilikon Macre natívan telepíthető?
- A hozzászóláshoz be kell jelentkezni
Remelem nem. Es remelem ez jo sokaig igy is marad, hogy fejlodjon a tobb egymassal versenyzo VM, a wine es a whisky.
- A hozzászóláshoz be kell jelentkezni