Tutti gli articoli di Marco Bonfiglio

Ring-KDE 3.0: riscritto e rilasciato

Facebooktwittergoogle_plusredditlinkedin

Ring è una piattaforma opensource per chat e telefonate (via internet) con una caratteristica principale: decentralizzazione.
Nel network di Ring ogni utente, identificato da un numero esadecimale di 40 caratteri, comunica direttamente (p2p o peer-to-peer -, se preferite) con gli altri, senza usare server centrali. Grazie a tecniche di DHT (distributed hash tables, tabelle di hash distribuite) ogni client è in grado di rintracciare il client richiesto per poter iniziare una conversazione, o riceverne una; fintanto che il client sarà online, parteciperà alla distribuzione di queste informazioni, senza bisogno di server dedicati allo scopo. Se a qualche vecchio utente di eMule è venuta in mente la rete KAD, ha fatto centro: anche Kadmelia era l’implementazione di una rete DHT.

Esistono client per Windows, Android, Linux,  e pochi giorni fa è stato annunciato il rilascio della versione 3.0 del client Ring per KDE, chiamato – con fantasia – Ring-KDE. Questa è una tappa importante, in quanto non è un semplice aggiornamento del software precedente: per poter usare le ultime tecnologie messe a disposizione dal framework QT è stato più facile riscrivere che aggiustare.

Si è colta l’occasione per poter cambiare un poco l’impostazione del software: da telefono IPmessenger universale. Il centro della confersione è la timeline, ovvero organizzare tutto per eventi nel passato; per esempio, in questa nuova ottica, la ricerca di un contatto avviene principalmente nella timeline, la storia delle chiamate, piuttosto che nella rubrica.
Il concetto di timeline coinvolge anche le chat, che fa anche da registro delle chiamate – similmente a quanto accade già da tempo con Skype, Whatsapp o Telegram.
Altri miglioramenti sono stati fatti nella gestione delle videochiamate, nonché nella condivisione del desktop.

Insomma, grandi cambiamenti, che rendono moderno questo software: ora parte la caccia ai bug e al miglioramento delle prestazioni, ma la presentazione è interessante. Sicuramente vale una prova: è FOSS (Free Open Source Software – software open-source gratuito)!

LibreOffice: rilasciata la versione 6.1

Facebooktwittergoogle_plusredditlinkedin

Sono passati solo 8 mesi dalla release di LibreOffice 6.0, ma i tempi sono maturi per un piccolo aggiornamento: LibreOffice 6.1.

Come si legge dall’annuncio ufficiale, l’aggiornamento in realtà non è poi così piccolo:

  • Colibre
    un nuovo tema di icone (per Windows) basato sulle linee guida di Microsoft, che renderà più esteticamente appagante l’uso della suite per gli utenti provenienti dall’ambiente Microsoft
  • Rifatta la gestione delle immagini
    caricamenti – notevolmente – più rapidi e morbidi grazie ad un nuovo gestore grafico e ad una vita dell’immagine migliorata, con qualche vantaggi anche  nel caricamento dei documenti nei formati proprietari di Microsoft
  • Riorganizzazione dei menù per Draw
    Per migliorare l’esperienza dell’utente, i menù di Draw sono stati resi più simili a quello dei vari componenti (Calc, Write). Aggiunto anche il menù Pagina.
  • Miglioramento di Base
    l’applicazione di database locale cambia il motore: HSQLDB viene deprecato e Firebird diventa il nuovo standard. Disponibile un tool di migrazione da un motore all’altro
  • esportazione EPUB migliorata
    Migliore gestione dei link, tabelle, immagini, supporto ai font integrati, più opzioni per la personalizzazione dei metadata
  • Help Online arricchito
    L’help disponibile online è stato arricchito di esempi, e ne è stata facilitata la traduzione.

L’elenco è bello sostanzioso, ma se volete vedere subito le novità, ecco il video di presentazione direttamente della Document Foundation!

WireGuard ha fatto colpo (perfino su Linus)

Facebooktwittergoogle_plusredditlinkedin

Neanche ad una settimana dall’inizio del processo di inclusione nel kernel di WireGuard torniamo a parlarne, per due motivi molto diversi: la richiesta di inclusione di una nuova libreria crittografica (che, manco a dirlo, WireGuard usa) e Linus Torvalds.

