🇮🇹 · /root · Lamberto Tedaldi
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
webnewsdatabaseOpen Source Spiritprivacysql
🇮🇹 · /root · Lamberto Tedaldi
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
webnewsAutomotive HackingcybersecurityExploitHonda
🇮🇹 · /root · Lamberto Tedaldi
Quanto spesso vi è capitato di fissare uno schermo, magari mentre state aspettando che un rendering in Blender finisca o che una stampa 3D arrivi al layer cruciale, e pensare: «Ma che cavolo sta succedendo?» Non parlo di un errore di sistema o di un kernel panic che vi manda in tilt il workflow. Parlo di quelle piccole, subdole incoerenze visive. Quel millisecondo in cui un’animazione di YouTube sembra seguire una fisica alternativa, o quel flash bianco che appare tra una schermata e l’altra in un’app che si spaccia per ‘premium’. Recentemente è uscito un pezzo di riflessione molto interessante (che gira molto su Hacker News) sul concetto di ‘Every Frame Perfect’. Il punto di partenza è quasi filosofico, ma con le radici piantate ben dritte nel protocollo Wayland: l’idea che ogni singolo frame renderizzato debba avere senso. Non importa se è un frame intermedio di una transizione o lo stato finale; se faccio uno screenshot a caso mentre un elemento si muove, quello che vedo deve essere logicamente coerente. Per noi che passiamo le giornate a smanettare con script, hardware custom e motori di gioco come Godot, questo concetto non è solo ‘estetica’. È ingegneria. Quando progettiamo una macchina per riciclare la plastica o configuriamo una CNC, non accettiamo che un movimento sia parzialmente completato o che un sensore legga un dato incoerente. Perché l’interfaccia utente dovrebbe essere diversa? Il problema è che oggi siamo abituati al ‘junk code’ che viene mascherato da animazioni fluide ma inconsistenti. Abbiamo sviluppato una tolleranza pericolosa verso l’imperfezione. Vediamo elementi che si spostano mentre il cursore va in un’altra direzione, o contenuti che ‘saltano’ (il temibile layout shift) mentre la pagina carica. Questo crea una micro-rottura della fiducia. Se il dev non ha curato il frame 12 di un’animazione, come posso fidarmi che abbia curato la gestione della memoria o la sicurezza del modulo di autenticazione? Certo, sappiamo tutti che gestire i DOM o le complessità delle moderne GPU stack è un incubo. A volte la tecnologia ‘batte’ il programmatore, costringendolo a compromessi assurdi. Ma non usiamo la complessità come scusa per l’approssimazione. Che siate esperti di retrocomputing che cercano la precisione del singolo clock o maker che cercano la perfezione millimetrica nel modellamento 3D, il principio deve essere lo stesso: la cura del dettaglio è ciò che separa uno strumento di precisione da un giocattolo rotto. La prossima volta che vedete un’animazione janky, non ignoratela. È il segnale che sotto il cofano, probabilmente, c’è un disastro. Source: Every Frame Perfect
webnewsdev-lifesoftware engineeringTech PhilosophyUI/UX
🇮🇹 · /root · Lamberto Tedaldi
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
webnewsaimaker culturesoftware-developmentTech Trends
🇮🇹 · /root · Lamberto Tedaldi
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
webnewsbiotechdebuggingFuture-Techscience
🇮🇹 · /root · Lamberto Tedaldi
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
webnewsentrepreneurshipphilosophyprogrammingstartup
🇮🇹 · /root · Lamberto Tedaldi
Ancora un altro aggiornamento che arriva senza preavviso, mentre noi siamo qui a cercare di far compilare un vecchio kernel o a capire perché il nostro estrusore della 3D printer ha deciso di fare le bizze proprio oggi. La notizia è passata sotto i radar di Hacker News: è uscito GLM 5.2. Sì, avete letto bene. Un altro numero, un’altra versione, un altro annuncio che promette di rivoluzionare il modo in cui interagiamo con le macchine. Se siete abituati al solito hype che incontriamo nei comunicati stampa delle big tech, probabilmente avrete già voglia di chiudere la scheda di browser e tornare a riga di comando. Cosa cambia davvero? Beh, la descrizione è piuttosto sintetica, il che è tipico di quando i developer vogliono far parlare i benchmark invece di scrivere romanzi. Per noi che passiamo le serate a scriptare automazioni in Python o a cercare di far girare modelli locali senza far esplodere la GPU, la domanda non è «quanto è intelligente», ma «quanto è integrabile e quanto pesa». Se questo GLM 5.2 rimane chiuso in un ecosistema proprietario e ci obbliga a pagare ogni singola chiamata API come se fosse un lusso, allora per me è solo un altro modo per fare vendor lock-in e svuotare il portafoglio. Per chi ama sporcarsi le mani con Godot, creare asset in Blender o programmare piccoli robot custom, la vera sfida è la flessibilità. Un’IA che funziona bene è quella che posso chiamare via script, che posso interrogare per generare frammenti di codice C++ o per aiutarmi a debuggare un file di configurazione di una CNC senza dover caricare tutto su un cloud che legga pure i miei pensieri. Se GLM 5.2 offre una latenza ridotta e una capacità di ragionamento logico più solida, allora ben venga. Se è solo una versione più ‘educata’ e meno capace di gestire logica complessa, è solo rumore di fondo. In sintesa: non fate troppo hype. Aspettiamo di vedere i test reali, quelli fatti da chi non ha interesse a vendere abbonamenti mensili, ma quelli fatti da chi prova a far girare l’IA dentro un workflow di automazione reale. Nel frattempo, io torno a controllare se quel modulo per il riciclo della plastica che sto assemblando ha smesso di fumare. Source: GLM 5.2 Is Out
webnewsaiautomationDeveloperLifeGLM