Il mondo Linux sta vivendo un momento di crisi d’identità che farebbe invidia a un personaggio di Inception: tutti vogliono Wayland perché è più sicuro e moderno, ma poi ti ritrovi con un sistema di remote desktop che si comporta come se avesse appena scoperto l’esistenza dei display.

Se siete tra quelli che preferiscono sporcarsi le mani con una distro Debian o Ubuntu e che non sopportano l’idea di dover andare fisicamente davanti a un PC solo per cliccare ‘Accetta’ su una richiesta di connessione, allora questa notizia è la vostra dose di serotonina della settimana. RustDesk ha appena annunciato che il supporto per l’unattended remote access su Wayland è finalmente arrivato davvero, e non parliamo di un workaround rudimentale che si rompe al primo aggiornamento del kernel.

Per chi non mastica abbastanza il basso livello, il problema di Wayland è che, per design, è molto più restrittivo rispetto al vecchio, glorioso e un po’ selvaggio X11. La sicurezza è aumentata, certo, ma ha reso un inferno l’idea di catturare lo schermo o simulare input da remoto senza un’interazione fisica. È un po’ come avere una fortezza con mura altissime dove però, se dimentichi le chiavi dentro, non puoi nemmeno passare la finestra per recuperarle.

RustDesk ha trovato la via per bypassare questo scoglio, permettendo l’accesso non presidiato e, bonus much appreciated, il supporto multi-monitor. Significa che potete gestire i vostri server o i PC remoti in ufficio (o in quel garage che chiamate laboratorio) con la stessa fluidità con cui gestireste una sessione di debugging locale.

Attenzione però, non siamo ancora alla perfezione assoluta: al momento è disponibile una build preview per sistemi x86_64 basati su Debian/Ubuntu. Quindi, se siete i soliti eroi che usano Arch o distro più esotiche, dovrete aspettare ancora un po’ o sperare che il team rilasci un pacchetto compatibile a breve.

In un panorama dove le soluzioni proprietarie cercano di incastrarvi in ecosistemi chiusi e monitorare ogni vostro movimento con algoritmi di telemetria che farebbero paura anche alla CIA, vedere un progetto open source che affronta frontalmente i limiti tecnici del software moderno è una boccata d’aria fresca. Niente fuffa, niente abbonamenti mensili per sbloccare le funzioni base, solo codice che funziona e che vi restituisce il controllo della vostra macchina.

Se avete un sistema Ubuntu sotto mano, andate a testarlo e fateci sapere se vi scoppia qualche driver o se è davvero la rivoluzione che promette. Io, intanto, vado a vedere se riesco a configurare tutto senza dover riavviare il mondo.

Source: RustDesk now supports true unattended remote access on Wayland

Speriamo solo che non sia l’inizio di una nuova era di app Electron che mangiano RAM come se non ci fosse un domani.

Finalmente, dopo un’attesa che sembrava un’eternità (o almeno quanto il tempo di compilazione di un kernel custom), l’app desktop di ChatGPT con Codex è arrivata in fase preview per Linux. Sì, avete letto bene: un pacchetto RPM ufficiale. Niente più workaround strani o browser pesantissimi, OpenAI ha deciso di bussare alla porta del nostro desktop Linux.

Però, come per ogni cosa che si presenti con l’etichetta ‘Preview’, c’è un piccolo ‘ma’ che potrebbe far venire il mal di testa a chi, come noi, non usa l’ambiente desktop standard di un ufficio contabile. Se siete dei puristi di Wayland, magari su Fedora o KDE Plasma con Fcitx 5, potreste scoprire che la digitazione (specialmente se usate input method non latini come il giapponese) decide di andare in sciopero non appena provate a scrivere nel composer.

Il problema è il solito copione: l’app è basata su Chromium/Electron e, nonostante i progressi, sembra avere una relazione complicata con Wayland e i sistemi di input. Molti di noi sono abituati a risolvere questi drammi facendo il fallback su XWayland, trasformando l’app in un fossile digitale che gira in una bolla di compatibilità retrograda. Ma qui c’è una buona notizia: non è necessario sporcarsi le mani con XWayland.

Un utente molto sveglio ha scoperto che basta un piccolo tweak ai flag di avvio per far funzionare tutto nativamente. Se lanciate l’app con questi parametri:

