A FreeBSD hacker szerint a FreeBSD kernel lényegesen gyorsabban bootol mint a Linux kernel

FreeBSD

Colin Percival - aki mostanában rengeteg időt ölt a FreeBSD boot idejének csökkentésébe - szerint, a FreeBSD kernel mostanra gyorsabban bootol mint a Linux kernel.

A FreeBSD kernel a BSD-licenc 115200 baudos soros portra történő kiküldéséhez szükséges idő kevesebb mint 1/4-e alatt tud elindulni. A Linux kernel a GPL-licenc 115200 baudos soros portra történő kiküldéséhez szükséges idő kevesebb mint 1/4-e alatt indul el, de ez közel sem olyan lenyűgöző.

A hacker arra céloz, hogy a BSDL lényegesen rövidebb szöveg, mint a GPL. A tipikus 3 kikötéses BSD licenc 220 szóból / 1 454 karakterből áll, míg a Linux kernelre vonatkozó GPLv2 licenc 2971 szóból / 17 509 karakterből áll.

Kirk McKusick UNIX veterán szerint a FreeBSD kernel jelenleg rövidebb idő alatt tud elindulni, mint amennyi időbe telt egy merevlemez seek-elés az első BSD-t futtató rendszereken.

( kicca | 2023. 06. 03., szo – 11:00 )

Fontos dolgok ezek :)

Aztan kapnak egy HP szervert es megoregednek mire eljut boot folyamat odaig, hogy betoltson egy linuxot vagy freebsdt.

 

Nem vagyok biztos abban, hogy a DOS kernel gyorsabban bootol mint 19,496 millisecundum ...

trey @ gépház

Igen. Mert én nem a kernel mesterséges felállási idejét néztem, amit a fejlesztő méreget. Természetesen abban a Linux is gyors, amikor betölt a kernel alapkódja (vmlinuz-linux), az idő az a TÉNYLEGES bootidő, amikor detektálja az eszközöket, tölti a drivereket, az init indítgatja a service-eket. Tudom, hogy jó rajtam gúnyolódni, mert épp nem fogalmaztam a szájízetek szerinti pontossággal. De ha te szerinted gyorsabb, akkor mérjétek le. Én most azért nem fogok azonos gépre két rendszert is húzogatni, hogy nektek bizonyítsak. Kipróbáltam már, maradjuk abban, nem is egyszer, nem csak FreeBSD-t, hanem más BSD-variánsokat, és nem csak egyféle Linux disztrót. Onnan tudom, mert érdekel engem is a téma. Ennyi, nem kell sokat belegondolni. systemd-nél írtam is, hogy NEM szeretem, de ezt az előnyét mindenképp találtam, ami elvitathatatlan, ha valakinek ilyen szempontok fontosak. Tudom, hogy nem mindenkinek, mert sokan a hosszú uptime-ra gyúrnak, mindig hibernálnak, stb., így a bootidő nem érdekli őket. Nem hibáztatok senkit, mindenkinek más a fontos.

Nem győzöm hangsúlyozni, hogy a tényleges bootidőről van szó, nem ilyen mesterséges, szintetikus tesztekkel, tool-lal (pl. systemd-analyze) mért marketingszámok érdekelnek, hanem, hogy a gép mennyi idő után használható ténylegesen. A BIOS/UEFI töltődését nem mérjük bele, sok embernek már ez is magas, mert arról nem az OS meg a hardver tehet, hogy melyik firmware milyen műveleten mit tököl még a bootloader, kernel indulása előtt, az gyártófüggő (meg néha annak is a függvénye, hogy hány meghajtó van a gépben, azokon milyen partíciókat, bootloadereket kell detektálni, stb.), és nem a teljesítményen múlik.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Raynes, arról szól ez a hír, hogy a FreeBSD kernel fejlesztő szerint, már gyorsabb a FreeBSD kernel bootja, mint a linux kernelé. Ez a hír, lényegtelen, hogy amúgy a gyakorlatban ennek mi a jelentősége.

