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

E se ti dicessi che un terminale può ingoiare 37GB di RAM in dieci giorni? No, non è l’ultimo esperimento di Elon Musk per colonizzare Marte, ma un problema reale di Ghostty che ha tenuto svegli più notti di un bambino con i denti che spuntano.

La storia è questa: Ghostty, il terminale che prometteva di essere più veloce di un hacker con troppo caffè in corpo, aveva un buco nero nella gestione della memoria. Un bug vecchio come le prime righe di codice di Ghostty 1.0, ma che si è scatenato solo con l’arrivo di Claude Code, un po’ come quando scopri che la tua vecchia bicicletta va a pezzi solo perché hai messo le ruote da mountain bike.

Il problema? Una questione di pagine standard e non-standard, di memory pool e di scrollback pruning. Insomma, roba che fa impazzire anche i più esperti di Zig e che ha portato a un leak che avrebbe fatto arrossire un principiante. Il tutto perché Ghostty pensava che una pagina non-standard fosse standard e, beh, ha deciso di non liberare la memoria. Classico.

La soluzione? Semplice: non riutilizzare mai le pagine non-standard. Come quando decidi che la tua vecchia scheda video non è più abbastanza potente per giocare e la butti via invece di provare a overclockarla fino a farla esplodere.

Ma cosa significa per noi smanettoni? Prima di tutto, che anche i terminali più fighi hanno i loro problemi e che la gestione della memoria è una bestia difficile da domare. Secondo, che se vedete Ghostty mangiare RAM come se non ci fosse un domani, forse è il caso di aggiornare. Terzo, che i semicoloni mancanti sono ancora il vero male del mondo.

E poi, ammettiamolo, è sempre bello quando un bug viene risolto con una soluzione semplice e pulita. Un po’ come quando trovi la causa di un problema che ti ha fatto perdere ore di sonno e ti rendi conto che bastava una riga di codice in più.

Quindi, la prossima volta che il vostro terminale inizia a comportarsi come un adolescente in crisi d’identità, ricordatevi di Ghostty e del suo memory leak. E magari, per sicurezza, controllate i semicoloni.

Source: Finding and fixing Ghostty's largest memory leak

WTF?! Avete letto bene. Su Ghostty, una piattaforma che sembrava uscita direttamente dai nostri sogni di hacker e maker, non potete più aprire issue direttamente. Cioè, non potete segnalare bug, chiedere feature, o semplicemente dire “ehi, ma questa cosa non funziona come dovrebbe” senza passare per un processo indiretto.

La notizia è spuntata su Hacker News e la spiegazione ufficiale è… beh, diciamo che è un bel groviglio di “sicurezza”, “spam”, e “moderazione”. In pratica, Ghostty è stata sommersa da segnalazioni automatiche, bot, e gente che usava il sistema di issue come un forum di supporto. Capiamoci, è un problema reale, soprattutto per progetti open source gestiti da poche persone.

Ma disabilitare la possibilità di aprire issue? Sembra un po’ eccessivo, no? È come chiudere il pronto soccorso perché ci sono troppi pazienti con il raffreddore. Certo, si può implementare un sistema di moderazione più efficace, usare CAPTCHA più intelligenti, o addirittura sfruttare l’intelligenza artificiale per filtrare lo spam. Ma togliere la possibilità di segnalare bug a chi contribuisce attivamente al progetto mi sembra una mossa controproducente.

Ghostty giustifica la decisione dicendo che vogliono concentrarsi su “un’esperienza utente più curata”. Tradotto: vogliono avere il controllo totale su ciò che viene segnalato e come viene gestito. Il che, diciamocelo, puzza un po’ di vendor lock-in. Cioè, invece di risolvere il problema alla radice, preferiscono imporre un processo che li metta in una posizione di controllo.

Cosa significa tutto questo per noi? Beh, significa che se trovate un bug su Ghostty, dovrete segnalarlo su Discord, Matrix, o tramite altri canali “ufficiali”. Il che è un po’ scomodo, e rischia di far perdere preziose segnalazioni nel mare di chiacchiere. E soprattutto, significa che il progetto sta prendendo una direzione meno aperta e collaborativa.

Non fraintendetemi, capisco le ragioni di Ghostty. Ma come community di hacker e maker, siamo abituati a sporcarci le mani, a smanettare, a trovare soluzioni creative. E la possibilità di segnalare bug direttamente è parte integrante di questo processo. È un modo per contribuire attivamente al progetto, per imparare, e per migliorare la piattaforma per tutti.

Spero che Ghostty riconsideri la sua decisione. O almeno, che trovi un modo per bilanciare la necessità di moderazione con la libertà di segnalare bug. Perché, alla fine, un progetto open source ha bisogno di una community attiva e coinvolta per prosperare. E togliere la possibilità di segnalare bug è un po’ come togliere l’ossigeno a un hacker.

E ricordate: controllate sempre i vostri semicolon!

Source: Why users cannot create Issues directly