Hans Reiser a börtönből szólt hozzá a ReiserFS elavulttá tételéhez

Fájlrendszer, NAS, storage

Hans Reiser, a ReiserFS megalkotója 2006 óta börtönben ül egykori felesége megölése miatt, így nem igazán tud elektronikusan részt venni az LKML levelezésében és a Linux kernel aktuális fejlesztésében. Annak híre azonban, hogy a Linux kernel fejlesztői hivatalosan is elavulttá (deprecated) tették a ReiserFS-t, eljuthatott hozzá a börtönbe. Mi több, állítólag postai úton hozzá is szólt a fájlrendszere körüli történésekhez, illetve a Reiser4 fájlrendszerrel kapcsolatos reményeit is kifejezte. Levelét bepostolták az LKML-re, így az elolvasható itt. Sőt, akinek kedve támadt levelezni vele, az megteheti, mert a börtönbeli postacímét is mellékelte:

Hans Reiser
CHCF G31008
PO 213040
Stockton, California, 95213, USA

Részletek itt.

( trey | 2024. 01. 19., p – 20:51 )

Szerkesztve: 2024. 01. 19., p – 21:13

Kéne egy LKML <> snail mail gateway.

https://ftp.mfek.org/Reiser/Letters/%E2%84%961%20Fred%E2%86%92Hans/reis…

https://ftp.mfek.org/Reiser/Letters/%E2%84%962%20Hans%E2%86%92Fred/reis…

I hope that OCR technologies are effective at saving you from having to type this in. [...] LKML and Slashdot.org seem like reasonable places to send it (as of 2006). Your advice is desired.

Fura lehet bentről találgatni, hogy mennyit változhatott a világ majd 20 év alatt.

trey @ gépház

( suckit | 2024. 01. 19., p – 22:28 )

Jan Kara helyében én nevet változtatnék, és elköltöznék valami ismeretlen helyre.

>Reiser acted as his own attorney during the trial and tried to argue that he killed his wife to protect their children (a wiki oldalról)

Az a baj, hogy simán vannak ilyen anyák, ez egy létező dolog, hogy betegségeket generálnak a gyereknek. Talán jogos volt és le se kellett volna csukni.

De, kéne, mert 2022-ben járt le neki a min. 15 év, akkor felül is vizsgálták a próbára bocsátási kérelmét, de a bizottság elutasította, a legközelebbi felülvizsgálati lehetősége 2027-re lesz. Szerintem akkor se engedik ki, mivel az igazságszolgáltatás rendszere rág a faszira, hogy a vádalkuval elkerülte az elsőfokú emberölésért járó tényleges, végleges életfogytot, így úgy vannak vele, hogy ha már megúszta enyhített emberölési elítéléssel, akkor kicsit még várakoztatják, hogy ne legyen az olyan gyors, hogy 15 év és még kint legyen az életét helyrehozni. Bár lehet tévedek, én ezt érzem ki belőle.

Egyébként a leveléből nekem úgy tűnik, hogy pedig nem egy rossz fószer, nem hülye, bár állítólag az orvosok szerint aspergeres. Megbánta, amit fiatalon, még antiszociális, forró fejjel elkövetett, nem csak a felesége megölését, hanem hogy bunkó volt emberekkel, nehezen lehetett vele együtt dolgozni, stb.. Lehet tényleg a börtön, meg egy kicsit az életkor előrehaladtával az erkölcsi érzék, bölcsesség megváltoztatta, írja is, hogy ma sok mindent máshogy, jobban csinálna. Azt meg nem bánja, hogy a ReiserFS-t kiszedik 2025-ben a kernelből, azt írja, hogy ma már az ext4 is bőven felzárkózott, meg ma már lehet jóval jobbat írni, legyen fejlődés.

Illetve szerintem a jövőben a fájlrendszerek fejlesztése nagyon le fog lassulni, elvesztik a jelentőségüket. Újak nem fognak kijönni, a meglévőknek lehet kijönnek új verziói, amiben lesz egy-két extra feature, plugin-szerű megoldással, de annyi. Az a fájlrendszer vs. teljesítmény téma HDD-kon volt érdekes, de mióta minden SSD, meg egyre inkább NVMe, azóta akkora I/O teljesítménye van a vezérlőknek, háttértáraknak, a modern, gyors DDR4-DDR5 RAM-on meg akkor sávszélessége és olyan ultraalacsony késleltetése van a tmpfs/ramdrive-nak, hogy mindegy milyen fájlrendszerrel hajtod, nem az lesz a sebességnél a szűk keresztmetszet. Ha meg feature-hegyek kellenek, akkor azt a részét meg az btrfs/ZFS szintén kimaxolta már.