La libreria è stata chiamata Zinc (i metalli sembrano andare di moda), si professa in realtà qualcosa meno di una libreria ma qualcosa più di un insieme ordinato di file sorgenti, e mira a sostituire l’attuale organizzazione di funzioni crittografiche presenti nel kernel: crypto.
E infatti Zinc a sua volta è un acronimo per Zinc Is Not Crypt (Zinc non è crypt), e nominare i componenti con acronimi di questo tipo è un’altra moda piuttosto antica (sapete da dove viene Linux, vero?).
Come dicevamo, anche questa libreria è stata presentata nella mailing list, e dallo stesso sviluppatore di WireGuard (Jason A. Donenfeld), con una lunga introduzione che spiega il suo punto di vista professandone niente meno che la necessità; compresa anche una certa esaltazione per le scelte fatte (ma forse è comprensibile, quando si è orgogliosi).
Ovviamente le prime reazioni non si sono fatte attendere, ed è possibile assistere ad una lotta senza esclusioni di colpi; d’altronde, comunità open vuol dire anche confronto (di fatti, idee, ed opinioni): a noi piace così!

Intanto, parlando di rete in generale, Linus ha accidentalmente commentato WireGuard e la sua inclusione nel kernel:

Btw, on an unrelated issue: I see that Jason actually made the pull request to have wireguard included in the kernel.

Can I just once again state my love for it and hope it gets merged soon? Maybe the code isn’t perfect, but I’ve skimmed it, and compared to the horrors that are OpenVPN and IPSec, it’s a work of art.

Comunque, riguardo un problema non correlato: Vedo che Jason ha effettivamente fatto la richiesta di pull per avere wireguard incluso nel kernel.

Posso affermare solo un’altra volta il mio amore per questo e sperare venga inglobato presto? Forse il codice non è perfetto, ma gli ho dato una scorsa, e in confronto agli orrori che sono OpenVPN ed IPSec, è uno stato dell’arte.

Nessun dubbio, quindi. E una voce tanto autorevole del benevolo dittatore aiuterà di certo il percorso di inclusione. Ah, senza favoritismi: questa è solo la sua opinione.

WireGuard verso l’inclusione nel Kernel

Facebooktwittergoogle_plusredditlinkedin


WireGuard si propone come una soluzione VPN che sia più semplice da usare delle soluzioni tradizionali (come IPSec), ed al contempo – parecchio – più performante di quelle basate su SSL (in particolare OpenVPN). Ecco un video di presentazione, ma più sotto trovate una breve spiegazione del funzionamento (o almeno un tentativo 😉 ).

Come spesso accade, una parte di WireGuard è un modulo specifico del kernel per generare e gestire l’interfaccia di rete da esso creata. E, per poter dire di far parte di Linux, deve essere integrato nel codice del kernel mainstream (quello emanato da Linus Torvalds).
L’ultimo giorno di luglio è comparsa nella mailing list del Kernel una proposta di patch per integrare il codice di WireGuard nel kernel: si tratta del primo passo per rendere ufficiale il nuovo modulo. E, magari, poterlo integrare nel Kernel di dispositivi embedded (come i cellulari).

Da ora in poi ci sarà un processo di review del codice, che sebbene non sia molto (meno di 40000 linee), difficilmente potrà essere completato per il prossimo rilascio (4.19): più probabilmente potremo vedere il nuovo modulo parte del Kernel 5.0. In effetti, come novità non sarebbe male.

Non sappiamo se sarà in grado di soppiantare le soluzioni tradizionali o anche solo OpenVPN, ma di sicuro si tratta di un’alternativa molto interessante. E open!

Proviamo a spiegare brevemente il funzionamento di WireGuard.
Una VPN si basa sulla criptazione della comunicazione tra due dispositivi direttamente di pacchetti IP (talvolta di frame ethernet). OpenVPN usa certificati SSL per poter autenticare e criptare il traffico, IPSec una serie di regole più o meno stringenti per l’autenticazione ed una chiave simmetrica (e condivisa a priori) per la criptazione; WireGuard usa IP sorgente (o destinazione) ed una chiave asimmetrica per l’autenticazione, e tramite le chiavi negozia con l’altro host una chiave di criptazione simmetrica che ogni intervallo predefinito di tempo o dati scambiati viene rinegoziata: questa tecnica risulta molto efficacie per garantire una criptazione robusta.
I protocolli usati da WireGuard per la criptazione sono i più sicuri in circolazione, ampiamente testati (e usati anche da altri).
Ogni peer può lavorare sia come client (creando una connessione con un altro peer) che come server (accettando una connessione); WireGuard usa UDP, ed il server necessita solo di una porta aperta.

Ad ogni interfaccia di WireGuard sono associati 3 elementi:

  1. la chiave privata (con cui decriptare i pacchetti che arriveranno criptati con la chiave pubblica associata);
  2. la lista di associazioni delle chiavi pubbliche dei peer che possono creare una connessione con gli IP dei peer;
  3. l’indirizzo IP (o gli indirizzi, o le reti) raggiunto tramite quel peer;

