Avete mai provato quella strana soddisfazione che si prova quando smontate un giocattolo nuovo e scoprite che dentro c’è solo lo stesso vecchio meccanismo di quello che avevate già in mano? Ecco, beh, è esattamente quello che sta succedendo nel mondo dei Large Language Models, ma con molta meno plastica e molto più marketing spazzatura.

La notizia che sta girando su Hacker News è un classico esempio di «fuffa tecnologica» che farebbe impallidire un venditore di tappeti. La municipalità di Rio de Janeiro ha presentato Rio-3.5-Open-397B come un modello originale, addestrato con fatica da IplanRIO. Peccato che il team di Nex-AGI abbia deciso di fare i veri hacker e andare a guardare sotto il cofano, scoprendo che non c’è nessun motore nuovo.

In pratica, non c’è stato alcun addestramento vero e proprio. I pesi del modello sono semplicemente un’interpolazione matematica: un mix al 60% del modello Nex e al 40% di Qwen. È come se qualcuno prendesse un hamburger di una catena famosa e un panino del bar all’angolo, li frullasse insieme e poi cercasse di venderti un nuovo ‘Signature Burger Gourmet’ creato in casa.

Le prove sono schiaccianti, roba da debugger incazzato. Primo: se togli il system prompt che dice al modello di fingere di essere ‘Rio’, il modello inizia a identificarsi come ‘Nex’ nel 79% dei casi. Addirittura, recita la storia aziendale di Nex-AGI parola per parola. Secondo: un’analisi statistica sui tensori mostra che ogni singolo strato della rete è esattamente quella combinazione matematica di Nex e Qwen. Non c’è margine d’errore, è matematica pura.

Per noi che amiamo smanettare con i pesi dei modelli, con il fine-tuning e con le architetture neurali, questa è una mezza sconfitta morale. Da un lato, l’idea di fare il merging di modelli esistenti è una tecnica legittima e super interessante per ottenere risultati interessanti senza bruciare budget infiniti in GPU. È un approccio ‘maker’, è efficiente, è smart.

Dall’altro, però, la parte ‘corporate’ che cerca di spacciarlo per un’innovazione proprietaria è fastidiosa quanto un bug che non si trova nel codice sorgente. È l’ennesimo tentativo di gonfiare il valore di un prodotto usando il nome di altri. Se vuoi fare un merge, fallo, chiamalo ‘Rio-Merge’ e dichiaralo con orgoglio. Non provare a venderci una nuova tecnologia che è solo un cocktail di quelle che già usiamo.

Alla fine della fiera, resta la lezione per tutti noi: non fidatevi mai dei comunicati stampa. Fate i vostri test, analizzate i pesi, controllate i prompt. La verità sta sempre nei bit, non nelle slide della presentazione.

Source: Rio de Janeiro's "homegrown" LLM appears to be a merge of an existing model

Se pensavate che il mondo del software fosse un meccanismo senza fine di patch, aggiornamenti e alert di sicurezza che vi saltano in faccia alle tre di notte, preparatevi a ricalibrare i vostri parser.

Daniel Stenberg, l’uomo che ha reso curl lo standard de facto per ogni singola richiesta HTTP che passa per i nostri terminali, ha appena annunciato una notizia che farebbe venire un infarto a qualsiasi CISO di una multinazionale: durante tutto il mese di luglio 202LE, il progetto curl non accetterà, né gestirà, alcuna segnalazione di vulnerabilità. Lo hanno ribattezzato, con un pizzico di sano sarcasmo, «curl summer of bliss».

Sì, avete letto bene. Il form di sottomissione su Hackerone rimarrà spento, come un vecchio Commodore 64 quando stacchi la spina. Per trenta giorni, i bug critici che potrebbero far saltare in aria metà della rete globale dovranno restare nel limbo, in attesa che gli sviluppatori tornino dalle vacanze a godersi il sole (o a smanettare con qualche progetto di retrocomputing senza l’ansia di un exploit imminente).

Per noi che viviamo di script, automazioni e tool che girano su server che non vediamo dal 2015, la cosa è decisamente bizzarra. Da un lato, c’è un fascino quasi romantico in questa idea: il diritto al disconnessione portato all’estremo, quasi un atto di ribellione contro la cultura della reperibilità perenne che distrugge il cervello. È un po’ come quando stacchi il modulo Wi-Fi dalla tua stampante 3D per evitare che parta un aggiornamento firmware non richiesto che ti rompe tutto il workflow: un momento di pace pura.

