Názory k článku
Nový ovladač NTFS v Linuxu už měsíce nikdo nevyvíjí

A ony tam jsou nejake vady? Co je treba jako udrzovat? Me jsem za to, ze kdyz nejaky jaderny vykuk zmeni API, tak by mel premigrovat vsechny zavisle kody na novou verzi, jinak je to jenom pridelavani prace lidem, kteri o to nestoji.. neco jako retezovy dopis.

Takze jak to je?

Odpovědi najdete v původním e-mailu: There is lot of bug reports which are ignored completely. Lot of patches which nobody applies.

I ve Vámi popisované API-breaking situaci má poslední slovo maintainer daného modulu: někdo změní API, navrhne změny (patch), a maintainer to musí schválit (začlenit). Pokud není maintainer, tak je problém.

Mě by zajímalo proč je ntfs-3g mimo kernel, i když je aktivní uz spoustu let. A pak se najednou z čista jasna objeví jiná implementace a šup s ní do kernelu...

Protože ntfs-3g není jaderný ovladač, je to FUSE program. Je to celkem normální Cčková knihovna pro Linux, linkuje se s libc, atd. Udělat z toho jaderný modul by byl v podstatě kompletní přepis.

Protože není inteligentní důvod to mít v kernelu. V kernelu by měli být jen FS ze kterých se chce bootovat. Na vše ostatní je tu FUSE.

Není důvod mít to v kernelu i vyšší výkon oproti FUSE?

Jaký je use case, když mírné zpomalení při použití takto exotického FS vadí?

Navíc díky vDSO tam ten overhead vůbec není tak hrozný, jak by to laickým pohledem vypadalo.

„Jaký je use case, když mírné zpomalení při použití takto exotického FS vadí?“

Dualboot Windows a Linux + ntfs oddíl se sdílenými daty (media, data aplikací, jako je Firefox, atd.) + synchronizace přes Unison s třetí stranou. Kdysi jsem měl tuto kombinaci (synchronizoval jsem s notebookem) a jakmile těch souborů bylo několik desítek tisíc (velice snadno naroste při synchronizaci dat aplikací), skenování změn trvalo velice dlouho.

To zpomalení kvůli ntfs bylo hodně viditelné díky tomu, že na notebooku jsem měl čistě Linux, takže data na ext. Přestože byl notebook výrazně pomalejší (hdd, cpu), skenování měl vždy mnohem rychleji hotové.

Samozřejmě Unison není jediný use-case; dotýká se čehokoliv, co skenuje souborový systém, ale ne obsah samotných souborů. Třeba Baobab. Nebo hledání.

NTFS se radu let nevyvyji :-)

Jinak důvodem je nejspíš válka nebo sankce, Paragon Technologie GmbH je sice registrovaná v Německu, ale firma je to ruská. Maintainer ntfs3 a CEO firmy Konstantin Komarov možná nereaguje, protože nesmí.

Toto vysvetlenie uz dava zmysel.

Toto je kvalitni prispevek.

Můžete mít částečně pravdu (skoro bych si na to i vsadil), ale to nevysvětluje, že tam není aktivita prakticky od konce října, tedy značně dříve, než začala válka o Ukrajinu. Mě akorát ještě napadlo, že prostě zjistil(i), že je to příliš velké sousto a tak se bude vývoj soustředit na LTS jádra (jakkoli to zní jako blbost).

Určitě tam těch faktorů je víc, souhlas. Na druhou stranu degradace kvality života tam nezačala v únoru, poslední roky a měsíce se tam utahují šrouby docela prudce. Dovedu si představit že i tohle mohlo s plány "západně orientovaného" Komarova zatočit.

To vypadá velmi reálně. Podobné to je s nginxem, před pár dny jsem koukal na mercurial od nginxu a dva měsíce žádný commit. Předtím pravidelně každý den až týden (a samá ruská jména)...

A vážně to mají zakázané? Protože tady nevidím moc důvod proč by jim tohle někdo zakazoval. Co přibližně je v tom zákazu někdo tuší?

Jen spekuluju, ale německá firma fakturující v EUR musí nějakým způsobem ty výplaty do Ruska dostat, a to jde teď dost blbě. Hodně softwarových firem svoje ruské pobočky úplně rozpustilo z tohoto důvodu.

Možná se jich nějak týká i zákaz převozu klíčových technologií (software je taky technologie a podléhá celním embargům, např. kryptografie v USA).