Clear Linux rinasce con The Ur Project: così cambia il modo di creare Linux

Creare una nuova distribuzione Linux nel 2026 può sembrare un esercizio quasi anacronistico: Debian, Fedora, Ubuntu, Arch, openSUSE e decine di progetti più specializzati coprono ormai gran parte degli scenari desktop, server, cloud ed embedded. Eppure Auke Kok, uno degli ingegneri che hanno contribuito ad alcune delle iniziative Linux più importanti di Intel, ha deciso di ripartire quasi da zero con The Ur Project (sito ufficiale). L’obiettivo non è aggiungere un’altra distribuzione all’elenco, ma ripensare il modo in cui una distribuzione nasce, viene costruita, aggiornata e perfino derivata da altre.

Kok ha lavorato per molti anni sui sistemi Linux di Intel e ha partecipato alle esperienze Moblin, MeeGo, Tizen e soprattutto Clear Linux OS. Nel suo primo intervento dedicato a Ur racconta di aver trascorso più di 8 anni su Clear Linux e circa 19 anni complessivi a studiare come costruire distribuzioni. Il curriculum di Kok è di quelli da “veterano” assoluto del settore: basti ricordare la sua lunga permanenza nell’azienda di Santa Clara, terminata nel 2023.

Ur non è quindi l’esperimento occasionale di uno sviluppatore curioso: dietro il progetto c’è l’esperienza accumulata gestendo sistemi che distribuivano decine di aggiornamenti al giorno e dove prestazioni, sicurezza e automazione avevano un ruolo centrale.

Ur non vuole essere semplicemente un’altra distribuzione Linux

Intel ha interrotto Clear Linux nel 2025 e i repository ufficiali del progetto riportano ormai esplicitamente la dicitura “DISCONTINUATION OF PROJECT“. Il repository principale su GitHub risulta archiviato dall’agosto 2025. Ur nasce quindi anche dal tentativo di recuperare alcune idee maturate durante quell’esperienza, evitando però una serie di errori commessi in precedenza, che Kok stesso riconosce apertamente.

Ur dovrebbe diventare una piattaforma per costruire distribuzioni Linux, non soltanto una distribuzione preconfezionata da installare sul PC.

L’idea, di per sé, non è nuova: progetti maturi come Yocto Project consentono da anni di selezionare componenti, ricostruire il software dai sorgenti e produrre immagini Linux fortemente personalizzate, soprattutto per sistemi embedded e appliance. Ur tenta di affrontare il tema da un’angolazione diversa: unificare maggiormente infrastruttura di build, repository, composizione del sistema e gestione dei pacchetti, rendendo più semplice anche la creazione di distribuzioni general purpose e delle loro derivate.

Utenti, sviluppatori e aziende dovrebbero quindi poter selezionare componenti, creare repository propri, ricostruire pacchetti e generare sistemi destinati a utilizzi molto diversi senza dover costruire attorno al progetto una complessa infrastruttura separata. Dalla stessa base tecnologica potrebbero nascere un sistema embedded estremamente ridotto, una distribuzione desktop con GNOME o Xfce, un’immagine cloud oppure un sistema basato su aggiornamenti atomici.

Molte distribuzioni tradizionali separano nettamente infrastruttura di compilazione, repository, strumenti di installazione, package manager e generatori di immagini. Ur punta invece a condividere una parte consistente del codice tra chi produce il sistema e chi lo utilizza.

Kok sintetizza il principio parlando di “composition as a layer“: composizione, installazione e gestione dei pacchetti dovrebbero poggiare su meccanismi comuni. Se l’idea arriverà a maturità, un’immagine avviabile, un sistema installato e un insieme di pacchetti non rappresenterebbero più tre mondi gestiti da strumenti quasi indipendenti, ma diverse manifestazioni della stessa descrizione del sistema.

La lezione di Clear Linux: velocità eccellente, contributi troppo difficili

Clear Linux ha dimostrato per anni quanto margine di miglioramento possa nascondersi nella parte software. La distribuzione Linux Intel otteneva risultati notevoli anche su processori AMD: molti vantaggi derivavano infatti da compilatori, ottimizzazioni, configurazioni, librerie e scelte effettuate a livello di sistema operativo, non da qualche meccanismo utilizzabile esclusivamente sui chip Intel.