Dall’altro lato, però, bisogna essere onesti. Se siete un ricercatore di sicurezza che ha appena trovato un buffer overflow che permette l’esecuzione di codice remoto su ogni server Linux del pianeta, trovarsi davanti a un modulo chiuso è frustrante quanto trovare un errore di sintassi in un codice Python complesso proprio un minuto prima della deadline.

Cosa significa per noi maker e smanettoni? Se state usando curl nei vostri progetti IoT o nei vostri script di automazione, sappiate che per luglio 2026 sarete ufficialmente in una zona di ‘sicurezza apparente’. Non è che il codice diventi magicamente incrollabile, è solo che nessuno ti dirà se sta bruciando.

In un mondo dominato da cloud provider che ti vendono servizi di sicurezza ‘all-in-one’ (e carissimi) e da una cultura enterprise che vive di panic-button, vedere un progetto così fondamentale che dice «No, ragazzi, questo mese non si lavora» è una boccata d’aria fresca. È un promemoria che, sotto l’hype dell’IA e delle megacorporazioni, esistono ancora esseri umani che gestiscono l’infrastruttura del mondo e che, ogni tanto, hanno bisogno di spegnere tutto e dimenticarsi dei pacchetti corrotti.

Source: Curl will not accept vulnerability reports during July 2026

Avete presente quella sensazione di onnipotenza che provate quando il vostro codice passa tutti i test, il linter non urla e il build è finalmente verde?

Ecco, dimenticatela. Se usate i dispositivi Kobo, la realtà è molto più cruda e decisamente meno logica. Recentemente è emersa una storia che è un vero incubo per chiunque ami gli standard aperti e la pulizia del codice. Un autore ha pubblicato un nuovo eBook, tutto in regola, superando l’epubcheck con la grazia di un robot senza bug. Eppure, per i lettori Kobo, il file risultava ‘corrotto’.

Il colpevole? Non è un errore nel file, ma un pezzo di tecnologia fossile: il RMSDK di Adobe. Parliamo del motore di rendering che Kobo usa ancora oggi, una roba che sembra uscita da un setup retrocomputing degli anni 2010. È il cuore di Adobe Digital Editions, quel software che tutti usiamo solo perché dobbiamo, un monumento al DRM e alla pesantezza software.

Il problema è che questo motore è rimasto congelato nel tempo. Mentre noi ci divertiamo a usare CSS moderni, Flexbox, Grid e funzioni matematiche avanzate, il parser di Adobe si blocca non appena vede qualcosa che non appartiene al suo mondo preistorico. In questo caso specifico, una riga di CSS totalmente valida — una semplice funzione ‘min()’ per gestire la larghezza di un’immagine — è stata interpretata come un errore fatale. Il risultato? Nessun messaggio d’errore utile, solo un silenzioso e frustrante crash del file.

Da smanettone, trovo questa cosa assolutamente inaccettabile. Siamo nel 2026! Se un software non riesce a gestire un’istruzione CSS standard senza dichiarare il fallimento totale, non è un software, è un timer a scadenza che aspetta solo di esplodere. È il classico esempio di vendor lock-in mascherato da ‘compatibilità’: Kobo si aggrappa a un motore proprietario e vecchio di un decennio, e noi siamo costretti a scrivere codice ‘povero’ e antiquato solo per non far piangere il loro parser.

Per noi che amiamo smontare le cose e capire come funzionano, questo è un promemoria brutale: non potete fidarvi solo degli standard ufficiali se sotto il cofano c’è un motore che gira ancora a vapore. Se volete che le vostre creazioni (che siano eBook o script per una CNC) funzionino ovunque, dovete testarle contro il peggior scenario possibile. Dovete sottoporle al ‘tritacarne di Adobe’.

In conclusione: meno hype sui nuovi standard e più attenzione alla robustezza dell’implementazione. Finché le grandi corporation continueranno a preferire il controllo del DRM alla qualità dell’esperienza utente, saremo sempre costretti a scrivere codice come se fossimo ancora nel 2013. Una vera tristezza per chi ama l’innovazione.

Source: Your ePub Is fine

