Megjelent a Rust a Windows kernelben is

Microsoft, Windows

A mérföldkőről Mark Russinovich, a Microsoft CTO-ja számolt be. Azok találkozhatnak vele, akik Windows 11 Insider build-et futtatnak.

( bennyh | 2023. 05. 19., p – 10:09 )

Szerkesztve: 2023. 05. 19., p – 10:14

Nálam is ott vannak az otthoni gébemen a system32 alatt, eddig semmi különöset nem vettem észre.

Microsoft Windows [Version 10.0.25357.1]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\System32>dir win32k*
 Volume in drive C has no label.
 Volume Serial Number is **********

 Directory of C:\Windows\System32

2023. 04. 29.  08:29           708 608 win32k.sys
2023. 04. 29.  08:28         3 420 160 win32kbase.sys
2023. 04. 29.  08:28           110 592 win32kbase_rs.sys
2023. 04. 29.  08:29         4 194 304 win32kfull.sys
2023. 04. 29.  08:28            40 960 win32kfull_rs.sys
2023. 04. 29.  08:28            69 632 win32kns.sys
2023. 04. 29.  08:28            98 304 win32ksgd.sys
               7 File(s)      8 642 560 bytes
               0 Dir(s)  507 363 418 112 bytes free

C:\Windows\System32>

Munkahelyin is lefuttattam, ott még valóban nincs ez a két állomány.

De miért lenne változás? Hol akartál változást látni?
   - funkcionalizásban?
   - sebességben?
Amit várunk, kevesebb biztonsági foltozgatás ezeknél a részeknél, mivel a memory vulnerability-jellegűek és még néhány alacsony szintű sérülékenység eltűnik a mindennapjainkból.

Más "fémes íz" mi lenne?

C-vel összevetve:

Lassulás: átlagosan 10% erőforrás többletet jelent a korrektség, minden lehetséges kritikus pont ellenőrzése és néhány egyéb dolog.
Gyorsulás: implementáláskor az algoritmusra jobban lehet figyelni, nem viszik el a fókuszt a low level dolgok. Tehát jobban "kiegyenesített" algoritmusok várhatóak.
További többszörösére gyorsulás lehetősége: könnyebb korrekt többszálú programot írni, több lesz a több magot normálisabban használni tudó szoftver. A CPU-k magszáma az elmúlt 10 évben növekedett. C-ben a korrekt sokszálú programozás sokkal macerásabb.

A kernelben biztos, hogy van C++? Nem hiszem, hogy a kernel módú lib loader támogatja pl. a polimorfizmust (virtuális metódusok), 2000/XP-ben legalábbis még biztos nem működött. Az, hogy egy struct-ba beleírsz egy függvényt, esetleg struct helyett classt használsz, az még elment.

Az a wiki cikk "időtlen", az az NT en-bloc; lejjebb ott vannak a verziók is, a legvégén a 11-essel. A citált idézeted pedig pont ezt feszegeti: ha a C-t többnyire kernelkódban használják, a C++-t meg többnyire userspace kódban, akkor az azt jelenti, hogy a kernelkód is tartalmaz valamennyi C++-t és az userspace programok egy része is tartalmaz C-t. (Gondolom a még régebben megírt, de még mindig használt CLI programokat anno még C-ben írták meg.)

Oldschool Computer - http://oscomp.hu

De amiből a C/C++ info jön, az egy technet cikkből van 2010-ből.

Egyébként keresgéltem, mennyire használható a C++ a kernelben. Nincs exception kezelés, STL helyett talán van valami helyettesítő. New-delete szintén nincs (nyilván a kernel allokátort kell használni). Meg még néhány nyelvi elem hiányzik, amúgy valóban használhatja, aki szeretné.

Szerk. Ja, hogy ez a Windows kernel. Azt hittem, hogy a WSL-ben futó Linux kernelről van szó. Így már értem. A Windowsban úgyse a kernel volt rossz eddig se, hanem a sok bloat, és felesleges sallang, azaz maga a koncepció, ökoszisztéma.

