Google e l’OS color Fuchsia

11

Che Google abbia sempre qualche cosa in sviluppo, valutazione o sperimentazione è indubbio. Spesso questi progetti sono anche pubblici, ma senza pubblicità che attiri l’attenzione.

Da un paio d’anni ha in sviluppo Fuchsia, un nuovo sistema operativo costruito in casa fin dal kernel, chiamato Zircon. In questi anni ogni tanto è apparso qualche riferimento, ma è rimasto sconosciuto lo scopo, il perché sviluppare un altro sistema operativo. Lo è tutt’ora, ma adesso abbiamo qualche dettaglio su cosa sia Fuchsia, e in cosa si differenzi da quanto già visto.
Google ha infatti pubblicato la documentazione, chiamata The Book.

Fuchsia is not Linux

Fuchsia non è Linux

Le prime parole del documento (nonché il titolo del primo paragafo) servono ad affermare una cosa non ovvia, di questi tempi: il nuovo sistema operativo non è in alcun modo basato su Linux. Fuchsia ha un kernel suo e programmi suoi, tutto fatto in  casa.
Un sistema operativo è formato da almeno due parti: il kernel, che si occupa di gestire l’hardware, ed i programmi base, che danno istruzioni al kernel. Le varie distribuzioni Linux (di cui così spesso parliamo) sono una combinazione del kernel Linux e dei programmi GNU (tanto che sarebbe corretto riferirsi sempre a sistemi GNU/Linux).
Come visto quando abbiamo parlato di Meltdown, lo spazio di memoria assegnato al kernel è separato da quello dei programmi, ed anche quello che può fare il kernel è diverso: dovendo gestire l’hardware, il kernel può mandare dei comandi ai dispositivi, mentre i programmi devono usare il kernel.

Tutto in userland

Leggendo la documentazione salta all’occhio come molte funzioni, che normalmente vediamo parte del kernel (al massimo come modulo da caricare), in Fuchsia siano processi (chiamati servizi) che girano nello spazio utente.
Per esempio, per accedere ad un file normalmente viene chiamato un programma che individua il file in un filesystem (caricato nel kernel), il quale usa un driver (caricato nel kernel) per leggere i dati memorizzati fisicamente sul disco.
In Fuchsia succede una cosa molto simile, ma non identica: un programma chiede il file ad un filesystem (che è un servizio, ovvero un altro programma), il quale chiede informazioni ad un driver (che è un altro servizio) per dare le istruzioni al kernel che legge fisicamente i dati dal disco; la catena di comunicazioni quindi procede a ritroso: il driver comunica il risultato al filesystem che comunica la disponibilità o meno dei dati al programma richiedente.

Scambio messaggi, non dati

Normalmente filesystem e driver devono essere scritti nello stesso linguaggio del kernel, e ne devono condividere le strutture dati visto che usano direttamente quei dati. Questo porta ad uno svantaggio: ad ogni aggiornamento della struttura dati del kernel, il modulo deve essere ricompilato e/o in parte riscritto, per adeguarsi ai cambiamenti.
In Fuchsia i componenti sono programmi a sé stanti che comunicano tra di loro con un protocollo standard: qualunque programma, scritto con qualsiasi linguaggio, sia in grado di comunicare con quel protocollo (chiamato RemoteIO) può svolgere quel compito. Questo vuol dire anche che l’aggiornamento di uno di questi componenti (kernel, filesystem o driver) non implica l’aggiornamento di tutti, e le modifiche di funzionamento o rappresentazione dei dati interno non coinvolge gli altri componenti.

A chi è destinato tutto questo?

