Mit keres a Dropbox a kernelben?
A Dropbox fejlesztői szerint a következő nagy funkcionális ugráshoz nem lesz elég egy áthidaló megoldás, így nem az eleinte próbálgatott FUSE-t fogják használni, hanem saját, zárt forrású kernelkiterjesztést fejlesztenek. A lépés ellenzői szerint egy harmadik féltől származó, távoli szerverekkel aktívan kommunikáló, zárt forrású fájlrendszernek semmi keresnivalója a kernelszinten.
Szakmai fórumokon egész jelentős (egyelőre inkább negatívba hajló) visszhangot keltett a Dropbox azon bejelentése, hogy a "Unix-szerű" rendszereken, tehát a Linux-disztribúciókon és OS X-en (üzleti szempontból bizonyára ez utóbbi a fontosabb) a jövőben már nem kizárólag a userspace-ben fog futni a felhős tárhely asztali kliense, hanem beköltözik a kernelbe.
A cég szerint erre az egy hónapja bejelentett Project Infinite miatt van szükség: a fejlesztéssel a Dropbox képes lesz a felhasználó felé teljesen transzparensen megjeleníteni a szolgáltatásban tárolt tartalmat, legyen az lokálisan is vagy adott pillanatban csak távolról elérhető. Ez azt eredményezi, hogy az asztali kliensben nem csak a helyben is leszinkronizált állományokat lehet majd látni (ahogy ez jelenleg van), hanem minden fájlt, amit a Dropbox felhőjében tartunk – a csak távolról elérhető állományokat a kliens helyettesítő ikonnal (placeholder) jelöli.
A Dropbox szerint a megvalósításhoz első körben a nyílt forrás FUSE-hoz (Filesystems in Userspace) fordultak, amivel kernelszintű jogosultságok nélkül lehet saját fájlrendszert létrehozni és azon műveleteket végezni. A FUSE itt közvetítőként működik a kernel és a userspace között, így a fejlesztő ugyan dolgozhat saját virtuális fájlrendszerrel, de közvetlen hozzáférése a rendszermaghoz nincs. A megoldás így ugyan több erőforrást igényel (mert több lesz a folyamatban a közbeiktatott réteg), viszont pont a kiemelt jogosultságok hiánya miatt nem is okozhat akkora bajt, ha homok (biztonsági sérülékenység) kerül a gépezetbe.
Az első prototípusok alapján azonban a Dropbox fejlesztői elvetették ezt az utat, mert sem teljesítmény, sem biztonság szempontjából nem ítélték elegendőnek a kapott eredményeket. Fájlműveleteknél szerintük túl nagy az erőforráspazarlás a gyakori userspace-kernel mód közötti váltások miatt (a blogbejegyzésben linkelt tanulmány szerint 5-25 százalék közötti), ami pedig a biztonságot illeti, a fejlesztők nem akarják vállalni a kockázatot a más által írt FUSE könyvtárak (kernelkiterjesztések) terjesztésével sem.
FUSE-zal...
Az AI és a nagy full-full-stack trend Az AI farvizén számos új informatikai munkakör születik, vagy már ismert munkák kapnak új nevet és vele extra elvárásokat is.
A cég ezért saját bevallása szerint az elmúlt két év nagyobb részét egy saját kernelkiterjesztés létrehozásával töltötte, mellyel minimálisra szoríthatja az erőforráspazarlást, és a biztonsági aspektust is teljesen magáénak tekintheti. A megvalósításról egyelőre nagyon keveset tudni – Twitteren és néhány fórumon olvasható, hogy a Dropbox valószínűleg a FUSE alapjaiból épített egy zárt forrású kiterjesztést (a lépés joggal keltené fel a szabad szoftveres közösség haragját), de maga a cég erről még semmit nem árult el.
...és anélkül
A komolyabb kritikákat azonban nem is ez, hanem a biztonsági kockázat váltotta ki. Ugyan a Dropbox hangsúlyozza, hogy a tesztverziókat belsőleg már egy éve használja, és néhány ügyfél is aktívan próbálgatja, a lépés ellenzői szerint egy harmadik féltől származó, internetes eléréssel is rendelkező, zárt forrású megoldásnak nincs helye a kernel szintjén. A Dropbox szerint azonban a kernelkiterjesztés a "legkisebb és ezért a legbiztonságosabb felület, amin keresztül a Project Infinite-et meg tudják valósítani", de kitartanak amellett, hogy fejlesztésük biztonságos.