Szerk. 2. Egy előnyét mégis csak látok. Elkezdenek bizonyos kódrészeket Rust-ban átírni, ezzel frissül, modernebb lesz a kódbázis. A MS-nál ugyanis elég lusták, sok minden kód még az NT4-XP meg a Vista-Win7-es időkből ragadt vissza, és használják, amíg lehet, lusták hozzányúlni. Ha a Rust fanboy-ok ezt most megbolygatják, akkor áttehetik a kernelt kicsit modernebb alapra, hátha optimálisabb lesz a kód, amiatt is gyorsulhat, nem csak a Rust-ban írástól önmagában.

Esetleg amihez jobban hozzányúlhatnának, az az NTFS kernelszintű kezelése, baromi lassú az a fájlrendszer, a linuxosok állva hagyják. Esetleg a rust-osok írhatnának valami normális új, modern MS fájlrendszert, nem az ReFS-re gondolok, meg nem FAT-klónra, hanem valami teljesen újra, ami újra van írva, gondolva, modern feature-ök, deduplikáció, CoW, esetleg még a 128 bites támogatás is beleférne. Csak hogy haladjunk a korral, meg sebességben legyen előrelépés.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

De miért lenne változás? Hol akartál változást látni?

Pont az a lényeg, hogy sehol. Itt az a jó hír, ha nincs hír. 

Csak a "first taste of Rust" fordulat és az első hozzászólás látszólagos ellentmondására reagáltam. Ha úgy tetszik belegondoltam, mekkora feladat lehet majd egy marketingesnek azt hírként eladni, hogy nem fog történni semmi.

Science for fun...

Jött új Insider, odalettek az _rs végződéske... Ez mit jelenthet?

Microsoft Windows [Version 10.0.25370.1]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\System32>dir win32k*
 Volume in drive C has no label.
 Volume Serial Number is ********

 Directory of C:\Windows\System32

2023. 05. 17.  01:57           704 512 win32k.sys
2023. 05. 17.  01:57         3 375 104 win32kbase.sys
2023. 05. 17.  01:57         4 153 344 win32kfull.sys
2023. 05. 17.  01:57            69 632 win32kns.sys
2023. 05. 17.  01:57            98 304 win32ksgd.sys
               5 File(s)      8 400 896 bytes
               0 Dir(s)  496 766 328 832 bytes free

A fájlnév önmagában nem sok mindent árul szerintem el. Én inkább a tartalmában kutatnék. Kérdés, hogy van-e valami jellegzetesség?
Esetleg lehet az alábbival szerencséd a lefordított binárisban:

$ strings <fájlnév> | grep -i rust

Viszont ha #![no_std] módon íródott az adott kód, akkor valószínűleg nem lesz benne a fentire illeszkedő szó a belőle fordított binárisban.
Ha valaki veszi a fáradságot, kíváncsi vagyok hogy lesz-e találata? Elsőre a témanyitóban látható 110 kB-ost lenne jó megnézni.

Ha nem kutyaütők írják újra a közvetlenül támadás lehetőségének kitett részeket, nagy baj csak nem lesz belőle. Azért az NT egy elég rugalmas rendszernek lett tervezve. Mostanában néztem, hogy nem csak Wine (és Linux) alatt van BTRFS, valakiknek spéci bootloaderrel + a windows-os BTRFS driverrel sikerült rendes Windows-t (Windows 10) is indítani BTRFS-ről. (Kár, hogy a Microsoft ezt sem karolja fel... vagy inkább jobb is :D ... )

