Tutti gli articoli di Marco Bonfiglio

Ubuntu 18.04 avrà un nuovo installer (testuale)

Facebooktwittergoogle_plusredditlinkedin

Ormai vicini al definitivo rilascio della nuova versione LTS di Ubuntu, abbiamo ancora qualche notizia – e novità.

In questo caso parliamo dell’installer, ovvero di quel programma, usato solo una volta, con il preciso scopo di installare il sistema operativo in un computer vergine (sia fisico o virtuale). Ubuntu, da molto tempo ormai, ha una sua versione grafica chiamata Ubiquity, ma che – per l’appunto – necessita il caricamento di tutto l’ambiente grafico (per esempio il server X): soprattutto in ambito enterprise, e su macchine virtuali dedicate ad applicazioni server, questo è semplicemente inutile, e spesso questo tipo di installazione richiede più risorse di quante poi il server dovrà usare in produzione.

Per questo esiste – da sempre – anche un installer testuale, che richiede meno risorse; e storicamente questo installer è proprio quello di Debian (da cui Ubuntu comunque deriva); con  la nuova release non solo sarà disponibile un nuovo installer testuale, che sostituisca quello di Debian, ma sarà anche quello attivato di default per la versione server, e si chiamerà Subiquity (Server Ubiquity).

Nel post di annuncio possiamo trovare alcune schermate, che mostrano un’interfaccia semplice ma efficace – e con il color arancione tanto tipico di Ubuntu.




La novità è piccola e riguarda un numero molto ristretto di utenti, ma rappresenta la continua volontà di Canonical di avere un sistema completamente autonomo e sviluppato in casa, anche nei programmi di supporto. Sempre che questa volontà di far da sé non si risolva in una bolla come Unity

Rilasciato Devuan 2.0 Beta

Facebooktwittergoogle_plusredditlinkedin

L’anno scorso è stata rilasciata, dopo lunga attesa, la versione stabile di Devuan 1.0 – la distribuzione alternativa systemd-free basata su Debian 8. Ieri, dopo solo 7 mesi, è stata rilasciata la ISO di Devian 2.0, ancora in versione beta, basata su Debian 9 – che è anche l’attuale stabile.

Questo passaggio implica un grande rinnovamento dei pacchetti disponibili per l’installazione, soprattutto per l’uso desktop, pur mantenendo la caratteristica principale di fare a meno di tutti gli orpelli legati a systemd.

Una novità c’è: si aggiunge la possibilità di usare OpenRC al posto degli script SysV (fin dall’installazione, ma in modalità esperta).

Per l’ambiente desktop è possibile scegliere tra praticamente tutti i più diffusi ambienti, partendo da XFCE (il default), passando per KDE, Cinnamon, LXQT, MATE, ed LXDE. Manca GNOME, in quanto le dipendenze legate a systemd rendono il suo porting praticamente impossibile. Ma forse, in futuro… 😉

Ulteriori informazioni possiamo trovarle nel file di annuncio.

Insomma, l’update è molto interessante, e siamo sicuri che i molti detrattori di systemd saranno entusiasti nel vedere la community di Devuan ancora tanto in salute!

Ubuntu ama sempre più SNAP, forse presente di default su 18.04

Facebooktwittergoogle_plusredditlinkedin

Ci avviciniamo all’uscita della prossima versione di Ubuntu LTS, e le voci riguardo alle novità (anche mancate) continuano a rincorrersi. Ultima arrivata: SNAP sarà presente (ed usata) di default nella distribuzione. Di cosa sia SNAP ne abbiamo già parlato poco tempo fa, mentre l’integrazione di default non è una novità assoluta, dato che Ubuntu Mint 17.10 già lo integra; la notizia è vederlo in una distribuzione LTS, ovvero orientata alla stabilità e con l’impegno del produttore per un supporto a lungo termine.

Una delle limitazioni classiche e note delle distribuzioni LTS è l’invecchiamento del software: le versioni dei vari programmi sono scelte e fissate all’uscita della distribuzione e il supporto (di stabilità e sicurezza) vengono garantiti per quelle versioni, legate alle librerie ed agli altri sistemi presenti (e fissati nel tempo anche loro). Ma se questa limitazione è poco importante in un contesto server, per un uso più desktop poter disporre dell’ultima versione di una certa applicazione, con feature o compatibilà migliori, può essere davvero importante; un esempio può essere una Ubuntu 14.04 (supportata fino al 2019) esclusa dall’ultima release di LibreOffice, o con una applicazione Skype ormai dismessa e non più compatibile.
I pacchetti SNAP, essendo autosufficienti, possono essere aggiornati senza dover aggiornare le librerie di sistema, e quindi permettono l’aggiornamento del software senza minare la stabilità di sistema.

