Come sicuramente molti di voi sanno, la possibilità di utilizzare un sistema desktop completo a partire dal proprio smartphone è da parecchio tempo un obiettivo di tutto il mondo geek. I due esempi più lampanti di questo fatto sono sicuramente Canonical con Convergence di Ubuntu Touch e Microsoft con Continuum di Windows 10 Mobile. Finora sono stati fatti anche dei tentativi di rendere Android un sistema desktop, mi vengono in mente RemixOS e PhoenixOS che stanno raggiungendo dei risultati molto interessanti. Tuttavia non mi era ancora capitato di vedere su Android qualcosa di simile a Continuum o Convergence, ma con Maru OS le cose sono destinate a cambiare presto.

L’obiettivo che si pone Maru OS, il cui sviluppo è portato avanti dallo sviluppatore Preetam D’Souza, è quello di permettere agli utenti di sfruttare tutto il potenziale del proprio smartphone Android trasformandolo in un desktop Linux completo semplicemente collegandolo ad un monitor via HDMI ed a una tastiera e mouse bluetooth.

Lo stesso creatore durante un’intervista ha dichiarato quanto segue: “Attualmente utilizziamo soltanto una piccola porzione della potenza di calcolo dei nostri dispositivi per rispondere alle chiamate, mandare messaggi ed utilizzare piccole app. Molto spesso però quei dispositivi mobili sono più potenti dei nostri laptop.” L’obiettivo dello sviluppatore è dunque quello di rendere fruibile tutta la potenza di uno smartphone e renderlo così uno strumento molto più produttivo.

Maru OS - 2

Per raggiungere l’obiettivo Maru OS sfrutta una combinazione di Android 5.1 AOSP e Debian. Stando a quanto dichiarato da D’Souza, in sostanza ci sono due sistemi che girano sullo stesso kernel, la cui visualizzazione viene gestita utilizzando il progetto Linux containers. Quello che rende Maru OS molto particolare è il modo in cui integra il desktop Linux nel display stack di Android: quest’ultimo infatti gira come sistema host e Linux viene eseguito come sistema ospite mentre entrambi condividono lo stesso kernel. In questo modo è anche possibile condividere i file fra Android e Linux. Il creatore del sistema ha dichiarato di aver scelto Debian come sistema Linux perché è quello con cui si trova più a suo agio, ma ha anche aggiunto che Maru OS è un framework che può lavorare con qualsiasi distribuzione.

Attualmente lo stato di sviluppo di Maru OS si trova in fase Beta ed è portato avanti dal solo creatore Preetam D’Souza che ha raggiunto questo punto con un anno di lavoro. Per il momento il sistema funziona soltanto su Nexus 5, questo perché si tratta dell’unico dispositivo a disposizione dello sviluppatore. Nei piani di D’Souza c’è anche quello di rendere tutto il suo lavoro open-source, eccezion fatta per i driver proprietari che ha utilizzato, con la speranza che un maggior numero di persone possano lavorare sul progetto e portare Maru OS a funzionare su altri dispositivi. Qui di seguito un piccolo video dimostrativo:

Ulteriori informazioni sono disponibili sul sito ufficiale del progetto che trovate a questo indirizzo. Se lo desiderate potete anche iscrivervi alla mailing list per essere aggiornati su tutte le novità riguardanti questo interessante sistema.

Che impressioni vi ha fatto questo Maru OS? Sareste curiosi di provarlo? Fateci sapere cosa ne pensate con un commento!

