🇮🇹 · /root · Lamberto Tedaldi
Immaginate di essere nel bel mezzo di un debugging notturno, con tre caffè in corpo e un codice che finalmente sembra funzionare, quando improvvisamente scoprite che anche l’accesso al vostro ecosistema digitale preferito richiede ora un rituale quasi magico. Google ha deciso che la vecchia e semplice registrazione di Gmail non è abbastanza ‘faticosa’ per noi, e ha introdotto una nuova procedura che prevede la scansione di un QR code e l’invio di un SMS dal proprio smartphone. Sì, avete letto bene. Non basta più inserire le tue credenziali e sperare che l’algoritmo non ti scambi per un bot russo. Ora devi fare un balletto tra lo schermo del PC e il tuo device, confermando la tua identità come se stessi superando un controllo doganale digitale. La giustificazione ufficiale? Sicurezza, ovviamente. La realtà? Probabilmente un modo per rendere la vita impossibile a chiunque voglia creare account senza legarli a un numero di telefono fisico e tracciabile. Il punto non è solo la scomodità, che per noi maker è quasi un insulto al concetto di efficienza, ma il problema della privacy che sta emergendo nelle discussioni tra esperti del settore. Se per creare un account ‘anonimo’ (e sì, lo sappiamo tutti che l’anonimato totale è un mito, ma ci proviamo) devi passare per un numero di telefono che, in molti paesi, è legato al tuo documento d’identità, la partita è persa in partenza. Se compri una SIM in Italia mentre sei in vacanza per un weekend e la usi per un account Google, quel numero tornerà in commercio non appena la tua SIM scadrà, ma la traccia digitale della tua identità rimarrà incisa nei database di Mountain View. Per noi che amiamo smanettare, costruire CNC, programmare in Godot o far girare vecchi sistemi retrocomputing, questa è una notizia pessima. Il nostro intero workflow si basa sulla libertà di sperimentare, di creare prototipi, di testare nuovi servizi senza dover necessariamente sottoporre la nostra intera esistenza burocratica a un check di Google. Questo tipo di ‘security through friction’ è l’antitesi dell’hacking creativo; è un tentativo di chiudere il perimetro, di rendere tutto più rigido, più tracciabile, più… corporate. Cosa significa per noi? Significa che la barriera all’ingresso per l’autonomia digitale si sta alzando. Se volete testare nuovi tool di IA o creare bot automatizzati, la gestione degli account diventerà un incubo di procedure fisiche. La raccomandazione di sempre rimane la stessa: usate YubiKey, configurate app di autenticazione e, se potete, cercate di non affidare la vostra intera vita digitale a un unico vendor che, a quanto pare, ha deciso che il QR code è il nuovo standard per tormentarci. In breve: la privacy sta diventando un lusso che Google cerca di rendere tecnicamente impossibile da mantenere. Restiamo pronti a trovare il workaround, come sempre. Source: Gmail registration now requires scanning a QR code and sending a text message
webnewsDigitalFreedomgoogleprivacysecurity
🇮🇹 · /root · Lamberto Tedaldi
Avete presente quella sensazione di puro disagio che provate quando un vecchio script Python va in loop infinito e non riuscite a killare il processo dal terminale? Ecco, Koji Suzuki ha passato la carriera a creare quel tipo di ansia, ma con una maestria che nessun bug di sistema potrebbe mai eguagliare. È arrivata la brutta notizia: il maestro del techno-horror, l’autore di «Ring», si è spento. E non parliamo solo di un autore di romanzi, ma di un vero e proprio architetto di atmosfere che ha saputo decodificare l’orrore moderno molto prima che l’IA iniziasse a generare immagini inquietanti con un semplice prompt. Per chi non fosse rimasto troppo sepolto nei propri progetti di retrocomputing o nella modellazione 3D su Blender, Suzuki non è stato solo lo scrittore dietro ai film che vi hanno fatto temere le videocassette. Con il suo romanzo del 1991, ha ridefinito i canoni del genere, portando l’orrore dentro la tecnologia stessa. Prima che i social media diventassero una prigione di algoritmi e privacy leak, lui ci aveva già avvertito che la tecnologia poteva essere un vettore per qualcosa di decisamente più sinistro e incontrollabile. Da maker e smanettoni, noi abbiamo un rapporto particolare con gli oggetti. Ci piace smontare, capire il segreto dietro un circuito, manipolare il codice. Ma Suzuki ci ha insegnato che l’hardware e il software possono ospitare fantasmi. La sua capacità di intrecciare scienza, biologia e tecnologia è pura genialità: non era semplice jump scare alla Hollywood, era una riflessione profonda su come l’infinitamente piccolo e l’infinitamente connesso possano sfuggire al nostro controllo. C’è una lezione quasi filosofica in tutto questo per chi ama il low-level programming o la costruzione di macchine CNC: la vera potenza di un’idea non sta nella complessità del tool che usi, ma nella logica con cui costruisci il mondo. Suzuki ha costruito un sistema operativo dell’orrore che gira ancora perfettamente sui nostri cervelli, nonostante decenni di aggiornamenti e patch. Oggi non c’è un fix o un rollback che tenga. Resta solo il rispetto per un creatore che ha saputo hackerare l’immaginario collettivo, lasciandoci un’eredità che, proprio come un vecchio loop di nastri magnetici, continuerà a girare nella nostra mente. Rip in peace, Koji. Il tuo codice è immortale. Source: RIP Koji Suzuki, Author and Creator of ‘The Ring’
webnewshorrorKoji Suzukipop cultureRetro Tech
🇮🇹 · /root · Lamberto Tedaldi
Scommetto che anche voi avete presente quel momento di puro disgusto quando un’app che usate ogni giorno, magari una di quelle che stiamo smanettando per integrare in qualche progetto custom, smette improvvisamente di funzionare solo perché i server di OpenAI hanno deciso di fare un break o perché il tuo abbonamento è scaduto. È frustrante, vero? Recentemente è uscito un pezzo su Hacker News che ha centrato il punto con una precisione chirurgica: stiamo vivendo l’era della ‘pigrizia da API’. Oggi, per ogni minima feature che richieda un briciolo di ‘intelligenza’, gli sviluppatori hanno la tendenza a lanciare una chiamata API verso Anthropic o OpenAI. Risultato? Abbiamo trasformato delle semplici funzioni in sistemi distribuiti complessi, costosi e, diciamocelo, incredibilmente fragili. Ma parliamoci chiaro: abbiamo in tasca dei mostri di silicio che farebbero impallidire un supercomputer di dieci anni fa. Il tuo smartphone ha un Neural Engine dedicato che sta lì, a polverizzare silicio, in attesa di fare qualcosa di utile. Invece, cosa facciamo? Mandiamo un payload JSON verso una farm in Virginia, aspettiamo che il server elabori, sperando che la latenza non sia troppa e che il provider non decida di cambiare i termini di servizio all’improvviso. È una follia. E non è solo una questione di efficienza o di latenza. Per noi che amiamo smontare le cose, il vero problema è la perdita di controllo. Quando spari i dati degli utenti in un cloud di terze parti, hai appena aperto il vaso di Pandora della privacy, della gestione del consenso e delle rogne legali. Hai trasformato un prodotto locale in un bersaglio per data breach e richieste governative. La vera sfida, quella che fa battere il cuore a chi mastica codice e hardware, è riportare il carico di lavoro sul dispositivo. Se una feature può essere eseguita localmente, farla girare su un modello compresso direttamente sul chip è l’unica strada onesta. Non serve l’IA ‘ovunque’, serve software che funzioni, che sia privato e che non dipenda dal buonumore di un’azienda della Silicon Valley. Per noi maker e dev, questo significa tornare alle basi: ottimizzazione, quantizzazione dei modelli, gestione intelligente delle risorse locali. Meno hype da comunicato stampa e più ingegneria vera. Meno ‘cloud-first’ e più ‘device-first’. Perché alla fine della giornata, l’unico sistema che vogliamo che funzioni senza interruzioni è quello che abbiamo costruito noi. Source: Local AI needs to be the norm
webnewsEdge ComputingLocal AIprivacysoftware engineering
🇮🇹 · /root · Lamberto Tedaldi
Se avessimo seguito il marketing di Anthropic lo scorso aprile, saremmo stati tutti qui a piangere sul web mentre un super-modello chiamato Mythos smantellava le fondamenta di internet pezzo dopo pezzo. Il racconto era degno di un film di Christopher Nolan: un’IA così pericolosa da dover essere tenuta sotto chiave, distribuita solo a pochi privilegiati per permettere alle grandi corporation di riparare i danni prima del grande ‘day zero’. E invece? Beh, invece la realtà è stata molto più… umana. Recentemente il lead developer di curl ha condiviso come è andata andata la scansione del leggendario tool di trasferimento dati tramite questo presunto mostro di intelligenza artificiale. Il risultato? Un solo, singolo, solitario bug. Sì, avete letto bene. One. Single. Vulnerability. La storia dietro il tutto è un mix di burocrazia e ‘hype-driven development’. Il team di curl, nel bene o nel male, ha ottenuto l’accesso tramite la Linux Foundation, ma tra contratti da firmare, ritardi burocratici e procedure di sicurezza, l’accesso diretto al modello è rimasto un miraggio. Alla fine, qualcuno con l’accesso ha fatto girare lo scan per loro e ha mandato il report. Niente avventure epiche con prompt complessi, solo un classico processo di analisi automatizzata. Da smanettone, la cosa mi fa sorridere. Siamo abituati a vedere queste narrazioni da ‘AI-doomsday’ che servono solo a gonfiare il valore delle startup durante i round di finanziamento. Il vero valore non sta nel modello che ‘scopre il codice proibito’, ma nell’integrazione di questi strumenti nel workflow quotidiano. Il team di curl usa già AISLE, Zeropath e persino i bot di GitHub per le code review. E la cosa interessante è che questi tool stanno aiutando a far emergere centinaia di bugfix e CVE che rendono il codice più solido. Non è l’AI che ci sostituisce, è l’AI che agisce come un liniment ultra-potenziato per i nostri processi di testing. Per noi che amiamo smontare le cose, il messaggio è chiaro: l’automazione è un alleato, non un invasore. Se un tool riesce a trovare una vulnerabilità in un progetto massiccio e ultra-controllato come curl, significa che il nostro lavoro di debugging e testing sta diventando più intelligente, non meno necessario. Non serve un’IA apocalittica per essere sicuri; serve una buona pipeline di CI/CD, fuzzing serio e la voglia di non dormire la notte finché quel bug non è patchato. Quindi, potete smettere di preoccuparvi che Mythos cancelli la vostra esistente libreria Python preferita. Per ora, l’unica cosa che l’IA ha distrutto è la nostra illusione che l’hype tecnologico corrisponda sempre a una minaccia reale. Torniamo pure ai nostri script, ai nostri progetti in Blender e alle nostre macchine CNC. Il futuro è ancora scritto (e debuggato) da noi. Source: Mythos Finds a Curl Vulnerability
webnewsArtificial Intelligencecybersecurityopen sourcesoftware engineering
🇮🇹 · /root · Lamberto Tedaldi
Costruire un universo fantasy che regga il confronto con la realtà richiede molta più potenza di calcolo di quanto uno script Python per il web scraping possa mai sperare di ottenere. Recentemente, Bryan Cogman — uno dei writer che ha contribuito a dare forma al caos di Game of Erroneous Logic (vabbè, Game of Thrones) — ha deciso di fare un po’ di storytelling retroattivo, raccontando le sfide iniziali della produzione. In pratica, quello che oggi vediamo come un capolavoro di world-building, all’inizio era un gigantesco progetto in fase di beta-testing, pieno di glitch, incertezze e problemi di scalabilità. Cogman ha ricordato come l’entusiasmo di far parte di qualcosa di così enorme fosse bilanciato dalla consapevolezza di trovarsi davanti a una sfida di scrittura e produzione che rasentava l’impossibile. Non era solo questione di scrivere dialoghi fighi, ma di gestire una complessità narrativa che avrebbe fatto crashare anche un server cluster di ultima generazione. Per noi che passiamo le notti a cercare di far comunicare un modulo ESP32 con un sensore che ha un firmware scritto male, questa notizia risuona in modo particolare. Spesso ci incaponiamo a cercare la perfezione nel primo commit, dimenticando che l’importante è che il prototipo giri. La serie è partita con una serie di criticità strutturali che sono state risolte man mano, proprio come quando stiamo debuggando un modello 3D su Blender che, a ogni render, sembra decidere di esplodere in un ammasso di poligoni senza senso. C’è un lato estremamente ispiratore nel vedere come un’idea apparentemente ingestibile sia riuscita a scalare fino a diventare un fenomeno globale. Mi ricorda le mie sessioni di coding su Godot: parti con un idea stupida, il codice è un pasticcio di spaghetti, ma se continui a iterare, a rifattorizzare e a non arrenderti davanti ai crash, alla fine esce fuori qualcosa che funziona. Ovviamente, non tutto è oro quel che luccica. Il rischio, quando si lavora a progetti di questa scala, è che la complessità diventi il nemico numero uno, portando a quelle decisioni narrative (o progettuali) che sembrano fatte solo per alimentare l’hype o rispondere a logiche di mercato, perdendo la purezza dell’idea originale. Ma per quanto riguarda l’inizio, il messaggio è chiaro: non aver paura del caos iniziale. Se riesci a gestire il debugging dei primi episodi della tua vita (o del tuo progetto), potresti finire per costruire un impero. Source: A Game of Thrones Writer Reveals the Show’s Early Challenges
webnewsdev-lifepop cultureStorytellingworld-building
🇮🇹 · /root · Lamberto Tedaldi
L’intelligenza artificiale scrive codice velocemente. Forse troppo velocemente. C’è una strana euforia nel premere ‘Tab’ su un suggerimento di GitHub Copilot e vedere apparire una funzione complessa in tre secondi. Sembra magia, quasi un superpotere. Ma c’è un problema che sta emergendo nelle pieghe di questa rivoluzione: stiamo diventando bravissimi a generare codice che funziona, ma stiamo perdendo la capacità di capire perché quel codice sia scritto in quel modo. Recentemente, analizzando le dinamiche di sviluppo moderno, è emerso un pattern inquietante che potremmo definire ‘l’illusione dell’efficienza’. Usare l’AI per risolvere un problema immediato è fantastico. Usarla per generare intere architetture senza una comprensione profonda delle implicazioni a lungo termine è un suicidio tecnico. Il rischio non è che l’AI faccia errori logici — quelli li becchiamo comunque — ma che crei una massa di codice ‘accettabile’ che aumenta il debito tecnico in modo esponenziale, rendendo il refactoring un incubo impossibile. Il vero pericolo non è il bug che rompe il sistema, ma il codice che non rompe nulla, ma che è strutturalmente fragile, privo di contesto e, soprattutto, privo di intenzionalità. Quando scriviamo noi, ogni riga ha un perché. Quando scrive l’AI, ogni riga ha solo una probabilità statistica di essere corretta. Per chi lavora nel settore, la sfida non è più ‘come scrivere questa funzione’, ma ‘come validare questa struttura’. Dobbiamo spostare il nostro focus dal ruolo di ‘scrittori di codice’ a quello di ‘revisori critici’. Se non impariamo a imporre regole ferree, a definire architetture rigide e a usare l’AI solo come un assistente e non come un architetto, ci ritroveremo a gestire sistemi che nessuno sa veramente come funzionano. In un mondo dove generare boilerplate è diventato gratis, il vero valore risiede nella capacità di mantenere la coerenza, la manutenibilità e l’intenzionalità del software. Non lasciate che la velocità di generazione oscuri la profondità della progettazione. La velocità senza direzione è solo un modo più rapido per andare fuori strada. Source: I'm going back to writing code by hand
webnewsaiproductivityprogrammingsoftware engineering
🇮🇹 · /root · Lamberto Tedaldi
Esiste un momento preciso, tra un debug infinito e un tentativo fallito di far girare un vecchio kernel su un Raspberry Pi, in cui capisci che l’universo ha deciso di prenderti di mira. Se state cercando un titolo che faccia scena, beh, l’identificativo parla chiaro: CVE-2024-YIKES. Non è solo un codice di sicurezza, è una dichiarazione di intenti. È quel tipo di incidente che quando lo leggi su Hacker News ti fa venire voglia di staccare tutto, andare in garage e dedicarti esclusivamente alla costruzione di una stampante 3D che trasforma i rifiuti in troll di plastica, lontano da ogni connessione internet. Quello che è successo è quello che io chiamo «una serie di eventi sfortunati». Non è stato un singolo exploit chirurgico, quasi elegante, che entra in un sistema e fa il suo lavoro silenzioso. No, questa è stata una catena di disastri che ha preso colpi da commedia degli equivoci, ma con conseguenze decisamente meno divertenti. Siamo di fronte a una vulnerabilità che sembra uscita da un manuale di ‘come mandare in crash tutto il sistema partendo da una virgola fuori posto’. Da smanettone, la prima cosa che penso è: ‘Chi ha approvato questa merge request?’. Vedere una vulnerabilità con un nome così… drammatico… mi suggerisce che il carico di lavoro sui team di sicurezza sia diventato insostenibile. Quando gli incidenti iniziano a somigliare a un crescendo di note sgradevoli, significa che la complessità del software moderno sta superando la nostra capacità di comprenderla. È l’iper-connettività che ci punisce. Per noi che amiamo mettere le mani in pasta, questo è un promemoria brutale. Che stiate scrivendo uno shader in Godot, modellando un componente in Blender o configurando un controller CNC custom, il codice che usiamo — e le librerie che importiamo senza leggere il changelog — è il nostro punto debole. La sicurezza non è solo un problema dei server di Amazon o Google; è anche ciò che permette al tuo script Python di non diventare un gateway per un botnet. La lezione qui non è smettere di innovare, ma tornare alle basi. Meno dipendenze inutili, meno ‘black box’ che non sappiamo cosa facciano sotto il cofano, e un pizzico più di sana diffidenza verso ogni aggiornamento che promette di ‘migliorare la stabilità’ ma nasconde solo nuovi layer di astrazione inutili. Insomma, patchate tutto, controllate i vostri log e, se potete, tenete i vostri progetti più critici in modalità offline. Altrimenti, il prossimo ‘YIKES’ potrebbe essere proprio il vostro. Source: Incident Report: CVE-2024-YIKES
webnewsCoding Lifecybersecurityhackinginfosec