Te azzal nyitottál, hogy amit a kernel fejlesztő állít az nem igaz, mert a linux disztrók gyorsabban bootolnak mint a FreeBSD, vagy bármelyik BSD. Szimplán hülyeséget beszélsz. Nem azért meg amúgy nincs igazad, hanem mert a hír szempontjából lényegtelen, nem erről szól a történet.

Mitha azt mondaná valaki, hogy krumplit gyorsabban pucol, mint hagymát. Te meg kategórikusan kijelented, hogy ez nem igaz, mert a rántotta hamarabb kész van, mint a rakott krumpli. WTF

Igen, elismerem, hogy annyiból igazad van, hogy először félreértettem a hírt, figyelmetlenül olvasva. Először azt hittem, hogy az egész bootról van szó, közben meg csak a kernel részéről célzottan. Megmondom őszintén, hogy Linux esetén nem ismerem a számokat, systemd-analyze teljesen hülyeséget mutat, máshogy meg amúgy sem tudnám mérni, meg nekem az számít, amit írtam.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ebben én sem. A DOS-nál nehéz ezt mérni, mert nincsenek hozzá ilyen szintetikus eszközök, amik csak a kernel betöltődési idejét mérik. A legjobb, amit tudsz, hogy Shift-re ráfeküdve kihagyod az autoexec.bat, config.sys fájlokban lévő konfigot, akkor csak a kernel meg a shell indul (command.com), de ugyebár ez több, mint a kernel. Ennek az ideje jobb gépeken MS-DOS esetén elég röpke, de sose mértem, hogy hány ms, de érzésre jóval 1 mp-en belül van, PC-DOS, DR-DOS, FreeDOS esetén meg kéne mérni, nem emlékszem rá. DOS-nál az is hátrány, hogy BIOS hívásokkal operál, és így néha a BIOS-on is múlik, meg csak 1 magot használ (meg emiatt kevesebb cache-t), meg 16 bitnyi adatokat mozgat, kevesebb regiszterrel dolgozik valós módban, nincs hozzáfordítva speciális utasításkészletekhez (mivel kézileg van ASM-ben hardcode-olva sok része a kódjának).

Igazából a DOS-hoz is kellett némi tudás, hogy valójában gyorsan bootoljon. Pl. ne töltsön be felesleges dolgot, erre lehetett menüprofilokat létrehozni, meg voltak trükkös kapcsolók, pl. a HIMEM.SYS betöltődésénél a /TESTMEM:OFF kapcsoló, hogy ne kezdje el végigtesztelgetni a memóriát, mert az sok memóriánál (főleg ilyen 64+ megánál) azért szép idő volt, meg néhány device driver is szeretett lassúcska lenni, így pl. számított, hogy milyen CD és egérdriver-t használ az ember, milyen kapcsolókkal (hogy azonnal megtalálja a kért eszközt, ne kelljen neki több mindent végigdetektálni), néha ez több másodpercet is jelentett. Már pedig a DOS instabil cucc volt, sokat indítgattuk újra, számított.

Klasszik PC-ken még a BIOS beállításokkal is lehetett trükközni, hogy gyorsabb legyen a gép vagy az indulás. Floppy seek kikapcsolása, néha a RAM teszt beállításait is lehetett piszkálni, Boot from HDD first opció (hogy ne csihogtassa végig feleslegesen a lassabb meghajtókat), IDE eszközök kézi rögzítése (pontos head, cilinder, stb., az üres helyekre meg None-t rögzíteni, így nem kellett őket boot előtt detektálgatni), shadow ROM to RAM, memóriaidőzítések csökkentése, régebbi gépen a wait state csökkentése (ideálisan 0-ra), meggyőződni, hogy a cache be van-e kapcsolva, stb.. Aki rutinos volt, ezen is nyert egy csomót, akár több másodpercet is.

