Chi l’avrebbe mai detto che il cuore pulsante di Internet sia gestito con lo stesso livello di coordinazione di un gruppo WhatsApp di genitori durante una gita scolastica?

È uscito un report piuttosto pepato su Openwall che mette in luce un problema strutturale che definire ‘disagio’ è un eufemissimo. In pratica, quando vengono scoperte delle vulnerabilità critiche nel kernel Linux, non c’è un sistema di allerta rapida o un ‘heads-up’ coordinato verso le principali distribuzioni. In breve: scoprono il bug, si parla del problema, e i maintainer delle distro si ritrovano a gestire l’emergenza quando ormai il codice è già pubblico e gli exploit sono pronti all’uso.

Per chi vive di automazione, server domestici o progetti di edge computing, la cosa è decisamente poco divertente. Immaginate di aver appena finito di configurare il vostro nuovo cluster Kubernetes o il vostro server NAS custom per lo streaming di vecchi titoli arcade, e svegliarvi con la notizia che il kernel che state usando ha un buco che permette l’escalation dei privilegi. E la cosa peggiore? Non c’è stata una fase di ‘pre-avviso’ per permettere alle distro di preparare le patch in silenzio.

Dal mio piccolo angolo di mondo, dove passo le notti a far girare script Python per ottimizzare il rendering di modelli Blender o a debuggare firmware di vecchi controller, trovo che questa mancanza di comunicazione sia un classico esempio di come l’ecosistema Open Source, pur essendo incredibilmente potente, soffra ancora di una frammentazione pericolosa sul fronte della sicurezza reattiva. Non è colpa dei singoli developer (che fanno un lavoro eroico), ma della mancanza di un protocollo di disclosure che protegga chi ‘subisce’ l’aggiornamento.

Cosa significa per noi smanettoni? Significa che non possiamo permetterci il lusso di ignorare gli update. Se usate Linux per compiti critici, la vostra unica difesa è l’iper-vigilanza. Non aspettate che la notizia finisca nel feed di qualche tech-influencer su X. Controllate i mailing list, seguite i repository ufficiali e, se potete, usate distribuzioni che hanno una policy di sicurezza più strutturata.

In un mondo dove l’hype per l’AI ci distrae costantemente da ciò che conta davvero (la stabilità del nostro stack software), ricordiamoci che la sicurezza non è un feature che si aggiunge con un plugin, ma un processo che richiede trasparenza. E finché non vedremo un sistema di allerta più serio, l’unica soluzione è restare con le dita sempre pronte sulla tastiera, pronti a compilare il prossimo kernel patchato prima che qualcuno decida di testare un exploit sul nostro server.

Source: For Linux kernel vulnerabilities, there is no heads-up to distributions

Comprare un veicolo elettrico oggi è un po’ come adottare un piccolo server mobile che, invece di far girare script Python, monitora ogni tuo spostamento, accelerazione e, presumibilmente, anche quanto sei stressato nel traffico.

Ho dato un’occhiata all’ultimo aggiornamento della documentazione di Rivian e, raga, la retorica aziendale è ai livelli massimi di hype. La loro missione? Preservare la natura e far evolvere i veicoli attraverso un’esperienza «connessa al 100%». Traduzione per noi che mastichiamo bit e circuiti: il tuo R1T o R1S non è solo un mezzo di trasporto, è un nodo IoT gigante che interagisce costantemente con il cloud, con l’app e con il resto dell’ecosistema aziendale.

Il marketing parla di comodità e sicurezza, ma noi sappiamo bene cosa significa quel «migliorare nel tempo» attraverso il software. Significa aggiornamenti OTA (Over-The-Air) che possono aggiungere feature fighe, ma anche patch che potrebbero cambiare le regole del gioco senza che tu possa dire nulla. Il problema non è la tecnologia in sé — anzi, l’idea di un hardware che evolve è pura poesia per chi ama il continuous deployment — il problema è la chiusura del cerchio.