chatgpt –enable-features=UseOzonePlatform –ozone-platform=wayland –enable-wayland-ime

tutto torna a funzionare come dovrebbe. È un fix pulito, che permette all’app di restare nel futuro (Wayland-native) invece di trascinarsi dietro i fantasmi di X11. Il consiglio è di modificare il file .desktop nella propria cartella locale così da non dover digitare tutto ogni volta che volete fare due domande all’IA.

Sinceramente, sarebbe stato molto più elegante se OpenAI avesse già incluso questi flag di default nella release ufficiale. È un po’ come ricevere un nuovo gadget tech figatissimo, ma scoprire che per farlo funzionare bisogna saldare un paio di ponti sul circuito principale. Però, per essere una preview, è un passo avanti non indifferente. Speriamo che la versione stabile sia meno ‘fai-da-te’ e che non porti con sé troppi altri regali inaspettati tipici dei software proprietari che atterrano sul nostro amato ecosistema Open Source.

Source: Codex in ChatGPT desktop app for Linux is now in preview

C’è qualcosa di profondamente poetico nel vedere un gigante del software che, dopo aver dominato il mondo con le API, decide improvvisamente di scendere in campo nel nostro territorio preferito: quello di chi vive tra terminali e script Bash.

Sì, avete letto bene. OpenAI ha annunciato il rilascio di ChatGPT Desktop per Linux (chiamiamolo anche Codex Desktop, per dare un tocco un po’ più ‘pro’). Dopo anni di passaggi via browser o di app che sembravano solo un wrapper web di scarsa qualità, sembra che abbiano capito che chi scrive codice o gestisce server non è che si sveglia la mattina con la voglia di usare un’interfaccia web pesante e poco integrata.

L’annuncio è arrivato dritto da Hacker News e, a prima vista, la notizia è decisamente figa. Avere un’app nativa che può interagire meglio con il sistema, magari con scorciatoie da tastiera che non ti costringono a switchare continuamente tra browser e IDE, è il tipo di miglioramento che fa dire «finalmente» a chiunque mastichi un po’ di Python o C++. Se l’integrazione con il file system e il terminale sarà all’altezza delle promesse, potremmo avere tra le mani un assistente che non si limita a chiacchierare, ma che capisce davvero cosa sta succedendo nella nostra workstation.

Però, non facciamoci prendere troppo dall’entusiasmo da fanboy. Sappiamo bene come funziona la storia: ogni volta che un big tech decide di ‘venire incontro alla community’, c’è sempre un retrogusto di controllo. L’integrazione profonda nel sistema operativo è una lama a doppio taglio. Da un lato è comodità pura, dall’altro è un modo molto elegante per infilare i propri occhi dentro i flussi di lavoro più intimi. Non stiamo parlando di privacy-invasion esplicita, ma di quel sottile confine che si dissolve quando il tuo assistente AI ha accesso diretto ai tuoi file e ai tuoi processi.

Inoltre, non dimentichiamoci che siamo in Italia e che la nostra gestione della sovranità digitale è… beh, diciamo che è un work in progress. Mentre noi ci interroghiamo su dove finiscano i dati e su quanto l’automazione possa influenzare il nostro lavoro, i colossi americani corrono spediti verso una centralizzazione che non sempre ci convince.

In conclusione: se cercate una nuova utility da testare nel vostro setup, scaricatela subito. È un passo avanti enorme per l’ecosistema Linux e per la produttività di chi ama l’automazione. Ma tenete sempre un occhio critico e, se potete, non smettete di configurare i vostri firewall. Il futuro è automatizzato, ma preferisco che rimanga sotto il mio controllo.

Source: ChatGPT Desktop (Codex Desktop) for Linux

Dimenticate per un secondo la polemica su quanto l’IA stia per rubarci il lavoro o, peggio, di quanto sia diventata una gigantesca macchina per sputare allucinazioni su Reddit. C’è un segnale che arriva direttamente dal fronte del codice, e stavolta non parla di marketing, ma di pura, cruda potenza di calcolo.

Geohot, uno di quelli che se dice una cosa è perché l’ha già testata compilando il kernel durante la pausa pranzo, ha appena rilasciato un update che sembra un manifesto di resistenza tecnologica. Il succo? Ama l’IA, ma odia l’hype. E, onestamente, chi di noi non prova lo stesso quando apre LinkedIn e legge di startup che promettono di risolvere il cancro usando un wrapper API di OpenAI?