DOS-os workflow-nál szintén. Normik gépelgettek a command.com-ba, hogy d:, cd akármi, cd bla-bla, dir /p/w, cd, whatever. Ezzel szemben egy power user már akkor is valami commander klónt használt (nc, vc, dn), vagy valami hasonló hasznos segédprogramot (xtree, dosshell, stb.), egyedi menüt, amiből sokkal gyorsabban érte el a programokat, csinálta meg a fájlműveleteket. Ne feledjük, hogy a klasszik command.com-ban nem volt Tab-os kiegészítés, meg history-kezelés, 3rd party toolokkal (multikey, doskey, stb.) vagy shellekkel (4DOS) hozzá lehetett adni, de ez megint nem a normik szintje volt akkor sem már. Aliasok helyett lehetett rövid nevű BATCH fájlokkal is operálni, vagy a PATH változót úgy bűvölni, hogy mindent megtaláljon. Ezzel gyakran hatékonyságban verni lehetett a windowsos workflow-t is. Gyakran a segédprogramok is számítottak sebességügyileg, pl. egy qpeg, quick view, cubic player, mpxplay gyorsabban játszott le médiás tartalmakat, mint más megoldások.

DOS telepítését is lehetett gyorsítani. A hivatalos 3 floppy-t cserégetős, kétszer újraindítós módszerhez képest én mindig azt csináltam, hogy volt egy saját bootfloppy-m, amin már rajta volt a rendszer, meg hasznos segédprogramok, azt bootoltam be, és egy másik meghajtóról vagy partícióról egy előre elmentett, tömörített tiszta, de jól beállított rendszert tömörítettem ki a C:-re, amit előbb FORMAT C: /Q /S segítségével pillanatok alatt formáztam, így pikk-pakk megvolt az újratelepítés, 100-ad annyi idő alatt, mint a hivatalos MS-féle telepítővel, és még nem kellett elkezdeni a rendszert is konfigurálgatni, mert az is megvolt (fullos autoexec, config.sys, driverek, memmaker által gyártott optimalizációk, fullos DOS mappa, stb.), kulcsra kész volt a rendszer néhány másodperc alatt. Ritkán volt rá szükség, de néha jól jött.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( outwork | 2023. 06. 03., szo – 14:47 )

"A hacker arra céloz, hogy a BSDL lényegesen rövidebb szöveg, mint a GPL."
És itt van az első nagy tévedés: A BSDL 4 betű, míg a GPL csak 3. Szóval ez téves megállapítás!

( Nyosigomboc v | 2023. 06. 03., szo – 15:22 )

Random mikrokontroller mindkettore koroket ver. Nem csoda, mert a BSD tudasahoz kepest semmi nincs benne - a Linuxehoz kepest meg plane.

A strange game. The only winning move is not to play. How about a nice game of chess?

( Raynes v | 2023. 06. 03., szo – 18:37 )

Értem, hogy humorizál a faszi, de nincs igaza. Nekem pont ez az egyik bajom a BSD-kkel, így a FreeBSD-vel is, hogy azonos hardveren komótosabb, mint egy pehelysúlyú Linux. Nem olyan fájdalmasan lassú, mint a Slowaris és az Illumos-alapú megoldások, de azért nem egy sebességbajnok.  A boot, a fájlrendszer (még ha csak egyszerű UFS2-ről is van szó, nem komplex ZFS-ről), GPU gyorsítás, meg minden, mind lényegesen lassabb. Nem csoda egyébként, a Linuxon jóval több fejlesztő dolgozik, és sokkal nagyobb hangsúlyt fektetnek arra, hogy minden sebességügyileg is optimalizáltabb legyen. BSD-knél ezzel szemben megelégednek azzal, hogy fut. Bár azért FreeBSD-nél is voltak optimalizációk a bootidő gyorsítására, ZFS zstd röptömörítés gyorsítására, a bootsebességen szóban forgó fejlesztő dolgozott, alakul, de még mindig nagyon el vannak maradva.