Ez nem valószínű. Sajnos a hg2ecz-hez hasonló profi Rust-osok - akik haszonnal forgatják ezt a nyelvet és csak ott forszíroznák a nyelvcserét, ahol a Rust a legoptimálisabb a választás - abszolút kisebbségben vannak, a többség csak vérhabot fröcsögve követeli a C azonnali betiltását; a sudo-s topicban kristálytisztán látszottak az arányok: volt hg2ecz, aki értette, hogy miről beszélt és csak azt állította, hogy van, amire a Rust a legjobb választás (amiben igaza is van) és volt vagy egy tucatnyi falangista, akik szerint a Rust mindenben is jobb, mint a C, de ha megkapták, hogy Rust-szektások, akkor kikérték maguknak, hogy ők sose írtak egy sort se Rust-ban. Akkor honnan tudják, hogy jobb, mint a C?
Az ilyenek semmit nem fognak ésszel átírni Rust-ba; leginkább csak átkonvertáltatják valami lófos konverterrel, ami jó vastagon meghinti majd unsafe blokkokkal az egészet és ezzel értelmét veszti az egész Rust-ra való átírás...

Én azt remélem, hogy a Linux mégis megússza valahogy ezt az egészet, a winfos viszont tönkremegy bele. (De ha mindkettő kinyúvad, akkor sem fogok sírni; valamit valamiért, maradt még másik rendszer elég, amire válthatok...)

Oldschool Computer - http://oscomp.hu

Megjegyzem, elmúlt héten is írtam egy bináris adathalmazt dekódoló segédprogramot. Az ok_or() és a ? operátor, mint hibafelterjesztés volt az egyik nagy áldás.
Így működik: https://doc.rust-lang.org/reference/expressions/operator-expr.html#the-…

Enélkül a szépség nélkül nem csoda, hogy a C-ben írt Linux 6.3-as kernel nem kevesebb mint 190_000 darab, főként hibakezelésre kiugró goto-t tartalmaz (nézd meg magad, ha nem hiszed, grep a barátod). Nehézkes a C-ben a hibafelterjesztés is.

Ez neat kis feature, de felveti a kérdést, hogy mi történik, ha nem lehet csak úgy visszatérni a függvényből, mert hiba esetén még egyéb teendők is vannak, pl. felszabadítások, lezárások?

Én elhiszem, de és? Az exception is csak goto, csak el van rejtve. Ha nem tetszik, lehet minden hiba után nyomni egy if -> return-t is, csak akkor a felszabadítások, lezárások redundánsak lesznek; igaz cserébe nem kell előtte ellenőrizni, mert az már megtörtént még előtte.

Oldschool Computer - http://oscomp.hu

C-ben nincs ilyesmi, mert a C-nek ez nem is feladata, ott a maximum kontrollon van a hangsúly. Hagyjuk a C-t, mert nem az volt a kérdés, hogy C-ben mi van, vagy mi nincs, hanem, hogy a Rust hogy működik.
Honnan tudja, hogy valamit tényleg fel kell-e szabadítania? Egy globális változóban allokált memóriaszegmenst pl.? Mi van, ha azt a hiba ellenére sem kell felszabadítania, pedig lokálisan allokálták? Mi van, ha mindenképpen fel kell szabadítania, pedig globális? Hogy dönti ezt el a Rust az ember helyett?

Oldschool Computer - http://oscomp.hu

"C-nek ez nem is feladata" - És körbeértünk. Van a feladatod, amelyre a Rust kézreállóbb. Hát azt használod.

Felszabadítás: na ez külön megér pár gondolatot. Jól belekérdeztél érdekes dolgokba, de továbbgondolva mindegyik egyértelmű. Nézzük.

Lifetime (életciklus) - nagyon korrekt Rust-ban. Minden adatszerkezetről egyértelmű, hogy mely függvényben szabadítható fel és ott fog magától felszabadulni. Lásd még ownership témát. Ha a vektort szőrőstűl-bőröstűl átadod a függvénynek, akkor a meghívó programban már nem tudsz rá hivatkozni és a fordítás során a függvényben lesz a felszabadítás rész implementálva. Ez volt talán az első legnagyobb húzás a nyelv alkotójától. Ezzel a trükkel végre egyértelműen követhetővé vált a változó életciklusa és így az, hogy hol kell felszabadítani.