L’aspetto che scotta non è tanto la critica ai comunicati stampa pieni di fuffa, quanto quello che sta succedendo ‘sotto il cofano’. Geohot racconta di aver configurato una macchina Linux con Opencode girante su un GLM-5.2 locale. E la cosa incredibile non è solo il modello, ma l’esperienza: basta lanciare un comando per impostare la sua configurazione di tmux e il sistema è pronto. Questo non è solo nerdolatry, è l’inizio di una rivoluzione dove gli agenti di coding e i modelli video iniziano a diventare strumenti tangibili, non solo demo patinate da conferenza stampa.

C’è un entusiasmo quasi punk in questo approccio. Vedere l’IA che non è solo un chatbot su un browser, ma un motore che gira localmente, che interagisce con la nostra shell e che potenzia il nostro workflow senza dover chiedere il permesso a qualche server proprietario in California, è la vera svolta. È quel tipo di progresso che ci ricorda perché amiamo il software: per la possibilità di padroneggiare la macchina, non di esserne schiavi.

Certo, restiamo con i piedi per terra. Mentre i big tech cercano di chiudere tutto in giardini recintati e di rendere ogni interazione un’occasione per raccogliere dati, c’è questo sottobosco di innovazione che spinge verso l’open source e la decentralizzazione. Non è che il ‘Year of the Linux Desktop’ sia arrivato domani mattina (siamo in Italia, sappiamo bene che la burocrazia e le comodità sono ostacoli enormi), ma se l’IA diventa il nuovo motore per rendere Linux finalmente usabile e potente come un sistema operativo moderno, allora forse la battaglia è ancora in corso.

Quindi, meno hype da conferenza di marketing e più modelli che girano sul nostro hardware. È lì che la magia succede davvero. Il resto è solo rumore di fondo per chi non sa distinguere un compilatore da un copywriter.

Source: I love LLMs, I hate hype

Diciamocelo subito: se riuscite a scassinare la porta blindata di un datacenter e il proprietario vi ringrazia con un assegno da un quarto di milione di dollari, avete ufficialmente vinto la partita della vita.

Questa settimana la sicurezza del kernel Linux ha ricevuto una bella scossa. Google ha deciso di svuotare il portafogli, versando ben 250.000 dollari a un ricercatore per segnalare una vulnerabilità di alto livello. Non stiamo parlando della solita fessura che permette di leggere un file di configurazione dimenticato in giro, ma di qualcosa di decisamente più cinematico: un «guest VM escape».

Per chi non mastica kernel e hypervisor ogni notte davanti a un caffè freddo, ecco il succo della questione. Immaginate di essere chiusi in una cella di massima sicurezza (la vostra macchina virtuale, o VM). Tutto intorno a voi ci sono muri di cemento armato, telecamere e guardie che controllano ogni vostro movimento. L’idea è che, anche se riusciste a scatenare l’inferno dentro la cella, non potreste in alcun modo toccare il resto del carcere. Ecco, questo bug permetteva di trovare un passaggio segreto nella tubatura, uscendo dalla cella e finendo direttamente nell’ufficio del direttore, con privilegi di root tutto vostro. Un vero e proprio salto fuori dal recinto.

Il problema non è solo la gravità tecnica, che è oggettivamente brutta, ma il potenziale impatto. Quando parliamo di cloud e infrastrutture condivise, l’illusione del confine è tutto ciò che ci separa dal caos. Se un utente non autorizzato può «evadere» dalla propria istanza per infettare l’host o altre macchine virtuali sullo stesso server, il concetto stesso di isolamento diventa una barzelletta senza senso.

Certo, leggendo la notizia dai soliti canali americani, sembra quasi una passeggiata di gloria. Ma restiamo con i piedi per terra: per noi che viviamo tra server in garage, Raspberry Pi e piccoli nodi self-hosted, queste beghe da grandi corporation spesso sembrano far parte di un ecosistema parallelo, quasi distaccato dalla realtà quotidiana. Però, c’è un lato positivo: il sistema di bug bounty funziona e il kernel Linux si è già mosso per patchare il buco.