A másik, hogy nem csak kerneltől, de initrendszertől is függ a bootidő. Nem szeretem a systemd-t, de el kell ismerni, hogy az bootol a legsebesebben, minden mást elsöpör ebben (már ha épp nem akad le nyomi job starting/stopping várakoztatásnál), talán sebességre az runit, OpenRC közelíti meg, ha be van állítva a párhuzamosítás, de nem érik utol.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Nincs igaza ja. Ha nem hiszed el, próbáld ki te is. Bebootolsz egy normálisabb, rendesen soványra szabott WM-es Arch vagy Debian alapú rendszert, aztán ugyanazt feltelepíted FreeBSD-vel. Bár az eltérés meg lesz egy fullos DE-s rendszeren is. Azonos gépen, mérd le az eltérést. Onnan, ahogy a BIOS/UEFI átadja a bootloadernek a vezérlést, egész odáig, hogy a grafikus desktop előtted van, nyilván a stoppert megállítod jelszóbegépelésnél, bejelentkezésnél. Esetleg ha csak a kernelrésze érdekel, akkor csak a grafikus loginig vagy hasonlóig méred. Fájlrendszert is mérheted, nem kell fio, meg hasonló szintetikus, dd-s, teszt, elég ha nagyobb fájlrendszerre fsck, tar-os tömörítés, tömeges find, vagy valami hasonló, egyszerűen méred, hogy mi hány mp. alatt fut le. OpenBSD még lassabb, NetBSD annál is. Nem is csoda, míg nem dolgozott rajta ez a Parcival, addig ezzel a részével tényleg kb. a kutya nem foglalkozott, ő volt az első, aki komolyabban is nekifeküdt ennek, hogy legalább valami be legyen hozva a lemaradásból, ne a végtelenségig nőjön a szakadék.

Mondom, én ebben nem hibáztatom a BSD-seket. Nincs annyi erőforrásuk rá egyszerűen, hogy még sebességre is optimalizáljanak az ínyenceknek. Meg cserében ez egyben előny is, nem unatkoznak annyira, meg a nagyvállalati tőke nem tolta bele ezeket a modern bloat hülyeségeket a BSD-kbe, nincs systemd, pulseaudio, pipewire, nem erőltetik a waylandet minden áron, meg a Snap, Flatpak, stb. formátumokat, immutable rendszert, és még lehetne sorolni. Tehát attól függ, hogy honnan nézzük. Meg pl. nagyon régi gépeken egy fullos mainstream DE-s corporate Linux lehet már be is áll, mint a szög, mert túl nagy falat, míg egy BSD ha kicsit lehet komótosabban nekiindulva, de akár még használhatóan fut is, mert kevesebb benne a bloat. Oda-vissza lehet érvelni.

Ugyanez licencnél. Nincs bajom az egyes BSD-s licencekkel, mert szabadok tényleg, mindent megengednek, ez cool, de a gyakorlatban a GPL és más copyleft licencek hasznosabbak, mert garantálják, hogy nyitva is marad a kód, senki nem zárja be egy fontos forkként, ellopva a közösség munkáját, hanem a hozzáadott kódokat, extra fejlesztéseket visszakapja a közösség azonos licencű nyílt kódként. Ez a valóságban jobban működik, részben ez is az oka, hogy a Linux életképesebb és elterjedtebb. Nem egyetlen ok persze, de egy jelentős részben erről is szó van. Ennek minden előnyével, meg hátrányával is, pl. a GPL-t sok nagy cég épp ezért nem szereti. Pl. a MS-ot is szerintem már csak rég az tartja vissza, hogy a Windows alatt is Linux kernel legyen (saját rc-vel, meg saját API-s GUI ökoszisztémával, zárt kódos alapon), de ugye a licenc miatt ezt nem tudja meglépni. A Sony is nem véletlen a FreeBSD-re alapozta a PS OS-ét, nem a Linux kernelre, be tudta zárni a kódot, Netflix szintén.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( Toth Lali | 2023. 06. 03., szo – 18:58 )

uptime: 586 days

Mi az a "boot"? ;)

( STP | 2023. 06. 03., szo – 19:52 )

Szerkesztve: 2023. 06. 03., szo – 19:52

.

( PDA_FAN | 2023. 06. 04., v – 17:07 )

