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.