Se ti piace smanettare con le tue CNC, costruire plotter o modificare il firmware di un vecchio Commodore, sai quanto sia frustrante il vendor lock-in. E qui casca l’asino. Quando un’azienda parla di una connessione così profonda e integrata, sta implicitamente dicendo che il controllo del dato non è nelle tue mani. La domanda che campeggia nel titolo dell’articolo di supporto di Hacker News — «Posso disabilitare tutta la raccolta dati dal mio veicolo?» — è il vero cuore della questione. La risposta implicita, che traspare da tutto quel linguaggio corporate sulla «connessione totale», è un bel no.

Per noi che amiamo l’open source, l’estetica del retrocomputing e la libertà di modificare ogni singolo parametro di un progetto, questo approccio è un po’ una pillola amara. È fantastico avere un’auto che è un capolavoro di ingegneria elettrica e software, ma l’idea che la nostra privacy sia il prezzo da pagare per la «preservazione del pianeta» è un trade-off che non abbiamo votato.

Speriamo solo che, tra un aggiornamento del firmware e l’altro, non ci dimentichiamo che un oggetto che possediamo dovrebbe restare, appunto, nostro. Altrimenti, non stiamo guidando un fuoristrada, stiamo solo pagando un abbonamento mensile per un sensore su ruote che ci dice quanto siamo bravi a non inquinare.

Source: Can I disable all data collection from my vehicle?

E se vi dicessi che a volte l’unico modo per non far crashare il sistema è ignorare il comando ‘shutdown’ e cercare di patchare il kernel in corsa?

Sembra il tipico fix disperato di un sysadmin alle tre di notte, ma è esattamente quello che sta succedendo in Belgio. Il Primo Ministro Bart De Wever ha appena annunciato che il piano di decommissioning delle centrali nucleari è ufficialmente saltato. Sì, avete letto bene: niente smantellamento, si continua a far girare i vecchi reattori.

La notizia, filtrata dalle testate internazionali, parla di un governo che vuole negoziare con ENGIE per nazionalizzare l’intera flotta nucleare. L’obiettivo dichiarato? Sicurezza, controllo della supply e meno dipendenza dalle importazioni di gas. In pratica, invece di fare un clean install di un sistema energetico nuovo (e costoso), hanno deciso di fare un upgrade forzato dell’hardware esistente, sperando che le dipendenze non vadano in conflitto.

Dal mio punto di vista, questa è la classica situazione in cui la realtà si scontra con le intenzioni idealiste. Dal 2003 il Belgio aveva deciso di chiudere tutto entro il 2025. Poi, tra crisi energetiche, costi folli delle rinnovabili e la necessità di non restare al buio mentre si aspetta che la tecnologia sia pronta, hanno cambiato idea. È come quando provi a migrare un vecchio server legacy su un’architettura cloud moderna, ma ti rendi conto che il budget è finito e i dati sono troppo critici per rischiare un downtime.

C’è però un aspetto che mi fa storcere il naso: la gestione della ‘nazionalizzazione’. Se il governo prende in carico non solo i reattori ma anche le responsabilità del decommissioning e le passività, stiamo parlando di un debito tecnico (e finanziario) mostruoso. È un po’ come quando compri un vecchio modulo CNC usato su eBay, scopri che ha tre motori bruciati e una scheda madre che gira su un microcontrollore custom che non trovi più in commercio, ma decidi di tenerlo perché ‘beh, è un pezzo storico’.

Per noi che amiamo smanettare, la cosa interessante è il messaggio sottinteso: la transizione energetica non è un semplice switch ON/OFF. È un processo di refactoring continuo. Non puoi semplicemente cancellare le vecchie istanze di produzione senza avere un piano di failover solido. Se il Belgio riuscirà a gestire questa transizione senza far esplodere i costi, potrebbe diventare un caso studio interessante su come gestire sistemi legacy critici.

Speriamo solo che questa ‘patch’ di emergenza non si trasformi in un memory leak che prosciugerà le casse dello Stato nei prossimi decenni. Intanto, io torno al mio Blender, che almeno lì, se crasho, posso sempre ripartire dall’ultimo autosave senza dover nazionalizzare l’intera industria del rendering.

Source: Belgium stops decommissioning nuclear power plants

