Lehet, hogy lesz karbantartója a Linux kernel HFS/HFS+ fájlrendszer driver-ének

Kernel

Előzmények itt.

[...] Válaszul a driverek elavulttá nyilvánítását célzó javításra, egy IBM-fejlesztő, aki több mint egy évtizede korábban már hozzájárult a HFS+ driverhez, felajánlotta segítségét a HFS/HFS+ driverkód körüli újbóli aktivitás előmozdításához. Viacheslav Dubeyko szeretné, ha a HFS+ kód legalább továbbra is a kernel része maradna.

A Debian fejlesztője, John Paul Adrian Glaubitz szintén jelezte, hogy kész segíteni a HFS/HFS+ kód karbantartásában, például a javítások tesztelésével és átnézésével. [...]

( Raynes v | 2025. 04. 20., v – 14:24 )

Bezzeg a sok Rustafári hogy lapít ilyenkor, amikor valamit karban kell tartani, és nem a hájpot meg a drámát kell nyomni. Ha valami jobban hájpolt téma lenne, Asahi LPina már rég virnyogna róla a redditen, hogy ezt ő milyen f4×án meg tudná oldani.

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

Nekem pedig a külső winyóim HFS+ fájlrendszert használnak, mert anno az Apple azt mondta, hogy az APFS-t inkább SSD-kre optimalizálták és mindenhol azt olvastam, hogy HDD-n az APFS kevésbé optimális megoldás.
Szóval én mai napig HFS+-ot használok HDD-n vagy exFAT-ot, SSD-re meg APFS vagy ha adat-hurcolászós meghajtó, akkor exFAT.

 

Szerk.: Csak a rendszermeghajtón használok APFS-t.

Mert ők akarnak fontosnak látszani, meg bebizonyítani, hogy milyen hasznosak az átírásaikkal, meg jobbak, mint az elavult C fejlesztők. Most itt lett volna az alkalom, hogy előlépjen akár csak egy közülük, de erre csendben lapítanak a fingszagban.

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

Iróniából írtam, ők próbálják így feltüntetni. Ilyen szövegekkel, hogy a C elavult, meg nem biztonságosch-ak a benne írt kódok, stb.. Itt most megírhatták volna a HFS/+ drivert, megmutatva, hogy így kell ezt, erre most lapítottak, mert nem hájptéma. Tipikus. Ezek a rust-osok inkább csak az 5 perc hírnévre mennek, hogy benne legyenek a közösségi médiában.

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