Tutto bene e bello, quindi? Sembra di no, in quanto alcuni utenti hanno esposto degli svantaggi:

  • tempi di apertura delle applicazioni più alti
  • spazio disco richiesto molto più grande
  • aspetto delle applicazioni non uniforme (insomma, sono brutte)

La sensazione è che per superare un problema se ne creino altri, e quindi che la soluzione non sia del tutto adeguata; inoltre, chi cercherà stabilità probabilmente non avrà bisogno delle applicazioni distribuite via SNAP, e chi invece avrà bisogno delle ultime versioni di certe applicazioni probabilmente potrebbe fare a meno delle LTS. O no?

SNAP avanza nel mondo Linux, Kernel incluso!

Facebooktwittergoogle_plusredditlinkedin

Appena rilasciato il kernel 4.15, si apre il periodo di tempo dedicato alle modifiche proposte per il kernel 4.16. La prima novità è l’aggiunta di Bison e Flex agli strumenti necessari per la compilazione (tradizionalmente limitati a GCC e Make): la novità è dettata dal bisogno di generare alcuni file e non solo compilarli. I nuovi strumenti richiesti sono però di uso comune, e quindi non dovrebbero affatto essere un problema per chi vorrà continuare a compilarsi “in proprio” il kernel.

Un’altra novità salta subito all’occhio: se da sempre il sistema di building del kernel ha previsto la pacchettizzazione in deb ed rpm, ora viene aggiunta la possibilità di creare pacchetti SNAP.
SNAP è un sistema particolarmente apprezzato per le applicazioni, in quanto permette di creare pacchetti autosufficienti: non solo l’eseguibile, ma anche tutti i file di supporto necessari (vedi librerie), permettendo l’esecuzione in un ambiente particolarmente isolato, una sandbox, tanto che Ubuntu lo vede come sostituto dei vari apt e yum.

Sebbene il kernel non sembri indicato per questo tipo di pacchetto, un vantaggio dell’utilizzo di questa tecnologia potrebbe essere la possibilità di aggiornamento atomico, secondo una logica “o tutto o niente”: fino alla completa installazione del nuovo pacchetto, quello vecchio rimane disponibile ed usabile, senza il pericolo che un’operazione andata male comprometta un componente critico come il kernel. La patch è stata introdotta l’anno scorso da Canonical, ma dal prossimo kernel farà parte degli strumenti uffciali.

Proprio per la capacità di essere autosufficiente, lo stesso pacchetto SNAP è installabile allo stesso modo su molte (se non tutte) distribuzioni Linux. E proprio per questo alla lista di applicazioni disponibili sullo SNAP store (di Ubuntu) si stanno aggiungendo sempre più applicazioni, comprese Slack, Spotify e Skype.

Rilasciato systemd 237

Facebooktwittergoogle_plusredditlinkedin

Nella stessa giornata del rilascio del tanto atteso kernel 4.15, systemd è stato aggiornato alla versione 237. Come sempre, gli interventi sono più che altro sotto la superficie, andando ad aggiungere delle API per gestire con maggiore profondità e puntualità alcuni componenti, e in particolare sd-bus (l’implementazione interna di D-Bus).

Di particolare rilievo troviamo due cose:

  1. l’aggiunta a systemd-networkd del supporto per WireGuard
    WireGuard è l’implementazione di una VPN pensata per essere leggera e performante, elaborata direttamente a livello kernel. Sebbene giovane ed ancora in pieno sviluppo, si vocifera di un’imminente introduzione nel kernel mainline.
  2. rottura della compatibilità di systemd-tmpfiles
    questo componente si occupa della creazione di file temporanei da poter usare; è legata in particolare all’uso di utenze temporanee, create al volo per poter avviare un servizio e distrutte alla sua chiusura. L’ironia risiede nel fatto che il cambiamento serve per adeguare il comportamento a quanto già descritto nella documentazione; inoltre si prevedono dei cambiamenti ulteriori che romperanno la retrocompatibilità della prossima versione.

Per i più curiosi, la lista ufficiale è sempre su GitHub! 😉

PC di casa down, LKML down

Facebooktwittergoogle_plusredditlinkedin