Valaki elmagyarázná, hogy hol fontos ez a boot idő? Én legfeljebb fejlesztési, tesztelési feladatoknál gondolom, mert ugye produktív szervert nem indítgatunk újra nyakra-főre, desktopon meg nem mindegy?

valami cloud-os VM provider (AWS-t írják) volt a fejlesztés fókusza ( Firecracker: https://www.freebsd.org/status/report-2022-07-2022-09/firecracker/  ). Valószínűleg ezrével indítgatják naponta a gépeket. Az is lehet, hogy folyamatosan minden feladathoz friss kernelt használ, azaz egy gép naponta százszor bootol újra így.

Azért mert átlag kkv-ig lát csak el valaki, nem biztos h. van fogalma a giganagyoknál mi hogyan működik. Ok nélkül nem feccoltak volna bele ennyi erőforrást időt meg pénzt néhány száz msec lefaragásába, ha valójában 2havonta 1x látszana az eredménye.

Mindig érdekeltek az új technológiák! Most megtudtam, hogy egyes cloud-os VM providerek 115200 baudos soros porttal dolgoznak, nem úgy, mint a kiscserkész kkv-k.

Világos, A fejlesztés fókusza a BSD-t futtató rendszerek seek idejének porbatiprása. Bár egy UNIX veterán igazán tarthatná magát K&R elveihez, mert ennél a Windows is fürgébben és felhasználóbarátabb módon működik.

Ha linkelted, akkor el is kellett volna olvasni!

Firecracker is an open source "microVM" developed by Amazon Web Services; it is designed for the needs of "serverless" compute environments and has a particular focus on security and minimalism.

...

to speed up the FreeBSD boot process; due to its low overhead and minimal environment

Szóval pont annyi köze van a kkv-hez és az összes eddigi hozzászóláshoz, mint a Hókefélke és a két bögre.

Továbbra sem világos, hogy a VM-ek miért kkv-n futtatják a lájszensz soros portját? (Asszem, valamit félreértek. :()

 

Azért folyamatos VM újraindítgatás sem tűnik túl életszerűnek, hacsak nem pont a kernel fejlesztés a lényeg. Persze, ha egy adott feladathoz ez kell, akkor hajrá, csinálják, de sok helyen meg pont nem ez kell. Amúgy meg kifejleszthetnének gyorsindítást ilyen célra is, hogy már kapásból egy a bejelentkezés állapotáig befagyasztott rendszert ébresztenek fel ezres példányszámban, pláne VM alatt simán megoldható, hogy ugyanaz a hw látszódjon.

( Nyosigomboc v | 2023. 06. 04., v – 18:12 )

Szerkesztve: 2023. 06. 04., v – 18:13

Ha jol szamoltam (10 bittel, start+8 adat+1 stop, 0 paritas) a licencek atkuldesi ideinek negyede 32 es 380 ms, nekem innentol felesleges optimalizalni, a teljes boot ido nem a kernel betoltesen fog mulni.

A strange game. The only winning move is not to play. How about a nice game of chess?

( Celtic v | 2023. 06. 05., h – 09:32 )

Ez azért arra emlékeztet, mikor a népszerú magyar disztro fejlesztője azzal haknizott, hogy az övét lehet a leggyorsabban telepíteni.

http://www.micros~1
Rekurzió: lásd rekurzió.

( SPYFF v | 2023. 06. 05., h – 11:16 )

Szerkesztve: 2023. 06. 05., h – 11:19

PREEMPT_RT-s emberek nemrég rakták bele a háttérszálon futó konzol kiiratásokat linuxba. Aki épp nem debugolja a rendszert, mert feláll, annak bőven ráér ha majd utólag néz egy dmesg-et hogy zajlott a boot - nem fogja a kiiratás blokkolni a boot folyamatot.

Akinek érdekes a gyors boot idő mondjuk gyorsabb fejlesztési iterációért, érdemes követni a virtme-ng projektet (https://github.com/arighi/virtme-ng), van qemu-microvm és custom precompiled rust init (bash helyett) - így egy Linux VM kevesebb mint 1sec alatt feláll. És van még hová optimalizálni :-)