C’è un momento preciso, di solito intorno alle tre del mattino, in cui la luce blu del monitor è l’unica cosa che separa il tuo progetto dal fallimento totale e il tuo cervello dal collasso nervoso. È quel momento in cui smetti di leggere le news aziendali piene di buzzword inutili e cerchi solo qualcuno che stia combattendo la tua stessa battaglia contro un bug impossibile o un motore passo-passo che non ne vuole sapere di girare.

Il thread di Hacker News di giugno 2026 è appena uscito e, come ogni mese, è la nostra dose di dopamina pura. Niente comunicati stampa patinati sulla ‘rivoluzione dell’AI generativa nel cloud’ o annunci di acquisizioni che servono solo a gonfiare i titoli in borsa. Qui la domanda è nuda e cruda: «What are you working on?». Una domanda che, per noi che passiamo il tempo a modellarci pezzi in Blender o a cercare di far girare emulatori di Commodore 64 su hardware moderno, ha un peso tutto diverso.

Ho scorso i commenti e, come sempre, è un mix meraviglioso di genialità e puro caos. Si parla di gente che sta scrivendo kernel personalizzati, di maker che stanno perfezionando estrusori per stampanti 3D fatti con pezzi di recupero e di dev che stanno cercando di addestrare piccoli modelli linguistici locali per gestire l’automazione della propria domotica senza mandare i dati in mano ai giganti del tech. È il rifugio sicuro contro il vendor lock-in che sta soffocando l’industria.

Per noi che amiamo mettere le mani in pasta, questo thread è fondamentale. Ci ricorda che la vera tecnologia non è quella che compri su Amazon con un click, ma quella che costruisci, smonti e riprogrammi secondo le tue regole. È l’orgoglio di chi preferisce scrivere uno script in Python per automatizzare un task noioso piuttosto che pagare un abbonamento mensile a un software proprietario che non ti permette nemmeno di vedere il codice sorgente.

Certo, ogni tanto spunta fuori qualche idea che sembra uscita da un episodio di Black Mirror andata male, ma è il prezzo che paghiamo per vivere sulla frontiera. Se state lavorando a qualcosa che richiede più caffè di quanto ne possiate consumare, o se il vostro progetto attuale è solo un ammasso di cavi disordinati e codice scritto con l’aria di chi ha dimenticato come si usa la documentazione, sappiate che siete nel posto giusto.

Quindi, cos’è che vi tiene svegli? State perfezionando quel motore CNC o state finalmente riuscendo a far compilare quel vecchio progetto C++ senza mille errori di memoria? Fatevi sentire, prima che l’hype del prossimo grande framework ci travolga tutti.

Source: Ask HN: What are you working on? (June 2026)

Smettetela di credere che Internet sia eterno. Ogni secondo, un sito web muore, un database si corrompe o un servizio cloud decide che la tua subscription è scaduta. Stiamo vivendo in un’epoca di estrema fragilità digitale: ci affidiamo a piattaforme che non possediamo, su infrastrutture che non controlliamo, con la speranza che un domani qualcuno non decida di spegnere l’interruttore.

È qui che entra in gioco kage, un progetto che mi ha fatto saltare sulla sedia. Non è il solito scraper che scarica HTML spazzatura; è uno strumento che mira a catturare l’essenza di una pagina web e renderla permanentemente tua, offline, pulita e priva di tutto quel rumore inutile (tracciatori, pubblicità invasiva, script di monitoraggio) che rende la navigazione moderna un inferno di telemetria.

Il funzionamento è quasi poetico nella sua efficacia. kage non si limita a copiare il codice; simula una navigazione reale, aspetta che il contenuto si carichi e poi ‘congela’ la pagina, ricostruendola in una versione snellita e autosufficiente. Il risultato? Un archivio di pagine che funzionano anche senza connessione, dove l’unico tracciamento presente è quello della tua stessa curiosità.

Cosa mi ha colpito davvero? La filosofia del ‘packing’. kage ti permette di impacchettare intere porzioni di web in formati che puoi conservare su un hard disk esterno o su un server locale. Puoi creare il tuo personale Wikipedia personale, o un archivio di documentazione tecnica che non dipenda dal fatto che l’azienda produttrice decida di spostare tutto dietro un paywall o, peggio, chiudere i battenti.

Certo, non è una bacchetta magica. Non è un sostituto per una strategia di backup strutturata, e richiede comunque un minimo di competenza per gestire i flussi di lavoro. Ma l’idea di poter generare file .zim o strutture di pagine pronte per essere consultate in un bunker digitale è troppo potente per essere ignorata.