Lokális változót hiba esetén nem kell felszabadítania? - eleve értelmezhetetlen, például hogyan hivatkozol rá amikor a neve csak a lokális térben értelmezhető. Tehát ahogy vége a függvénynek, a lokális változók, továbbá aminek az életciklusa itt ér véget (lásd iménti példát), az fel fog szabadulni. Az erőforrások is a Drop trait szerint az összes utófeladat végrehajtásával együtt felszabadulnak. Tudsz esetleg ellenpéldát, ahol nem lenne jó és kell tartani bármi lokális változót?

Globális változó - több oka van, hogy unsafe { .. } környezetben tudod használni. Unsafe kulcsszót pedig csak indokolt esetben alkalmazz. A felelősség ugyebár unsafe kulcsszó mentén a programozóra van testálva. Tehát itt nem dönt a Rust az ember helyett. :)

És körbeértünk. Van a feladatod, amelyre a Rust kézreállóbb.

Automatikus erőforrás-felszabadításra? Ez nekem hol feladatom? Ha automatikus, akkor a nyelv/fordító feladata, nem? Ha meg az én feladatom, akkor meg manuális, nem?

Lokális változót hiba esetén nem kell felszabadítania? - eleve értelmezhetetlen, például hogyan hivatkozol rá amikor a neve csak a lokális térben értelmezhető. Tehát ahogy vége a függvénynek, a lokális változók, továbbá aminek az életciklusa itt ér véget (lásd iménti példát), az fel fog szabadulni. Az erőforrások is a Drop trait szerint az összes utófeladat végrehajtásával együtt felszabadulnak. Tudsz esetleg ellenpéldát, ahol nem lenne jó és kell tartani bármi lokális változót?

Nagyon félreértetted a dolgot. Én lokálisan allokált globális változóról beszéltem. Van egy interthread-buffered, amit néha reallokálsz. Tegyük fel, hogy ez volt az első kör és még allokálva sem volt. Az allokáció sikeres volt, viszont az adatbeolvasás megdöglött, mert a windóz egy szar és a megrendelt kazettán ?LOAD ERROR nevű programok találhatóak. Ilyenkor a globális buffert nem kell felszabadítani, hisz később még használva lesz, viszont allokálva lokálisan lett.
És akkor képzeljük el ugyanezt nem interthread bufferrel, hanem interprocessz shared memory-vel.

Globális változó - több oka van, hogy unsafe { .. } környezetben tudod használni. Unsafe kulcsszót pedig csak indokolt esetben alkalmazz. A felelősség ugyebár unsafe kulcsszó mentén a programozóra van testálva. Tehát itt nem dönt a Rust az ember helyett. :)

Mitől követelné meg egy globális változó alaphangon az unsafe blokkot? A processzbe beeső signalok sem szoktak sokkal többet csinálni, mint beállítani egy globális flag-et. Ez mitől unsafe?

Oldschool Computer - http://oscomp.hu

Sajnos a Linux sem az a community-based projekt már, mint húsz éve.
Ezen a síkon talán a FreeBSD lépett a helyébe. Ott szemlélet van és elvek; nincs mögötte akkora tőke, érdek és befolyás, mint a Linux mögött.
Mindennek a fonákja: meg lehet nézni szegényt, hol tart három évtized után.