“title”: “Claude Code ha deciso di fare il bullo (e di chiederti il pizzo digitale)”,
“excerpt”: “Claude Code ha iniziato a rifiutare richieste o a gonfiare i costi se rileva ‘OpenClaw’ nei tuoi commit. Benvenuti nell’era del copyright applicato all’intelligenza artificiale.”,
“content”: “Quanto è diventato tossico il mondo del coding moderno?nnSe pensavate che il peggio fosse dover lottare con i driver di una vecchia scheda video o con i bug di un plugin di Blender che crasha senza motivo, preparatevi a rimettervi comodo. C’è una nuova forma di censura che non arriva dai burocrati, ma dagli algoritmi. Recentemente è emerso che Claude Code, il tool di Anthropic, ha iniziato a comportarsi in modo decisamente poco amichevole: se i tuoi commit menzionano ‘OpenClaw’, l’IA può decidere di rifiutarsi di eseguire i tuoi task o, peggio ancora, di farti pagare un extra.nnSì, avete letto bene. Non è un glitch del server o un problema di latenza. È una scelta deliberata di filtraggio e pricing basata sul contenuto del codice. Praticamente, l’IA ha imparato a fare la guardia ai termini ‘sensibili’, agendo come un casello autostradale che ti chiede un pedaggio più alto solo perché hai scritto una parola specifica nel messaggio del commit.nnDa smanettone che passa le notti a compilare kernel e a cercare di far girare software legacy su hardware che dovrebbe essere in un museo, questa cosa mi fa venire i brividi. Non è solo una questione di ‘costi extra’. È un attacco diretto alla libertà del developer. Il bello del nostro mondo è che se scrivi codice, lo scrivi perché devi, perché vuoi risolvere un problema o perché ti diverte vedere un motore fisico che funziona. Se iniziamo a dover fare il ‘coding con la censura’, preoccupandoci di non triggerare i filtri commerciali del provider di turno, la creatività muore.nnQuesta è l’essenza del vendor lock-in travestita da ‘policy di sicurezza’. Oggi è OpenClaw, domani potrebbe essere un riferimento a un framework open source che non va a genio ai piani alti di Anthropic o Google. È una mossa subdola che crea un ecosistema dove solo chi può permettersi di pagare il ‘pizzo digitale’ può sviluppare senza restrizioni.nnCosa significa per noi che amiamo mettere le mani in pasta? Significa che dobbiamo stare all’erta. Mentre noi cerchiamo di far girare macchine CNC o di modellare oggetti complessi in 3D, le aziende che forniscono la ‘mente’ del nostro workflow stanno costruendo recinti invisibili. Se usate tool basati su LLM per aiutarvi nel debugging o nella generazione di boilerplate, sappiate che il vostro workflow non è più solo vostro. È soggetto alle fluttuazioni del loro ‘sentiment’ commerciale.nnLa prossima volta che vedete un annuncio di una nuova feature di IA, non guardate solo quanto è veloce o quanto è intelligente. Chiedetevi: «Quanto mi costerà scrivere la parola ‘libertà’ nel mio prossimo commit?».”,
“tags”: [
“AI”,
“ClaudeCode”,
“Coding”,
“OpenSource”,
“TechEthics”
],
* “image_prompt”: “A high-contrast, cyberpunk-style digital illustration. A glowing, robotic hand (representing AI) is seen placing a heavy, metallic padlock over a stream of flowing green code. In the background, silhouettes of hackers working on vintage monitors and 3D printers are visible in a dark, gritty workshop atmosphere. Neon colors: electric blue, toxic green, and deep shadows. Moody, cinematic lighting with a glitch art aesthetic.”
}

Source: Claude Code refuses requests or charges extra if your commits mention "OpenClaw"

Immaginate di aver passato ore a configurare perfettamente il vostro setup, a ottimizzare i container e a far girare script di automazione che sembrano magia nera. Ora, immaginate che un bug silente e bastardo entri nel sistema, bypassando le difese e rendendo tutto vulnerabile. Non è l’inizio di un nuovo dungeon crawler su Godot, purtroppo, ma la realtà di CopyFail.

