Carissimi,
dalla ripristinata pace dal mio eremoTR.reginadellapace.it mi trovo attualmente impegnato nello studio di un corso accademico di “Sistemi Operativi Dedicati”: mentre configuro il mio nuovo Raspberry pi 5 e ho nel carrello amazon business una nucleo, sto seriamente meditando di riesumare il mio Commodore 128 proprio per tornare – dopo tanti tanti anni – allo sviluppo sia di VERO software VERAMENTE “RealTime” che mettere le mani su ConTiki: un vero e proprio mini-os realtime nato su C64 (con l’originalissimo concetto di protothread) e poi portato su svariate piattaforme.
In questo clima di “back and forth” fra presente e passato remoto noto che è passata ancora relativamente in sordina una notizia che merita un’analisi tecnica e un momento di riflessione: il rilascio della versione 7.0 del Kernel Linux avvenuto lo scorso 12 Aprile 2026.
Solo pochi giorni fa, durante la lezione del corso di cui sopra avevamo notato quasi per caso la presenza della Release Candidate 4 sulla specifica sezione di GitHub mantenuta ancora da Linus Torvalds in persona … ecco, in questo caso da neo-“ingegnere” sento quasi un dovere di comportarmi come Jerry Pournelle dy Byte (dal suo mitico Chaos Manor) per delle considerazioni più sentimentali che tecniche: guardare ad un kernel Linux oggi nel 2026 è come osservare un ecosistema che ha sfidato negli anni i processi naturali dell’entropia del software 🙂
I dettagli architetturali della specifica release 7.0
Scendiamo un attimo nel tecnico, senza soffermarci sui dettagli minori del changelog che potete leggere su qualsiasi aggregatore, ma valutando l’impatto architetturale nel suo complesso su tre aspetti veramente “macroscopici”:
un vero e proprio incubo ingegneristico
A – Ottimizzazione per l’Hardware “Contemporaneo”: Il nuovo kernel non si limita a supportare nuove istruzioni, ma lo scheduler è stato completamente ristrutturato per permettere una gestione asimmetrica dei core in modo nativo, riducendo in modo importante l’overhead quando in esecuzione su macchine ad elevate prestazioni;
B – Sicurezza: L’integrazione di Rust per la scrittura dei moduli di sistema non è più un esperimento confinato, ma con la sua definitiva accettazione kernel-level questa release marca un punto di non ritorno verso una gestione della memoria safe-by-design a livello di driver;
C – Deprecation : dopo 14 anni dal taglio del supporto alle cpu 386 avvenuto nel dicembre 2012 in occasione del rilascio della versione 3.8 del Kernel è ora il turno delle cpu 486 oltre a decine di vecchie architetture ormai non più mantenute da tempo. Nel primo caso fu Ingo Molnár di Red Hat a proporne formalmente la rimozione per ridurre la complessità del codice SMP sostenendo che il vecchio hardware era ormai troppo obsoleto per giustificare il lavoro di manutenzione (e Torvalds la accettò con un commento sarcastico del tipo “I’m not sentimental about x86 hardware”) mentre in questo caso analoghe motivazioni le hanno addotte un numero ben superiore di altri manutentori.
Dal Freax 0.01 del 1991 al Kernel 7.0 del 2026
Mentre la versione 0.01 di quel progetto che all’inizio non si chiamava nemmeno Linux (ma – appunto – Freax quale portmanteau di “free”, “freak” e “x” per alludere a Unix) nel 2026 siamo in grado di scaricare un’immagine compilata in pochi istanti, ma il vero salto evolutivo compiuto dai tempi di quel rudimentale “task switcher” nato per i processori 386 ad oggi dove quel kernel fa “girare” di tutto, dai supercomputer futuristici, ai nostri pc, dai dispositivi embedded fino a macchine a 16 e persino 8 bit è una delle più grandi lezioni di ingegneria del software disponibili ad oggi!
Alla fine, non è stata l’eleganza del design teorico a vincere, ma il pragmatismo iterativo: fin dagli inizi se un pezzo di codice funzionava, entrava nel kernel … se corrompeva lo user space (ad esempio) veniva rigettato senza pietà … tutt’ora la versione 7.0 è arrivata al giorno del rilascio dopo un rigoroso processo di peer review attraverso ben 7 (SETTE) release candidate! Una vera e propria garanzia di ostinata, granitica affidabilità in cui sicuramente gli umani sono stati affiancati sia da model checker “tradizionali” che da strumenti più ai-driven.
Il Paradosso di GitHub
Fa riflettere non poco una visita al mirror-repository ufficiale del Kernel di Linux su GitHub, dove a fare da ultimo “gatekeeper” c’è ancora il medesimo Linus Torvalds degli inizi … una continuità operativa che oggettivamente costituisce un’anomalia statistica nel settore IT: con un progetto globale dove il “Direttore dei Lavori” è lo stesso da oltre trent’anni abbiamo anche un raro esempio di Tracciabilità Storica completa!
Però tutti sappiamo che ormai GitHub è in mano a Microsoft e per quanto la cosa stoni e faccia storcere il naso a tanti (me incluso) forse serve fare un poco di ordine: prima di Git, il “sistema” di sviluppo del kernel usava un sistema di controllo di versione proprietario chiamato BitKeeper; quando poi l’azienda che lo produceva decise di ritirare la licenza gratuita per gli sviluppatori open source, Linus si trovò all’improvviso senza strumenti “open” per cui in poche settimane nel 2005 sviluppò il core di Git da zero, perchè riteneva necessario un sistema decentralizzato, veloce e crittograficamente sicuro (per tutelare il codice da ogni forma di possibile corruzione).
Fu nel 2008 che quattro persone (Tom Preston-Werner, Chris Wanstrath, PJ Hyett e Scott Chacon) hanno fondato GitHub come azienda commerciale costruendo un business milionario intorno al protocollo “libero” creato da Torvalds: sopra il motore robusto di Git (che all’epoca era ancora piuttosto ostico da usare da riga di comando specie per i non addetti) è stata costruita un’interfaccia web collaborativa oggettivamente ben fatta, democratizzando il processo di sviluppo multiutente e diventando un hub globale de facto …
… il tutto fino al 2018, anno in cui con un atto storico a dir poco clamoroso la stessa azienda che sotto Steve Ballmer definiva Linux “un cancro”, sotto la guida invece di Satya Nadella ha sborsato 7,5 miliardi di dollari per comprarsi la casa mondiale dell’open source, riuscendo poi persino ad integrarla in modo magistrale con il proprio ambiente di sviluppo.
Torvalds l’Irriducibile!
Ad oggi mentre più del 98% degli sviluppatori al mondo (inclusa la stessa Microsoft) usa GitHub, GitLab o simili per fare comode pull request via web, Torvalds e i suoi “luogotenenti” continuano a gestire il progetto software più complesso della storia scambiandosi patch testuali via email sulla Linux Kernel Mailing List (LKML) e facendo i merge sui server blindati di kernel.org.
Ribadisco: il repository torvalds/linux che si raggiunge su GitHub è, letteralmente, un mirror in sola lettura tenuto aggiornato per i “comuni mortali”.
Considerazioni “RealTime”
Mentre mi preparo a fare esperimenti “bare metal” con il C-128 e Contiki dal mio “Chaos Manor” di eremoLU.reginadellapace.it (con la meravigliosa vista sul Pisanino a fare da dissipatore termico naturale per i miei server ma soprattutto la mia mente) non posso fare a meno di notare come se da una parte Linux come sistema operativo sia ormai diventato uno standard “planetario” (di questi giorni la notizia in cui la Francia ha “deprecato” tutto il software chiuso) la sua magnificenza sembra allontanarlo sempre di più dalle sue radici di controllo totale e deterministico dell’hardware.
Nel 2026 per poter ottenere un comportamento “RealTime” puro (detto Hard-RealTime) un Ingegnere sviluppatore deve astrattamente guardare altrove, comunque verso soluzioni con micro-kernel specializzati, lasciando a Linux il ruolo più “pesante” di direttore d’orchestra dei layer superiori in un senso al più Soft-RealTime.
Make? Whats?
In tanti anni è cambiato radicalmente il modo di gestire linux: I più “anziani” tra i miei lettori ricorderanno le nottate passate a configurare il kernel a colpi di “make” e “menuconfig” (sperando di aver selezionato i driver giusti per non incorrere in un kernel panic al riavvio) mentre oggi il Kernel 7.0 troverà presto il suo posto in Ubuntu LTS ed in generale le tante distribuzioni (più di 500 attivamente mantenute) vengono pacchettizzate e distribuite attraverso pipeline automatizzate da sembrare magia agli occhi di chi compilava su dischi IDE a 5400 rpm: L’artigianato del tuning manuale ha ormai ceduto il passo all’ingegneria dei sistemi su larga scala.
Politica? Si, in questo caso si, Grazie!
Mentre ormai il mondo che “gira” intorno a Linux non ha più le caratteristiche di una “religione” come ai tempi delle infuocate discussioni sulle mailing list degli anni ’90, il modello “open”che lo accompagna sta diventando una scelta sempre più frequente persino in Politica, quella vera: molto recente la notizia dell’abbandono di parte dell’intera Francia del software “chiuso”, avevano già fatto scelte analoghe (in ordine cronologico inverso) Corea del Sud, Cina e Russia, Germania, Austria, Brasile … e ancor prima singole città tipo Monaco.
Ritengo il trend “confortante” così come l’arcobaleno che vedo dalla finestra di “eremotr” alla fine di un bel temporale primaverile … saluti a tutti mentre mi metto in viaggio verso Porto Recanati
EremoTR 14 Aprile 2026
Ave Maria!
Marco Piagentini
P.S.L(ungo): Fra il 1996 e il 1997 mi ricordo chiaramente come per la mia neo-fondata azienda WNET (Wizard Networking Education and Training) indicai ai miei soci che la strada del futuro era sicuramente costellata di linux, così spinsi tutti a prendere la distribuzione italiana di “Caldera Open Linux” mentre io continuai ad investire sul “mondo NT” certificandomi prima product specialist per NT 3.51, poi MCSE per NT.40, infine MCSE per Windows 2000 Server e MCT … da allora sono ancora un Microsoft Certified Trainer con la mia certificazione sistemistica sempre aggiornata all’attuale Microsoft 365 Certified: Enterprise Administrator Expert ma il mio cuore resta “command line”. Certo, non ho più cmd.exe come shell, ma l’attuale Windows Subsystem for Linux fa il suo buon lavoro nel compilare ed eseguire il codice che a lezione il mio professore fa girare su un Raspberry pi5 e l’ultimo data recovery (eseguito per motivi squisitamente professionali) l’ho portato a termine con una Ubuntu LTS live e ddrescue, perchè un povero WD Passport da 1TB (a proposito, ho appena comprato un modello da 6TB) non voleva più saperne di essere montato sotto windows, e anche su linux il suo connettore usb-3 canonicamente danneggiato generava un problema singolare: full speed per 20-25 secondi e poi downgrade a pochi k al secondo … un vero e proprio delirio ottenere un file immagine da 1TB per completare – alla fine con successo totale – il data recovery di anni di dati contabili.
Save as Image
Save as PDF