Most ennél az a szituáció, hogy maga a projekt nem érdekel senkit, hiába van C nyelven (#fixme hogy tényleg C). Erre te azon habzol, hogy hol vannak a rusthuszárok, írják meg hyperustban? 

Minek?!? 

Vagy a rusthuszárok tartsák karban a senkit nem érdeklő C projektet? Nem értem a habzásod miértjét sem. Vagy csak rúgnod kellett egyet a rusthuszárokba?

Hát, ha fontosnak akarnak látszani, akkor lehet, hogy valójában nem egy olyan legacy lófasz karbantartásával akarnak foglalkozni, ami valószínűleg összesen két marék embert érdekel.

Egyébként meg nem mindegy neked? Rohadt visszatetsző, amikor másnak akarjátok megmondani, hogy mit és hogyan kéne csinálnia.

/troll ráadásul ők pont nem mondják, hogy jobbak, mint az elavult C fejlesztők, hanem pont hogy nem hiszik el, hogy csak okosnak kell lenni, és nem fogjuk elbaszni a memória kezelést. Ugye itt az szokott lenni a mantra. Aztán mikor az ember megkérdezi, hogy akkor CVE-k nagy részérért a többi C fejlesztő felel-e, akik rendre mégis elbasszák, akkor meg laptítanak a fingszagban a válasszal.

Igen, ez is egy érv, de inkább csak kifogáskeresésnek tűnne a részükről. Legacy, de egy terület, ahol lenne esélyük. Mert menni szokott a sírás, hogy jajj, nincsenek egyenjogúként elismerve a C-s kernelfejelsztőkkel, most itt lett volna egy terület, ami a C-seket se érdekelte volna annyira, nem bánták volna a Rust-ot. Értem, ezek a muzeális fájlrendszerek rétegigény, igazából egy jófajta user space fuse driver is elég lenne, ha normálisan meg van írva. reiserfs-ből is kéne egy ilyen. Rétegigény, de hasznosabb, mint a 6 ezredik AI integrációt, meg chatgpt query felületet implementálni, meg az electronos chat-szarok, amikből Dunát lehet rekeszteni.

Itt most nem azt kellett volna nézni ennél a HFS-ses témánál, hogy rétegigény, hanem kicsi, de biztos bizonyítási lehetőség egy feltörekvő Rust-osnak. Értem, hogy 10 millió kódsoros modern GPU driverét, meg legújabb kernelütemezőt írni nagyobb izgalom és hírnév, de aki alulról kezdi, még bizonyítania kell, azoknak jó lehetőség egy ilyen kisebb projekt. Egyfajta demózási lehetőség a tudásukra.

Ez ugyanígy van, ha felvesznek valakit egy céghez kódolni. Nem mindjárt a legjelentősebb projektbe szokták betenni, hanem adnak neki valami hablingya, senkinek nem kellő kisebb projektet, karban tartani, rendbe hozni, azon lemérik, hogy mit tud. Ha ott legény a gáton, akkor bevonják nagyobb tétre menő, jelentősebb projektbe is. Egyfajta ranglétrán felküzdésnek tekinthető.

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

Igen, ez is egy érv, de inkább csak kifogáskeresésnek tűnne a részükről

Milyen kifogáskeresés? Hogy jön valami nagyonokos az interneten, hogy ezt kéne neki csinálni? Miért kéne kifogást keresni :D

Legacy, de egy terület, ahol lenne esélyük. Mert menni szokott a sírás, hogy jajj, nincsenek egyenjogúként elismerve a C-s kernelfejelsztőkkel, most itt lett volna egy terület, ami a C-seket se érdekelte volna annyira, nem bánták volna a Rust-ot.

Ne haragudj, de ez a sírás itt van most velünk a szobában, ahogy a művelt angol mondani szokta?

Nem tudok erre érdemben reagálni, mert annyira nincs semmi értelme, meg annyira nincs köze a valósághoz, hogy nem tudom, hol kéne kezdeni.

Ezt általánosságban írom, ne vedd magadra. Plusz Rustban sem tudok programozni, úgyhogy elméleti eszmefuttatás az egész. Napi 8-10 órában foglalkozom IT-val. Általában szeretem, ha meg valami izgalmas projekt van, akkor még mindig tudok kifejezetten lelkesedni érte. Plusz még jól meg is fizetnek. De amikor ilyesmit olvasok, tudod, mi az első gondolatom?

Hogy menjetek a jó édes tudodkibe.

Ez a hozzáállás borzasztó idegesítő. "X programnyelvben dolgozol? Akkor miért nem oldasz meg benne ingyen, a szabadidőd terhére egy olyan problémát, ami téged nem is érint? Ezek szerint X egy szar?" Mondjál már valamit, amit te, önkéntes alapon megcsináltál a szabadidődben, és van legalább egy ici-pici felhasználói bázisa (mondjuk minimum 1 ember, rajtad kívül), akit érdekel a projekt!

Nem attól lesz jó vagy rossz egy technológia, hogy egy random arc bevállalja-e egy full érdektelen probléma megoldását benne, két gyerek meg egy fulltime meló mellé. 

( kisg v | 2025. 04. 20., v – 23:08 )

A fő kérdés itt, hogy disztró kernelek bekapcsolják-e. Ha igen, az azért lehet gond, mert egy ilyen legacy kódbázis, amit kb. lélegeztetőgépen tartanak, simán lehet táptalaja biztonsági hibáknak, amik így olyan emberek gépén is kihasználható lehet, akik nem is használnak HFS+-t. Ha a disztrók nem kapcsolják be, akkor meg tényleg kb. senki sem fogja használni.

( Czo v | 2025. 04. 22., k – 15:56 )

kb 20 eve, ez volt az a filerendszer, amit hordozasra hasznaltam a Mac/Win/Linux trioval. Az OSX szamara ugye ez volt akkor a nativ (HFS+), a Windowsra kellett a MacDrive nevu szoftver, linuxon pedog volt a hfsplus modul, igy mind a harom platform tudta irni, illetve tamogatottak voltak a 4GB-nel nagyobb filemeretek is. Viszont, akkor az volt a "baja" ennek, hogy ha be volt kapcsolva a journaling a HFS+ particion, akkor a Linux csak read-only modon tudta mountolni (diskutil disableJournal kellett Macen). Nos, most direkt kiprobaltam, AlmaLinux9, ELRepo -ml kernel (6.1.134), de a journalinggal meg most sem tudja irhato modon mountolni. Ezek mellett, azon is tokre meglepodtem, hogy 15.4.1 alatt, volt meg lehetoseg a journal kikapcsolasara.