In un mondo dove tutto è ‘as-a-service’ e la proprietà digitale è un miraggio, avere uno strumento che ti permette di riprendere possesso dei contenuti che ritieni preziosi è un atto di resistenza. kage non è solo un tool; è un’assicurazione sulla vita per la tua memoria digitale.

Source: Show HN: Kage – Shadow any website to a single binary for offline viewing

Il database è il cuore pulsante di ogni progetto, eppure spesso ci ritroviamo a usare strumenti per visualizzare gli schemi che sembrano progettati apposta per spiare la nostra infrastruttura.

Siamo onesti: quante volte avete provato a usare un visualizzatore di diagrammi ER online e vi siete trovati davanti a un muro di ‘Crea un account’, ‘Accetta i cookie’ e ‘Carica il tuo file per iniziare’? In un mondo dove il marketing corporate cerca di convincerci che il cloud sia l’unico posto sicuro (spoiler: non lo è), l’idea di inviare i miei `CREATE TABLE` su un server di qualche startup che domani potrebbe sparire nel nulla mi fa venire i brividi. È proprio il tipo di ‘convenienza’ che non abbiamo chiesto.

Per fortuna, tra le ultime chicche emerse da Hacker News, è spuntato fuori sqltoerdiagram.com. E no, non è l’ennesima piattaforma SaaS con un piano premium che ti blocca le funzioni migliori dopo tre tabelle. È uno strumento che gira interamente nel browser, con un approccio che definirei ‘zero fuffa’.

Funziona in modo elementare: incolli il tuo SQL sul lato sinistro e, magicamente, vedi apparire il diagramma sul lato destro. Puoi trascinare le tabelle, zoomare, rinominare gli elementi e, cosa più importante, esportare il risultato. La vera magia, però, è che tutto avviene localmente. I tuoi dati non lasciano mai la tua scheda del browser. Zero upload, zero account, zero rischi di far finire la struttura della tua DB in qualche dataset di addestramento per qualche IA senza il tuo consenso.

Da smanettone che passa le ore a modellare database per progetti custom o a gestire dati di sensori IoT, trovo che questa sia la quintessenza del software utile. Non ha bisogno di un’interfaccia super rifinita o di animazioni in 4K; ha solo bisogno di fare una cosa e farla bene senza invadere la tua privacy.

Per noi che amiamo smontare le cose, questo è un piccolo trionfo dell’approccio client-side. È uno strumento che puoi usare anche quando sei offline o quando sei su una rete non proprio sicura. Se state lavorando a un progetto in Godot o state strutturando il backend di un nuovo prototipo di macchina CNC, tenetelo nel kit di sopravvivenza. È veloce, è pulito e, soprattutto, non cerca di venderti nulla.

In un’epoca di sovra-complessità, a volte la soluzione migliore è semplicemente un piccolo script che fa il suo lavoro e poi torna a tacere.

Source: Free SQL→ER diagram tool, runs in the browser, nothing uploaded

C’è chi pensa che se non usi un LLM per scrivere la lista della spesa o per decidere che tipo di filamento PLA usare per la tua prossima stampa 3D, allora sei rimasto all’era del floppy disk. Ma la verità è che l’hype sta iniziando a sgonfiarsi, o almeno, la gente sta iniziando a capire che non tutto richiede un modello da miliardi di parametri.

Recentemente è uscito un paper interessante che mette nero su bianco quello che noi, che passiamo le notti a compilare codice o a rifinire mesh su Blender, sappiamo già: il consumo di AI è come quello della carne. C’è chi ne va matto, chi cerca di limitarla per non far degenerare la qualità del proprio lavoro e chi, molto giustamente, preferisce evitarla come la peste. Non siamo tutti schiavi dell’algoritmo, e non dovremmo esserlo.

Il punto non è essere tecnofobi (perché, diciamocelo, quando riesco a far girare un modello locale per automatizzare un task noioso, mi sento un dio), ma è una questione di tool appropriati. Usare l’AI per generare un asset procedurale in un gioco fatto con Godot può essere una svolta; usare l’AI per scrivere la logica fisica di un engine è il modo più veloce per ritrovarsi con un bug che non potrai mai debuggare perché non capisci cosa sta succedendo sotto il cofano.