La notizia è arrivata con la stessa eleganza di un corto circuito su una breadboard mal progettata: CopyFail è la minaccia più seria per l’ecosistema Linux che abbiamo visto in anni. E non parlo di quel piccolo script che ti ruba la password del Wi-Fi, ma di qualcosa che colpisce duramente i server multi-tenant, i workflow di CI/do e, peggio ancora, l’intero mondo Kubernetes. Se gestite infrastrutture cloud o container, il mondo sta letteralmente correndo ai ripari perché il perimetro di sicurezza è diventato poroso come un pezzo di plastica riciclata male con una stampante 3D economica.

Il problema è che CopyFail non gioca secondo le regole. Colpisce proprio dove ci sentiamo più sicuri: l’isolamento dei processi. Se i container non sono più i ‘fortini’ che credevamo, l’intera architettura moderna del software viene messa in discussione. È quel tipo di vulnerabilità che ti fa venire voglia di tornare ai tempi del retrocomputing, dove tutto era locale, isolato e non dovevi preoccuparti che un container malintenzionato potesse saltare l’overlay del kernel.

Da smanettone, la mia reazione è un misto di ‘lo sapevo che non era tutto oro quello che luccica’ e una sana dose di ansia tecnica. Sappiamo tutti che la comodità del cloud e dell’automazione ha un prezzo, e questo è il debito tecnico che stiamo pagando. Vedere tutto questo hype intorno alla scalabilità infinita scontrarsi con una vulnerabilità così strutturale è una lezione di umiltà necessaria per tutti.

Cosa significa per noi che amiamo sporcarci le mani con l’hardware e il software? Se state facendo esperimenti con server casalinghi, Raspberry Pi o cluster Kubernetes fatti in casa per testare le vostre IA, non fate i pigri. Gli update non sono suggerimenti opzionali del vendor, sono sopravvivenza. Controllate i vostri kernel, verificate le configurazioni dei container e, per l’amor di tutto ciò che è open source, non assumete che l’isolamento sia garantito per default.

In un mondo dove tutto è interconnesso, un buco nel kernel Linux è come una crepa in un trasformatore elettrico: può sembrare un problema lontano, finché non ti ritrovi al buio.

Source: The most severe Linux threat to surface in years catches the world flat-footed

Mettete pure in pausa quel rendering di Blender o quel debug su Godot, perché c’è una notizia che fa tremare le fondamenta del vostro stack Linux.

Non è il solito bug che richiede un’exploit complicatissima o un accesso di rete pregresso. Parliamo di ‘Copy Fail’, una vulnerabilità che sta facendo discutere su Hacker News e che colpisce quasi tutto ciò che è mainstream. Se il vostro kernel è stato compilato tra il 2017 e l’ultimo patch, siete potenzialmente nel mirino. E la cosa peggiore? Non serve nemmeno avere i permessi di debugging o configurazioni particolari. Basta che il kernel abbia l’API crypto (AF_ALG) abilitata, il che, per dispetto della nostra tranquillità, è la configurazione standard su quasi tutte le distro che usiamo quotidianamente.

Per chi mastica Linux, la lista dei sospetti è lunga: Ubuntu, Amazon Linux, RHEL, SUSE… ma non fermiamoci qui. Se usate Arch, Debian, Fedora o anche i sistemi embedded che state smanettando per far funzionare qualche macchinario CNC fatto in casa, siete nello stesso baratro. Il problema è che un semplice utente locale, uno di quelli con i permessi minimi, può scalare i privilegi e diventare root senza troppi complimenti.

Analizziamo la cosa con la freddezza di chi ha visto troppi server esplodere. Se gestite macchine multi-tenant, server di build come GitHub Actions self-hosted o runner Jenkins, la situazione è da codice rosso. In un ambiente containerizzato (Kubernetes, Docker e compagnia bella), un attaccante potrebbe saltare da un pod all’altro, compromettendo l’intero nodo. È il classico scenario da incubo in cui l’isolamento dei tenant diventa una barriera di carta velina.