Ugyanez van már évtizedek óta a tömörítőknél is. A legtöbb átlag usernek az ezer éves pk/info/g/zip, xz/lzma, 7-zip/ppma megfelel, a tömörítési fok, ami reális hardverigénnyel elérhető, az már ki van maxolva. A zstd, lz4, brotli, zopfli részéről meg sebességügyileg nem lehet már hová fejlődni, meg már eleve a legtöbb tömörítő többszállúsítva van, meg szintén, az NVMe meghajtók korában az I/O sem szűk keresztmetszet többé, meg mióta a gépek ki vannak tömve sok giga RAM-mal, már a nagy szótárméret se okoz gondot ki/betömörítésnél. Így csak nincs hová fejlődni a tömörítőknek. Eleve, régóta a legtöbb formátum, legnagyobb fájlok eleve előtömörítve jönnek, főleg a médiafájlok, codec-ek már erősen tömörítettek, nincs mit rajtuk tovább tömöríteni, meg a háttértárak is terában mérődnek. Így csak a tömörítés nem játszik már akkora szerepet, mint egykoron, mikor még ilyen floppy-kra, CD-kre, ftp-kre kellett darabolgatni, meg minden bájt számított. Most is van tömörítés, de azt megoldják FOSS kódokkal, és a fájlrendszer szintjére van kitolva transzparens, opcionális röptömörítésként, ha szükség van rá. Ezért is csodálkozok, hogy több fejlesztő még árul zárt, fizetős tömörítőket (WinRar, WinZip, stb.), mikor ezeknek az előnye rég megszűnt, hosszú ideje már csak a csili-vili GUI-val tartják magukat, de ebben is kezdi behozni a lemaradását a PeaZip, 7-zip, meg fájlkezelők, amik archívumkezelést is tudnak.

Erre a sorsa fognak jutni a fájlrendszerek is, meg még sok informatikai vonatkozásban igaz, pl. codec-ek sem fejlődnek. Pl. a legtöbb embernek bőven elég a mai napig a jpeg/png, mp3/aac(+), vorbis/opus/flac, videóknál x264, és nem igényelnek többet, egy új formátumra váltással már nem lesz akkora ugrás (pl. webp/heif/avif, x265-x266/av1, stb.), hogy megérje upgrade-elni. Ugyanezt érzem a felbontásoknál is. Az átlag, olcsó FullHD/IPS kimenetek, kijelzők már elérték azt a küszöbszintet, képminőséget, amihez képest a 4K-8K/OLED nem akkora ugrás. Ugrás, de nem annyira, hogy a legtöbb átlag felhasználónak megérje a brutális extra költséget, extra sávszélességet/adatméretet.

Nem kizárt, hogy az AI még hozhat valami ugrást fájlrendszereknél, tömörítésnél, kódekeknél, de valószínű már az se lesz túl nagy, meg ugye sokan (közöttük én se) nem bíznak egy AI által kibűvölt csoda transzformációs mátrixban. Inkább bízom rá magam egy jól ismert, nyílt, közösségi FOSS, diszkrét algoritmusra, aminél lehet tudni mit csinál, hogy működik, és a hardverigénye is csak négyzetgyök.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Óvatosan, mert a narcisztikus pszichopaták képesek behízelgőek lenni, mindenkinek az a benyomásuk róla, hogy rendes emberek, pont ezért veszélyesek. Reiser nem hülye, pontosan tudja, hogy mind a bemenő, mind a kimenő levelezését olvassák, iktatják és elemzik. Éppen ezért akkor is írhat olyanokat, hogy nagyon megbánta, hogy elnézést kér, hogy változott stb., ha közben nem is, mert tudja, hogy ezek számítanak a próbára bocsátási bizottság előtt.

Ennek ellenére, lehet, hogy megbánta valóban, de azért ezt nem egy levélből kell majd levonni.

trey @ gépház

Ebben igazad van, meg is játszhatja. Nem látunk a fejébe, meg nem vagyunk képzett kihallgatók, pszichiáterek, akik alaposabban fel tudják mérni. Nyilván benyomásoknál csak a levelére támaszkodok.

