Saturday’s talks: l’eterno dilemma dell’utente Linux: distribuzioni stabili o super-aggiornate?

Linux è ovunque, anche in orbita

Una delle più comuni domande di chi non conosce ancora il mondo Linux è la classica: quale distribuzione fa al caso mio? Ce ne sono fin troppe!

La scelta non è semplice e non mireremo a chiarirvi le idee con questo articolo. V’è il rischio, anzi, che possiate uscirne più confusi di prima, se non con una crisi esistenziale che vi farà venire voglia di fare distrohopping.

Non crediate, però, che, chi invece lavora in questo settore da anni, abbia necessariamente preso una posizione: non solo non v’è una risposta corretta o una soluzione universalmente adeguata per ogni utilizzo ma, come tutti sappiamo, solo gli inetti non cambiano mai idea.

In generale, sebbene il panorama delle distribuzioni Linux installabili sia, ad oggi, discretamente ampio, si tratta quasi in ogni caso di distribuzioni derivate da poche, storiche radici comuni. Ad oggi, quindi, una scelta realistica su una workstation personale tende a essere ristretta nell’insieme che comprende Debian (e Ubuntu, che esplicitiamo perché probabilmente la più conosciuta), Red Hat Enterprise Linux e cloni, Fedora, Slackware, OpenSuse e Arch.

Non è nostra intenzione voler scatenare una flame war, dal momento che ogni distro (o quasi, non ce ne vogliano i fan di Hannah Montana) ha la sua ragione d’esistere e che tale ampiezza di scelta incarna perfettamente lo spirito dell’open-source, ovvero la libertà di scegliere.

Vogliamo però focalizzare su un aspetto generale che tende a dividere le distribuzioni lungo uno spettro e a polarizzare le opinioni, ovvero la frequenza (nonché i criteri) con cui esse aggiornano i propri pacchetti.

Vi anticipiamo che esistono parecchie sfaccettature alla tematica e agli approcci delle singole distro e che scegliere quella ideale, anche al netto di questo fattore, non è un processo banale (ne parleremo in un articolo dedicato, prima o poi), ma ciò che salta subito all’occhio tra, ad esempio, un utente Debian e un altro che ha installato Arch, è che quest’ultimo avrà un ambiente di lavoro che può essere anche sostanzialmente diverso dal primo, nel bene e nel male (basti pensare alla differenza che vi è stata tra Gnome 2 e 3) e una versione del Kernel Linux che sarà molto vicina (se non, addirittura, coincidente) all’ultima versione disponibile su kernel.org.

L’esempio è tanto estremo quanto tipico: Debian è una distribuzione ben nota, tra le più longeve con 30 anni di storia, popolare in ambito server e che ha un approccio conservativo, con una major release mediamente ogni 2 anni (ogni nuova versione esce “quando è pronta”), mentre Arch è una distribuzione decisamente più recente, popolare in ambito desktop e gaming, di tipo rolling-release, ovvero priva di numero di versione, poichè segue sempre le ultime versioni di ogni pacchetto.

Chiariamoci, Arch non è l’unica rolling release, Debian non è la distro più conservativa (il podio, in questo senso, spetterebbe a Slackware, che ad oggi non usa nemmeno systemd) ed esistono ragionevoli vie di mezzo, come ad esempio Ubuntu (che rilascia ogni 6 mesi) e Fedora (anch’essa rilascia ogni 6 mesi, ma aggiorna le versioni dei pacchetti con molta più aggressività), ma non vogliamo, oggi, focalizzare su una distribuzione in particolare, bensì sulla dicotomia delle due filosofie (stabilità vs freschezza) e su cosa tale scelta comporti.

Prima di iniziare, precisiamo che per stabilità non intendiamo la frequenza (o rarità) con cui il software tenda a crashare, bensì la stabilità nel tempo delle medesime versioni del software.

La definizione è del tutto arbitraria (per alcuni, le versioni software di 6 mesi fa sono da considerare nuovissime) e, in questo articolo, considereremo stabile una distribuzione che mantenga, ad esempio, la stessa major release del kernel (e, verosimilmente, anche di una buona parte dei suoi pacchetti) per almeno 6-12 mesi.

Cominciamo dalla parte ‘facile’, ovvero i vantaggi di avere una distro aggiornatissima:

  • Supporto hardware migliore: portandovi gli ultimi (o quasi) Kernel Linux disponibili, la probabilità che il vostro laptop o desktop appena acquistati, con CPU e schede Wifi di ultima generazione, funzionino subito, sono massimizzate. Sebbene questo effetto sia percettibile più che altro da chi ha acquistato o acquista spesso hardware recente, è un’innegabile realtà che, in alcuni casi, senza versioni aggiornate dei pacchetti si corre il rischio di non sfruttare appieno l’hardware. E’ stato il caso, ad esempio, dell’uscita di nuovi processori Intel con due categorie di core, supporto che è stato introdotto nella versione 5.18 di Linux, ma non ne mancano di altri, soprattutto se si è appena acquistato un laptop.
  • Ultime feature del software: va da sè che, seguendo gli ultimi sviluppi direttamente dai progetti di ogni pacchetto, si trarrà vantaggio di tutte le ultime novità che li hanno interessati (siano esse bugfix minori o nuove feature).
  • Userbase molto attiva online in caso di problemi: i subreddit di Ubuntu e Arch (come anche i rispettivi forum) sono molto più attivi di quelli di distro più ‘stabili’ e conservative. Le ragioni possono essere opinabili, alcune intuibili (se tutto funziona e non si guasta niente da anni, perchè andare a scrivere su un forum?) e altre non del tutto chiare, ma il risultato non cambia.
  • Sicurezza: seguendo molto da vicino l’ultima versione dei software, saremo tra i primi a ricevere le security fix, che dovranno invece venire riadattate e riviste anche dalle distro più conservative, per essere incluse anche nelle versioni antecedenti del software (processo che può richiedere da alcune ore ad alcuni giorni). Secondo alcune fonti, però, sorge il sospetto che non tutte le falle di sicurezza ricevano una CVE e che, quindi, alcune patch non arrivino a essere integrate nelle distro stabili poichè passano ‘sotto il radar’, seppur fixate da nuove minor version. Resta anche da tener presente che, anche nel migliore dei casi, v’è comunque un necessario intervallo di tempo (da alcune ore ad alcuni giorni) da attendere affinchè i team di sicurezza integrino le patch nella propria distribuzione e, abbiamo già visto, nella cybersecurity il tempo può essere un fattore strategico.