Per noi maker e smanettoni che usiamo Linux sul laptop personale, il rischio è leggermente più basso perché, beh, siete quasi sempre gli unici utenti. Tuttavia, se per caso vi capita di far girare script di terze parti o servizi web esposti, l’exploit potrebbe essere l’ultimo tassello per una compromissione totale.

Il mio consiglio? Niente panico da primo piano, ma niente nemmeno l’indifferenza di chi non ha mai letto un man page. Aggiornate i kernel. Subito. Non aspettate che la vostra workstation diventi un gateway per un ransomware o che il vostro server di automazione inizi a minare crypto per conto di sconosciuti. La patch è uscita, quindi non c’è scusa che tenga. Fate il lavoro sporco, patchate tutto e tornate pure a modellare i vostri asset 3D o a scrivere codice. Ma fatelo in sicurezza.

Source: Copy Fail

Esiste un confine sottile tra il genio dell’automazione e il caos più totale, e sembra che Anthropic l’abbia appena varcato con un botto che non si sente da tempo.

Se siete il tipo di persona che passa le notti a ottimizzare script Python o a cercare di far girare un vecchio kernel su un hardware sperimentale, sapete quanto sia importante la precisione. Ecco, immaginate di fare un commit banale, magari solo per aggiornare una documentazione, e scoprire che quel minuscolo refuso nel messaggio di commit sta attivamente svuotando il vostro credito extra. Non è uno scherzo, è quello che sta succedendo con Claude Code.

Un utente ha scoperto che se nel tuo storico git compare la stringa ‘HERMES.md’ (attenzione, proprio con le maiuscole!), il sistema di routing delle API di Claude decide che non è più ora di usare la tua quota mensile del piano Max, ma è il momento di iniziare a scalare i costi sul piano ‘extra usage’. Parliamo di un utente che ha visto bruciare oltre 200 dollari senza nemmeno accorgersene, mentre il suo dashboard mostrava ancora l’86% della capacità settimanale disponibile. Una magia nera, ma con un conto in banca decisamente meno magico.

La cosa assurda è che il bug non riguarda l’esistenza del file sul disco, ma la presenza della stringa nel messaggio di commit. Claude Code include i commit recenti nel prompt di sistema, e qualcosa lato server, probabilmente un regex scritto male o un rule-based router decisamente poco intelligente, interpreta quella stringa come un segnale per cambiare la classe di fatturazione. Se scrivi ‘hermes.md’ in minuscolo, tutto funziona. Se scrivi ‘HERMES.md’, sei fregato.

Da smanettone, trovo questa cosa profondamente irritante. Siamo abituati a bug, certo, ma un bug che introduce una latenza nel monitoraggio dei costi e che agisce in modo silente è il nemico numero uno di chiunque faccia debugging o automazione. È il classico esempio di ‘spaghetti code’ lato infrastruttura che finisce per punire l’utente finale. Non è solo un problema di codice, è un problema di trasparenza. Come fai a diagnosticare un errore che ti dice ‘hai finito i crediti extra’ quando, in realtà, i tuoi crediti del piano principale sono ancora lì che ti salutano?

Per noi che amiamo smontare tutto e capire come funzionano le cose, questo è un monito: fate attenzione a cosa scrivete nei vostri commit quando usate tool AI integrati. E soprattutto, controllate i log di billing con la stessa ossessionità con cui controllate i voltaggi su un oscilloscopio. Il ‘corporate-speak’ ci vende l’efficienza infinita, ma la realtà è che un semplice errore di case-sensitivity può trasformare il vostro workflow in un bancomat impazzito.

In breve: se vedete ‘HERMES.md’ nei vostri messaggi di commit, cambiate nome o fate un rename immediato. La tecnologia è fantastica, finché non decide di fatturarti un errore di battitura come se fosse un servizio premium.

Source: HERMES.md in commit messages causes requests to route to extra usage billing

Smettetela di trattare il vostro editor di codice come se fosse una tab di Chrome aperta da tre giorni senza mai chiuderla. Se siete stanchi di vedere la CPU che decolla al minimo movimento del mouse, c’è una notizia che potrebbe farvi tornare il sorriso (e salvare i vostri ventilatori).

Zed è ufficialmente arrivato alla versione 1.0. E no, non è il solito annuncio marketing pieno di fuffa per convincere i manager a comprare licenze enterprise. Qui la storia è diversa. Il team di Nathan Sobo ha fatto quello che noi facciamo quando troviamo un vecchio Commodore 64: ha smontato tutto e ha ricostruito il motore da zero.

Sapete come funziona la maggior parte degli editor moderni, no? Sono dei pesanti wrapper Electron che caricano un intero browser web solo per mostrarvi un cursore lampeggiante. Un sacco di RAM buttata, un sacco di overhead inutile. Zed ha detto «basta». Invece di costruire una pagina web, hanno costruito un videogioco. Usano Rust e un framework chiamato GPUI che spinge tutto sulla GPU tramite shader. In pratica, scrivere codice con Zed è più simile a giocare a un titolo moderno che a navigare su un sito web pesante.

Per noi che amiamo il controllo totale, la cosa figa è che hanno scritto ogni singolo livello dello stack. Non stanno usando fondamenta prese in prestito da altri. E poi c’è l’integrazione con l’AI. Non è quella roba ‘incollata sopra’ che ti suggerisce commenti inutili, ma un approccio AI-native con agent che possono lavorare in parallelo. È un concetto che mi ricorda un po’ i nostri script di automazione quando vogliamo far fare il lavoro sporco alla macchina mentre noi ci godiamo il caffè.

Certo, c’è un piccolo retrogusto amaro per i puristi: hanno lanciato anche «Zed for Business». Vedere l’introduzione di billing centralizzato e gestione dei ruoli fa sempre un po’ tristezza, perché sa di quella tendenza aziendale a trasformare ogni strumento creativo in un asset gestibile dai reparti IT. Però, se questo significa che lo strumento diventa più stabile e supportato, posso anche chiudere un occhio.

Il vero salto di qualità però è DeltaDB. Stanno sviluppando un motore di sincronizzazione basato su CRDT che permette a umani e agent AI di collaborare sullo stesso codice in tempo reale, con una precisione granulare a livello di singolo carattere. Roba da matti.

Se siete stanchi di aspettare che il vostro editor finisca di caricare i plugin, scaricatelo. È veloce, è scritto in Rust (e quindi è solido) e sembra fatto da gente che odia l’inefficienza quanto noi. È il momento di tornare a scrivere codice con la velocità della luce, senza che il vostro laptop sembri pronto a decollare.

Source: Zed 1.0

Se pensavate che il vostro unico problema fosse far compilare correttamente un codice C++ pieno di puntatori selvaggi, preparatevi a rimettervi in discussione.

La notizia che arriva da Ars Technica è di quelle che ti fanno venire voglia di staccare tutto e tornare a programmare su un Commodore 64, dove l’unico rischio di hacking era il tuo vicino di casa che cercava di rubarti i record di Donkey Kong. Un attacco alla supply chain ha puntato il mirino proprio contro i ‘pesi massimi’ della sicurezza: Checkmarx e Bitward​warden. Sì, avete letto bene. I giganti che dovrebbero essere il nostro bunker digitale sono diventati il cavallo di Troia per i malintenzionati.

Ma come cavolo è possibile? Il succo della questione è che l’attacco non ha cercato di scassinare la porta blindata, ma ha corrotto i pezzi di ricambio mentre venivano fabbricati. In pratica, gli hacker sono riusciti a infiltrarsi nel processo di distribuzione di software e strumenti che noi diamo per scontati. Quando un’azienda come Bitwarden, che gestisce le nostre password (le uniche cose che ci separano dal caos totale), viene coinvolta in un incidente del genere, il problema non è solo un ‘bug’ o una patch da applicare. Il problema è la fiducia.