Egyébként én a helyükben a következő felülvizsgálaton kiengedném, ha valóban nem csak megjátszotta, amit a levelében ír. Azon a ponton ült 20 évet (annyival a legtöbb modern nyugati állam megelégszik emberölésnél, hacsak nem valami minősített eset, vagy terrorcselekmény, vagy sorozat- vagy tömeggyilkosság), ami azért nem kevés, meg szerintem ő a szaktudásával, fejlesztési-oktatási képességeivel több javát szolgálja a társadalomnak, ha kernelkódon, fájlrendszeren dolgozhat, így talán még tud adni valamit a linuxos közösségnek, amolyan jóvátétel címen hasznosulna a tudása, nem menne pocsékba. Bár az is igaz, hogy a közösség lehet a hírneve miatt továbbra is kiközösítené, és nem nyúlna a projektjeihez, meg nem használná őket, plusz szponzorok a negatív PR miatt nem támogatnák. Ki tudja mi lenne, csak tippelgetek természetesen, de én így látom.

A kernel-, fájlrendszerfejlesztésből mindenkinek több haszna van, mintha csak bűnhődne a csávó, a feleségét meg úgyse támasztja fel már semmi. Meg a másik érv a kiengedése mellett, hogy a börtönben a fejlesztés nem lehetséges, mivel a börtönök 100%-ban biztonság, szökéskivédés, zendülésszervezés kivédése okán nem elérhető az internet teljes korlátozottság, cenzúra, stb. nélkül, az pedig kell a fejlesztéshez. Sem saját számítógép nem engedélyezett, komoly, nagy méretű projekt kódját meg nem lehet kézzel, papírra irkálni, meg pull request-eket levelekben küldözgetni. Így ez a fajta fejlesztés a legenyhébb fokozatú intézetben sem kivitelezhető.

Persze azt is megértem, hogy aki úgy gondolja, hogy szépen rohadjon csak élete végéig a cellában, a feleségének se lesz esélye kijönni a sírból, meg így is örüljön, mert sok helyen ezért kivégezték volna. Ebben is van valami, komoly érvelési vonal ez is, amit nem lehet cáfolni, ellentmondani neki. Nyilván mindenki máshogy mérlegel.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

"pl. codec-ek sem fejlődnek"

Szvsz, ahol számít a pénz, ott igyekeznek a jobb hatékonyságúakra terelni. Persze sokáig párhuzamosan fut több formátum, mert 5-10 éves tévéken is mennie kell. De ahogy a statisztika kiadja, hogy kikoptak a régi tévék - alig használja már valaki, akkor leállítják a régi támogatását. 
Inkább a szoftverszabadalom és licenszdíjak állank némelyik újabb codec terjedésének útjában. Ezért születtek alternatív codec-ek, amelyek hasonlóak, de szabadon használhatóak. 
Az otthoni használatnál lehet jó a 20éves megoldás is, de amikor előfizetsz valami szolgáltatásra, ott más szempontok vannak.

Veszteséges tömörítésnél azért más a helyzet, mint ott, ahol az eredeti kell bitre pontosan visszaadni. Azt nem lehet ai-val "okosítani", hogy felskálázza és behelyettesítsen valami hasonlót helyette.

> ahol az eredeti kell bitre pontosan visszaadni. Azt nem lehet ai-val "okosítani"

dehogynem. mar 30 eve, a 90-es evekben is arrol szolt a vesztesegmentes keptomorites, hogy minel jobban prediktald a kovetkezo pixeleket, es csak a hibat (elterest a valos es a predikt kozott) kell tarolni keves biten. lasd PNG kepformatum.

de a videotomoritesek (a vesztesegesek is) ugyanigy mukodnek, megprobalja az elozo kepkockakbol megjosolni mi lehet a kovetkezon (mozgast kovetve, motion prediction) es akkor eleg az elterest tarolni.

ebben azert az AI tudna eleg sokat segiteni, mind kepeknel felskalazassal (letarolod pici meretben a kepet, plusz az AI altal abbol felskalazott es az eredeti kozotti eltereseket) mind vidoenal (AI jobban tudna a mozgasokat josolni, mint par masodfoku egyenlet)

inkabb az a baj, hogy jelenleg az AI meg nagyon eroforrasigenyes, izmos GPU kell hozza ami nincs minden pc-ben. ugyanaz van mint 20 eve a h264-el, akkori atlag pc nem birt vele cpu-val, a celhardverek meg meg nagyon dragak voltak eleinte. ma meg mar egy olcso okostelefon is siman dekodol hardveresen fullhd h264-et...

Az a soydevek szerint van mindenkinek. A laptopjában is. Mert mindenki ×4rja a pénzt, ahogy ők a nagy multik alkalmazásában. Ha nincs ilyen a gépedben, meg legalább proci az utolsó két generációból, akkor elavult a gép, dobja ki mindenki.