Su quest’ultimo punto non ce la sentiamo di commentare: vi sono opinioni contrastanti su forum e web e, se è vero che, ad esempio, la versione di Chromium che si trova in Debian riceve le patch di sicurezza, in media, alcuni giorni dopo che le riceva Chrome (e si potrebbero fare esempi simili), è anche vero che le distribuzioni ‘stabili’ sono alla base di pressocchè tutte le infrastrutture informatiche basate su Linux, anche mission critical.

Stando a questi primi ragionamenti, verrebbe da chiedersi – se siamo su un desktop e non su un server, perchè fare altrimenti? Quale assurdità sarebbe, decidere deliberatamente di rimanere indietro con le versioni?

Anche qui, non vi è una soluzione unanime e ciò che stiamo per dire potrebbe risultare controverso o scatenare una guerra ideologica, ma è innegabile che utenti diversi abbiano priorità diverse e che, quindi, alcune distribuzioni siano meno adatte di altre, per certi utenti e certi utilizzi.

Non installerete Debian, ad esempio, se siete sempre in cerca dell’ultimo Kernel e dell’ultima feature e volete che l’ultimo commit sul repository dei vostri progetti preferiti finisca sul vostro PC nel giro di una settimana.

Analogamente, non installerete Arch se non siete disposti a ‘sporcarvi le mani’ quando serve, con tutti i pro che la cosa comporta. Sebbene vi sia praticamente sempre qualcosa da imparare, quando ci si ritrova a fare troubleshooting, non è detto che tali skill siano di nostro interesse (ebbene si, non tutti gli utenti Linux sono informatici di professione) e, soprattutto, può capitare in momenti imprevisti, quando si avevano altri piani. E’ per quest’ultimo aspetto che vogliamo fare alcuni esempi.

Immaginate di essere un professionista che usa il proprio PC per lavoro. Magari avete delle attività da seguire o dei progetti da discutere con dei clienti importanti la mattina successiva e, la sera prima di andare a dormire, decidete di scaricare e installare gli ultimi aggiornamenti. E’ vero, potevate aspettare il weekend, ma dal momento che non sapete se vi sono aggiornamenti di sicurezza inclusi nella lista e non vi va di andare a leggere nel dettaglio in cosa consistono, decidete di farlo adesso e togliervi il pensiero. Del resto, si tratta giusto di un paio di pacchetti, tra cui grub, il boot loader.

L’aggiornamento termina con successo in pochi secondi. Meglio così, perchè domani dovete svegliarvi belli freschi e di buon’ora. Come ultimo passaggio, decidete di riavviare la macchina per vedere se tutto ‘torna’.

E’ già la seconda o la terza volta, questa settimana, che riavviate la macchina perchè gli aggiornamenti lo richiedono. Riavviare è questione di una manciata di secondi, tuttavia avete la vostra bella disposizione di finestre disposte su 4-5 desktop virtuali e, ad ogni riavvio, dovete riaprire tutto da capo. Poco male, anche se ogni tanto riflettete su quanto vadano a sommarsi tra di loro quei 3 minuti spesi ogni volta a far questo.

Mentre rinsavite dai pensieri, però, mettete gli occhi nuovamente sullo schermo del vostro laptop e notate che la macchina non fa il boot: mentre stavate per andare a dormire, siete fermi davanti a un terminale, con il cursore che lampeggia e un errore ben poco familiare.

Domattina non avrete tempo di risolvere, dovete farlo adesso e, quindi, la vostra priorità è cambiata: stavate per alzarvi dalla sedia e, invece, avete vinto un nuovo problema da risolvere, peraltro con una certa urgenza.

Dal momento che di fare il boot normalmente non se ne parla e non riuscite neanche a entrare in modalità rescue, vi serve una chiavetta USB con una live image, per poter avere un terminale funzionante e risolvere la situazione. Nella vostra sfortuna, siete fortunati: siete a casa e avete accesso a tutto ciò che vi serve, quindi inserite la chiavetta e fate un chroot, bootate nella vostra installazione e reinstallate correttamente grub.

Se foste stati in ufficio, avreste dovuto chiedere a un collega di scaricare una ISO della vostra distribuzione e reperire una chiavetta su cui scriverla. Se, invece, fosse stati in auto, in treno o in hotel in trasferta, avreste avuto, diciamo, una situazione interessante sotto mano.

Una lancia a favore della community, qui, va spezzata: la soluzione e i passaggi da seguire erano sui forum e su Reddit praticamente già da subito e, spesso, se si da un’occhiata su forum e sito web della distro prima di fare degli aggiornamenti critici, si sa già a cosa si potrebbe andare incontro e si ha già quindi una soluzione sotto mano prima ancora di avere il problema, ma la sostanza non cambia molto.

Un evento del genere, sebbene decisamente raro, è del tutto possibile e si è già verificato, interessando sia Arch, sia alcune derivate.

Un altro esempio viene da altro articolo di blog, in cui l’autore ci racconta della sua positiva esperienza con Gentoo, un’altra rolling release, installata 20 anni fa e ancora funzionante. Ne parleremo un altro giorno, in quanto già cosa notevole, ma la parte che oggi vogliamo discutere è quella in cui questa persona ci racconta di una situazione tanto rara quanto inconveniente: un aggiornamento di udev andato non proprio benissimo. Un incidente raro, ma che capitava nel momento peggiore:

The worst example of this was when I had to do a nontrivial upgrade to udev. After the upgrade and reboot I could not even get a shell prompt. Unfortunately, this happened just as I was moving to another city for a new job. I simply could not spend time debugging this.
Great: A major move coming up, and I don’t even have a computer! I did not have a smartphone either.

L’esempio peggiore è stato quando ho dovuto fare un aggiornamento non banale di udev. Dopo l’upgrade e il reboot non avevo neanche una shell. Sfortunatamente, ciò accadeva proprio mentre stavo traslocando in un altra città per un nuovo lavoro. Non avevo tempo per pensare a debuggare questa roba. Bene: un trasloco non da poco in vista senza neanche un computer! Non avevo neanche uno smartphone.

L’autore aggiunge:

These kinds of breakages are not that common. Once every 1.5-2 years or so. Most of the time I resolve it within a day or two. Still, I would never use Gentoo for professional work. Imagine trying to explain to your boss that you can’t do any work because you broke a udev upgrade.

Questo genere di problemi non sono affatto frequenti. Capiterà ogni 1,5-2 anni o giù di lì. La maggior parte delle volte li risolvo entro un giorno o due. In ogni caso, non userei mai Gentoo per lavoro. Immaginatevi di dover spiegare al vostro capo che oggi non potete lavorare perché un aggiornamento vi ha spaccato udev.

Inconvenienti simili sarebbero stati aggirabili decidendo, ad esempio, di rimandare gli aggiornamenti al weekend, così da avere più tempo per far fronte a eventuali imprevisti, ma il problema è che non è sempre chiaro, a prima vista, se siano aggiornamenti di sicurezza o solo bugfix e feature aggiunte.

Su una distribuzione stabile, invece, (specialmente nel caso di Debian) si avrà la quasi certezza che tali aggiornamenti sono stati proposti perché interessano la sicurezza del sistema e che, quindi, non è una buona idea rinviare.

In tema di ‘incidenti’ dovuti alla novità, alcuni anni fa, uno dei Kernel più recenti del tempo, si scoprì potesse causare addirittura danni agli schermi di alcuni laptop a causa di un bug.

Inutile dire che, in quel caso, gli utenti Arch (specialmente coloro che avevano anche i repository di test attivi ed escludendo coloro che hanno optato per usare un kernel LTS) sarebbero stati i primi a ritrovarsi quel kernel, seguiti (dopo alcune settimane) dagli utenti Fedora, mentre gli utenti Debian (ma anche di quasi tutte le distro ‘stabili’) non sarebbero stati minimamente affetti.

Per questi, infatti, il bug sarebbe dovuto rimanere nell’ombra, senza che nessuno lo incontri, per molto, molto tempo, prima di arrivare a far parte delle nuove major release di una Debian o RHEL (ma anche di una Ubuntu) di turno.

In vena simile, nel 2018, venne fuori un bug di un Kernel appena uscito che poteva causare corruzione del filesystem in certe specifiche situazioni e, nel 2016, un altro bug Kernel poteva causare seri problemi a certi laptop Samsung.

Un bug poco simpatico ha interessato anche l’ultimo Kernel (la versione 6.3.3), uscita giusto pochi giorni fa, anche se di buono c’è che, se possiamo leggerne un bug report, significa che la problematica è stata resa nota e il roll-out di tale Kernel sospeso, dove non già avvenuto.

Nella fattispecie, tale versione appena uscita del Kernel è, come prevedibile, già in Arch da più di una settimana e sarebbe normalmente finita anche in Fedora a stretto giro, se non vi fosse stata la diligenza di chi ha riportato tempestivamente il problema nel bug tracker.

In questo caso, la problematica è stata segnalata abbastanza rapidamente, visto che il Kernel 6.3.3 è stato rilasciato praticamente nel mese in cui scriviamo, e ciò è testamento che, ancora una volta, la community è reattiva e in buona salute.

Ricordiamo, non v’è sistema operativo che è immune da questo genere di problematiche, ma se il codice è open-source e chiunque può aprire facilmente dei bug report, i problemi vengono a galla in fretta e in fretta vengono risolti.

Di esempi del genere se ne possono fare anche altri, anche se quasi tutti di più lieve entità come, ad esempio, un programma che smette di funzionare dopo un aggiornamento o dei piccoli ma nuovi bug introdotti proprio dalle nuove versioni.

Casi del genere sono spesso di poco conto ma innumerevoli, poichè sono parte della naturale evoluzione del software, e vi si è esposti tanto più spesso quanto più spesso si riceve sulla propria macchina del codice nuovo (ergo, gli aggiornamenti di versione di cui stiamo parlando).

Sebbene delle regressioni come quelle sopra citate accadano di rado e siano, tranne che nei casi più gravi, di facile soluzione (spesso si tratta di in pochi passaggi e pochi minuti spesi, ammesso di non andare in panico e decidere di reinstallare tutto), essi sono una parte, seppur non quotidiana, dell’esperienza bleeding edge (che, anche chiamandola leading edge, non fa necessariamente meno male).

Insomma, inseguire l’ultima versione del software troppo da vicino comporta dei vantaggi, ma con lo svantaggio di regalarvi, occasionalmente, momenti… interessanti.

Tornando al nostro esempio precedente, supponiamo che, sul vostro laptop di lavoro, usiate Debian. Quella stessa sera che immaginavamo poche righe fa sarebbe terminata come previsto, senza incidenti, probabilmente senza neanche un aggiornamento da fare perchè avete la stessa versione di grub da quasi 2 anni, non riavviate il pc da un mese perchè gli aggiornamenti avvengono molto di rado e, anche quando avete dovuto farlo in seguito a un aggiornamento di routine, non vi siete mai chiesti se poi sarebbe tutto ripartito correttamente perchè è sempre andata così.

Ci teniamo a essere precisi: ciò non vuole essere un attacco ad alcune distribuzioni, anche perchè la realtà è spesso più complicata di così e, pur rimanendo nel perimetro di una specifica distro, possiamo decidere almeno in parte quanto vogliamo essere bleeding edge. Esempi del caso sono l’utente Fedora che decide di rimanere una major release indietro rispetto all’attuale, l’utente Arch che non lancia un aggiornamento ogni sera e l’utente Debian che, però, segue il branch sid).