Insomma, meno fumo negli occhi e più patch applicate. Se proprio dobbiamo preoccuparci, meglio che sia per un bug che ci ha portato un premio da 250k, piuttosto che per una nuova policy di qualche big tech che decide arbitrariamente cosa possiamo o non possiamo compilare sul nostro terminale.

Source: Google pays $250K for Linux vulnerability allowing guest VM escapes

Scommetto che qualcuno di voi stava già preparando il kit di riparazione e un set di saldatori per smontare tutto il primo pomeriggio.

Valve ha deciso di spingere sull’acceleratore: la Steam Machine è ufficialmente fuori. Dopo anni di rumors, leak e quella nebbia di incertezza che rendeva tutto simile a un episodio di Westworld dove nulla è come sembra, il progetto è arrivato sul mercato. Ma la domanda sorge spontanea: è la rivoluzione che aspettavamo per distruggere il monopolio delle console tradizionali o è solo un altro gadget costoso che ci costringe a giocare dentro un recinto ben preciso?

Per chi non fosse in linea con i feed di Hacker News, l’idea è semplice (o almeno, sembra tale): un hardware dedicato, ottimizzato per far girare la vostra libreria Steam senza dover configurare driver, aggiornamenti Windows infiniti o preoccuparsi se il kernel ha deciso di fare le bizze dopo un aggiornamento non richiesto. L’obiettivo è l’esperienza ‘plug and play’, quella comodità che ci fa sentire come se stessimo usando una console, ma con la potenza (teorica) di un PC.

Dal punto di vista tecnico, l’entusiasmo è legittimo. Se Valve riuscisse a mantenere il sistema abbastanza aperto da permetterci di smanettare, installare distro Linux custom o iniettare i nostri script preferiti senza che il sistema ci lanci un errore di certificato, avremmo tra le mani un gioiello. C’è qualcosa di profondamente soddisfacente nell’idea di avere tutta la potenza del gaming PC racchiusa in un box che si accende e basta.

Però, restiamo con i piedi per terra. Sappiamo bene come funziona il gioco. C’è sempre il rischio che, dietro quella bellissima interfaccia user-friendly, si nasconda un ecosistema che vuole decidere per noi cosa possiamo e non possiamo fare. Se la libertà di installare software di terze parti o di modificare le impostazioni profonde del sistema venisse sacrificata sull’altare della ‘semplicità’, allora avremmo solo comprato un altro terminale proprietario molto costoso.

In Italia, poi, sappiamo che il prezzo del hardware può essere un deterrente non trascurabile, specialmente quando si sommano i costi di spedizione e le possibili rogne doganali se decidiamo di importare versioni particolari. Non è esattamente la notizia che ci fa saltare sulla sedia mentre aspettiamo il prossimo aggiornamento di Arch Linux, ma è sicuramente un movimento che merita un’analisi approfondita.

Insomma, la Steam Machine è partita. Vedremo se riuscirà a sopravvivere al primo incontro con la realtà del gaming moderno o se finirà dritta in un cassetto insieme ai vecchi controller che non sappiamo più come collegare.

Source: Steam Machine launches today

C’è qualcosa di profondamente catartico nell’osservare un vecchio nemico che finalmente viene estirpato dal proprio ecosistema. Non parlo di un boss di fine livello di un RPG che non riesci mai a battere, ma di una funzione C che è stata per anni una brutta bestia capace di scatenare bug a tradimento: la mitica strncpy.

Con l’arrivo del kernel Linux 7.2, la strncpy è ufficialmente andata in pensione. E non parlo di quel pensionamento dignitoso con festa e torta, ma di una rimozione chirurgica dopo un lavoro titanico durato sei anni e che ha richiesto ben 362 commit. Se pensate che sia solo una formalità da manuale, vi sbagliate di grosso: è stata una pulizia profonda, un setaccio che ha rimosso ogni traccia rimasta di questa API nelle implementazioni per ogni singola architettura CPU.

Per chi non ha passato le notti insonni a debuggare buffer overflow, lasciate che vi spieghi perché strncpy era il tipo di collega che nessuno vuole in team. Questa funzione ha una semantica così controintuitiva che fa sembrare i regolamenti della privacy europei una lettura leggera per bambini. Il problema principale? La gestione del terminatore NUL. Strncpy può decidere di non aggiungerlo se non riesce a completare la copia, lasciandoti con una stringa che è una vera bomba a orologeria pronta a esplodere non appena qualcuno prova a leggerla.