Il modulo Kernel serve a gestire la criptazione del pacchetto prima dell’invio all’IP remoto, a creare le interfacce, ma anche a modificare la tabella di routing: associa l’interfaccia creata ad ogni IP o rete raggiungibile configurata.
I file di configurazione prodotti risultano compatti, e non molto complicati; le performance sono notevoli (almeno stando alla documentazione da loro prodotta).

Rispetto ai concorrenti designati, WireGuard ha due limiti:

  1. l’impossibilità di lavorare a livello 2 della pila ISO/OSI (il frame ethernet di cui sopra): talvolta più che mettere in comunicazione due reti (facendo routing a livello 3) è utile estenderne una (incapsulando i messaggi a livello 2) e permettere l’uso di protocolli che non dipendono da IP.
  2. non è possibile usare TCP: la scelta di UDP è dettata dalle performance, ma talvolta è impossibile usarlo (bloccato da un firewall di cui non è possibile cambiare configurazione) o è preferibile usare TCP per connessioni poco affidabili (sebbene per una VPN sia una cattiva idea usare TCP).

I due limiti però riguardano casi particolari, e chi dovesse avere queste necessità normalmente è in grado di usare e impostare le tecnologie alternative. 😉

OpenWRT 18.06: prima release dalla pace con LEDE

Facebooktwittergoogle_plusredditlinkedin

A distanza di – poco più – di 6 mesi dalla riunione dei progetti OpenWRT e LEDE, vede la luce la prima release della pacificazione: OpenWRT 18.06.
Questa release dimostra che il progetto è ancora ben pieno di vita, e il lavoro portato avanti è davvero molto.

Non sono ancora disponibili le release notes (note di rilascio) abituali, con riassunti i vari interventi e miglioramenti effettuati, ma la lista di commit del repository git del progetto lascia ben pochi dubbi sulla quantità di lavoro; possiamo solo sperare che la qualità sia la solita, se non addirittura migliorata grazie ai nuovi metodi di verifica implementati. E, perché no, anche al rinnovato entusiasmo che sembra caratterizzare le prossime release.

Le build per le varie piattaforme sono già disponibili al downloadio ho intenzione di provarla il prima possibile sui miei sistemi, senza aspettare la lista ufficiale di modifiche.
Voi che fate, aspettate? 😉

Browsh: il browser completo per il terminale

Facebooktwittergoogle_plusredditlinkedin

I siti su internet oggi sono tutti improntati alla grafica, ma i dinosauri come me ricordano il tempo in cui le pagine erano quasi solo testo, con unici vezzi grafici il titolo un po’ più grosso e i link ben evidenziati.

Sempre in quei tempi era possibile usare browser puramente testuali, proprio perché tutte le informazioni erano testuali; che si preferisse links o lynx (ed io sono tra questi, nda), non c’era bisogno di tutta la pesante infrastruttura di server X e Desktop Environment per leggere velocemente un manuale (magari di installazione, chessò, di Arch… 😉 ).

Da allora HTML è progredito, diventando inscindibile dal CSS (ovvero le istruzioni per le decorazioni grafiche), così come dal web dinamico permesso da Javascript: lynx semplicemente non ce la fa più. Ma ecco apparire browsh (ovvero il BROWser per SHell).

In realtà browsh è un browser a metà: si occupa della renderizzazione su terminale, mentre la vera parte di caricamento e comprensione la lascia fare a Firefox in sottofondo. Ma grazie a questo stratagemma, tutta la potenza (e compatibilità) di Firefox è a disposizione, tab comprese (e su un terminale non è cosa da poco). Certo, le immagini rese in ASCIIArt risultano più pixellate di Mario Bros su Atari 2600, ma per tornare ad un sano bianco e nero basta schiacciare Alt+m e – buona parte dei- problemi scompare.
L’opinione personale (e da test molto rapidi e limitati) è che il risultato non sia ancora sufficientemente chiaro ed intuitivo per poter essere davvero efficacie, ma la strada è quella giusta.

Le forme di distribuzione vanno dal programma compilato al container docker; molto interessante questa possibilità, grazie alla quale basta connettersi via SSH al server per poter navigare in via testuale senza dover installare il browser sulla macchina locale (magari lenta o con poco spazio disco, come un Rapspberry Pi Zero).

Che posso dire? L’epoca del terminale non finirà mai! 🙂

ElementaryOS: versione 5.0 Beta

Facebooktwittergoogle_plusredditlinkedin

Elementary OS è una distribuzione apprezzata soprattutto per la pulizia dell’interfaccia grafica: la scelta di usare Pantheon come Desktop Environment e Plank, una barra di icone per lancio delle applicazioni e conteggio delle notifiche, unita alla scelta evidente di richiamare MacOS, le hanno permesso di crearsi uno spazio tutto suo nel mondo Linux.