La sua architettura degli aggiornamenti era altrettanto particolare: il client swupd operava a livello di sistema operativo e Clear Linux faceva ampio uso di aggiornamenti delta, evitando quando possibile di trasferire nuovamente dati già presenti sulla macchina. Kok continua a considerare quella scelta valida e, nel suo post, precisa che i delta non rappresentavano affatto uno degli errori del progetto.

Il problema principale, secondo l’ex ingegnere Intel, stava altrove: contribuire a Clear Linux era troppo complicato. Modificare un componente, provarne rapidamente una variante, proporre una modifica e inserirla nel processo produttivo richiedeva uno sforzo non indifferente.

A questa difficoltà si aggiungeva un’infrastruttura cresciuta progressivamente nel tempo: dashboard, framework appartenenti a generazioni diverse e strumenti aggiunti uno sopra l’altro dovevano coordinare un flusso molto intenso di aggiornamenti. Funzionava, anche grazie alle risorse di Intel, ma non costituiva necessariamente il modello ideale da riprodurre altrove.

Ur prova a partire dall’estremo opposto: rendere semplice non soltanto installare un pacchetto, ma anche produrlo, modificarlo, pubblicarlo in un repository e creare una propria variante del sistema.

Più di 1.000 progetti open source e desktop GNOME e Xfce

L’ambizione iniziale è tutt’altro che minimale. Kok parla già di oltre 1.000 progetti open source preparati per la distribuzione, compresi GNOME e Xfce4.

La presenza di GNOME e Xfce suggerisce che Ur non nasce esclusivamente come piattaforma server o embedded: la medesima tecnologia, come spiegato in precedenza, consentirà la creazione di immagini desktop complete, sistemi cloud e installazioni specializzate.

Una “Ur Desktop” potrebbe essere soltanto una delle composizioni possibili: un produttore di appliance potrebbe selezionare invece kernel, systemd, strumenti di rete e pochi servizi, escludendo completamente l’ambiente grafico.

Kok indica Rust come uno dei linguaggi centrali del progetto (sicurezza della memoria al centro degli sforzi), specificando che dovrebbe comparire sia negli strumenti usati per produrre la distribuzione sia sul lato che consuma e installa i componenti.

Nella descrizione iniziale compare anche la possibilità di realizzare sistemi con aggiornamenti atomici. Un aggiornamento di questo tipo tenta di evitare gli stati intermedi: il sistema passa da una configurazione coerente A a una configurazione coerente B, con la possibilità di mantenere la precedente per un eventuale rollback. Ur, almeno nelle intenzioni iniziali, non sembra però voler imporre il modello atomico a ogni installazione.

L’intelligenza artificiale entra perfino nella creazione dei pacchetti

L’elemento più insolito è probabilmente quello definito “Package designer MCP“. Il riferimento è al Model Context Protocol (MCP), il protocollo che consente a modelli linguistici e applicazioni AI di interagire con risorse e strumenti attraverso interfacce standardizzate.

Kok dichiara apertamente che nel progetto c’è una componente AI e cita un package designer basato su MCP, ma non ha ancora pubblicato dettagli sufficienti per comprenderne il funzionamento definitivo. L’interpretazione più plausibile, osservando le funzioni offerte da MCP, è uno strumento capace di mettere a disposizione del modello sorgenti, metadati e comandi necessari alla preparazione di un pacchetto.

Un sistema del genere potrebbe aiutare a generare ricette di compilazione, individuare dipendenze, aggiornare versioni upstream o analizzare errori di build. L’AI potrebbe ridurre il lavoro ripetitivo dei maintainer, ma non elimina la necessità di una catena verificabile.

Con buona pace di chi continua a considerare l’intelligenza artificiale incompatibile con lo sviluppo di software critico. È un’impostazione che, almeno sul piano pratico, appare in linea con l’approccio portato innanzi da Linus Torvalds: usare gli strumenti AI dove possono far risparmiare tempo, senza attribuire loro affidabilità o autonomia che non possiedono. Mai prescindere dalla supervisione e dal controllo umano; anche perché la responsabilità è sempre e comunque esclusivamente dello sviluppatore.