Devuan è nata dopo che il team di Debian ha scelto systemd come sistema di init predefinito per “Jessie” andando contro l’opinione della community.

Come detto molti utenti non furono d’accordo e monto’ un vespaio di proteste in particolare all’interno del gruppo VUA (Veteran Unix Admins) il quale, sentendosi inascoltato, decise di effettuare un fork del progetto Debian (la Fork in Unix consiste nella creazione da parte di un processo detto ‘padre’ di un altro processo identico detto ‘figlio’).

Questa prima beta release di Devuan rappresenta uno step importante per il progetto. I pacchetti sono basati su quelli presenti nei repository di “Jessie” e l’utente è libero di scegliere il sistema di init che preferisce. Ovviamente tutti i programmi dipendenti da systemd non potranno essere utilizzati.

devuan logo

La principale critica mossa contro systemd è la sua tendenza ad inglobare programmi esterni e di legarli a se. L’ultimo esempio è rappresentato da gummiboot, un bootloader pensato per gestire il boot su sistemi UEFI (Unified Extensible Firmware Interface) che è pero’ diventato parte integrate di systemd.

È bene sottolineare però che Debian non è legata a systemd in modo indissolubile, a partire da Debian 8 infatti quest’ultimo è diventato il sistema di init predefinito (e consigliato) ma l’utenza può ancora optare per delle alternative grazie al fatto che le principali soluzioni concorrenti sono comunque presenti nei repository.