Per noi che amiamo smontare le cose, il problema vero è il ‘black box’ che l’AI porta con sé. Se sto costruendo una CNC o una macchina per il riciclo di plastica, voglio sapere esattamente perché un parametro è impostato in quel modo. Non mi serve una risposta tipo ‘lo ha deciso il modello’. Il rischio del vendor lock-in e della perdita di controllo sulla logica fondamentale è una minaccia reale alla nostra libertà di maker.

Quindi, alla prossima ondata di marketing che vi promette che l’AI risolverà anche il problema della gravità, sorridete pure. Continueremo a usare i nostri script Python, le nostre vecchie librerie C e il nostro buon vecchio cervello per risolvere i problemi veri. L’AI è un modulo, un plugin, un tool in una cassetta degli attrezzi enorme. Ma la cassetta, e soprattutto le mani che la usano, restano nostre.

Source: No, everyone is not using AI for everything

Esiste un segreto che nessuno ti dice quando guardi i titoli di apertura di qualche conferenza tech piena di gente in felpa con cappuccio: la ricchezza estrema non ha nulla a che fare con la qualità del tuo codice o con quanto è elegante il tuo modello di machine learning.

Ho passato un po’ di tempo a sviscerare l’ultimo post di Paul Graham, intitolato ‘How to Earn a Billion Dollars’. Se vi aspettavate una guida passo-passo su come scalare un’architettura microservizi fino a far esplodere i costi di AWS, siete fuori strada. Graham non parla di ottimizzazione di query o di come gestire i conflitti in Git; parla di quella strana, quasi metafisica, capacità di creare valore su una scala che noi, che siamo troppo impegnati a far girare una CNC fatta in casa o a debuggare un shader in Blender, facciamo fatica a concepire.

Il succo della questione è che per arrivare a cifre simili non serve solo il talento tecnico, ma una sorta di ‘visione’ che sconfina nel puro istinto imprenditoriale (e un pizzico di fortuna che nemmeno un drop di loot leggendario in un GDR possa eguagliare). Il concetto è che devi risolvere problemi che sono così enormi che la soluzione stessa crea un ecosistema di valore immenso.

Ora, facciamo un passo indietro e usiamo il nostro approccio da smanettoni. Se io passo la notte a perfezionare un plugin per Godot o a creare una macchina per il riciclo della plastica che funziona con i pezzi recuperati da un vecchio Commodore 64, sto creando valore, certo. Ma sto creando valore ‘locale’, tangibile, artigianale. È la differenza che passa tra l’inventare un nuovo tipo di vite per stampanti 3D e progettare il nuovo standard globale di produzione automatizzata.

C’è una parte di me che trova questa riflessione profondamente stimolante, ma anche un po’ frustrante. Perché, siamo onesti: l’hype verso la ‘scalabilità infinita’ e i miliardi di dollari ha reso il mondo tech un posto dove spesso conta più il pitch deck che il prodotto reale. Siamo diventati ossessionati dal ‘disruption’ invece che dal ‘making’.

Per noi che amiamo il controllo, il ferro e il bit, il messaggio dovrebbe essere questo: non puntate al miliardo, puntate all’eccellenza tecnica. Il miliardo è un glitch nel sistema, un output anomalo di un algoritmo sociale complesso. Noi invece preferiamo il piacere di un circuito che chiude perfettamente o di un algoritmo che gira fluido senza mandare in crash il kernel. Alla fine della fiera, un miliardo di dollari non ti permettono di goderti il piacere puro di aver risolto un problema complesso solo perché potevi farlo.

Source: How to Earn a Billion Dollars

Immaginate di parcheggiare la vostra amata Honda Civic davanti a un hotel, dare le chiavi al valet e ritrovarvi l’auto che, senza che abbiate toccato nulla, ha un nuovo sistema operativo custom installato nel cruscotto. Sembra l’inizio di un film di spionaggio low-budget, ma è la realtà tecnica di una vulnerabilità che l’autore di un recente paper ha ribattezzato «EvilValet».

Il cuore della questione è il sistema di infotainment (quella famosa headunit che usiamo per far girare Spotify e non soffrire durante il traffico). Qualcuno ha deciso di fare l’esperto di reverse engineering sulla Honda Civic del 2021 e ha scoperto una falla che farebbe impallidire un hacker di fascia bassa. In pratica, il processo di aggiornamento via USB di Honda è un vero disastro di sicurezza. Nonostante i vari controlli, il sistema accetta file di aggiornamento AOSP (Android Open Source Project) firmati con una chiave di test pubblica che è rimasta lì, speranzosa, in un angolo del filesystem.