[Fonte]

  • MarcoLinux

    ah ah ah ma possibile che costui, è riuscito a fare cio che Cannonical millanta da anni, in così poco tempo ?

    • Porca miseria… lo pensavo pure io.

      Comunque hai ragione, Canonical secondo me si è persa per strada.

      • floriano

        Troppi progetti contemporaneamente….

        • Aury88

          no, troppe modifiche necessarie da sviluppare prima di avere un sistema utilizzabile con continuità e sicuro…alla fine non hanno sviluppato nulla di più che fosse strettamente necessario alla convergenza…quindi o così o nulla, e se lo vuoi così questo richiede tempo.
          ps: UT con capacità di convergenza è in circolo ormai da un annetto (purtroppo sfruttabile solo da nexus4)

    • elios93

      Secondo me semplicemente Canonical ha interrotto lo sviluppo per diversi motivi: 1) Google non lo avrebbe mai implementato di default, 2) avrebbe dovuto inseguire per strada il progetto per mille dispositivi diversi e per ogni nuova versione di Android, 3) sarebbe stato molto più redditizio per l’azienda introdurre quest’idea in un sistema mobile solo suo (come sta facendo ora con Convergence) e con questa mossa avrebbe anche potuto evitare i primi due problemi avendo il pieno controllo sull’OS.

    • Aury88

      no, non è possibile e infatti non ha fatto la stessa cosa….non ha scritto un sistema operativo per smartphone da zero, non ha neanche apportato grossi cambiamenti al sistema operativo che si usa in desk mode…non ha realizzato un interfaccia adattabile o un esperienza continua tra smartphone e il desk…ne i programmi che girano su desk sono utilizzabili su smartphone e viceversa (almeno per il momento).
      senza voler sminuire l’incredibile lavoro dello sviluppatore di MaruOS, le due cose sono molto differenti e solo chi non ha capito o non sa cosa stia cercando di realizzare canonical (un so universale utilizzabile ovunque con l’interfaccia che si adatta al sistema I/O , non due so tra qui scegliere e lanciare in base a cosa si collega allo smartphone) può sembrare uguale.
      qui di unico c’è il kernel, ma i due ambienti sono totalmente differenti.
      questo ha dei vantaggi (la relativa facilità nel realizzare il sistema “adattabile” ) ma anche degli svantaggi come il dover “sdoppiare” il software per fare lo stesso lavoro nelle due modalità (a partire dall’interfaccia/displayserver a finire per tutti quegli applicativi in utilizzo sia su desk che su smartphone come file manager, client mail, browser, lettore multimediale ecc ecc) e la difficoltà nel creare continuità tra le due modalità (per fare un esempio la mail incompleta sullo smartphone che si vuole continuare in modalità desk).

      canonical non ha”millantato” nulla. la convergenza è stata “promessa” da anni ed è stata “realizzata” da mesi (un annetto se consideriamo il solo device develop).

      • Teo

        Ok. però il risultato è lo “stesso”, se ti serve un OS da PC, colleghi lo smartphone e sei pronto, aldilà di tutte le differenze sostanziali che hai giustamente elencato.

        • Aury88

          anche una bici ti permette di spostarti dal punto a al punto b esattamente come una lamborghini…peccato che lo spostarsi dal punto a al punto b sia solo uno degli aspetti.

          è chiaro…entrambi danno la modalità desk e MaruOS indubbiamente permette di ottenere brillantemente questo risultato….ma limitare ubuntu a questo solo aspetto è estremamente riduttivo e non considera appunto le differenze sostanziali che sono il motivo della differenza nel tempo di sviluppo (che era la cosa che l’utente sopra non si spiegava)

          personalmente non è solo l’avere il pc nello smartphone che mi interessa, ma avere un solo sistema…la differenza è la capacità di lavorare con continuità passando da una modalità all’altra…almeno, io la vedo così. c’è a chi basta avere il pc nello smartphone e allora maruos sarà più che adeguato per lui.

        • il risultato non è lo stesso.
          è completamente diverso

          • Teo

            Hai ragione. Debian è più stabile e affidabile : – )

          • ange98

            Debian è più stabile e affidabile : – )

            Stabile e affidabile != vecchio e antiquato.
            Per quanto a me la questione della convergenza non faccia impazzire particolarmente, questo progetto vale zero se confrontato con quello che sta facendo Canonical.
            È praticamente poco più di un dualboot, non mi pare niente di sensazionale. Tra l’altro è anche malfatto e poco curato (vedasi com’è stato “customizzato” Xfce per esempio)

          • Teo

            ma certo che quello che sta facendo Canonica è tutt’altro, non ci sono dubbi su questo.
            Comunque ” != ” significa non uguale, ovvero diverso, quindi hai scritto che “Stabile e affidabile non è uguale a vecchio e antiquato” ; )

          • Samael

            Beh, è la verità.
            Slackware, per dirti, ad ogni release ha quasi sempre le ultime versioni dei software che compongono la distro. Eppure è stabile quanto Debian.

            Anche Windows e OSX sono OS stabili, sebbene i software di terze parti siano spesso aggiornati in quanto non legati alla piattaforma sottostante.

            La teoria del “vecchie versioni == pacchetti stabili” è una stupidaggine colossale già smentita da tempo, ed è più una scusante per giustificare un comportamento idiota che purtroppo ci ritroviamo in quasi tutte le distro Linux: il parco software che invecchia insieme all’OS.

          • Teo

            beh dai, però io non mai avuto problemi con le applicazioni su Debian stabile, funzionano a dovere e non danno problemi , che poi si possa fare qualcosa di meglio, sono d’accordo con te, Su Chakra ad esempio, che considero un’ ottima ed elegante dietro è da un po’ di tempo che sto avendo problemi con K3b, mi falla 2 masterizzazione su 3.

          • Samael

            Non fraintendermi, Teo. Non è una questione di avere o meno problemi.

            Neanche io ho avuto problemi con applicazioni vecchie. I problemi sorgono nel momento in cui io cerco di avere applicazioni aggiornate su una base solida.

            Alla fine dovrei essere io utente a decidere se e quando aggiornare il mio parco software. Sono io, sulla base delle mie esigenze, che dovrei rendermi conto se una determinata applicazione necessita un downgrade oppure no. Mentre adesso è tutto deciso a priori e tutto collegato fra loro.

            Che poi è anche il motivo per cui spesso gli avanzamenti della distribuzione creano problemi. Troppe ragnatele che creano una situazione delicata e che portano spesso a rotture di compatibilità col software.

            Molto spesso si dice che Linux non è retrocompatibile come Windows, ma questa è una bugia.
            Linux è retrocompatibile come e più di Windows. Semplicemente le rotture di compatibilità sono date da scelte politiche, tipo la creazione di ragnatele di dipendenze.

          • michele casari

            Il progetto snappy di Canonical? Dovrebbe risolvere il problema delle dipendenze, ancor prima i bundle (non sono sicuro del nome) di chackra per le applicazioni GTK.
            Slackware, ahi me, hai toccato un punto dolente (per me). L’ho usata per anni senza avere problemi, ma per quanto riguarda il software (‘ufficiale’) esce si con le ultime release, ma per anni non si aggiorna. Certo c’è sempre la possibilità di aggiornare manualmente, o appoggiarsi al comodo slackpkg+, ma in entrambe i casi ti basi sul lavoro di un singolo, anche l’intero KDE 5 se lo vuoi (la 14.2 ormai è chiaro che esce con la 4.x) devi affidarti ad un singolo (il grande Alien).

          • Samael

            Snappy ha idee molto più vaste del singolo bundle per applicazioni di terze parti.
            Snappy ha intenzione di gestire l’OS a tutti i livelli. Può essere la soluzione al problema come potrebbe essere un fiasco, ma finché non lo vedremo in azione su un desktop è difficile capire quanto potrà essere fattibile.

            Per quanto riguarda Slackware, in realtà in dieci anni ha stabilito più o meno una regolarità di una release all’anno.
            2004 => 10.0
            2005 => 10.1, 10.2
            2006 => 11.0
            2007 => 12.0
            2008 => 12.1, 12.2
            2009 => 13.0
            2010 => 13.1
            2011 => 13.37
            2012 => 14.0
            2013 => 14.1
            Solo la 14.2 ha interrotto lo schema.
            E riguardo KDE5, ci sono diversi problemi attorno a quel desktop. Il primo è che lo stack Applications non è ancora completamente libero dal runtime di KDE4 ed il secondo è che la loro politica verso systemd non è ben chiara, vedasi la storia di SDDM che voleva solo supportare logind e della presenza esplicita di rimandi a journalctl in Plasma.

          • Aury88

            le necessità desktop non si discostano poi molto dalle necessità smartphone o anche solo IoT o cloud e in questi due campi snappy è già parecchio che dimostra di funzionare…gli unici settori in cui non è ancora stato utilizzato appieno sono il desk e, credo, il supercomputing.
            i vantaggi per il desk sono specialmente per il software di terze parti (che non devono più rilasciare una nuova versione del proprio software ogni volta che viene cambiata una dipendenza sul so) ma naturalmente non è limitato solo a quello.
            i vantaggi per il desk sono abbastanza oggettivi e snappy risponde a specifiche richieste di utenti, aziende (software sicuro e aggiornabile senza toccare il resto del so) e sviluppatori(programmare una sola volta per tutte distro e le loro versioni ), quindi non penso si pecchi troppo di ottimismo se si dice già da adesso che sarà la soluzione a molti problemi…il problema è imho che per diventare veramente conveniente per gli sviluppatori snappy dovrebbe venir usato da più distro…ora come ora gli sviluppatori risparmiano solo la fatica di dover testare ed eventualmente aggiornare per ogni nuova versione della sola ubuntu…

          • Samael

            le necessità desktop non si discostano poi molto dalle necessità
            smartphone o anche solo IoT o cloud e in questi due campi snappy è già
            parecchio che dimostra di funzionare

            Non è così.
            Nel cloud e nell’IoT la situazione è meno complessa del desktop, ad onor del vero.
            Il cloud non ha nemmeno bisogno di un sistema operativo in pianta stabile. Puoi tranquillamente tenerlo su una chiavetta e fare il boot, come fa SmartOS. Tecnicamente non hai nemmeno bisogno di un package manager per gli aggiornamenti, perché ti basta un sistema di diff binario in stile FreeBSD ed hai risolto i problemi.
            Nel cloud il compito non è far girare applicazioni bare-metal, ma interi stack virtualizzati.
            Senza contare che lì non hai bisogno di rivedere il concetto stesso di policy e di autorizzazioni per renderle flessibili, in quanto gli scenari di cui tener conto sono decisamente limitati rispetto al desktop.

            Metterli sullo stesso piano è un azzardo non da poco.
            Ed il fatto che Snappy stia funzionando lì non ti dà la sicurezza matematica che funzioni anche sul desktop.
            Senza contare che sebbene si possa mitigare le vulnerabilità, bisogna vedere la sostenibilità a lungo termine di mantenere duplicati di runtime, e su questo c’è persino il problema che Canonical è stata poco chiara avendo dato troppa libertà di scelta agli sviluppatori che possono scegliere se e quanto condividere con il resto del sistema. E se a questo ci aggiungi che GLIBC non è tanto amichevole quando si tratta di staticizzare, allora capisci che prima di dire che funziona bisogna vederlo in azione in contesti come il desktop, laddove le necessità sono molto più variegate e gli scenari da tener conto molteplici.

          • Aury88

            Mi sono espresso male…Intendevo più come funzionamento…snappy funzionano e ci sono più settori in cui dimostrano di funzionare.
            Nel cloud e IoT è vero che le necessità sono molto differenti e infatti a mio avviso li snappy aveva meno senso di quanto non ne abbia su desk proprio per la minore “variabilità” dell’ambiente su cui dovrebbero girare gli applicativi e quindi il minor sforzo comunque per lo sviluppatore proprio perchè non dovrebbe comunque fare il testing e l’eventuale porting delle dipendenze del proprio applicativo su più ambienti…lì sono stati usati quindi solo in virtù della loro sicurezza e, sopratutto, la capacità di upgrade/downgrade in caso di malfunzionamento.
            sul desk il problema delle dipendenze e della loro versione è un dato di fatto quindi è indubbia la comodità del non doversene più preoccupare..tanto più se il sistema snappy verrà adottato da altre distro.

            non ho capito il discorso del package manager…cioè capisco che su iot e cloud (e aggiungerei server) non sia strettamente necessario, ma non capisco il punto della questione da te sollevata… proprio perchè non ne hanno bisogno avrebbero un motivo in meno di usare un package manager come snappy, no?

            non rispondo su glibc e runtime perchè non conoscendo bene il campo non vorrei dire stupidate…dico solo che avevo letto che cose corpose, largamente utilizzate e generalmente retro-compatibili come glibc sarebbero rimaste “condivise” come lo sono attualmente.

            A parte tutto comunque sia sono fiducioso…specialmente perchè c’è stato un forte apprezzamento da parte di moltissimi programmatori (naturalmente esterni a canonical) e progetti di applicativi desk (anche molto importanti) e imho se per loro una cosa risulta essere comoda vuol dire che la scelta non può essere poi così sbagliata, no? 😉

          • Samael

            Certo che è un dato di fatto il problema delle dipendenze. Il punto però è che bisogna vedere la sostenibilità nel modello proposto da Canonical. Non basta dire: pacchettizzate come volete e fine dei problemi, perché come ho detto ci sono enormi problemi a livello di GLIBC quando si staticizza, e Canonical non ha mai dato indicazioni chiare in merito.
            Ti faccio un esempio: su XDG-APP (oggi Flatpak) si è deciso che i runtime devono essere condivisi sempre e comunque per ridurre la ridondanza. Ciò però non vuol dire che la situazione sia uguale a quella attuale, perché i runtime possono anche essere molteplici ed installati in parallelo.
            In sostanza, si è scelta una via simil-Windows. Hai presente il Visual C++ Runtime Redistributable che è richiesto in varie versioni a seconda del software? Ecco, proprio come quello.
            Solo che i runtime vengono distribuiti in automatico quando un software ne fa uso.

            Su Snappy non c’è niente di simile. Si è semplicemente detto: volete condividere? ok. Volete staticizzare? ok. Fate come vi pare.
            Questa cosa può andare bene nel mobile dove le applicazioni non sono complesse come quelle desktop. Può andare bene nell’IoT. Ma su un desktop/workstation no. Serve una politica definita, altrimenti si rischia il caos, perché i software sono spesso complessi e richiedono molta più manutenzione. E questo è anche uno dei motivi per il quale si è scelto di fare package freezing e di bloccare le versioni dei software nei repository.

            E no, GLIBC non è retrocompatibile per nulla, perché ha il maledettissimo vizio di fare versioning dei simboli in ogni header di un binario.
            Quando vuoi usare un software su più distro, la copia della libc è la prima libreria che ti devi portare appresso, altrimenti rischi errori in runtime.
            Per questo molti scelgono di staticizzare. Tuttavia GLIBC (Ulrich Drepper) è contro ogni forma di staticizzazione, al punto che ha volontariamente aggiunto simboli inutili che rendono inutilmente bloat i binari.
            Per questi motivi dico da sempre che GLIBC è un cancro ed è la peggior libc che si possa usare.

            Senza contare che non penso proprio che Snappy possa uscire fuori dall’ecosistema di Canonical, sia per i motivi di sostenibilità che ti ho citato e sia perché è progettato per essere un superset al packaging di Debian e che vuole l’integrazione con AppArmor.

            proprio perchè non ne hanno bisogno avrebbero un motivo in meno di usare un package manager come snappy, no?

            Infatti proprio per quello ho scritto che tecnicamente non ne avrebbe nemmeno bisogno. xD

            Per quanto riguarda gli apprezzamenti, ripeto: prima di giudicare le cose vanno viste in azione. Non sto dicendo che Snappy è un mer*a. Sto dicendo che prima di definirlo la panacea, bisogna andarci piano e usarli per bene.
            A parole tutti possiamo essere entusiasti di una cosa. Poi però bisogna fare i conti con la realtà.
            Anche con HAL all’epoca erano tutti entusiasti, salvo poi scoprire che era una porcheria e che andava buttato via. Poi venne sostituito con upower/udisks e tutti di nuovo erano entusiasti. Ma anche stavolta si sono accorti che questi due sono un’altra porcheria che funzionano peggio di HAL.

          • Aury88

            bhe…come puoi vedere ho ragione io….non ne capisco nulla di glibc e runtime in generale XD
            comunque sia ogni tot fanno un QA su hangout…potrebbe essere una domanda interessante…se capissi meglio il discorso farei io stesso la domanda :-/

          • ange98

            So cosa vuol dire ed è giusto così 🙂
            Debian ha software vecchio e antiquato (nella stable perlomeno) che non ha senso per un utilizzo Desktop, software non al passo coi tempi solitamente. Questa concezione per me è totalmente differente dal concetto di “stabile ed affidabile”, pertanto “software stabile ed affidabile != software vecchio e antiquato”.
            Ma questa è solo una vecchia battaglia tra debianisti e non.
            Mi spiace che si sia frainteso ciò che intendessi comunque

          • holmannus

            “Debian ha software vecchio e antiquato (nella stable perlomeno) che non
            ha senso per un utilizzo Desktop, software non al passo coi tempi
            solitamente”. Dipende dall’uso che fai del desktop. In un ufficio, una volta aggiornato il browser, cosa te ne fai dell’ultima versione di Libreoffice?

          • Teo

            Vero, tra l’altro se un’ applicazione funziona bene perchè dovrei cercare a tutti i costi l’ ultima versione rilasciata, che magari aggiunge solo la traduzione in aramaico 😀
            Potrei capire se ci fosse un problema legato alla sicurezza, altrimenti …

      • floriano

        Il prossimo passo sarà mettere chrome os così ci sarà solo chrome come programma 😀

        • Aury88

          da quello che ho capito chrome os è un sistema operativo diverso da android e di conseguenza avresti comunque due sistemi operativi differenti…almeno dovrebbe essere così fino a quando google non farà convergere i due so in un unico progetto cosa che non ha intenzione di fare (almeno stando alle dichiarazioni dell’ottobre 2015)…l’avere un solo sistema operativo richiederebbe di riscrivere comunque l’interfaccia per adattarsi alla configurazione di utilizzo…cosa non ancora presente ne in android ne in cromeos
          se oggi venisse messo chromeOS è vero che saresti in grado di avviare gli stessi applicativi di android ma rimane il problema dell’interfaccia di questi applicativi non ottimizzati per l’ambiente desk e poi, anche non considerando questo, comunque sarebbe , allo stato attuale, un sistema operativo “switchato” e i cui applicativi (anche se identici a quelli sul desk) non è detto possano creare continuità nell’utilizzo tra due modalità (l’esempio della mail di sopra)

          • floriano

            maruos ha messo insieme Android con Debian, chromeos è semplicemente una versione di linux (basta su gentoo?) che può benissimo coesistere con Android con la stessa tecnica…

          • Aury88

            ok, ma questo non sposta di una virgola quello che ho detto sui due sistemi operativi e sulla discontinuità nell’utilizzo

    • floriano

      Lavorando da solo non ha compromessi da accettare e non ha capi senza cervello…

    • a dir la verità la risposta è no.
      il lavoro di canonical è molto più grande e ambizioso rispetto a Maru OS, canonical per realizzare una convergenza sta sviluppando un OS mobile, un nuovo server grafico un nuovo DE, inoltre l’obbiettivo di canonical non è avere 2 OS differenti per pc e mobile, ma vuole avere lo stesso OS per diversi dispositivi e l’OS si deve adattare in base all dispositivo in cui gira, le app sono esattamente le stesse.
      questo invece prende android, prende debian xfce e li unisce così che se usi lo smartphone usi android e quando colleghi lo smartphone ad uno schermo esterno, usi debian, come puoi ben capire è completamente diverso dal lavoro fatto da canonical

    • Guarda che un risultato molto simile puoi ottenerlo anche tu in 20 min scaricando le app “Linux Deploy” è “XSDL”.

      In entrambi i casi si sfrutta il fatto che Android monta kernel Linux. Quest’ultimo può benissimo eseguire in parallelo un altro sistema operativo Linux come Ubuntu.

      È così che funzionano (più meno) chroot, systemd-nspawn, docker…

  • floriano

    Mi sa che qualcuno adesso fonderà chrome os con Android con la stessa tecnica…

No more articles