Nem AI-s megoldásból is van durva, egyes PAQ8-variánsok tudnak 20+ órán át ki/be tömörítgetni, 10-20+ gigás memóriahasználat mellett, pedig azokban se AI nincs, se GPU-t nem használnak, hagyományos algoritmussal futnak a procin. A gyakorlatban nem éri meg, mert összességében alig nyer vele az ember extra pár százalék tömörítést egy sima xz/7-zip-hez képest. Ugyanezért van, hogy a legtöbb tömörítőben az alapértelmezett tömörítési fok kb. csak közepes, mert ezen hozzák a legjobb tömörítés/idő arányt, ettől lefelé gyorsabb, de a tömörítési fok aránytalanul rosszabb, illetve magasabb fokozaton meg a tömörítési fok alig javul, de legalább az egész elviselhetetlenül sokáig tart.

A legtöbb felhasználásra meg átlag usernek még az xz is overkill, elég az, amit a pkzip/gzip/tar.gz tud.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

> a soydevek szerint

azok kik?

> A gyakorlatban nem éri meg, mert összességében alig nyer vele az ember

kiveve akkor, ha millioan fogjak letolteni. nem veletlen szenvednek annyit a streaming cegek (netflix stb) a videotomorites optimalizalasaval, naluk 1-2% is jelentos megtakaritas adatforgalomban.

igy pl. a linux dirsztrok csomagmereteben is szamitana par % javulas, pl. ubuntu repoknal.

Nem érted: azért az 1-2% javulásért több ezer százalék időveszteséget, és hardverigényt szenvedsz el. Annyit 1-2% méretspórolás nem ér. Ha csak 10-20%-kal kéne érte a másik oldalon többet fizetni, akkor okés lenne. Nem véletlen, hogy a legtöbb Linux disztró is megmaradt a tar.gz-nél, az tar.xz-re csak néhány váltott, meg a kernel.org-on is évekig vitatkoztak, hogy az xz-t bevezessék-e. Sőt, pl. az Arch már a tar.zst-t vezette be (Ubuntu is tervezi), mert a tar.gz-nél jobb, de a kitömörítése sokkal gyorsabb, és a sebességre mennek, nem a tömörítési fokra. Rájöttek, hogy a legtöbb felhasználónak a telepítési-frissítési sebesség számít, nem az az 1-2% tárhelykülönbség.

Ilyen a tömörítés, ahogy közelíted meg az elvi tömörítési maximumot (ez a Shannon-határ, amikor az adott adathalmaz már jobban nem tömöríthető elméletileg sem), úgy szál el aszimptotikusan a végtelen felé a hozzá szükséges erőforrás/idő, vagy az algoritmus mérete, komplexitása válik végtelenné. Ez nem technikai korlát, amit mérnöki találékonysággal ki lehet kerülni, hanem áthághatatlan elvi, entrópiás korlát. Nem véletlen, hogy tömörítőknél néznek gazdaságosságot, hogy melyik az a tömörítési fok, ami még nem túl sok időbefektetéssel, hardverigénnyel hozható, és jelentős előrelépés az előző, egyel kisebb fokhoz képest. Ez az a pont, amikor a tömörítési fok vs. idő diszkrét görbe differenciahányadosa a legközelebb van a √2/2 értékhez, ez az arany középút. Ez mindig ki is tolódik, ahogy egyre erősebbek a hardverek, ahogy egyre nőnek a tárhelyek, memóriák méretei.

Létezik még egy csomó hasonló limit, ami szintén nem szeghető meg, mert ahhoz valamelyik Plank-féle határt kéne átlépni kvantummechanikailag, vagy a fénysebességet, a relativitáselméletet megszegve, vagy fekete lyukká alakulna a történet, és ennek vannak gyakorlati kihatásai, ahogy a technológiai fejlődés megy előre, és közelítik meg egyre jobban ezeket. Ezekkel számolni kell, tisztában lenni a természetükkel, akkor lehet megérteni, hogy nem lehet növekedni meg fejleszteni a hatékonyságot a végtelenségig.