Da notare, anche, che le community Linux (specialmente quella di Arch) sono estremamente collaborative e inclini a condividere la conoscenza (la wiki di Arch ha pochi rivali) e le distro a rapida cadenza di aggiornamenti sono la ragione per cui è possibile avere un’esperienza Linux moderna, su hardware moderno, senza rinunciare a nulla o quasi, passando anche dal gaming e da Steam Deck. Tutto ciò senza avere un’azienda dietro.

L’esperienza tipica di Arch e Fedora è solitamente priva di grossi imprevisti e non è nel nostro spirito trasmettere l’idea (che sarebbe inaccurata) che distro aggiornate sono una costante fonte di guai: al contrario, esse (come anche le distro stabili) sono speso sorprendentemente affidabili e, miracolosamente, sono frutto della community e non di dipendenti corporate, incarnando quindi appieno lo spirito di Linux, dell’open-source e del fatto che con la cooperazione a livello globale si possano fare grandi cose.

Sarebbe, però, da ipocriti affermare che potremmo installare Arch o Fedora sul PC ‘della nonna’ e potersene dimenticare, cosa che sarebbe, invece, assolutamente fattibile con distribuzioni abbastanza ‘ferme’ e prevedibili nel tempo.

Come detto, però, non riusciremmo a immaginare il mondo dell’Information Technology senza l’open-source e, se non vi fosse alcuna distribuzione che abbia il coraggio di implementare e mantenere software molto recente, non vi sarebbe alcun progresso poiché le nuove versioni non verrebbero mai testate da quasi nessuno.

Nonostante ciò, non tutte le distro sono adatte per tutti gli scopi e a ciò si somma il fatto che il software è scritto da esseri umani (a volte in una più o meno sostanziale deprivazione di sonno) e, in quanto prodotto umano, non è esente da difetti. Questo ci porta anche a ritornare sul punto della sicurezza che, come vedremo, non è affatto semplice da trattare.

Vi anticipiamo che, in tal senso, non esiste un consenso unanime: pacchetti recenti avranno tutte le bugfix disponibili già applicate direttamente dagli autori, tuttavia essi avranno anche delle nuove feature che possono aprire ulteriori superfici di attacco ancora non note.

Al contrario, pacchetti fermi a 1-2 anni fa e che sono stati patchati solo con bugfix di sicurezza (l’approccio delle distro ‘stabili’, per intenderci), potrebbero non includere ogni singola bugfix (specie se di minore entità) ma essi sono stati maggiormente rodati, testati e analizzati, in virtù del fatto che il codice è fermo nel tempo e non un obiettivo in movimento.

A complicare le cose ulteriormente vi è, poi, il fatto che alcune delle maggiori falle che hanno interessato Linux nell’ultimo decennio (vedi DirtyCow, ShellShock e tutte quelle che hanno interessato sudo) interessavano un range così ampio di versioni Kernel e di librerie che anche le distro ‘stabili’ sono state affette (ci teniamo a ribadire che la situazione con gli altri sistemi operativi non è necessariamente più rosea).

Nel mondo enterprise, la decisione è stata, in realtà, già presa: qui, la fanno da padrona le distro ‘stabili’ nel tempo, come RHEL e cloni, Debian, Suse e Ubuntu.

E’ molto difficile che vediate infrastrutture di produzione con flotte di sistemi Fedora o Arch. Non stiamo dicendo che tali distro non sarebbero in grado di gestire un workload di tipo enterprise: tutto è possibile, nelle mani di sysadmin adeguatamente preparati (e disposti a lavorare più del necessario), ma una lunga lista di fattori (tra cui il rischio di ‘rompere’, con l’ennesimo aggiornamento, gli applicativi che vi girano sopra) ha cristallizzato lo status quo per il quale, in infrastrutture di servizi (lontano quindi dai nostri laptop personali), si tiene l’approccio dello stabile e collaudato (a volte anche troppo) e non si insegue praticamente mai la novità, almeno in ambito server.

Che sia, questo, l’approccio migliore o meno, non è una conclusione ovvia da trarre: fare il backporting di patch di sicurezza che sono state pensate per delle versioni software molto più recenti, richiede una sostanziale abilità nel capire a fondo cosa fa quella patch e in cosa consisteva la falla.

Sebbene i team di sicurezza delle maggiori distro siano di tutto rispetto, questo aggiunge un ulteriore margine di errore umano.

Da un punto di vista ideologico e spirito di community, invece, chi testerebbe e riporterebbe bug se nessuno usasse le versioni appena uscite dei pacchetti?

Come detto, c’è un luogo e un tempo per ogni cosa e, se state tirando su un server che eroga servizi critici o se con il vostro PC lavorate e pretendete che il suo sistema operativo vi serva fedelmente senza imprevisti e senza quasi richiedere alcuna manutenzione o attenzione, non v’è molta alternativa: vi servirà una distro ‘stabile’ e installerete sul vostro laptop\desktop una distro server-ready.

Al contrario, se avete le skill tecniche per rimediare a eventuali imprevisti post-upgrade e\o non temete la probabilità, di tanto in tanto, di dover fare del troubleshooting o leggere da un forum (e magari compilare i bug report, per contribuire a vostra volta), sarete ricompensati dalle ultime versioni di qualsiasi cosa, che spesso portano con sè una ventata di freschezza e, a volte, completi cambi di paradigma (si pensi ad esempio al suddetto Gnome, che dalla 2 alle 3 e dalla 3 alla >40 si è reso quasi irriconoscibile, o a btrfs e zram, introdotti nei default in una normale installazione di Fedora o Arch con archinstall e a cui l’utente medio di Debian o RHEL o Slackware, sebbene siano feature che possa installare autonomamente, non sarebbe stato esposto con le installazioni di default).