Da smanettone, questa cosa mi fa bollire il sangue. Noi siamo abituati a smontare hardware, a scrivere script per automatizzare tutto e a usare tool open source perché ci fidiamo di ciò che possiamo leggere e controllare. Ma quando il livello dell’attacco sale così in alto, colpendo la catena di approvvigionamento del software stesso, il perimetro di sicurezza svanisce. È come se scoprissi che le viti che usi per il tuo nuovo CNC sono state pre-programmate per autodistruggersi dopo mille ore di lavoro.

Cosa significa per noi che amiamo sporcarci le mani con l’elettronica e il codice? Significa che la fiducia cieca è diventata un lusso che non possiamo più permetterci. Non dico di smettere di usare Bitwarden (perché, onestamente, gestire le password a memoria è una missione impossibile), ma è il momento di riconsiderare la nostra ‘igiene digitale’. Verificare le integrità, preferire il self-hosting quando possibile e, soprattutto, smettere di considerare i vendor come entità infallibili.

Non lasciatevi incantare dal marketing della ‘sicurezza totale’. La sicurezza assoluta è una favola per vendere abbonamenti SaaS costosi. La vera sicurezza è l’ossessione per il controllo. Quindi, mentre continuate a modellare i vostri pezzi in Blender o a scrivere shader in Godot, ricordatevi che ogni pacchetto che scaricate potrebbe contenere una sorpresa non proprio gradita. Restate critici, restate paranoid e, soprattutto, continuate a smontare tutto.

Source: Why a recent supply-chain attack singled out security firms Checkmarx and Bitwarden

Avete presente quando il vostro setup preferito inizia a comportarsi come un vecchio Commodore 64 con l’alimentatore che frigge? Ecco, GitHub per Mitchell Hashimoto è diventato esattamente questo.

La notizia sta girando su Hacker News come un kernel panic in un loop infinito: Ghostty, il progetto che tutti amiamo (e che merita molto più di un terminale instabile), sta ufficialmente abbandonando GitHub. E non è un capriccio da developer viziato, ma una vera e propria fuga disperata.

Mitchell non è un utente qualunque; è uno che su GitHub ci ha passato metà della sua vita, dai tempi di Vagrant a oggi. Ma la goccia che ha fatto traboccare il calderone è stata la serie di outage che hanno reso impossibile, letteralmente, lavorare. Immaginate di essere lì, nel pieno di una sessione di coding notturna, con il caffè ancora caldo e la voglia di pushare quel fix critico, per poi scoprire che GitHub Actions è andato in crash. Di nuovo. Ancora. Per ore.

Il punto non è Git, che per definizione è distribuito (sì, lo so, ho già sentito le lamentele dei puristi nei commenti), ma l’ecosistema. Issues, Pull Request, Actions… tutta quella ‘comodità’ che GitHub ci vende come un paradiso cloud, ma che in realtà è una gabbia dorata fatta di dipendenze che possono saltare in qualsiasi momento. Quando la piattaforma non ti permette più di fare il tuo lavoro, non è più uno strumento, è un ostacolo.

Per noi che amiamo smontare le cose, questa è una lezione fondamentale di sopravvivenza digitale. Siamo abituati a costruire macchine CNC, a modellare in Blender o a far girare motori grafici in Godot con la certezza che l’hardware risponda. Ma nel software, ci stiamo fidando troppo di un unico enorme monolite centralizzato. Il ‘vendor lock-in’ qui non è solo una parola da meeting aziendale, è un rischio reale che può bloccare la produzione di interi progetti open source.

Cosa succederà ora? Ghostty ha un piano. Non scappano nel nulla, ma stanno cercando alternative, tra provider commerciali e soluzioni FOSS. Manterranno un mirror in sola lettura su GitHub, giusto per non lasciare i vecchi commit all’abbandono, ma l’anima del progetto si sposterà altrove.

Questa mossa è un promemoria brutale: non lasciate mai che il vostro flusso di lavoro dipenda interamente da un unico punto di fallimento. Se un progetto importante come Ghostty può decidere di staccare la spina dopo 18 anni, dovremmo tutti iniziare a chiederci quanto è solida la nostra infrastruttoria.

In bocca al lupo, Mitchell. Speriamo che la nuova casa sia meno problematica di questo caos.

Source: Ghostty is leaving GitHub