In più, c’è il problema delle performance. strnccpy ha la cattiva abitudine di riempire inutilmente con zeri il resto della destinazione, sprecando cicli CPU che potrebbero essere usati per cose molto più interessanti, tipo far girare un container in più o compilare un kernel senza piangere. È quel tipo di inefficienza che ti fa venire voglia di lanciare il laptop dalla finestra.

Ora, la strada è spianata verso alternative molto più sane e trasparenti. Se devi copiare stringhe con terminatore, c’è strscpy. Se ti serve il padding, ci sono strscpy_pad o memcpy_and_pad. È un approccio molto più ‘explicit’ e meno ‘magia nera che sembra funzionare ma poi ti frega’.

Non è una notizia che cambierà la vita del sysadmin che gestisce un server in un datacenter in Lombardia, ma per noi che viviamo di codice e di tutto ciò che è open source, è un segnale di salute. Dimostra che il kernel Linux non è un museo polveroso dove si conserva tutto per paura di rompere qualcosa, ma un organismo vivo che ha il coraggio di fare manutenzione pesante per eliminare il debito tecnico. È l’approccio che vorremmo anche nella vita reale: se una cosa è strutturalmente sbagliata e genera solo problemi, non cercare di metterci un patch, eliminala e passa oltre.

Source: Linux eliminates the strncpy API after six years of work, 360 patches

C’è un momento preciso, nel cuore di una notte passata a debuggare una rete Docker che non ne vuole sapere di collaborare, in cui ti senti veramente impotente. Sei lì, dentro un container super-stripped, pulito come un codice scritto da un purista della programmazione, e realizzi che non hai nemmeno wget o curl per fare un semplice test di connettività. Niente, zero, il vuoto pneumatico. Sembra la fine del mondo, ma in realtà è solo l’occasione perfetta per tirare fuori il trucco sporco che ogni vero smanettone dovrebbe avere nel proprio kit di sopravvivenza.

Recentemente è emerso un piccolo gioiello (che in realtà è un classico, ma che sempre stupisce chi non mastica terminale ogni giorno) su come bypassare l’assenza di strumenti standard usando solo Bash e la sua capacità di parlare direttamente con /dev/tcp. Sì, avete letto bene. Non è un vero file su disco, non lo troverete facendo un ‘ls’, ma è una funzione interna di Bash che permette di aprire socket TCP come se steste scrivendo su un file normale.

Il trucco è tutto qui: basta usare ‘exec 3/dev/tcp/hostname/port’ per aprire una connessione e poi iniettare manualmente la stringa della richiesta HTTP. Un ‘printf’ con l’header corretto e un ‘cat’ per leggere la risposta, ed ecco che il server vi risponde. È brutale, è sporco, è meraviglioso. È esattamente lo spirito del retrocomputing: quando le risorse scarseggiavano, non potevi permetterti l’overhead di un client moderno; dovevi parlare direttamente con l’hardware, o in questo caso, con il socket.

Certo, non fate l’ebete: non è un sostituto di curl. Non gestisce redirect, non capisce la compressione GZIP, non sa nemmeno cosa sia l’HTTPS (per quello serve ancora openssl) e, se dimenticate l’header ‘Connection: close’, il comando ‘cat’ rimarrà lì a fissare il vuoto all’infinito, proprio come noi davanti a un bug senza log.

Per noi che amiamo smontare le cose per capire come funzionano, questa è pura poesia tecnica. Ci ricorda che sotto tutto l’hype dell’intelligenza artificiale e dei framework pesantissimi, la base è ancora quella: flussi di byte che viaggiano su socket. Usare questo trucco in un ambiente di produzione è un suicidio, ma usarlo per debuggare un microservizio in un container minimalista è un atto di pura maestria tecnica. È quel tipo di ‘hack’ che ti fa sentire un po’ più vicino ai vecchi hacker degli anni ’70 e un po’ meno uno sviluppatore che dipende da mille dipendenze NPM.