Non ci dilungheremo oltre sulle caratteristiche tecniche, che sono peraltro ben approfondibili grazie proprio al Libro di Google. Aggiungiamo solo che l’architettura sembra studiata per avere nativamente certe caratteristiche:

  • un alto livello di sicurezza: ogni processo è indipendente e potrebbe aver accesso solo allo stretto necessario;
  • multipiattaforma: il (micro)kernel e la modularità dei servizi permetterà di avere solo i componenti necessari su hardware embedded, mentre più generale e completo su altri tipi di hardware; inoltre, grazie al sistema a servizi non si è legati ad un linguaggio specifico;
  • facilità di manutenzione: l’aggiunta, l’aggiornamento o la rimozione di un servizio sono istantanei e indipendenti dagli altri.

Queste caratteristiche fanno pensare ad un uso che spazia dai pc ai telefonini, tanto che qualcuno ha già ipotizzato possa essere il futuro sostituto di Android e ChromeOS.
Noi crediamo sia semplicemente un po’ troppo presto per dirlo: il sistema è ad uno stadio di esercizio di stile, non ancora definibile nemmeno come versione Alpha (in cui le funzionalità base sono state implementate), quindi per poter valutare cosa effettivamente sia e dove potrebbe avere senso usare Fuchsia ci vorranno ancora anni.

In compenso, ci fa molto piacere che esista, e che si stia sviluppando tanto velocemente, un’alternativa. Opensource, naturalmente.

Ho coltivato la mia passione per l’informatica fin da bambino, coi primi programmi BASIC. In età adulta mi sono avvicinato a Linux ed alla programmazione C, per poi interessarmi di reti. Infine, il mio hobby è diventato anche il mio lavoro.
Per me il modo migliore di imparare è fare, e per questo devo utilizzare le tecnologie che ritengo interessanti; a questo scopo, il mondo opensource offre gli strumenti perfetti.