Non dimentichiamo, inoltre, che con l’avvento di Flatpak, Snap, AppImages e simili, è possibile avere versioni di alcuni software molto recenti, indipendentemente dalla distribuzione su cui vi si trova, in quanto essi portano con sè le loro stesse dipendenze e librerie, a delle versioni specifiche e potenzialmente diverse da quelle presenti sul sistema, senza contare la possibilità, sempre aperta su qualsiasi distro, di installare del software direttamente dai pacchetti forniti dai rispettivi siti web (è il caso, ad esempio, di Visual Studio Code, Google Chrome, Microsoft Edge, WINE, e tanti altri, che aggiungono interi repository alla distro e forniscono sempre le loro versioni più recenti).

Tutte queste considerazioni, ribadiamo, sono indipendenti dal tipo di sistema operativo in essere. Che si parli di finestre o di mela, i dilemmi sono gli stessi, soltanto che la decisione, nei sistemi operativi closed-source più diffusi, è già stata presa da altri al posto vostro, giusta o sbagliata che sia.

Nel mondo dell’open-source, invece, siete voi al centro di tutto, anche delle decisioni meno facili.

Come sappiamo, da grandi poteri, derivano grandi responsabilità e si può anche decidere di rimanere a metà dello spettro ma, in ogni caso, tutto dipende dalla destinazione d’uso: se doveste effettuare il provisioning dei laptop da spedire sulla Stazione Spaziale Internazionale, magari in uso a dello staff che non è pagato per badare al mantenimento dei sistemi operativi ma per occuparsi di tutt’altra missione, vi sareste già fatti un’idea di quale paradigma sia più adeguato.

Lo scenario appena dipinto è accaduto realmente e, nonostante trattare questo tema possa facilmente scatenare gli animi dei proseliti di ciascuna distribuzione menzionata, confidiamo nel fatto che, almeno per ciò che riguarda casistiche del genere, le vostre opinioni possano convergere.

Appassionato di Linux e della cultura open-source da vent’anni, continuo a fare del mio meglio per diffondere tale filosofia e soprattutto condividere la conoscenza.

C’è sempre qualcuno da qualche parte nel mondo che sta avendo un problema che tu hai già risolto e, condividendo la soluzione, puoi fare la differenza.

Se quel qualcuno sei tu, chiedi pure alla community. La trovi ovunque, ad esempio su reddit.com/r/italyinformatica, reddit.com/r/fedora, reddit.com/r/debian, reddit.com/r/ubuntu, reddit.com/r/archlinux, reddit.com/r/linux, sui forum specifici delle distro oppure sulle loro wiki.

Perchè nessun problema andrebbe risolto più di una volta.