Quindi, la prossima volta che vi trovate in un ambiente deprivato di strumenti, non disperate. Ricordate che Bash ha dei poteri nascosti. Ma per le cose serie, mantenete curl installato, perché non abbiamo tutti il tempo di scrivere manualmente gli header per ogni singola API.

Source: TIL: You can make HTTP requests without curl using Bash /dev/TCP

Tutto è iniziato con un’anomalia nei log di commit di alcuni repository critici su Fedora. Non erano errori di sintassi, né bug logici evidenti. Erano contributi troppo… perfetti.

Un gruppo di osservatori della community ha notato un picco di attività proveniente da account creati di recente, i cui messaggi di commit seguivano un pattern linguistico estremamente pulito, quasi accademico, privo delle tipiche idiosincrasamente degli sviluppatori umani (come errori di battitura o commenti colloquiali).

Il sospetto è che stiamo assistendo all’ascesa di ‘Agentic Bots’: script avanzati che utilizzano LLM (Large Language Models) per analizzare bug report, scrivere patch e sottoporre pull request in modo totalmente autonomo. Sebbene l’idea di un collaboratore automatico sia affascinante, la questione della fiducia è centrale. Se un bot può simulare la competenza di un umano, può anche simulare la malizia di un attaccante, inserendo vulnerabilità quasi invisibili sotto la maschera di una ‘ottimizzazione necessaria’.

La comunità di Fedora sta ora implementando nuovi protocolli di verifica, ma la sfida è globale: come distingueremo un collaboratore IA ultra-efficiente da un attacco sofisticato di supply chain injection?

Source: AI agent runs amok in Fedora and elsewhere

Smettete di trattare il vostro MacBook come una scatola chiusa e dorata progettata solo per scorrere i feed di Instagram o editare video in 8K con il minimo sforzo.

Per anni, chiunque abbia provato a fare qualcosa di serio — che si tratti di compilare un kernel, far girare un database per un progetto di automazione o testare uno script Python che richiede librerie Linux specifiche — si è trovato davanti al solito muro: o la comodità di macOS (che però è un ecosistema chiuso e spesso frustrante per il debugging di basso livello) o l’instabilità di una Virtual Machine pesante, che mangia RAM come un processo zombie e ti costringe a fare il ‘sync’ dei file tra host e guest come se fossimo ancora nel 2005.

Apple ha deciso di smetterla di fare la misteriosa e ha rilasciato ‘container machine’. E no, non è l’ennesima mossa di marketing per venderti un abbonamento iCloud. È un tool che fornisce un ambiente Linux altamente integrato, leggero e, soprattutto, persistente. La vera magia? Il montaggio automatico della tua Home directory. Il tuo `$HOME` su macOS è lo stesso dentro il container. I tuoi dotfiles, i tuoi repository, i tuoi script… tutto lì, pronto all’uso. Puoi usare l’IDE che preferisci su Mac, ma far girare il build e i servizi sotto Linux con un semplice comando.

Per noi che amiamo spulciare ogni singolo bit, questa cosa è una bomba. Immaginate di poter lanciare un `systemctl start postgresql` dentro un container Alpine o Ubuntu, ma di poter comunque usare i profiler nativi di macOS o i tool di debug grafici per ispezionare gli artefatti creati. È come avere un laboratorio di elettronica dove il tuo oscilloscopio è collegato direttamente al circuito che stai saldando, senza dover passare per un adattatore scadente.

Il workflow sembra quasi troppo fluido per essere vero: `container machine create alpine:latest –name dev`. Fine. Hai un ambiente Linux che risponde ai comandi come se fosse nativo. Puoi persino personalizzare le risorse, decidendo quanta RAM o quanti CPU dedicare a questa piccola bestia senza dover configurare file XML infiniti.

C’è qualche rischio? Beh, come sempre con Apple, c’è il rischio di un leggero ‘vendor lock-in’ metodologico, ma finché si basano su standard OCI (quelli di Docker, per intenderci), la portabilità è salva. La vera sfida sarà vedere come si comporterà sotto carico pesante o con progetti che richiedono accessi hardware particolari.

In breve: se sei uno di quelli che passa le notti a far girare container per simulare server o testare script di automazione, fatevi un giro. È un modo elegante per rendere il vostro Mac un vero strumento di sviluppo e non solo un bel pezzo di alluminio con un display fantastico.

Source: macOS Container Machines