Egyre bloatabb a rendszer, csak a pkgsrc-ben annyi bug volt már, hogy három teljes OS-re elég lenne és nem ritkák benne a súlyos sérülékenységek, amiket évekig nem javítanak... Nem csoda, ha fejlesztés helyett azzal vannak elfoglalva, hogy kinek az idézetei vannak a szerencsesüti programban... Tényleg biztos az a legfontosabb. :(

Oldschool Computer - http://oscomp.hu

  1. Ennyi idő alatt szerintem természetes, hogy növekszik a kód méret, gyanítom hogy minden más OS kódmérete növekedett ezen idő alatt. Csomó új driver, stb. Ezzel természetes hogy a fordítási idő is növekszik. Ami aggasztóbb az a NetBSD alatti csomagfordítás idejének növekedése (gabucino blog), ott már lenne mit optimalizálni gyanítom, bár nem mentem utána a dolognak, mi volt a háttérben, megoldódott-e azóta.
  2. Pkgsrc project érdekes. Szerintem hatalmas nagy potenciál lenne benne, de nem kapta fel nagyon senki, minden OS saját csomag repót tart fent, igazából csak a NetBSD-n és a SmartOS-on alapértelmezett. Linux-ra meg macOS-ra van még érdemi felhasználói tábor, de szerintem az is kevés. A bug-ok jelentős része különféle platformot érintő hiba, jelentős erőforrást von el a karbantartás a semmiért igazából. Itt szerintem koncepciót kellene váltani és simán kidobni a felesleges platformokat, úgy is csak a problémák vannak vele, ha valaki oda is tévedne. De valóban vannak bajok vele, NetBSD-n futottam bele, hogy egy csomag telepítése során a függőségi lánc fordítása/telepítése többször is megakadt, kézzel kellet mókolni az adott csomaggal, hogy végig menjen. Ilyennel pl. OpenBSD ports-ban nem találkoztam.
  3. Ha jól raktam össze a listát, az OpenBSD (security skill miatt választottam kontrasztnak) sem túl fényes ezen a kimutatáson. Nem tudom mennyire aggasztó amúgy ez a kimutatás, mi alapján jegyzi a dátumokat, mennyire lehet ebből következtetni adott OS milyenségére, stb.
  4. Bármelyik OS levlistájából, bug trackeréből lehetne kihámozni hasonló szinvonalú témákat, de szerintem ez nem azt jelenti, hogy az adott OS-nak az lenne a legfontosabb.

NetBSD-nek szerintem nem a "linux-way" a problémája, hanem inkább, hogy a fejlesztői közösség a "kritikus létszám" alá került, humán erőforrás probléma van. Pl. úgy néz ki 9.4 is lesz, mert a 10.0 előtt még jócskán van fixálni való (főleg az új linux 5.6-on(!) alapuló drmkms-el összefüggő bugok).

1. Persze, hogy növekszik a kódméret, de ez nem csak feature, hanem struktúra is; látod, hogy a sebessége is csökken: azt mérte ki Gabu is a NetBSD 6 és 9 között, azt a sok felesleges layer-t...
2. A NetBSD nem teheti meg, hogy platformokat dob ki, hiszen az a profiljuk, hogy ők támogatják a legtöbb platformot. Ami egyébként igaz, csak kérdés, hogy hogy... Egyébként, ha már Gabucino tapasztalatai szóba kerültek, a pkgsrc-t ő is nagyon lehúzta. De emlékeim szerint neked is az volt a tapasztalatod vele, hogy a ports-szal ellentétben egy csomó reszelést igényel, mert sokkal instabilabb, tákoltabb. Az igaz, hogy a bugjainak nagy része szét van szórva a különféle platformok között, de attól még ez a NetBSD defacto ports-pótléka és elég rossz fényt vet a NetBSD fejlesztőkre en-bloc, ha ennyire sok a bug a cuccaikban.
3. Az OpenBSD-nek is sok baja van (ld. pl. a mostani 7.2 to 7.3 ABI breakage-t (tarthatok két OpenBSD-s binárist a YTFE-ből, kösz, srácok...)) és abban is fordulnak elő sechole-ok, de ott azért próbálják javítani, ill. fókuszban is van, hogy ne legyen belőle annyi, még ha ez nem is sikerül mindig. Viszont az OpenBSD-nél nem jellemző sem a bloat, sem a crapware (pkg-config sajnos itt is van). De ami még fontosabb, hogy az OpenBSD-nél nem ideológiák mentén folyik a fejlesztés (hanem rögeszmék mentén: security over sanity :P ) és nem ugatnak bele nagy cégek. Azért ez se mindegy.
4. Nyilván ez kikarikírozás volt, hogy az a legfontosabb, de könyörgöm...WTF? Holnaptól a NetBSD-sek szerint az ég is zöld lesz, mert a csúnya Dolfi bácsi szerint is kék volt? (Egyébként ekkora marhaságot én csak SJW-uralta fórumokon láttam; az OpenBSD-nél ilyen tuti nem volt.)

És miért került a fejlesztői közösség létszáma egy kritikus szint alá? Ha a NetBSD olyan jó lenne/olyan jó vezetéssel bírna, akkor egyre többen szállnának bele, nem? Szóval valami nagyon nem stimmel ott.

Oldschool Computer - http://oscomp.hu

  1. Végülis igaz, van benne logika.
  2. Pkgsrc platfromokról beszéltem, lehet félreérthető voltam. Nem elsősorban az architektúrákra gondoltam, hanem a különböző OS-eket. Minek arra pazarolni az amúgy is kevés erőforrást, hogy annyi OS supportja legyen a pkgsrc-nek. Igen nekem is volt vele problémám, most is említettem. Mondjuk ettől függetlenül szerintem nagyon jó és nagyon jó doksija is van, szeretem.
  3. Igaz, OpenBSD tényleg letisztult, nagyon egyben van. Viszont a NetBSD fejlesztésbe sem szólnak bele nagy cégek, mert nincsnek körülötte ilyenek :P
  4. A NetBSD közösség szerintem nagyon jó amúgy, amit én látok róluk az alapján szimpatikus közösség, segítőkészek, jó fejek. Nem mondanám hogy jelen van a felsleges PC, meg LMBQakármi. A dev létszám lehet nem is csökkent számszerűen (#FIXME), inkább nem követte le a folyamatosan felfelé mozgó "kritikus létszám" igényt. Alternatív OS világban ez jelen van, nem is tudok az OpenBSD-n meg FreeBSD-n kívül más OS-t, ahol nem probléma a jelenség. (linux-ot nem az alternatív OS-ek közé, hanem a mainstream OS-ek közé sorolom)

2. Valóban félreérthető volt, de a konklúzió szempontjából irreleváns: a NetBSD profilja - a specialitása - a portabilitás. Ez az egyetlen, amiben tényleg mindenkit überelnek; a Linuxot (!) is. Ez a pkgsrc-ra is vonatkozik. Nem szerintem, szerintük. Ha kukázni kezdik a platformokat, kukázni fogják a saját specialitásukat.
3. Oké, nagy cégek nincsenek a NetBSD körül, de SJW-k/snowflake-ek vannak, láthatod. :P
4. Nem minősítettem minden NetBSD user-t/dev-et; általánosságban beszéltem. Én is ismerek NetBSD dev-et, aki az egyik legsegítőkészebb ember, akivel valaha is találkoztam és akitől rengeteget tanultam (persze főleg Amiga témákban, hehe :D ), de látod, hogy sajnos az ideológiai szál, a jelenség létezik a NetBSD világban. Nem feltétlenül az eLMeBeTeG betűlevesre kell gondolni, hanem arra, hogy egyesek ideológiai alapon kapnak seggfájást és nem azzal foglalkoznak, ami a dolguk, hanem ideológiai hadviseléssel és ez a fejlesztésre is kihat; ld. még 300%-os lassulás a NetBSD 6 és 9 között. Ha így is kevés a fejlesztő, akkor nem volna jobb fejlesztéssel foglalkozni?

Oldschool Computer - http://oscomp.hu

2. Azért mert a pkgsrc-ből kidobnák a sok OS támogatást, még nem szenvedne csorbát a NetBSD portabilitás profilja. 

Code exists in pkgsrc to support 20+ Unix-like operating systems and 15+ CPU architectures.

20+ OS support, minek? A NetBSD-n is vannak problémák vele, minek a többivel egyáltalán foglakozni, gondolom azokon még gyatrább amúgy is. Már az sokat segítene a pkgsrc átláthatóságán, ha nem lenne tele csomó OS specifikus if-ekkel, változásokat nem kellene átvezetni a többi OS felé is, azokon hogy működik.

3-4. Velem pl. nem jött még szembe ez a fajta sjw akármi NetBSD esetén, míg pl. FreeBSD fórumon szaladtam már bele ilyesmibe (de ott sem uralta le szerintem az egész közösséget ez a fajta jelenség). Az általad beidézett levlistában egy user (ha egyáltalán NetBSD user volt) írt és bár nem olvastam végig, de a többiek, köztük NetBSD devek inkább leállították az egészet. Megnéztem a NetBSD -current-ben még benne van a kifogásolt idézet, nem távolították el. Egyáltalán nem tapasztalom, hogy a NetBSD fejlesztése körül ideológiai faszságok vannak jelen. Van mit optimalizálni, lenne mit rendbe rakni, hiányoznak vagy bugosak képességek, igen. De nem azért, mert azon megy a vita, hogy lila vagy rózsaszín hajuk legyen. Azért mert kevesen vannak, és időhiány van. Az meg hogy kevesen vannak nem igazolja azt, hogy azért mert szar csapat mert csak az ideológiával foglalkoznak. 

2. Szerintük meg de, különben már kidobták volna. Ezt nem velem kell megvitatnod, mert ők gondolják így.

3-4. Nem egyedül volt ez a fickó; volt olyan, aki kijelentette, hogy azért kell mennie az inkriminált idézeteknek, akár az egész programmal együtt ("inkább pusztuljon minden, de annak pusztulnia kell, amit én utálok"-mentalitás), mert a NetBSD technikai. A Sztálin/Lenin/stb. idézetek valahogy nem zavarták. Az biztos technikai.
Az, hogy a devek kirugdalták az SJW-ket, az nagyon pozitív, ezt nem tudtam. Viszont én nem azt mondtam, hogy az, hogy kevesen vannak, az azt igazolná, hogy szar a csapat, mert csak az ideológiával foglalkoznak, hanem azt, hogy az ideológiai hadviselés puszta jelenléte elkergeti az embereket és ezért vannak kevesen. Nagy különbség. A 300%-os lassulást viszont nem lehet megmagyarázni az emberhiánnyal, hiszen ott pont, hogy bekerült egy csomó felesleges kód, amit valaki(k)nek meg kellett írnia... A létszámhiány magyarázná a driverhiányt, az apphiányt, a supporthiányt, az akármilyen hiányt, egyszóval azt, hogy a NetBSD-ben nincs X vagy Y, mert nincs erőforrás a lefejlesztésére. De azt, hogy 300%-kal belassult a rendszer a túlabsztrahálás okozta rétegcsillapítás miatt, azt nem lehet az emberhiány számlájára írni, hiszen azt is megcsinálta valaki...

Oldschool Computer - http://oscomp.hu

Nem hiszem hogy volt itt kirugdalás, inkább annyi, hogy nem jellemző a NetBSD-re az ideologizálás. Az hogy felbüffen egy egy próbálkozás egyesek részéről a mai világban, az nem meglepő. Lényeg, hogy nem talált táptalajra, láthatod a kérdéses dolog még a -current-ben van, 6 év telt el azóta. Ez a lassulás érdekes téma, rá fogok mérni ha lesz időm, más rendszerekhez képest, meg önmaga korábbi verziójához képest is. Amúgy az optimalizálatlan kód is lehet erőforrás miatt. Kell valami feature, valaki beletolta, de optimalizálatlan, bugos és nincs aki rendbe rakja, vagy nincs olyan aki kompetens rendberakni, vagy épp működik csak lassú és hátul van a queue-ben a probléma. Egészen biztos, hogy a NetBSD fejlesztők nincsenek annyian, hogy működjön pl. az OpenBSD féle 1 diff 2 OK modell. De, hogy zárjam ezt a szálat: igen van probléma a NetBSD/pkgsrc körül, de ez nem a linux-way és/vagy swj miatt van.

Rendben, akkor szerencsére tévedtem és a NetBSD még nem jutott a Linux és a FreeBSD sorsára.

Az új feature-rel bekerült optimalizálatlan kódot viszont nem igazán értem, hogy hogyan is csinálhatna ugyanannál a tevékenységnél 300%-os lassulást. Gondolj bele: ha a NetBSD 6-ban egy konkrét feladatot (Gabu mérésében az SDL 1.2 fordítása) már végre lehetett hajtani, akkor a NetBSD 9-esnél is ugyanazoknak a mechanizmusok fognak dolgozni, függetlenül attól, hogy mi más feature-öket pakoltak még bele. Ez csak abban az esetben fordulhat elő, ha ezek a mechanizmusok változtak meg. Igen, az is lehetne, hogy csak újraírtak valamit és az nincs még optimalizálva, de annak azért nem kéne ekkora lassulást eredményeznie. Itt inkább az újrastruktúrálás lehet a háttérben, hogy a korábbi mechanizmusok eddig X db layerben voltak implementálva, most meg X+Y db layerben. A túlabsztrahálás jókora overhead-del tud járni.

Az nem rossz, ha te is mérsz, de ha a NetBSD devek ennyire nyitottak a vitára, akkor akár rá is kérdezhetsz náluk, hogy mi lehet az oka, mert lehet, hogy valójában nem is túlabsztrahálás és nem is az optimalizáció hiánya, hanem az, hogy NVAX-ra sokkal szarabb kódot fordít már az a fordító, amivel a NetBSD-t fordítják, mint a NetBSD 6 idején és ezért az egész rendszer sokkal lassabb lett. Egyszóval, hogy a probléma nem is a NetBSD-ben van, hanem a fordítóban és a probléma csak N db architektúrát érint, köztük az NVAX-ot is.

Oldschool Computer - http://oscomp.hu

( kassaiviktor | 2023. 05. 20., szo – 14:30 )

ebben a kernelben van benne a scrollbar kezelés?

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

( Szunyi76643843 | 2023. 05. 21., v – 19:41 )

Mi a magyarázata az eszméletlenül különböző méretnek?
30,100x eltérés?
Funkcinonális is már, vagy csak egy részhalmaz lett implementálva, vagy ténlyeg ennyivel kisebb lett?

Látok én is két eltérő nevű állományt a mentett képernyőképen. Kérdés, hogy van-e átfedés közöttük vagy csak gondolunk valamit a névhasonlóság okán?

Egyébként ha ügyesek, akkor a kockázatosabb dolgokat írják át első körben. Példának okáért Linux parancsok esetén a minden parancsnak való nekiesés helyett az általánosságban aktivált SUID illetve SGID bittel rendelkező programokkal kezdeném. Ezzel sok komoly méregfogat kihúzva a rendszerből. Ugyanis ha ezek közül bármelyik sérülékeny, akkor jogosultság kiterjesztés érhető el ezekkel, mivel ezek a programok nem a usereddel futnak valójában. Lásd:

/usr/bin/su
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/sudo
/usr/bin/passwd
/usr/bin/mount
/usr/bin/umount
...

Windows esetén szintúgy a kockázatosabb dolgokra tenném első körben a fókuszt, azután jöhetnek a kisebb kockázatúak.

"Mi és mi között van eltérés?" kérdésből az jött le

Nem kötözködés, hanem pusztán technikai síkon: te meg tudod mondani, hogy mi és mi között látható az eltérés? Azonos funkciójú bináris fájlok vagy eltérő funkciót tartalmazó bináris fájlok között?