La base di sviluppo è da sempre Ubuntu, 10.10 per la prima release (Jupiter, 0.1) del 2011 per diventare 12.04 LTS con la seconda (Luna, 0.2) del marzo 2013: questa è la prima vera release che incarna la visione del team di sviluppo, comprese alcune applicazioni scritte apposta. Da allora, ad ogni rilascio Ubuntu LTS segue il rilascio di una nuova versione di Elementary OS: 0.3 Freya per la 14.04, 0.4 Loki per la 16.04.

Ieri è stata la volta della versione 5.0, Juno. Come si vede è cambiato lo schema di numerazione: si voleva abbandonare lo zero iniziale in quanto non più progetto, ma oramai prodotto completo, ma al contempo si voleva dare continuità alla numerazione; inoltre  il lavoro fatto sotto il cofano è stato talmente esteso da far parlare di applicazioni di nuova generazione: ecco spiegato il salto. Nell’annuncio ufficiale si sottolinea comunque (in maniera ossessiva, direi) che questa è una beta, quindi incompleta sotto alcuni aspetti, come l’App Store che è vuoto.

Le novità sono parecchie, ma riguardano principalmente la resa grafica: nuovo set di icone, nuovi colori, uso estensivo di fogli di stile CSS per rendere omogenea la resa dei vari programmi.
Non mancano aggiornamenti alle applicazioni sviluppate apposta, compresa Elementary Code, ovvero l’editor di testo di riferimento.
Il risultato sembra, manco a dirlo, piuttosto accattivante.

Il modello di sviluppo non prevede rilasci scadenzati (come fa Ubuntu, che si prende l’impegno di rilasciare una versione ad una data prestabilita), ma piuttosto il lavoro procede e quando gli sviluppatori credono il prodotto sufficientemente maturo lo rendono disponibile pubblicamente (come Debian), quindi non possiamo sapere quando potrà esserci una nuova versione, ma sicuramente l’annuncio di questa Beta lascia sperare che il tempo non sia molto lontano.

Allora, chi vuole farci un giro?

GitLab si sposta da Azure a GoogleCloud

Facebooktwittergoogle_plusredditlinkedin

Appena dato l’annuncio dell’acquisizione da parte di Microsoft di GitHub, la paura, o anche solo l’antipatia, verso il nuovo padrone hanno creato una migrazione di massa: abbiamo assistito ad una vero e proprio esodo dei progetti ospitati. E molti hanno scelto il principale concorrente: GitLab.

Pochi, però forse, sanno che GitLab a sua volta si appoggia all’infrastruttura cloud di Microsoft, Azure: se l’obbiettivo era scappare dal nuovo padrone, in realtà ci si stava consegnando volontariamente, sebbene indirettamente.

Ecco perché l’annuncio del 25 Giugno fatto da GitLab potrebbe avere un risalto particolare: dal 28 Luglio (o giù di lì) lo stesso sarà migrato su piattaforma Google Cloud abbandonando Azure.
Il tempismo potrebbe essere sospetto, quasi ad arte, ma per poter migrare un portale ampio come GitLab serve tempo e preparazione: più di 200 TB di dati dei repository e 2 TB di database, il tutto a caldo, ovvero lasciando il sito principale attivo ed aperto all’uso durante tutto il processo.
Per permettere clonazione e sincronizzazione di sito primario (Azure) e secondario (Google) viene usato Geo, una tecnologia sviluppata da GitLab proprio per questi scopi e per cui questa migrazione rappresenta un test sul campo particolarmente gravoso ma interessante.

La motivazione principale può essere riassiunta in Kubernetes: in GitLab pensano che questa tecnologia sia l’unico modo per garantire il servizio ed aumentare la scalabilità dello stesso. E chi meglio di chi ha inventato Kubernetes per usarlo?
In parallelo GitLab cambierà anche la tecnologia di storage utilizzato, passando dal “solito” filesystem (NFS, considerato un single-point-of-failure) ad un sistema ad oggetti (il più famoso è S3 di Amazon, ma non è l’unico). Anche questo passaggio non è banale, e la sicurezza di non tralasciare nulla richiederà una certa cura.

Per chi volesse seguire da vicino i lavori è disponibile una pagina con tutti i dettagli del processo (ovviamente un repository Git su GitLab), da cui abbiamo conferma che il lavoro è stato avviato ben prima dell’acquisizione di GitHub (almeno 4 mesi fa). A voler essere cattivi, potremmo far notare che questo non implica non sia stato accelerato, però.