Tradotto per chi mastica codice: se riesci a formattare una chiavetta USB e a firmare un pacchetto con quella chiave, hai il controllo totale. Non serve nemmeno il root classico con i suoi setuid complicati; basta l’accesso fisico alla porta USB davanti a te. È quello che in gergo chiamiamo «evil maid attack», ma visto che parliamo di un parcheggiatore che ti ruba l’identità digitale dell’auto, «EvilValet» è un nome decisamente più figo.

Per noi che passiamo le notti a smanettare con i microcontrollori o a compilare kernel custom, questa notizia è un mix di eccitazione e profonda frustrazione. Da un lato, c’è la soddisfazione tecnica di vedere come un progetto di reverse engineering possa smontare pezzo per pezzo un sistema proprietario, con strumenti come «ota-builder» o «apk-rebuilder» che automatizzano il lavoro sporco di ricostruzione delle risorse e del codice smali. È puro artigianato digitale.

Dall’altro lato, è un promemoria del fatto che le big tech stanno diventando sempre più pigre. Invece di implementare una vera sicurezza crittografica, lasciano le chiavi sotto lo zerbino sperando che nessuno le veda. È l’ennesimo esempio di quel design mediocre dove la comodità dell’aggiornamento OTA (Over-The-Air) vince sulla sicurezza fondamentale.

Cosa significa per noi maker? Che il confine tra hardware ‘chiuso’ e software ‘aperto’ è sempre più labile. Se hai una macchina moderna, la tua privacy non dipende solo da quanto sei bravo a gestire i permessi su Android, ma da quanto è competente il tizio che ti parcheggia l’auto. La lezione è chiara: se un sistema permette l’aggiornamento fisico senza una verifica d’identità solida, non è un sistema sicuro, è solo un invito a cena per chiunque sappia usare una chiavetta USB.

Source: Honda Civics and the Evil Valet

E se vi dicessi che il cancro non è un errore di sintassi casuale, ma un processo che gira con un comando ‘main’ maledettamente preciso?

Mentre noi passiamo le notti a cercare di capire perché quel modulo C++ compili ma crashi in runtime, la ricerca medica ha appena droppato una notizia che sembra uscita da un film di fantascienza (ma senza il budget di Hollywood). Sembra che, studiando i tumori al pancreas, i ricercatori abbely individuato quello che chiamano il ‘master switch’. In pratica, hanno trovato un interruttore centrale che controlla la proliferazione cellulare incontrollata.

Per chi mastica codice o elettronica, l’analogia è immediata: non stiamo parlando di un singolo bit corrotto in un settore del disco, ma di un register fondamentale che, se impostato su ‘1’, attiva una routine di replicazione infinita che manda in kernel panic l’intero organismo. Se riesci a intercettare quel segnale e a forzarlo su ‘0’, potresti, in teoria, killare il processo maligno senza dover mandare in crash l’intero sistema operativo (cioè il paziente).

Perché è una cosa figa? Perché finora la lotta contro il cancro è stata un po’ come cercare di riparare un corto circuito in un circuito stampato con un martello: si colpisce tutto, sperando che il danno non si estenda. L’idea di avere un punto di input specifico, un interruttore che puoi bypassare o disabilitare, cambia completamente le regole del gioco. Non è più solo ‘taglia e cuci’ chirurgico, ma un intervento mirato sul firmware biologico.

Naturalmente, non siamo ancora alla patch definitiva scaricabile da GitHub. C’è ancora un sacco di ricerca da fare per capire se questo switch sia unico o se esistano altri script malevoli che girano in background. Per noi maker e smanettoni, la cosa eccita perché dimostra che anche i sistemi più complessi e apparentemente caotici — come il genoma umano — seguono logiche che possono essere decodificate, analizzate e, potenzialmente, hackerate per il bene comune.

Speriamo solo che questa scoperta non finisca sotto il controllo di qualche big pharma che vuole applicare un modello di ‘subscription service’ per la salute. Perché se la cura diventa un software proprietario con licenza d’uso mensile e DRM che ti impedisce di usare farmaci generici, allora sì che avremo un vero problema di vendor lock-in biologico.

Restate sintonizzati, perché se riescono a patchare questo bug, il futuro sarà decisamente più interessante.

Source: Treating pancreatic tumours may have revealed cancer's master switch