Potete trovare ulteriori informazioni sul sito dedicato a Devuan cliccando qui potete invece scaricare la Beta.

  • mrholidayr

    congratulazioni al team devuan, sembra che prendano il concetto di libertà molto sul serio! quando rilasceranno una stabile sarò lieto di testarla

  • Simone Picciau

    Buona iniziativa, anche se sinceramente non condivido l’astio nei confronti di systemd…

    • Nella community utenti devuan c’e’ sicuramente anche astio contro systemd. Non c’e’ in devuan come progetto, non e’ astio verso systemd, ma e’ non condivisione della linea di sviluppo di systemd che diverge dalla filosofia UNIX e da quella KISS, cosa che invece intendiamo perseguire in devuan come la ha sempre perseguita anche debian prima dell’introduzione di systemd. Non e’ quindi questione di astio, ma di alternativa.

    • Benjamin Sisko

      hahaha si… effettivamente un pò di astio nei confronti di SystemD ce l’ho…. lo considero alla stregua dell’ MCP in Tron, una roba che vuol controllare tutto… lo trovo una roba ridondante uno strato intermedio frà kernel e servizi ed applicativi che onestamente non vedo utile in ambito server.
      Posso capire la rapidità del boot e la gestione di alcuni servizi che possono essere lanciati e rimossi nel caso di un desktop o notebook, ma francamente renderlo così invasivo e, sopratutto, rendere altre parti (vedi gnome) così dipendente da systemd, tanto da non poterne far a meno, proprio non mi và giù… non parliamo poi del fatto che gli stanno mettendo dentro tante di quelle robe che lo renderà ancora più invasivo (vedi boot managar), e credo, più pericoloso… se salta fuori una vulnerabilità di systemd si porterà dietro tutta una serie di conseguenze prevedibili.
      Poi vabbè… lasciamo stare i log binari, che è l’ultimo dei problemi, che seppur leggibili dal journalctl mi disturbano lo stesso.

      A questo punto tanto varrà chiamarli non più sisyemi GNU/Linux, ma GNU/Linux/Systemd.

      • Simone Picciau

        Bisognerà vedere come saranno sviluppate le cose tra altri anni, chiaramente tra un decennio i sistemi operativi saranno ancora diversi. Le cose cambiano di continuo.

        • Benjamin Sisko

          certo… ma c’è da dire che Unix, di cui Linux è l’ultimo arrivato, esiste da 40-45 anni, e tutto sommato alcune robe sono rimaste invariate… systemd mi pare una roba tipo svchost di windows… e quindi, concettualmente, distante dal mondo unix… che ripeto, va benissimo ci possa anche essere, perchè in certi ambiti sicuramente è utile, ma non va bene che venga imposto a tutti.

          • Simone Picciau

            Sì l’importante è che ci sia sempre una alternativa.

  • gnumico

    Complimenti se si considera che è un Beta, tra altro provata con il criticato processore Skylake (nel mio caso un i5-6200u) Speriamo che ne faranno pure una versione rolling….di nuovo complimenti

  • ange98

    Ma per quanto riguarda i DE che hanno systemd come dipendenza, come hanno risolto?

    • Per ora non sono molti i DE che necessitano per forza di systemd, pero’ in debian dipendono da alcuni processi che a loro volta sono legati a systemd. In devuan si stanno riportando questi processi a quelli che erano in precedenza dell’ingresso di systemd in debian e/o si stanno scrivendo alternative a tali processi.

      • Maddo

        Non c’è astio contro systemd nel progetto, però systemd è accuratamente blacklistato tra le scelte possibili di init system? Cioè capisco che uno si può benissimo scaricare debian se vuole systemd e tutto, ma non capisco il senso di blacklistarlo se non c’è “astio” nei suoi confronti.

        • Non vedo cosa centri un blacklist di un progetto con un eventuale astio nei suoi confronti.

          systemd non e’ blacklistato perche’ lo odiamo, e’ blacklistato perche’ allo stato attuale, per la catena di dipendenza che comporta il suo uso, romperebbe devuan ed e’ quindi non utilizzabile.

          E’ una questione puramente e semplicemente tecnica, per come e’ strutturato systemd oggi come oggi o lo usi integrato appieno nel sistema o non lo usi, non ci sono vie di mezzo, avendo noi scelto di non permettere a un pacchetto di fare hijacking del base system, non e’ possibile integrare, allo stato attuale, systemd cosi’ com’e’.

          Se in futuro si trovera’ una soluzione tecnicamente valida e in linea con i principi UNIX e KISS, systemd potra’ rientrare in devuan, seppure non come default, in qualsiasi momento.

      • ange98

        Interessante…
        Per quanto riguarda invece la gestione delle dipendenze, voi come le gestirete? Cioè fate sempre come Debian splittando i vari pacchetti o prenderete una strada diversa (più alla Arch diciamo)?
        Chiedo a te perché mi pare di capire che fai parte del progetto o che perlomeno ne sai più di tutti noi

        • Seguiremo la filosofia debian in tal senso, il nostro scopo e’ quello di rimanere il piu’ possibile vicini alla filosofia debian originaria, quindi da questo punto di vista non ci saranno, non a breve almeno, cambiamenti. Nel lungo periodo, tutto puo’ essere.

          Ti confermo che sono parte del progetto, faccio parte del gruppo “VUA” originario che ha fondato il progetto.

          • ange98

            È un vero peccato, mi avrebbe fatto molto piacere…
            Beh magari la proverò più avanti 🙂

          • Ognuno ha i suoi gusti, l’importante e’ sempre poter scegliere, motivo principale per cui esiste anche devuan 🙂

          • Benjamin Sisko

            Concordo sulla libertà di scelta e nel non avere imposizioni.
            Ho un paio di server che stò aspettando di aggiornare (sono fermo alla debian 7) per vedere che piega prende Devuan… non vorrei aggiornare e poi rendermi conto che il progetto muore per mancanza di update, sopratutto sul fronte patch di sicurezza.
            Francamente mi stò stancando del mondo Linux in generale, le grandi distribuzioni si stanno muovendo in direzioni troppo distanti appunto dalla libera scelta, e stò seriamente pensando di passare al mondo Bsd, che ha comunque tutti i pacchetti più importanti per essere utilizzato in ambito server (intendo nfs, samba, mta tipo exim o postfix, courier etc.etc.) ed inoltre freebsd ha pure ZFS che è un gran bel filesystem.

          • Samael

            Capisco la tua idea, ma credimi: stai raggiungendo conclusioni sbagliate.
            I BSD non sono più per la libera scelta, ma anzi sono esattamente dove systemd vuole arrivare. E la stessa cosa è illumos.
            Su BSD il sistema non è modulare, come con GNU/Linux: ovvero un insieme di pacchetti presi da altri ed assemblati dando vita alle distro.
            Su BSD kernel, toolchain e userland sono sviluppati insieme, nello stesso trunk e dagli stessi sviluppatori.
            In sostanza è il contrario di ciò che speri di ottenere, visto che come tutti i
            sistemi UNIX non è sviluppato a bazaar, ma a cattedrale. Ha un modello
            di sviluppo rigido, molto simile ai sistemi commerciali.

            Ciò che sta facendo systemd altro non è che ammazzare la libertà di scelta nello userland per cercare di fornirne uno standard che valga per tutti e che azzeri completamente il divario tra una distro e l’altra.
            In sostanza, ciò che si prospetta è un mondo simile a BSD, dove le singole distribuzioni (tipo PC-BSD) non sono altro che il sistema liscio (in questo caso FreeBSD) + pacchetti pre-installati.
            Tutto
            ciò che sta sotto il cofano (INIT, configurazioni, funzionalità) è
            centralizzato e controllato dal team che sviluppa il sistema vero e
            proprio.

            Il modello a Bazaar non solo non è proprio di BSD, ma è anche una delle critiche più note da loro mosse a Linux, in quanto ha portato il pinguino a non essere un vero sistema operativo.

            PS: Non fraintendere questo post pensando che stia facendo pubblicità a systemd, perché non era quella la mia intenzione.

          • Non concordo, Sui BSD si e’ mantenuta la logica UNIX appieno. E’ si vero che il “pacchetto” e’ sviluppato tutto assieme, ma questo non comporta problemi fintanto che le componenti, sebbene nello stesso trunk sviluppati assieme etc, sono singoli e non strettamente legati fra loro, intercambiabili, e sviluppati con la logica “fai una cosa sola e falla bene”. In BSD e’ cosi’, come in molti altri UNIX.

          • Samael

            No, Franco, non è così.
            I BSD, come tutti i sistemi UNIX, non sono mai nati con componenti pensati per essere intercambiabili, ma sono nati con l’idea che il kernel e lo userland fossero componenti progettati per lavorare insieme.
            Ti faccio esempi pratici: mentre su Linux abbiamo l’abitudine di compilare una nuova versione del kernel senza intaccare il resto della distro, su FreeBSD se aggiorni il kernel devi anche aggiornare lo userland.
            Non puoi aggiornare il kernel a FreeBSD 10.x e rimanere con lo userland a 9.x.
            Così come su FreeBSD non puoi togliere la sua libc e sostituirla con GLIBC, e pensare che tutto funzioni, non senza averci lavorato su prima come si è fatto su Debian GNU/kFreeBSD.
            Su OpenBSD pledge() è integrato sia a livello kernel che a livello di userland, il che vuol dire che il kernel in sé si aspetta di trovare utility in grado di gestire la sua tecnologia e lo userland si aspetta di trovare un kernel che abbia determinate funzionalità.
            Su Solaris addirittura non c’è nemmeno una separazione tra base e kernel, ma è tutto in una sola OS/NET consolidation (illumos-gate su illumos), e quando compili lo fai per tutto il blocco. Solaris 11 usa solo ZFS come root ed IPS nasce completamente integrato con esso (Boot Environment), con SMF e con FMA.
            Solo su GNU/Linux, per motivi storici, abbiamo un OS a bazaar, dove ogni componente è sviluppato separatamente, e spesso con una povera integrazione perché ogni componente è un progetto a sé sviluppato da persone con obbiettivi differenti l’uno dall’altro.

            Che poi su UNIX esista il principio del fare una cosa e farla bene, ok. Siamo d’accordo.
            Ma questo non ha nulla a che vedere con la libertà di scelta in sé, ma è solo un effetto collaterale. L’avere strumenti in grado di fare una cosa e farla bene ha il solo scopo di rendere più evolvibile il tutto a lungo termine.
            E ti dirò: nessuno UNIX oggi segue quel principio alla lettera, a partire dagli innumerevoli flag che ogni comando ha. ls è il peggior caso, ad esempio.

            Dal man di FreeBSD:

            BUGS
            To maintain backward compatibility, the relationships between the many options are quite complex.

            Secondo la filosofia di Doug McIlroy infatti molti dei flag di ls sarebbero dovute essere utility separate, ma così non è stato perché per comodità si è scelto di fonderle trasformando così il tutto in una roba bloat.

            h t t p s : // mkremins . github . io/blog/unix-not-acceptable-unix/
            Questa è una lettura interessante. Sebbene prenda in esame Linux e OSX, la cosa vale praticamene anche per i BSD ed il resto della famiglia.

            Paradossalmente, l’unico sistema che segue la filosofia UNIX alla lettera è il suo erede Plan9.

          • Non siamo d’accordo, vediamo la cosa su piani diversi.

            E’ si vero quel che dici riguardo al discorso upgrade dei BSD di kernel e userland, ma e’ un discorso ad un livello totalmente diverso, in cui si parla di versioning di cose che pero’, tra loro, sono indipendenti, e sono poi legati da scripring di supporto.

            Insomma, il punto e’ che se io in un BSD voglio togliere il suo ls e reimplementarlo come voglio io non ho problemi a farlo: e’ un binario indipendente da mv, da cp, dall’init e dal resto del sistema se non la libc, con api chiare, documentate e stabili, e gli altri binari di “pari livello” non sono strettamente legati e/o dipendenti da lui, e alla fine fa una cosa sola e la fa bene.

            Con systemd invece ti trovi un set di binari strettamente interdipendenti l’uno dall’altro, ognuno dei quali non fa solo una cosa ma ne fa troppe, nell’insieme occupano praticamente tutto il base system e si estendono anche ben oltre, partendo da pid1 anzi ora pure dal boot loader, le api sono mobili, mal documentate e in continuo cambiamento, e, ciliegina sulla torta, il team di sviluppo e’ poco supportivo nella gestione dei border line use case e troppo sbrigativo a usare un WONTFIX supponendo che i bug sono sempre di altri e rifiutando di inserire qualsiasi workaround e/o fix che non sia in linea con la loro visione.

            Non so tu, ma io vedo un’enorme differenza tra le due cose.

          • Samael

            Non fanno troppe cose insieme, Franco.
            Ogni componente di systemd (systemd-journald, systemd-timedated ecc.) ha compiti specifici e ben delineati.
            L’unica differenza con la filosofia UNIX originaria è che essa prevedeva che ogni compito venisse frazionato in singole utility, mentre systemd propone utility singole ma che facciano tutto il lavoro. Ma a suo modo anche questo è fai una cosa e falla bene. Dipende tutto da che punto di vista lo si guarda.
            E ribadisco quanto detto sopra: nessuno UNIX segue la filosofia originaria alla lettera, perché altrimenti ti ritroveresti con duecentomilioni di utility, ognuna per una delle funzioni che oggi esprimiamo tramite flag ad un comando. Converrai con me che un modello del genere sarebbe decisamente caotico.
            La filosofia di UNIX è importante, non lo metto in dubbio. Ma non c’è bisogno di rimanere ancorati alla sua implementazione originaria. Oggi non abbiamo più gli stessi limiti di risorse e di caratteri di 60 anni fa.
            Le sue idee possono essere implementate senza problemi in chiave più attuale ed in linea con le esigenze di oggi.

            E, tornando a systemd, anche se tutti sono comunque legati da delle API, ciò non vuol dire che il singolo in sé non sia reimplementabile.

            Semmai il problema REALE di systemd (come ho scritto nel post sopra su pastebin e come hai ribadito tu) è che manca di una politica chiara sulle API.
            Ovvero, è troppo poco trasparente, nello stesso stile delle Native API del kernel NT, in quanto Red Hat non vuole che ci siano altre implementazioni delle componenti di systemd che farebbero andare alla deriva una strategia di controllo dello sviluppo di Linux, in favore di un modello più aperto ma comunque interoperabile.

            systemd alla fine è ciò che avremmo dovuto creare tutti quanti noi della comunità Linux: un set di API e funzionalità specifiche e standard che avrebbero permesso di unificare la piattaforma sottostante.
            Tuttavia così non è stato. Abbiamo preferito farci la guerra, e Red Hat per scopi puramente politici ne ha approfittato imponendo uno standard de facto che ha lo stesso sapore di un vendor lock-in fatto a Redmond.

          • In verita’ fanno piu’ delle singole cose che sostituiscono, lo stesso init “fa troppo” anche preso singolarmente a mio parere… ma soprattutto lo fanno in maniera troppo interconnessa in maniera stretta tra loro.

            A mio parere, sinceramente, la maggior parte degli UNIX la seguono, abbiamo un modo di intenderli diversi.

            A mio parere invece c’e’ si bisogno di rimanere inchiodati sui suoi principi di base, perche’ ancora oggi sono la migliore soluzione possibile a mio avviso, nonche’ quelli che hanno reso linux il sistema operativo piu’ diffuso al mondo.

            Il fatto che poi oggi non ci siano i limiti di risorse di 60 anni fa ( ma diciamo 40 va ) e’ opinabile, ancora oggi ci sono ambienti in cui lo sviluppo ideale e’ il deeply embedded, dove liunx peraltro non appena si va su sistemi completi la fa da padrone, ed e’ un ambiente dove ci sono tante esigenze border line, quelle per cui il team di systemd spesso dice “wontfix”.

            Le sue idee possono essere sicuramente implementate in chiave piu’ attuale e in linea alle esigenze odierne, ma questo non deve essere snaturarne in concetti di base, altrimenti e’ una cosa diversa. Che va benissio se copre le esigenze di chi vuole usarle, non va piu’ bene se la si impone a tutti. A mio parere poi, systemd, non e’ per nulla piu’ moderno, e’ anzi un ritorno al passato, come se le tante lezioni che unix ha insegnato al mondo fossero state scordate.

            Per come e’ strutturato reimplementarlo diventa molto problematico, ci sono api non documentate, ci sono api che cambiano continuamente… non e’ impossibile ma quasi.

            Inoltre non dimentichiamo che rifiuta di essere cross platform e posix compliant, e questo di per se’ e’ il male a mio avviso.

            Non sono d’accordo nemmeno sul fatto che serva un set di api standard per unificare la piattaforma, penso sinceramente che uno dei grandi valori di linux, che ne hanno anche determinato il successo, sia la grande malleabilita’ frutto anche della enorme differenziazione, unificare significa perdere questo valore.

            E’ un po’ come confrontare la cucina italiana, ricchissima di tantissimi piatti differenti, con il mac donald’s dove tutto ha un solo sapore. Preferisco rimanere nella cucina italiana!

          • Samael

            No, Franco. Non fanno niente di più di quanto non dicano.
            Lo stesso systemd che sta in PID1 (grazie Poettering per aver chiamato il gestore dei servizi come la suite intera. Proprio un esempio di chiarezza, guarda…) ha solo logica di avvio, monitoraggio e respawning. Esattamente ciò che serve ad un gestore dei servizi.

            Certo, è più di quanto facesse INIT, ma è normale. INIT non faceva nulla. Era solo un processo zombie che doveva tenere fermo il PID1 mentre demandava tutto a degli script.
            Ma questo non vuol dire che fa più cose del dovuto, perché le stesse funzionalità di systemd le avresti avute con un supervisore messo separatamente, tipo supervisor.
            L’unica differenza è che quelli di systemd hanno deciso di andare diretti di PID1, anziché tenerlo come processo separato visti i problemi relativi al monitoraggio (double-forking).

            Sulla questione dell’essere interconnesso, quello non è un problema in sé, perché anzi ti permette di eporre API specifiche e sfruttarle in diversi punti.
            Il problema è quanto trasparenti e documentate esse siano. Ma questo non è un problema tecnico, ma politico. Il problema non è systemd, ma Red Hat. E questo punto vale anche sulla questione della difficoltà a reimplementare le singole funzioni, sul wontfix e sull’imposizione in generale.
            Franco, su questo punto la pensiamo uguale, ma quello che io continuo a ribadire è che questo è un problema relativo a Red Hat e che non ha a che vedere col design di systemd.
            Le API sono poco chiare perché è una scelta politica dell’azienda, esattamente come le Native API di Windows.

            E no, non si stanno snaturando i concetti base.
            Sempre di “fare una cosa sola e farla bene” si parla. Semplicemente, mentre prima per limiti tecnici e per una concezione della complessità differente da quella attuale si preferiva frammentare il singolo procedimento, oggi si preferisce frammentare la suite.

            Sul non essere cross-platform.
            Frega poco, onestamente. systemd nasce per essere uno userland per Linux, non per UNIX. E la cosa non è tanto diversa da quanto avviene su BSD.
            Pensi che a quelli di OpenBSD gliene freghi qualcosa di Linux? LibreSSL e OpenSSH sono software OpenBSD-specifici.
            Le versioni che abbiamo noi sono fork in linea con l’upstream che hanno patch per la portabilità. Patch che sono tenute separatamente perché a Theo de Raadt ed il resto del team non interessano.
            Non vedo perché un prodotto nato per esporre API di Linux debba diventare cross-platform. Ed in ogni caso è open source, quindi se vogliono possono tranquillamente forkare e portare. Sempre se siano interessati, cosa di cui dubito fortemente.

            Sull’essere POSIX-compliant, qui io e te possiamo anche concordare.
            A Lennart POSIX interessa poco e lui vuole che si sviluppi per Linux.
            Ora, sebbene POSIX sia tutto fuorché uno standard serio, dato che è pieno di rimandi alle singole implementazioni (echo se lo ricorda qualcuno?), è l’unica cosa che possa assicurare stabilità all’implementazione in un’ottica di lungo periodo.

            Sul grande successo di Linux, vero, è derivato dalla sua malleabilità.
            Ma questo ha ben poco a che vedere con systemd in sé, perché nulla anche oggi ti vieta di prendere il kernel e metterlo in uno userland custom.
            systemd è più orientato all’uso all’interno di sistemi operativi server e desktop, dove più che frammentazione si ha bisogno di implementazioni definite.

            Difatti, andiamo a vedere dove Linux ha avuto successo:
            1) Server
            Qui c’è principalmente RHEL, che è la distro di riferimento e quella più supportata a livello di applicativi commerciali;
            2) Cloud
            Qui c’è principalmente Ubuntu Server;
            3) Embedded
            Qui per lo più è roba specifica e legata ad i singoli dispositivi;
            4) Smartphone
            Android. Non mi pare che qui la diversificazione sia come la intendiamo noi, visto che le ROM hanno sempre la stessa base di codice.

            L’unico punto in cui Linux è davvero variegato è il desktop. E non mi pare sia stato tutto ‘sto grande successo.
            Alla fine Linux ha dominato dove c’era un’implementazione di riferimento sulla quale puntare in fase di sviluppo.
            Dove c’è stata balcanizzazione c’è stato solo caos e poca crescita generale.

          • prokopios

            “Systemd alla fine è ciò che avremmo dovuto creare tutti quanti noi della comunità Linux: un set di API e funzionalità specifiche e standard che avrebbero permesso di unificare la piattaforma sottostante. Tuttavia così non è stato. Abbiamo preferito farci la guerra, e Red Hat per scopi puramente politici ne ha approfittato imponendo uno standard de facto che ha lo stesso sapore di un vendor lock-in fatto a Redmond”. Mi sembra azzardato il paragone con Microsoft visto che il kernel Linux è opensource e chiunque può realizzare un sostituto di SystemD per la propria distribuzione. RH può proporre uno standard, ma mai imporlo a nessuno.

          • Samael

            prokopios, l’ha già fatto. Ed il paragone con Microsoft è più che azzeccato dato che il comportamento delle due aziende è praticamente lo stesso.
            systemd è già uno standard-de-facto, dato che molti dei progetti freedesktop e GNOME sono sponsorizzati o addirittura sviluppati direttamente da Red Hat. Senza contare che praticamente tutte le distro big (che sono quelle che trainano lo sviluppo sul pinguino) lo usano già.

          • Benjamin Sisko

            grazie delle considerazioni che trovo interessanti, perchè appunto, non conosco Open-Free/BSD così a fondo.
            C’è una cosa da dire comunque sul modello verticale a bazaar, e come mi pare di capire, anche tu sei d’accordo.
            Systemd ce lo stanno comunque cacciando in gola a forza, perchè frà qualche versione di qualsiasi distribuzione, non potremmo più farne a meno… esattamente quello che a me non piace, sopratutto in Debian che dovrebbe essere una distribuzione orientata alla stabilità, ai server e agli sviluppatori.
            Debian doveva lasciare libertà di scelta… può andare bene averlo di default, ma è evidente, per la piega che ha preso con le dipendenze, che alla versione 9 o 10 di Debian, non sarà possibile farne a meno.

          • Samael

            Non so perché diamine Disqus censuri commenti a caso. Mah…

            Ti ho scritto la risposta su Pastebin.
            h t t p : / / pastebin . com/ZYjR8EUa

          • Senza volerti dire per forza di rimanere su linux ( e ci mancherebbe, usa quello che reputi piu’ adatto alle tue esigenze ) voglio pero’ rassicurarti almeno sul fronte patch di sicurezza: devuan gia’ ora ha il repository jessie-security e ascii-security, che sono in sync con debian security ( al netto di nostre eventuali aggiunte/modifiche relative alla stabilizzazione dei pacchetti in debian )

          • Benjamin Sisko

            Ottimo… questo è rassicurante.

  • Gino

    Ho installato Devuan e devo dire che tutto funziona alla perfezione ed è molto interessante come distro. Ho scelto Lxde come ambiente desktop, anche se ho usato spesso Gnome in passato ma mi sembra di aver capito che ci sono problemi di dipendenze almeno per il momento. Per il resto ho apprezzato molto la rapidità di accesso e lo stile del login, libreoffice aggiornato a 5 e Iceweasel come browser di default (spero che rimanga tale). Complimenti e un grazie agli sviluppatori di Devuan.

No more articles