[https://it.linkedin.com/in/john-toscano]

31 risposte a “Saturday’s talks: l’eterno dilemma dell’utente Linux: distribuzioni stabili o super-aggiornate?”

  1. Avatar amedeo lanza
    amedeo lanza

    ti è scappato un refuso: può capire in momenti

    Io utilizzo Ubuntu sul desktop e trovo che due dei problemi più fastidiosi siano:
    – i driver video (grazie nVidia per l’immenso sforzo che fai per supportare l’open source!) che a volte non digeriscono l’aggiornamento e nel migliore dei casi rendono inutilizzabili gli schermi esterni
    – i problemi per lo sviluppo web come mantenere diverse versioni di PHP e la mancanza di librerie (giusto in questi giorni ho scoperto che php 8.1 manca della libreria intl a causa di conflitti con altre librerie di sistema) ma so già che mi cerco una risposta del tipo

    utilizza doker

    .

  2. Avatar John Toscano
    John Toscano

    > ti è scappato un refuso: può capire in momenti

    Corretto, grazie.

    > NvidiaUbuntu

    Eppure Ubuntu è tutto sommato conservativa con gli aggiornamenti kernel, verrebbe da chiedere se sono stati installati con il package manager, dai repo ufficiali della distro (pratica consigliata e che generalmente regala meno problemi) o manualmente dal sito web

    > Docker

    Una soluzione non sempre comoda ma decisamente funzionante potrebbe essere sviluppare in una macchina virtuale vicina all’ambiente target, con il vantaggio di avere un ambiente di lavoro separato, stabile o rolling esattamente quanto vogliamo noi (così da poter usare, ad esempio, una RHEL o una Debian come host e una FedoraArch come guest dentro la VM, o l’opposto) e da non dover riconfigurare ogni volta che si cambiareinstalla l’OS di base.

  3. Avatar John Toscano
    John Toscano

    Intendi una DebianRHEL in stile Fedora Silverblue?

  4. Avatar Alessandro Scarozza
    Alessandro Scarozza

    Il modo migliore per risolvere i problemi Nvidia è vendere la GPU e prendere una Radeon. Per me mai scelta fu più felice

  5. Avatar Alessandro Scarozza
    Alessandro Scarozza

    Io sono anni che spero in una distro stabile magari proprio immutabile, con tutto il tecnicamente possibile gestito con flatpak.

    In questo momento non trovo una distro che mi piaccia al 100%

  6. Avatar Simone
    Simone

    Fedora ha i repository modulari, grazie ai quali si può avere due o più versioni differenti di uno stack software.

  7. Avatar Simone
    Simone

    Non sono sicuro che sia meglio mantenere una versione vecchia con una montagna di pezze sopra piuttosto che aggiornare il software alla versione upstream, che le falle le ha già risolte di suo. È vero che con una nuova feature può arrivare un nuovo bug, ma nel mondo opensource di solito i bugfix sono tempestivi.

    Quanto al pc della nonna , ci installerei pure la Fedora molto tranquillamente.
    Potete andare a leggere questo interessantissimo link, sul blog di Richard Brown, a proposito delle rolling releases:

    https://www.rootco.de/2020-02-10-regular-releases-are-wrong/

  8. Avatar sabayonino
    sabayonino

    Se il timore che un aggiornamento porti ad un blocco della macchina indipendentemente che sia una versione del S.O. stabile o testing e non si ha il tempo per il “debug” basterebbe un backup/immagine prima di farlo o utilizzare quello più recente sempre se lo si è fatto e verificare che sia ripristinabile.
    Questo ti da la possibilità di ripristinare la macchina e continuare ad utilizzare e rimandare aggiornamenti a tempi migliori.
    La cultura dell’ “aggiornare tutto e subito” dovrebbe essere soppiantata con “backup tutto e subito” 😀

  9. Avatar carlo coppa
    carlo coppa

    Io non utilizzerei mai una Rolling senza istantanee di ripristino, per questo ho scelto openSUSE Tumbleweed, tutto impostato di default.
    Una mattina ho fatto gli aggiornamenti e dopo avrei dovuto prendere un aereo per motivi di lavoro, per qualche strano motivo qualcosa non ha funzionato, mi è successo raramente, ma guarda il caso… proprio quel giorno. In meno di un minuto ho fatto un rollback e il sistema era tornato a funzionare.

  10. Avatar John Toscano
    John Toscano

    Sebbene l’articolo sia degno di nota e porti dei punti condivisibili, vorrei focalizzare su una delle più importanti premesse:

    > Given enough eyes, all bugs are shallow

    Più si testa un software e più attenzione il suo codice riceve, meglio è da un punto di vista di sicurezza e quant’altro. Siamo d’accordo.

    Ora, siamo davvero sicuri che vi sia più attenzione e test su, ad esempio, un Kernel uscito la settimana scorsa e usato praticamente solo sul desktop di un sottoinsieme di utenti Linux, rispetto a uno che viene usato sui server di tutto il mondo da 1-2 anni su infrastrutture importanti?

  11. Avatar Simone
    Simone

    Giusta osservazione, comunque credo che a breve le distribuzioni immutabili prenderanno il sopravvento soppiantando questo eterno dilemma

  12. Avatar carlo coppa
    carlo coppa

    Non è proprio così. Questo era un concetto valido fino a qualche anno fa, quando lo sviluppo dei vari software era molto lento, oggi le cose sono diverse, innanzi tutto è raro che le distribuzioni fix release facciano backports o fix se non è un bug di sicurezza, per cui come capita spesso il bug te lo porti fino a fine supporto. Oggi giorno la.maggior parte dei bug viene scoperta quando il software è stato rilasciato, se una distribuzione lo congela, non puoi farci più niente. Dopodiché con le Rolling release è vero che il software è meno testato, ma mano a mano arrivano le correzioni direttamente nella distro.
    Secondo me le distribuzioni fix release sono solo più prevedibili, ma non per questo più stabili inteso come privo di bug, anzi….

  13. Avatar Rickyx
    Rickyx

    Purtroppo alcuni software utilizzano Cuda e non ci sono alternative.

  14. Avatar JustATiredMan
    JustATiredMan

    per quello che mi riguarda, se parliamo di server, meglio stabili, con updates solo per bug e sicurezza, e per le nuove features, proprio solo quando non se ne puo’ fare a meno. Per il desktop invece va a “gusti”

  15. Avatar JustATiredMan
    JustATiredMan

    guarda… per Nvidia, alla fine, dopo anni di rotture di @@ ho risolto la cosa alla fonte… ho preso una Radeon. Si e’ vero forse le nvidia sono piu performanti, ma per quel 10-15% in meno, le rogne che risolve una Amd almeno su Linux, valgono di piu’.

  16. Avatar JustATiredMan
    JustATiredMan

    assolutamente…. e comunque quando c’e’ da fare un update di qualche server di produzione, che magari e’ di una certa importanza, prima va testata ripristinando una vm da un altra parte e provata l’update.
    Mai fare gli update su robe importanti, senza prima averli testati, ed ovviamente con backup esterno e snapshot.

  17. Avatar JustATiredMan
    JustATiredMan

    concordo… le distribuzioni stabili non sono esenti da bug, ma generamente (e ripeto generalmente) sono bug che possono essere aggirati con qualche workaround. Poi dipende dal caso singolo se e’ qualcosa che il workaround puo’ essere applicato o meno. Spesso mi sono trovato con workaround su moduli o funzioni, che manco usavo. Se il bug invece comincia ad essere importante, generalmente rilasciano una fix.

  18. Avatar JustATiredMan
    JustATiredMan

    eeee allora mi spiace… sei fregato 😀

  19. Avatar amedeo lanza
    amedeo lanza

    Purtroppo utilizzando un portatile non è molto facile; quando lo ho acquistato era piena crisi CPU, avrei voluto trovare un Ryzen + Radeon ma ho dovuto ripiegare su Intel + nvidia

  20. Avatar Alessandro Scarozza
    Alessandro Scarozza

    ad oggi consiglierei un portatile con ryzen serie 7040 (non 7045), ma cambiare l’intero pc non è una cosa da fare al volo

  21. Avatar amedeo lanza
    amedeo lanza

    stai girando il coltello nella piaga: non amo Microsoft, Intel e nVidia e per ora sono riuscito a liberarmi solo della prima (e neanche completamente visto che ormai è decisamente attiva nel settore del pinguino ed utilizzo pure Github)

  22. Avatar amedeo lanza
    amedeo lanza

    Quando ho ordinato il portatile erano appena finiti quelli con Ryzen che avevo visto la settimana prima, dopo l’ordine mi hanno chiamato poiché non era più disponibile la gpu ‘di base’ ma solo il modello superiore. Che io ricordi, da quando utilizzo Linux ho avuto problemi solo (o perlomeno prevalentemente) con nVidia.

  23. Avatar JustATiredMan
    JustATiredMan

    a beh ok… se è su un portatile allora c’è poco da fare, o lo eviti o lo tieni così.
    Ho anch’io un Dell con Nvidia, ma alla fine ho preferito tenerlo con winzozz piuttosto che rompermi le scatole… linux me lo tengo su una vm e la tiro su quando serve.

  24. Avatar amedeo lanza
    amedeo lanza

    nvidiaubuntu
    probabilmente le ultime disavventure hanno a che fare con il repository dell produttore tedesco che distribuisce i Clevo (al momento non ricordo il nome) , usato per installare i driver audio; per ora dopo il passaggio alla 23.4 non hanno più fatto le bizze. Comunque negli anni mi hanno dato problemi senza bisogno che provvedessi io a sabotarmi.

    docker
    credo che delle macchine virtuali non mi semplificherebbero molto la vita: mantenerne
    una per php7, una per php 8.0, una per php 8.1 e una per php 8.2 significherebbe un deciso ingombro sul disco. Inoltre mi sembra che l’IDE (PhpStorm) gradisca le librerie installate per lavorare. Attualmente installo le diverse versioni, mantengo i server virtuali (Apache) configurati con la versione richiesta di FPM e per lavorare passo da una versione all’altra utilizzando uno script riconfigura la versione corrente(update-alternatives). Probabilmente dovrei adeguarmi,

  25. Avatar Guglielmo Cancelli
    Guglielmo Cancelli

    Io ho risolto con multipass. mi sono configurato li dentro il mio ambiente di sviluppo.
    Per le varie versioni di php devi andare di php-fpm, puoi scegliere la versione di php singolarmente per ogni virtualhost

  26. Avatar amedeo lanza
    amedeo lanza

    uso già i virtual server con php-fpm e personalizzo la configurazione per eseguirli con il mio utente per avere un accesso come sulle macchine di produzione (istanza eseguita dal proprietario della struttura). Proverò a guardare multipass ma ad un primo sguardo non mi sembra molto differente dall’utilizzare VirtualBox; che vantaggi ha ?

  27. Avatar Guglielmo Cancelli
    Guglielmo Cancelli

    Multipass è già pronto all’avvio della macchina, virtualbox in questo è molto piu lento. Per altro non devi spegnere la vm o salvarne lo stato quando spegni o riavvi il pc.
    Anche la creazione della macchina virtuale è quasi istantanea, a differenza di virtualbox dove, se non hai già delle vm pronte, devi seguire tutta la prassi di un normale pc.
    Ovviamente non è tutto rose e fiori, per quello che ho visto fino ad ora, forse perchè il progetto è relativamente giovane, soffre di alcuni problemi di stabilità: a volte si resettano delle impostazioni o non vengono montate le cartelle remote all’avvio

  28. Avatar amedeo lanza
    amedeo lanza

    mi manca di aggiungere qualche problema di stabilità…
    penso che per le mie esigenze sia meglio imparare ad usare bene docker

  29. Avatar Shiba
    Shiba

    Non ho esperienza in fatto di portatili con grafica ibrida, sarebbe eventualmente possibile usare il chip Intel come default e relegare la GPU Nvidia solamente ai lavori CUDA?

  30. Avatar John Toscano
    John Toscano

    > Fedora mai rotta onestamente

    Non dubito della tua parola, ma la mia esperienza parla molto diversamente, e potrei fare una lunga e tediosa lista della spesa di situazioni tediose che hanno rotto il mio workflow (per non dire altro 🙂 ) nei momenti migliori.

    > è anche vero che io sono sempre stato nel ramo current-1 proprio perché cercavo la stabilità e non il correre dietro all’ultima release.

    Quindi vedi, un po’ siamo d’accordo 🙂

    > Per Debian usare i backports non è un così grave problema,

    Non è grave, è tedioso, e a quel punto non ho più Debian stable, ma fattibile, anche se va contro i principi suggeriti in https://wiki.debian.org/DontBreakDebian.

    > dire c’è chi usa unstable (sid) o testing è fuori standard non è proprio vero, sono approcci diversi ma testing di per sé è una rolling decisamente stabile.

    Testing non è formalmente una rolling, anche se in pratica lo è per la maggior parte dell’anno. Durante il periodo di freeze, le release vengono congelate, per non parlare del delay che c’è con gli aggiornamenti di sicurezza.

    Stando a https://www.debian.org/doc/manuals/securing-debian-manual/ch10.en.html#security-support-testing , possono volerci anche 10 giorni, che per me è un’eternità.

    Tu ci rimarresti 10 giorni con Dirty Cow?

    > Ubuntu si basa sui pacchetti di sid eh quindi venirmi a dire è più stabile di sid o testing è una parodia…

    Ubuntu si basa su Sid ma non è Sid. Sid riceve continuamente aggiornamenti sostanziali fino al periodo di freeze (periodo in cui smette di averne) e, per definizione, è dove le cose possono rompersi.

    Per definizione 1 di stabilità (riferita ai numeri di versione), non è stabile, e vedo poco margine di dubbio.

    Per la definizione 2 di stabilità (riferita a quanto spesso crashi), magari lo è anche, l’ho usata per un periodo e non ho avuto chissà quali problemi, ma mi è capitato che alcuni pacchetti che usavo avessero problemi di orphaning, e comunque dopo il freeze mi arrivava una valangata di aggiornamenti che di solito qualcosa un pò la spaccavano, anche se risolvibile.

    Ubuntu, pur basandosi su Sid, rimane ferma per 6 mesi, quindi non vedo la parodia di cui parli: sono due approcci completamente differenti.

    Approccio differente anche con Fedora, che pur avendo anch’essa release ogni 6 mesi, aggiorna il Kernel praticamente entro 3-4 giorni da quando ne esce uno nuovo, beccandosi quindi quasi tutte le regressioni Kernel anche gravi.

    Abbiamo avuto di tutto, in tal senso. Ne ho parlato su https://www.miamammausalinux.org/2023/05/saturdays-talks-leterno-dilemma-dellutente-linux-distribuzioni-stabili-o-super-aggiornate/

    > Poi per il problema “vecchio” anche con le lts di Ubuntu avresti lo stesso problema quindi per quale motivo per Ubuntu non lo metti tra le con’s mentre per debian si?

    Lo metto tra i pro perchè nella stessa distro hai la scelta di andare di LTS o di 6month release. Lo trovo un pro enorme, visto che le esigenze tra le persone cambiano.

    > Ad oggi lavoro (quindi diciamo che è il mio reale daily non come arch che lo uso il fine settimana) con Oracle Linux 8, di applicazioni non aggiornate che mi servono onestamente ancora non ne trovo

    Esigenze diverse, sacrosanto, oltre che hardware diverso. Se provi a installare Oracle 8 su un laptop recente, magari un Intel che usi P-core e E-core (distinzione che solo gli ultimi Kernel hanno iniziato a cogliere), una scheda Wifi uscita da meno di un anno, a farci gaming con Steam o a usare le ultime Nvidia RTX, aspettarti che webcam, rgb lighting della tastiera, audio e tutto il resto funzionino out of the box, con anche gli ultimi codec proprietari, il discorso magari sarà diverso.

    Distro enterprise come OL8 o anche RHEL, in generale, trovo che abbiano un pò di attrito per renderle dei desktop “normali”, anche se tutto è possibile.

    Poi non dico che non si possa giocare su OL 8 o usarlo come daily driver ma, probabilmente, ci sono path di minor resistenza.

    Dipende tutto da ciò che si fa. Se ci si fa solo browsing e mail, anche con OpenBSD l’esperienza magari sarà tranquilla.

    > distrobox che ti fa un container con quello che ti serve e se si rompe lo ricrei…

    La cosa bella dell’open source è che ci sono tante opzioni, e questo è solo che un bene

    > Cioè il problema si riduce a non avere il de aggiornato…

    Gli esempi che si possono fare sono mille, ma comunque anche il DE mica scherza 🙂

  31. Avatar John Toscano
    John Toscano

    > Fedora mai rotta onestamente

    Non dubito della tua parola, ma la mia esperienza parla molto diversamente, e potrei fare una lunga e tediosa lista della spesa di situazioni tediose che hanno rotto il mio workflow (per non dire altro 🙂 ) nei momenti migliori.

    > è anche vero che io sono sempre stato nel ramo current-1 proprio perché cercavo la stabilità e non il correre dietro all’ultima release.

    Quindi vedi, un po’ siamo d’accordo 🙂

    > Per Debian usare i backports non è un così grave problema,

    Non è grave, è tedioso, e a quel punto non ho più Debian stable, ma fattibile, anche se va contro i principi suggeriti in https://wiki.debian.org/DontBreakDebian.

    > dire c’è chi usa unstable (sid) o testing è fuori standard non è proprio vero, sono approcci diversi ma testing di per sé è una rolling decisamente stabile.

    Testing non è formalmente una rolling, anche se in pratica lo è per la maggior parte dell’anno. Durante il periodo di freeze, le release vengono congelate, per non parlare del delay che c’è con gli aggiornamenti di sicurezza.

    Stando a https://www.debian.org/doc/manuals/securing-debian-manual/ch10.en.html#security-support-testing, possono volerci anche 10 giorni, che per me è un’eternità.

    Tu ci rimarresti 10 giorni con Dirty Cow?

    > Ubuntu si basa sui pacchetti di sid eh quindi venirmi a dire è più stabile di sid o testing è una parodia…

    Ubuntu si basa su Sid ma non è Sid. Sid riceve continuamente aggiornamenti sostanziali fino al periodo di freeze (periodo in cui smette di averne) e, per definizione, è dove le cose possono rompersi.

    Per definizione 1 di stabilità (riferita ai numeri di versione), non è stabile, e vedo poco margine di dubbio.

    Per la definizione 2 di stabilità (riferita a quanto spesso crashi), magari lo è anche, l’ho usata per un periodo e non ho avuto chissà quali problemi, ma mi è capitato che alcuni pacchetti che usavo avessero problemi di orphaning, e comunque dopo il freeze mi arrivava una valangata di aggiornamenti che di solito qualcosa un pò la spaccavano, anche se risolvibile.

    Ubuntu, pur basandosi su Sid, rimane ferma per 6 mesi, quindi non vedo la parodia di cui parli: sono due approcci completamente differenti.

    Approccio differente anche con Fedora, che pur avendo anch’essa release ogni 6 mesi, aggiorna il Kernel praticamente entro 3-4 giorni da quando ne esce uno nuovo, beccandosi quindi quasi tutte le regressioni Kernel anche gravi.

    Abbiamo avuto di tutto, in tal senso. Ne ho parlato su “saturdays talks: l’eterno- dilemma dellutente linux distribuzioni stabili o super aggiornate”

    > Poi per il problema “vecchio” anche con le lts di Ubuntu avresti lo stesso problema quindi per quale motivo per Ubuntu non lo metti tra le con’s mentre per debian si?

    Lo metto tra i pro perchè nella stessa distro hai la scelta di andare di LTS o di 6month release. Lo trovo un pro enorme, visto che le esigenze tra le persone cambiano.

    > Ad oggi lavoro (quindi diciamo che è il mio reale daily non come arch che lo uso il fine settimana) con Oracle Linux 8, di applicazioni non aggiornate che mi servono onestamente ancora non ne trovo

    Esigenze diverse, sacrosanto, oltre che hardware diverso. Se provi a installare Oracle 8 su un laptop recente, magari un Intel che usi P-core e E-core (distinzione che solo gli ultimi Kernel hanno iniziato a cogliere) a farci gaming con Steam o a usare le ultime Nvidia RTX, il discorso magari sarà diverso.

    Poi non dico che non si possa giocare su OL 8 ma, ecco, probabilmente ci sono path di minor resistenza, specie in virtù del fatto che nei repo non troverai tutto ciò che ti serve, dovrai andare di pacchetti installati a manella (che non si auto aggiorneranno) o aggiugere altri repo non ufficiali (cosa che non mi piace).

    > distrobox che ti fa un container con quello che ti serve e se si rompe lo ricrei…

    La cosa bella dell’open source è che ci sono tante opzioni, e questo è solo che un bene

    > Cioè il problema si riduce a non avere il de aggiornato…

    Premesso che il DE non la reputo roba da poco, la lista che si può fare è sempre lunga, ma dipende tutto dalle esigenze personali

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *