No Vasco, io non ci casco

Lo dico senza vergogna: Vasco Rossi non mi piace. E non perché lo consideri scarso o perché voglia fare il bastian contrario. Semplicemente, non mi piace quello che rappresenta musicalmente e non mi piace gran parte della musica italiana che viene etichettata come rock (Maneskin, siete voi?)

Parto da una premessa importante: riconosco l’enorme impatto culturale di Vasco Rossi. Ha scritto canzoni che hanno segnato generazioni, riempie gli stadi e ha un seguito che pochi artisti possono vantare. Ma il successo non è automaticamente sinonimo di apprezzamento personale.

Il mio problema nasce dal fatto che non riesco a vedere in Vasco quel rock che molti suoi fan descrivono. Quando penso al rock penso a sonorità più dure, a una maggiore ricerca musicale, a una certa attitudine ribelle che va oltre i testi provocatori o l’immagine da trasgressore. In gran parte della produzione rock italiana, e Vasco ne è forse il simbolo più famoso, trovo invece una formula molto diversa: canzoni costruite soprattutto attorno al testo, melodie immediate e arrangiamenti che spesso risultano più vicini al pop che al rock.

In generale faccio fatica ad apprezzare la musica italiana contemporanea proprio per questa ragione. Troppo spesso ho l’impressione che il genere venga definito più dalle parole che dalla musica. Il rock italiano, almeno quello più popolare, mi sembra spesso un compromesso: abbastanza aggressivo da essere chiamato rock, ma abbastanza rassicurante da piacere a tutti.

Non è una questione di superiorità della musica straniera. Semplicemente, nei gruppi e negli artisti internazionali che ascolto trovo un’energia, una sperimentazione e un’identità sonora che raramente riesco a trovare nella scena italiana mainstream.

Per questo Vasco Rossi non fa per me. Non metto in discussione la sua importanza né il diritto di milioni di persone di amarlo. Semplicemente, quando lo ascolto non sento il rock che cerco. E la musica funziona così: non sempre ciò che è amato da tutti riesce a parlare anche a noi.

Probabilmente continuerò a essere una minoranza durante le grigliate estive e le feste di paese, costretto ad ascoltare “Albachiara” come una tassa non prevista dal sistema fiscale italiano. Ma posso conviverci. Dopotutto, il bello della musica è che nessuno è obbligato ad amare gli stessi artisti.

Steam Deck: il dispositivo che ha cambiato il gaming PC e riportato Linux al centro della scena

Quando Valve presentò Steam Deck nel 2021, gran parte dell’industria videoludica lo considerò semplicemente un nuovo tentativo di entrare nel mercato dell’hardware. In realtà, a distanza di alcuni anni, è evidente che il vero successo della console portatile non risiede soltanto nelle sue vendite o nella qualità del dispositivo, ma nell’aver trasformato profondamente il panorama del gaming su PC.

Steam Deck ha infatti ottenuto qualcosa che per oltre vent’anni sembrava impossibile: rendere Linux una piattaforma di gioco mainstream.

Un problema storico: il monopolio di Windows nel gaming

Per decenni il gaming su PC è stato praticamente sinonimo di Microsoft Windows. Le ragioni erano molteplici:

  • DirectX era lo standard dominante per lo sviluppo dei videogiochi.
  • La maggior parte degli engine era ottimizzata principalmente per Windows.
  • Gli sviluppatori consideravano Linux una nicchia troppo piccola per giustificare investimenti dedicati.
  • La frammentazione delle distribuzioni Linux scoraggiava il supporto ufficiale.

Anche quando alcuni studi pubblicavano versioni native Linux, queste spesso arrivavano in ritardo, ricevevano meno aggiornamenti oppure soffrivano di prestazioni inferiori rispetto alle controparti Windows.

Di conseguenza si era creato un circolo vizioso: pochi utenti Linux significavano pochi giochi, e pochi giochi significavano pochi utenti Linux.

La scommessa di Valve

Valve comprese molto presto il rischio di dipendere completamente da Windows.

Già nei primi anni 2010 l’azienda iniziò a investire nel supporto Linux, portando Steam sulla piattaforma e contribuendo allo sviluppo di tecnologie open source fondamentali.

Il vero punto di svolta arrivò però con Proton: basato su Wine ma profondamente modificato da Valve e dalla community, Proton consente di eseguire giochi Windows su Linux traducendo in tempo reale le chiamate DirectX verso Vulkan.

Per anni il progetto fu considerato un interessante esperimento tecnico. Con Steam Deck è diventato il pilastro di un’intera strategia industriale. Ma la scelta più coraggiosa di Valve è stata quella di costruire Steam Deck attorno a SteamOS, una distribuzione Linux basata su Arch Linux.

L’obiettivo non era convincere gli utenti a usare Linux. L’obiettivo era renderlo invisibile. L’utente accende la console, installa un gioco e gioca. Non è necessario conoscere il sistema operativo sottostante.

Questa scelta ha prodotto un effetto sorprendente: milioni di utenti hanno iniziato a utilizzare Linux senza nemmeno rendersene conto. Per la prima volta nella storia del gaming, Linux non era più una piattaforma alternativa riservata agli appassionati, ma il sistema operativo predefinito di un dispositivo di massa.

Quando Linux gira meglio di Windows

Uno degli aspetti più interessanti emersi negli ultimi anni riguarda le prestazioni.

Contrariamente a quanto si potrebbe immaginare, Proton non rappresenta sempre uno svantaggio. In numerosi casi i giochi mostrano prestazioni equivalenti o addirittura superiori rispetto a Windows.

Le ragioni tecniche sono diverse.

Overhead ridotto del sistema operativo

Linux tende a consumare meno risorse in background rispetto a Windows, e meno processi attivi significano maggiore disponibilità di CPU e memoria per il gioco.

Vulkan come vantaggio competitivo

La traduzione effettuata da Proton verso Vulkan ha avuto effetti inattesi.

Molti giochi sviluppati attorno a DirectX 11 beneficiano dell’efficienza dell’API Vulkan, soprattutto su sistemi con CPU limitate.

In alcuni scenari questo porta a frame rate più stabili e regolari rispetto all’esecuzione nativa su Windows.

Ottimizzazioni specifiche di Valve

Valve controlla completamente l’hardware di Steam Deck e il software che lo gestisce.

Questo approccio ricorda quello delle console tradizionali: il sistema operativo, i driver grafici e Proton vengono ottimizzati come un ecosistema unico.

Su Windows, invece, gli sviluppatori devono supportare una quantità enorme di configurazioni hardware differenti.

Un enorme contributo all’ecosistema open source

L’impatto di Steam Deck va ben oltre il videogioco.

Per supportare la propria piattaforma, Valve ha investito direttamente nello sviluppo di tecnologie open source fondamentali:

  • Mesa, la principale implementazione open source dei driver grafici Linux.
  • Vulkan.
  • DXVK, che converte DirectX 9, 10 e 11 in Vulkan.
  • VKD3D-Proton, dedicato alla traduzione delle API DirectX 12.
  • Wine e numerosi progetti correlati.

Molti miglioramenti finanziati da Valve oggi beneficiano l’intero ecosistema Linux, indipendentemente dall’utilizzo di Steam Deck.

Forse il cambiamento più importante è stato culturale.

Prima di Steam Deck, supportare Linux significava raggiungere una nicchia di utenti desktop. Oggi supportare Linux significa supportare direttamente una piattaforma commerciale di successo.

Gli sviluppatori sanno che ogni gioco pubblicato su Steam potrebbe essere eseguito da centinaia di migliaia o milioni di possessori di Steam Deck e questo ha modificato le priorità di molti studi.

Anche quando non viene realizzata una versione Linux nativa, sempre più team verificano ufficialmente la compatibilità con Proton durante lo sviluppo. La certificazione “Steam Deck Verified” è ormai diventata un parametro importante quanto il supporto per controller o risoluzioni ultrawide.

Il ritorno dei porting nativi Linux

Un altro effetto interessante riguarda il ritorno dell’interesse verso i porting nativi dopo che per anni la tendenza era stata quella di abbandonare completamente Linux, affidandosi esclusivamente a Wine o Proton.

Oggi alcuni sviluppatori e publisher stanno rivalutando il supporto nativo, soprattutto quando utilizzano motori grafici già compatibili con Linux e Vulkan.

Non si può ancora parlare di una rinascita completa del gaming Linux nativo, ma Steam Deck ha eliminato uno degli ostacoli principali: la mancanza di un mercato sufficientemente grande da giustificare l’investimento.

Un modello che potrebbe influenzare l’intero settore

Il successo di Steam Deck dimostra che il futuro del gaming PC non è necessariamente legato a Windows, per la prima volta esiste una piattaforma commerciale importante che utilizza Linux come sistema operativo principale e che offre un’esperienza paragonabile a quella delle console tradizionali.

Ancora più significativo è il fatto che questo risultato non sia stato ottenuto imponendo agli sviluppatori di adottare Linux, ma costruendo strumenti capaci di rendere trasparente la compatibilità.

Valve ha trasformato un vecchio problema di frammentazione e incompatibilità in un vantaggio competitivo.

Steam Deck verrà probabilmente ricordato come una delle console portatili più riuscite della sua generazione. Tuttavia il suo contributo più importante potrebbe essere un altro.

Ha dimostrato che Linux può essere una piattaforma di gioco credibile, moderna e competitiva. Ha accelerato lo sviluppo di tecnologie open source fondamentali. Ha costretto sviluppatori e publisher a considerare seriamente un ecosistema che per anni era stato ignorato.

Soprattutto, ha fatto qualcosa che pochi avrebbero ritenuto possibile: portare Linux nelle mani di milioni di videogiocatori senza chiedere loro di installare e imparare ad usare Linux.

Ed è proprio questa invisibilità, più delle specifiche hardware o delle vendite, il vero segreto del successo di Steam Deck.

La regola “AURea”

Oltre 1.500 pacchetti compromessi nell’AUR di Arch Linux: cosa è successo davvero?

Negli ultimi giorni la comunità di Arch Linux si è trovata ad affrontare uno dei più grandi incidenti di sicurezza mai registrati nell’Arch User Repository (AUR), con oltre 1.500 pacchetti coinvolti in una campagna malevola che ha sfruttato la fiducia degli utenti e i meccanismi di gestione della piattaforma.

Cos’è l’AUR?

Per capire l’accaduto bisogna prima sapere cos’è l’AUR.

L’Arch User Repository è una raccolta di pacchetti mantenuti direttamente dalla comunità. A differenza dei repository ufficiali di Arch Linux, i contenuti presenti nell’AUR non vengono controllati o certificati dagli sviluppatori del progetto. Chiunque può proporre, mantenere o adottare un pacchetto, e gli utenti possono installarlo utilizzando strumenti molto diffusi come yay o paru.

In pratica, l’AUR è uno dei punti di forza di Arch Linux perché offre accesso a migliaia di software aggiuntivi, ma richiede anche maggiore attenzione.

Come è avvenuto l’attacco

Secondo le analisi pubblicate dai ricercatori di sicurezza, gli attaccanti hanno preso di mira numerosi pacchetti “orfani”, cioè pacchetti abbandonati dai loro manutentori originali. Dopo averne ottenuto il controllo, hanno modificato gli script di installazione inserendo codice malevolo.

A prima vista gli aggiornamenti sembravano normali. In realtà, durante la fase di installazione o aggiornamento venivano scaricati componenti aggiuntivi progettati per raccogliere informazioni sensibili, come credenziali, token di accesso e altri dati presenti sul sistema. Alcuni rapporti parlano persino di funzionalità assimilabili a quelle di un rootkit, cioè software progettati per nascondere la propria presenza sul computer compromesso.

L’aspetto più insidioso è che gli utenti non stavano installando software sconosciuti, ma pacchetti che in molti casi esistevano da tempo e godevano già della fiducia della comunità.

Chi è stato colpito?

È importante chiarire un punto: i repository ufficiali di Arch Linux non sono stati compromessi. Il problema ha riguardato esclusivamente l’AUR.

Questo significa che gli utenti che installano software soltanto dai repository ufficiali non sono stati coinvolti dall’incidente. Il rischio riguarda invece chi utilizza abitualmente pacchetti provenienti dall’AUR e li ha installati o aggiornati durante il periodo interessato dall’attacco.

Nel frattempo il team di Arch Linux ha avviato un’operazione di pulizia, bloccando attività sospette e rimuovendo i pacchetti compromessi.

Perché questa notizia è importante anche per chi non usa Arch Linux

L’episodio non riguarda soltanto Arch Linux. È un esempio di quello che viene definito “supply chain attack”, cioè un attacco alla catena di distribuzione del software.

Invece di colpire direttamente gli utenti, gli aggressori compromettono un elemento considerato affidabile — un repository, una libreria, un componente software — e sfruttano la fiducia che le persone ripongono in esso. Una volta che il canale di distribuzione viene compromesso, il malware può diffondersi rapidamente.

Negli ultimi anni questo tipo di attacchi è diventato sempre più frequente e rappresenta una delle principali preoccupazioni nel mondo della sicurezza informatica.

Cosa ci insegna questa vicenda

Ogni incidente di sicurezza lascia delle lezioni importanti.

1. La fiducia non può essere automatica

Molti utenti tendono a considerare sicuro qualsiasi software installato tramite un gestore di pacchetti. In realtà esistono diversi livelli di affidabilità. I repository ufficiali e quelli gestiti dalla comunità non offrono necessariamente le stesse garanzie.

2. La comodità ha sempre un costo

L’AUR è estremamente comodo perché permette di installare praticamente qualsiasi software con pochi comandi. Tuttavia questa comodità richiede una maggiore responsabilità da parte dell’utente, che dovrebbe verificare cosa sta installando e da chi viene mantenuto il pacchetto.

3. La sicurezza è anche un problema organizzativo

L’attacco non ha sfruttato una falla tecnica particolarmente sofisticata. Gli aggressori hanno approfittato di processi e dinamiche della comunità, come l’adozione di pacchetti abbandonati. Questo dimostra che la sicurezza non dipende solo dal codice, ma anche dalle procedure e dalla governance di un progetto.

4. Nessun ecosistema è immune

Spesso gli utenti Linux guardano con sospetto le minacce che colpiscono Windows o macOS. La realtà è che qualsiasi ecosistema sufficientemente diffuso può diventare un bersaglio interessante. La differenza la fanno i controlli, la trasparenza e la rapidità con cui gli incidenti vengono individuati e gestiti.

In conclusione

L’incidente che ha coinvolto oltre 1.500 pacchetti dell’AUR rappresenta un campanello d’allarme per tutta la comunità open source. Non mette in discussione la qualità di Arch Linux né la validità dell’AUR come progetto, ma ricorda un principio fondamentale: la sicurezza non è mai qualcosa che si può dare per scontato.

Anche negli ecosistemi più aperti e collaborativi, la fiducia deve essere accompagnata da verifiche, controlli e buone pratiche. È proprio questa attenzione continua che permette alle comunità open source di reagire e migliorare dopo ogni incidente.

Aggiornamento

Al momento della pubblicazione dell’articolo c’erano poco più di 1500 pacchetti compromessi sull’Arch User Repository (AUR). L’elenco dei pacchetti interessati è aumentato rapidamente e ora se ne contano quasi 2.000. Si tratta di un numero ENORME.

E’ stato segnalato che gli attacchi stavando continuando “con codice offuscato” e un altro rapporto nelle prime ore di questa mattina indicava che erano diventati “un po’ più elaborati”. Non tutti i problemi di packaging sono gravi come l’ondata iniziale di tentativi di furto di credenziali; alcuni si limitano ad aggiungere messaggi assurdi in russo.

Gli sviluppatori e i manutentori di AUR dovranno sicuramente ripensare al modo in cui viene gestito il servizio. Sebbene sia un’ottima idea permettere a chiunque di creare pacchetti di applicazioni aggiuntive mancanti nei repository ufficiali Arch, qualsiasi cosa lasciata aperta in qualche modo causerà problemi. Soprattutto ora che Linux è più popolare che mai, qualsiasi cosa legata a Linux come questa diventerà un bersaglio più appetibile. E con i bot basati sull’IA, colpire nel modo giusto è diventato molto più facile.

Sarà necessario almeno un minimo di controllo umano. Altrimenti, questo non sarà certo l’ultimo caso in cui vedremo l’AUR alle prese con problemi di sicurezza.