Qualche giorno fa si è registrata una certa dose di panico perché il sito lkml.org, che ospita un archivio della mailing-list del kernel linux – metodo normale di dialogo tra gli sviluppatori e canale ufficiale degli annunci del più grande progetto opensource di sempre -,  era completamente offline. E non per poco tempo: giorni!

La causa? Tra le più banali di sempre: guasto al computer che ospita il sito. Sì il computer: in epoca di cloud fa un po’ sorridere, ma il sito (o meglio, il backend) era ospitato in un computer di una casa, e nello specifico in quella dell’olandese Jasper Spaans.

Dato che la sfortuna ci vede benissimo, ha aspettato un viaggio del suddetto per far saltare la corrente elettrica di casa, con riavvio del suddetto. Appena accortosi del problema, Jasper ha imputato il mancato riavvio completo all’impossibilità di inserire la password per LUKS, il sistema di crittografia del disco: il software di collegamento remoto non funzionava, quindi ci avrebbe guardato appena a casa. Niente di grave ma, appena tornato, ha dovuto constatare che il salto di corrente aveva creato un danno vero: scheda madre andata!

Dando spiegazioni del perché il sito sarebbe rimasto giù per un tempo indeterminato, si è scatenata una vera e propria gara di solidarietà, che ha permesso in pochi minuti di trovare un pezzo di ricambio, ritirare su il server e… trasferire il tutto su una VPS (Virtual Private Server – un server privato ospitato in un datacenter remoto), così da scongiurare il ripetersi della situazione.

Chiunque si sia avvicinato al mondo sistemistico si è creato, prima o poi, qualche tipo di server in casa: che sia un server web, mail o per qualche gioco online, l’essere il fornitore per se stessi è un traguardo tanto esaltante quanto comune. Il più delle volte viene usata una macchina dedicata, e spesso a livello domestico si tratta di vecchi PC riciclati al ruolo di server – e Linux è da sempre il SO più indicato per riesumare i vecchi rottami.

Jasper non ha fatto altro che questo, offrendo un sito web al mondo da casa sua, e forse ha ignorato il fatto che quanto erogato dalle sue quattro mura è negli anni diventato molto utile ed utilizzato da tutta la comunità. Ma i tempi sono cambiati ed ora tutto deve passare dal cloud per essere affidabile. O no?

LEDE ed OpenWRT tornano insieme

Facebooktwittergoogle_plusredditlinkedin

Avevamo parlato di LEDE appena annunciata la sua nascita: ancora non esistevano pagine del progetto, men che meno software utilizzabile. Il fork di OpenWRT però sembrava aver ingranato piuttosto bene, tanto che pochi mesi fa riportavamo la notizia dell’uscita di una nuova versione del software creato dal progetto, confermando il buon lavoro.

Ora, anno nuovo, situazione nuova! Come già vociferato, il vecchio ed il nuovo progetto si riuniranno per tornare a fare uno sforzo comune di miglioramento; le motivazioni che avevano portato alla scissione erano per lo più politiche, nel senso che erano legate al modo di prendere le decisioni all’interno del progetto ed agli obbiettivi che si cercava di inseguire: dall’annuncio rilasciato,  LEDE sembra aver risolto così tanto bene questi problemi che il progetto unito userà il nuovo modello decisionale, abbandonando completamente il vecchio.

L’infrastruttura (i server su cui risiedono i portali) sarà – in qualche modo – unificata, mentre i due portali (news e wiki del progetto) rimarranno separati, almeno per ora: non è ancora stata decisa una riunificazione. Il nome, invece, tornerà ad essere solo OpenWRT, sicuramente più conosciuto; inoltre, è un marchio rappresentato da una società no-profit (SPI – Software in the Public Interest) che offre un ombrello sicuro sia per ricevere donazioni che per gestire questioni legali (sebbene sul loro sito sia confermata solo la prima funzione…).
L’ultima versione di LEDE (la 17.01) continuerà ad essere completamente supportata, mentre l’ultima di OpenWRT (la 15.05) riceverà solo alcuni bugfix e aggiornamenti di sicurezza; c’è pure qualche problema di integrazione con la generazione automatica usata da LEDE, quindi alcuni binari non saranno proprio creati. Tutte le versioni antecedenti di OpenWRT saranno invece abbandonate.

La piccola secessione di 20 mesi sembra aver fatto bene al progetto, imponendo un modello organizzativo con più consenso (cosa non banale in una community) e dando nuovo entusiasmo ad un progetto che cominciava a mostrare un po’ di stanchezza: l’ultima news pubblicata sul sito di OpenWRT risale ad agosto 2016…