Ugyanezért van, hogy a Moore-törvény által előrejelzetthez képest a fejlődés lassult, meg pl. ugyanezt az optimalizációs problémát a CPU/GPU gyártók szem előtt tartják, amikor belövik az üzemi feszültséget, meg órajeleket az adott processzornál, akkor nem a maximális teljesítményre mennek, hanem arra, hogy az adott proci a maximális teljesítményének a legnagyobb részét még úgy hozza, hogy a fogyasztása, melegedése nem száll el irreálisra. Ezzel küzdenek a tuningosok is, ahogy növelik a GHz-eket, úgy az adott proci már nem lesz lineáris gyorsabb, csak már folyékony nitrogénnel is alig hűtöd le, meg egyre instabilabb lesz, a teljesítménynövekvény ezért cserében egyre kisebb. Ilyenkor beleütközik egy architekturális korlátba, vagy valami más bottleneckbe (cache, memóriasávszél, magok közötti koordináció, szoftveres platform, kernel ütemezőjének a limitje).

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

> azért az 1-2% javulásért több ezer százalék időveszteséget, és hardverigényt szenvedsz el

amikor 1x kell betomoriteni de sok millioszor ki, akkor ez vallalhato, es vallaljak is. persze csak ha a kitomorites gyors marad, de xz-nel pl. az gyors, csak a betomorites lassu nagyon.

> nem az az 1-2% tárhelykülönbség.

nem a tarhely a lenyeg, hanem az adatforgalom, amikor millioan toltik le

> Ez nem technikai korlát, amit mérnöki találékonysággal ki lehet kerülni, hanem áthághatatlan elvi, entrópiás korlát.

koszi, de en tisztaban vagyok ezekkel. 90-es evek ota irok tomoritoket, volt olyan (ESP) ami honapokig vezette a ranglistat, a legjobb kep tomorito volt ugy, hogy kozben a zip-nel is gyorsabb...

Azért ez az egyszeri betömörítés se mindig igaz, pl. szerveren, ami automatikus tömöríti mindig az adott napi dev buildet vagy disztrótárolóban mikor épül a legfrissebb verziós csomag, akkor ott nem mindegy, hogy milyen terhelést okoz maga a tömörítés. Meg pl. tömörítője is válogatja, mert van, amelyiknél az erősebb tömörítéssel a kitömörítés is lassulhat (pont a ZPAQ ilyen, amit említettem). Van, amelyiknél valóban nem függ a betömörítés sebességétől a kicsomagolás.

Azt nem tudtam, hogy tömörítőkben otthon vagy, ha ezzel kezded, megspóroltál volna nekem egy csomó felesleges magyarázatot. A lényeg lényege, hogy a legerősebb tömörítési fok sokszor nem éri meg. Optimalizálni kell ehelyett.

Nekem pl. volt évekkel ezelőtt még egy speciális eset, hogy valami orvosi felvételeket egy CD-re kellett rányomorgatni (eredeti formátumban ráadásul, nem lehetett átméretezni, meg kisebbre áttömöríteni lossy megoldással), mert a fogadó oldalon valami elavult orvosi intézmény volt, ahol nem volt normális net és korszerű gép, így se pendrive, se semmi nem játszott, és CD-n kellett eljuttatni az anyagot, ami már akkor is rettenet elavult volt, és bajosan fért rá az egész cucc, végül csak a nanozip és a zpaq tömörítette be elég jóra, de az utóbbi olyan lassú volt, hogy az előbbinél maradtam. Végül is feleslegesen dolgoztam vele, mert nem adtak konzultációs időpontot, de az eset emlékezetes maradt.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

pl. szerveren, ami automatikus tömöríti mindig az adott napi dev buildet vagy disztrótárolóban mikor épül a legfrissebb verziós csomag, akkor ott nem mindegy, hogy milyen terhelést okoz maga a tömörítés

De, hidd el, teljesen mindegy. :)

A nightly buildet eleve nem ott keszitik es tomoritik, ahol az eles szolgaltatas fut. Majd TeamCity-ben az egyik agent kicsit tovabb dolgozik hajnalban, senkit nem erdekel. Centekben merheto a kulonbseg build time-ban, mikozben az egress traffic aranyarban megy.

( Ebcsont | 2024. 01. 20., szo – 08:49 )

"Csak az, hogy felrobbantott négy hidat&#8230;

Csak az, hogy felrobbantott négy hidat,
Nem elég, hogy börtönbe csukják,
Mert ilyen szépen nem mosolyog senki,
Érdemes megnézni az arcát.

Csak az, hogy a fiát narkóval tömte,
Felesleges, hogy ezért kötelet kapjon,
Mert ilyen festő az életben nem volt,
Képein oly gyönyörű az alkony.

Azért mert a színpadon van,
Nem biztos, hogy jól érzi magát.

És, hogy a húgát az utcára küldte,
Felesleges, hogy ezért felpofozzák,
Mert mutassanak nekem egy olyan embert,
Aki a húgával nem ezt tenné."

ÜÚF