11 risposte a “Google e l’OS color Fuchsia”

  1. Avatar Kim Allamandola
    Kim Allamandola

    Mh, l’idea dei microkernel non è nuova, l’idea di un certo tipo di modularità manco (da Hurd a Inferno) tuttavia dubito che possano realmente creare un OS moderno (anche se per molti aspetti ne abbiamo bisogno) all’interno di un’azienda per illuminata e grande che sia, quando la gestione di quest’ultima è manageriale: innovazione a managerismo sono un’ossimoro. Il manager non può mentalmente creare nulla, solo ingegnerizzare l’esistente.

    Quanto all’esser open: non basta. Se non è sviluppato da una community morirà se muore l’upstream, andrà dove l’upstream lo vorrà far andare. Un progetto oggi per esser considerato sicuro dev’essere sviluppato da una vasta e variegata community. Linux lo è come GNU, Fuchsia come WebKit e tanti altri non lo sono.

  2. Avatar Ivan Guerreschi
    Ivan Guerreschi

    Volevo chiederti cosa ne pensi di GNU Hurd, se ha un senso in qualche ambito o è solamente il kernel di riserva di GNU/Linux

  3. Avatar Kim Allamandola
    Kim Allamandola

    L’idea è interessante (e incorpora idee di Plan9, come il tutto è un file, ma veramente tutto), è molto robusto ed essendo realmente modulare permette di aggiornare singole componenti senza riavviare, permette di riavviare parti del “kernel” in caso di crash ecc ma è semplicemente partito troppo tardi e si è evoluto troppo lentamente, IMVHO oggi è praticamente impossibile recuperare… Puoi provarlo con NixOS/Arch/Debian, forse tra un po’ anche GuixSD, ma dato il supporto hw nullo solo in una vm (qemu) e essenzialmente non si vede nulla di che… Vedi al massimo com’è facile operare a livello di fs, per dire cd “dentro” un’iso o una risorsa di rete ftp/dav come fosse una directory locale ma praticamente null’altro.

    Oggi purtroppo il kernel (o la parte di userland che su GNU/Linux è in-kernel) è qualcosa che non interessa più a nessuno, persino server side dove un tempo compilarsi un kernel custom era la norma oggi è una pratica sostanzialmente scomparsa, non si sente più alcuna necessità. Non interessano manco più le performance, per dire nonostante GNU/Linux su 40Gb ethernet viaggia alla metà grossomodo di FreeBSD sullo stesso ferro si preferisce GNU/Linux perché tanto è più noto, è più “certificato” ecc. Su FreeBSD ci sono da eoni le jails che sono assai superiori a lxc/d/docker, forse arriveranno le zones di IllumOS che sono a loro volta un ordine di grandezza superiori alle jails ma nulla, si va sul mainstream.

    Se sei curioso puoi anche provare altri OS ispirati da plan9, i più noti
    “semi-usabili” a livello domestico (qemu) sono Plan9 stesso, 9front,
    Inferno, Harvey OS e AkarOS. Puoi anche provare utilities di Plan9 in
    GNU/Linux (es. plan9port, glendix ecc). A livello professionale sono
    usati in HPC e ricerca, a livello cloud credo che Amazon sia il più
    grande “implementatore” di pezzi di tecnologia Plan9… IBM con il port
    di Plan9 per Blue Gene è forse il progetto più noto. Per far qualche esempio di quanto comodo fosse plan9 pensa a fuse, che deriva concettualmente da lui, pensa al semi-scomparso HP The Machine, ovvero il “cloud distribuito” secondo HP.

    Il GROSSO problema che abbiamo è che negli anni ’60-’70-’80 era NORMALE fare progetti di lungo periodo con obbiettivi distanti anni nel tempo e rivoluzionari, dalla metà degli anni ’80 in poi s’è solo fatto ordinaria amministrazione, non si possono più fare progetti di lungo periodo in un mondo guidato dalla logica manageriale e non si possono più fare progetti rivoluzionari con tecnici formati da università moderne ovvero gente formata per imparare a memoria tonnellate di nozioni e del tutto mortificati se vogliono uscire dal seminato. Prendi solo come esempio un testo “anziano”, diciamo anni ’50/’60, provalo, si legge bene, scorrevole, apre un mondo e non è mai conclusivo ti indica in ogni sua parte innumerevoli vie da esplorare, approfondire. Il corrispondente testo moderno è un mattone molto più grande, con contenuto informativo eguale o minore e appare conclusivo in ogni sua parte, non lascia spazio a nulla, lo scibile deve ritenersi esaurito alla fine di ogni capitolo. Questo è lo stile moderno. Il manager moderno poi vuole risultati per ieri, break even entro pochi mesi e solo evoluzione lineare, perché ciò che “va fuori dal seminato” è troppo difficile da inquadrare. GNU ci ha provato mantenendo il “vecchio” modus operandi, ma in mancanza di teste giovani, fresche, appassionate non riesce a sfondare più di tanto…

    Temo che sino a quando la torre di babele attuale sarà tenibile in piedi in qualche modo con scotch e puntelli nulla cambierà veramente, si aspetterà l’ingestibilità completa quando oramai non avremo più tecnici vecchia scuola né più quasi memoria di tutte le tecnologie valide perse in passato.

  4. Avatar Ivan Guerreschi
    Ivan Guerreschi

    Sei un’enciclopedia vivente grazie mille, mi hai dato spunto per la scaletta di studio per la prossima settimana 🙂
    Spero che GNU Hurd sia ben integrato su GuixSD così da poterlo provare con questa distribuzione che sto provando adesso, per adesso voglio provarlo con mamma Debian.
    Per il resto ti do perfettamente ragione non vedo nulla di veramente rivoluzionario a lungo termine ormai, sto leggendo qualcosa sulla SUN e non capisco ancora come sia fallita dopo tutte le innovazioni che ha portato sia in ambito hardware e software

  5. Avatar Kim Allamandola
    Kim Allamandola

    Mah, non so se sarà ben integrato o meno, ad ogni buon conto non sarà usabile fuori da QEMU, quindi non usabile installato sul ferro… Ci potrai giusto giocare. Per il resto che vai di Debian, Arch o NixOS (che è la base di GuixSD) puoi usarci sopra ogni applicazione ed userland che vuoi, concretamente al di fuori dell’esplorazione personale potrai giusto divertirti a dare un ls di un indirizzo ftp o http, dare cd come sopra e vedere diciamo le risorse di rete come un fs locale, solo un po’ lento in base alla connessione. Cosa che sarebbe di estrema utilità se diffusa, su Plan9 che va un po’ oltre per capirci tu puoi “loggarti” tanto in terminale quanto in ambiente grafico su qualsiasi host che accetta connessioni in maniera del tutto trasparente, come se avessi un ssh embedded all’ennesima potenza. Puoi per dire avere Blender con un rendering pesante su una macchina “tosta” remota nella sua finestra sul tuo display server locale, nel contempo Firefox è una finestra condivisa con un’amica a cui stai dando supporto, come foste via TeamViewer/ImPcRemote/Anydesk ma singola applicazione, e a lato il tuo file manager locale. Il tuo telefono accede ai files del tuo desktop allo stesso modo in maniera trasparente e sincronizzata come fosse un IMAP ecc. Essendo il tutto a livello di sistema lato applicativo non servono sforzi particolari. È un “cloud distribuito”, privato, all’ennesima potenza. Purtroppo manca, ovvero non essendoci che 4 gatti sopra ti manca tutto il layer applicativo sovrastante, puoi solo immaginarlo visto ciò che fai girare in locale/tra due hosts in LAN…

    In altri termini sarà un po’ frustrante da tirar su, ti farà dire “che figata!” ma poi finirà tutto li perché alla fine non c’hai nulla da fare sopra…

    Se sei curioso c’è una cosa che invece puoi usare con un certo profitto: nilfs2, un fs mainline in Linux da un po’ di anni e tutt’ora sviluppato che è versioned, come molti OS classici da Plan9 a OpenVMS. Puoi vederlo come una sorta di nix/guix store per il filesystem. Ogni cambiamento crea “un ramo a se” e tu puoi attraversare l’albero dei cambiamenti, lo spazio fisico su disco sono solo le differenze e c’è una garbage collection sia automatica che manuale. È abbastanza stabile da poterci metter sia la /home che anche la /. GuixSD e NixOS lo supportano senza problemi nelle hardware config standard. C’è anche una comoda GUI per “esplorare” graficamente con un filemanager i vari “rami” : nilfs_gui…

    Sulla SUN: ha fatto molte cose rivoluzionarie ma ha avuto una gestione PESSIMA e molte suoi straordinari progetti sono arrivati in ritardo… Per dire si è accorta che Sparc pur eccellente era troppo caro per la maggior parte degli usi circa nel 2004. Ha creato una bella linea x86 di tutto rispetto e con costi assolutamente competitivi (server 1U/2U detti SunFire e workstation ovvero desktop SUN W1100z e W2100z), l’ha tenuta senza granché pubblicizzarla sino al 2006, poi ha detto basta. Molto prima creò Java senza tentare neppure di spiegare al mondo quale fosse il suo obiettivo (un nuovo OS composto da kernel con JVM in-kernel ed userland fatto essenzialmente di “progetti java” ovvero pkg con nomi di dominio inversi, .class, .jar ecc.) e alla fine ha lasciato sfumare quell’obbiettivo. Molto prima aspettò anni per rendersi conto che l’smp era il futuro e ci arrivò con una lentezza mostruosa, in ultimo lanciò OpenSolaris capendo che il futuro doveva essere FOSS ma oramai già a ridosso delle trattative con Oracle. E non è la sola big di unix ad aver fatto scelte disastrose, prima di lei pensa all’SGI (da cui oggi abbiamo ad es. le OpenGL, che sono le librerie grafiche di IriX), prima ancora la DEC… Praticamente tutte le unix company sono rimaste troppo elitarie e troppo convinte di poter vivere sopra il mondo perché (effettivamente) superiori… Purtroppo questo in un mondo mediamente ignorante e con una spinta commerciale sopra quella tecnica…

  6. Avatar Ivan Guerreschi
    Ivan Guerreschi

    Ho avuto tempo di giocare un pochino con Debian Hurd questa settimana ed è come dicevi tu, mi sono divertito un pochino ma nulla di più e trovo che sia ancora molto limitato su certe cose. Invece trovo molto potente e di facile uso nilfs2, per adesso ho giocato anche con lui con una partizione e una chiavetta, ma voglio provare la soluzione che mi hai descritto magari con un sistema NixOS

  7. Avatar Kim ALLAMANDOLA

    È molto stabile e a livello di performance non è malaccio, specie se sei su SSD. Non ti aspettare però un successo strepitoso nel senso che creando un “cp” ad ogni write()(checkpoint ovvero quel che su zfs si chiamerebbe snapshot, la sola differenza è che il garbage collector lo eliminerà appena serve spazio fisico su disco mentre lo snapshot viene conservato sino a quando non lo butti via tu) e questo ha solo un id numerico, devi “convertirlo” (al volo, chcp ss $numero_cp, è istantaneo) e poi montarlo da qualche parte (mount -t nilfs2 -r -o cp= /dev/nilfs2_device /path/che/ti/pare) non puoi “fare un diff al volo” (stile zfs diff $vol@$snap) o chessò vedere qualcosa come la cronologia di quel che copi in un clipboard manager di X.

    Ora siccome di write ne hai in genere tante in una /home come in /var ecc ti trovi un mare di cp e l’unico caso “comodo” è se cancelli per sbaglio un files perché prendi un cp a caso un po’ più vecchio e sai che lo trovi alla prima. Altrimenti devi montarti uno per uno i cp, diff-arli e vedere il “cambiamento” che ti interessa. Questa macchinosità lo rende “scomodo” e quindi non sfonda nonostante l’idea sia fantastica. È comunque comodo e per un desktop moderno con SSD per me è la miglior alternativa allo zfs o al più all’f2fs (recente, meno stabile, + performante, creato apposta per gli ssd da Samsung e mainline anche lui), col bonus che allunga pure la vita al devices distribuendo le write sull’intero ssd anziché riscrivendo sempre gli stessi blocchi. Se solo fosse stato sviluppato con l’admin in mente anziché con lo sviluppatore, come fu per lo zfs sarebbe una vera “killer solution”. Potrebbe anche esserlo in un prossimo futuro (fortunatamente il progetto è vivo e attivo) quando avrà la possibilità di crescere e dimagrire facilmente. Se avesse un pool come lo zfs beh, avresti la possibilità di dividere in n volumi un “pool” così da limitare il numero di cp per volume e quindi localizzare al volo un cambiamento che ti interessa…

    In futuro spero e se ti piace sperimentare te lo consiglio per gioco sin d’ora, perché questo non è mainline ne production-ready, è bcachefs che dovrebbe essere il futuro zfs vivo per GNU/Linux, altra base di codice, migliori e maggiori funzionalità 🙂

    Per me oggi bcachefs è per gioco, nilfs2 è il default su tutto ciò che non metto sotto zfs.

  8. Avatar Ivan Guerreschi
    Ivan Guerreschi

    In effetti ho trovato un po’ macchinoso montare ogni volta uno snapshot sarebbe bello avere qualcosa di più immediato. Bcachefs lo proverò sicuramente e spero venga integrato a livello kernel visto che ne hai parlato così bene, non capisco come mai la Microsoft non abbia mai sviluppato o integrato filesystem evoluti come invece è abitudine del mondo Unix GNU/Linux

  9. Avatar Kim ALLAMANDOLA

    Beh ntfs è un fs abbastanza “evoluto” (ad es. supporta piuttosto bene gli snapshot, chiamati “punti di ripristino” tanto per confondere le acque), solo che non è commercialmente interessante avere soluzioni di storage evolute: ricordi quando la SUN annunciò zfs che Netapp si infuriò chiedendo di rendere chiuso e proprietario il progetto altrimenti avrebbe “ucciso il mercato dello storage”? Se avessimo storage evoluti comuni, magari pure con georeplica “lazy-sync” quanto interesse ci sarebbe per il cloud di turno?

    Per nilfs2 si parlava tempo fa, ma non so lo stato della cosa, di esporre una piccola API che permetta di vedere un “diff” o per lo meno accedere alle “versioni precedenti” per-directory essendo teoricamente semplice implementare questa feature… Può essere che arrivi in qualche anno 🙂

    Su bcachefs penso l’attesa sarà ancora lunga perché sono ancora molte le features che deve sviluppare. Han scelto (bene IMVHO) di creare un formato stabile on-disk per renderlo usabile e “stabile” da subito, ma han ancora molte feature da implementare. Cresce, non molto velocemente ma cresce!

  10. Avatar Ivan Guerreschi
    Ivan Guerreschi

    Tra l’altro la NetApp fece causa alla SUN e perse, di sicuro aveva paura. Zfs è davvero un bellissimo pezzo di codice usato con FreeBSD ma non è un firstclass upstream Linux filesystem o almeno da questa impressione e la licenza di zfs non aiuta la causa. Comunque mi piacerebbe sperimentare tantissime cose ma il tempo è sempre poco, ma non voglio fare l’utente passivo di tecnologie e quando posso le studio e le provo. Grazie mille per i tanti spunti che dai nei tuoi commenti

  11. Avatar Kim ALLAMANDOLA

    Ci mancherebbe! È attraverso la comunicazione che evolviamo tutti.

    Sullo zfs posso solo dire che purtroppo è uno zombie. Oracle non ha semplicemente le teste per mandarlo avanti, tutti gli ex-SUN di vaglia sono scappati poco dopo l’accordo, IllumOS che vuol essere la continuazioni di Solaris da parte degli stessi che ci lavoravano alla SUN non ha semplicemente risorse per far nulla di più di tenere il codice in modalità “bugfix” che grossomodo vuol dire in pratica tenerlo compilabile e se possibile in grado di girare su ferro fisico ma nulla di più. OpenIndiana fa lo stesso e Nexenta&c sono di fatto delle navi alla deriva senza possibilità di ritrovare una rotta… Il LLNL ha fatto un eccellente lavoro di porting su GNU/Linux e lo zfs è ragionevolmente stabile da usarlo sul proprio desktop personale e pure su qualche server non troppo importante ma dallo stato attuale non si muoverà più. Se vuoi provarlo NixOS lo supporta senza problema alcuno, Arch con repo di terze parti ma comunque stabile, Ubuntu devi installarlo a mano (iow fuori dall’installer) se vuoi la root sotto zfs ma anche li ti trovi tranquillamente bene.

    Ad oggi è ancora il top, bcachefs è un ragazzino che gioca a costruire un carroarmato di lego guardando timidamente a quello di ferro, nilfs è poco più di un trattore con 4 placche sopra al confronto ma questi han ancora uno sviluppo, lo zfs purtroppo non più. La sola cosa che mi auguro è che avremo su GNU/Linux una gestione dello storage avanzata, comoda, efficacie quanto lo zfs prima di 10 anni, visto che già da almeno 10 sappiamo come farlo assai bene… Questo è il problema dello sviluppo commerciale. Le idee che rendono denaro avanzano, quelle che possono rivoluzionare in meglio la vita ma non rendono altrettanto no. Aver problemi significa pagare supporto, avere complessità significa pagare training e non poter saltare facilmente da un vendor all’altro…

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *