🇮🇹 · /root · Lamberto Tedaldi
Quanto pensate che costi gestire il sistema di punteggio di una pista da bowling? Se la risposta è ‘una cifra che mi fa piangere’, siete sulla strada giusta. Recentemente è emersa una storia che è pura poesia per chiunque abbia mai provato il disgusto di dover pagare un abbonamento o una licenza per usare un pezzo di ferro che possiede già. Un ingegnere SRE (Site Reliability Engineer, per chi non mastica abbastanza termini da infrastruttura) si è ritrovato con in mano un vecchio bowling center abbandonato nel Midwest americano. Il problema? Il sistema di gestione, installato nel 2008, era un mostro di complessità inutile e costi folli. Parliamo di preventivi da 120.000 dollari per sostituire un hardware che, in fin dei conti, deve solo far scattare dei relè per far muovere macchine meccaniche vecchie di settant’anni. Praticamente, un sistema high-tech che serve solo a dare un input digitale a un interruttore analogico. Uno spreco di silicio che farebbe inorridire qualsiasi hacker. Invece di accollarsi il debito e sottomettersi ai diktat dei fornitori ufficiali, il nostro eroe ha deciso di fare quello che sappiamo fare tutti: smontare, capire e ricostruire con componenti che trovi anche nel cassetto dei telecomandi rotti. Il risultato? OpenLaneLink. Un sistema basato su ESP32 che costa circa 200 dollari per coppia di piste. Parliamo di un risparmio che potresti usare per comprarti un set di Raspberry Pi e sopravvivere a tre blackout. La struttura è una figata tecnica: una topologia a stella usando il protocollo ESP-NOW (per comunicare senza troppi fronzoli) con un fallback in RS485 per quando l’ambiente radio diventa troppo rumoroso. Il cuore pulsante è un gateway Raspberry Pi che gestisce tutto tramite Redis, trasformando eventi grezzi in un flusso di dati che può essere visualizzato con qualsiasi UI moderna, magari in React, usando WebSocket per aggiornamenti in tempo reale. Non c’è bisogno di chiamare un tecnico specializzato in costume e cravatta che ti chiede 4.000 dollari per un pezzo di ricambio. Se un nodo muore, ne prendi un altro dal cassetto, lo flashi e in dieci minuti la pista è di nuovo operativa. E la cosa più bella? Niente temi predefiniti e noiosi. Se vuoi una serata a tema Tron con estetica neon e neomorfismo, puoi farlo. Sei tu il padrone del tuo codice, della tua hardware e dei tuoi dati. In un mondo dove tutto sembra essere progettato per renderci dipendenti da un cloud proprietario o da contratti di manutenzione assurdi, vedere qualcuno che usa la Computer Vision e i microcontrollori per riprendersi la propria autonomia è la dose di dopamina di cui avevamo bisogno. Questo è il vero spirito maker: non serve reinventare la ruota, basta rendere la ruota accessibile, riparabile e, soprattutto, libera. Source: Show HN: I replaced a $120k bowling center system with $1,600 in ESP32s
webnewsdiyEspressifHardwareHackingmaker
🇮🇹 · /root · Lamberto Tedaldi
Se avete mai partecipato a un meeting di gruppo — che sia un progetto open source o una riunione di condominio — sapete esattamente di cosa parlo. Il sistema è in crash, il database sta perdendo integrità e il team di sicurezza sta cercando di capire come non far esplodere tutto, ma la discussione principale si è bloccata su una domanda vitale: «Il blu del tasto ‘Invia’ deve essere un azzurro cielo o un blu navy?» Questo fenomeno ha un nome ufficiale, ed è lo ‘Bikeshedding’ (o ‘Law of Triviality’). L’idea è semplice e terribilmente frustrante: le persone tendono a dare un’importanza spropositata a dettagli insignificanti solo perché sono facili da capire. È molto più semplice discutere del colore di un capanno per le biciclette che progettare il motore di una supercar. Il primo richiede opinioni, il secondo richiede competenze ingegneristiche che la maggior parte dei presenti non ha. Recentemente, un articolo su ACM ha riportato un riflesso su questo concetto, e non potevo non scriverci qualcosa. Perché, ammettiamolo, è la piaga che uccide la produttività di ogni maker o dev. In una community di appassionati, dove tutti hanno un’opinione (e spesso un kernel customizzato per dimostrarlo), il rischio di finire in un loop infinito di discussioni su dettagli estetici o wayland vs x11 è altissimo. Il problema non è la discussione in sé, ma lo spostamento del focus. Quando la discussione su una ‘triviality’ prende il sopravvento, stiamo smettendo di costruire e stiamo iniziando a fare solo rumore. È quel momento in cui l’energia creativa viene sprecata in un vuoto pneumatico di decisioni che, in fondo, non cambieranno minimamente il funzionamento del software o dell’hardware che stiamo creando. Certo, parlando di contesto, questa è una dinamica universale e non riguarda solo le policy legislative straniere o i grandi colossi della Silicon Valley. È una questione di mindset. Che stiate scrivendo una macro in Python o montando un modulo ESP32, l’obiettivo è far funzionare le cose. Se passiamo tutto il tempo a decidere se la scocca del nostro progetto debba essere nera o grigio antracite, non avremo mai un prototipo funzionante da mostrare. Quindi, la prossima volta che vi ritrovate intrappolati in un thread di GitHub che dura da tre settimane solo per decidere la nomenclatura di una variabile poco importante, ricordatevi: state solo discutendo del colore del capanno. E forse, è il caso di chiudere il laptop e tornare a scrivere codice che faccia davvero la differenza. Source: Goodbye, and Thanks for All the Bikesheds
webnewsdecision makingmaker cultureproductivitysoftware-development
🇮🇹 · /root · Lamberto Tedaldi
Immaginate di dover spiegare a un amico che per far girare un semplice script non serve un supercomputer della NASA, ma solo un po’ di buona volontà e zero overhead inutile. Ecco, l’autore di Handy ha avuto esattamente questo pensiero, e invece di lamentarsi solo sui forum, ha deciso di scriverci una libreria. Parliamo di transcribe.cpp. Se seguite il mondo dell’AI locale, sapete bene quanto possa essere un incubo gestire l’inferenza speech-to-text su diverse piattaforme. Al momento, o vi attaccate a whisper.cpp o provate a usare ONNX, sperando che i driver non facciano i capricci e che la performance non sia quella di un vecchio Commodore 64. La situazione attuale è un po’ come cercare di montare un set della LEGO usando pezzi di un castello della Disney e di un kit della Technic: funziona, ma è un delirio di compatibilità e manutenzione. L’idea dietro transcribe.cpp è pura filosofia maker: risolvere un problema che ti sta facendo impazzire mentre sviluppi il tuo progetto. L’autore ha creato una libreria basata su ggml che supporta oltre 60 modelli di diverse famiglie ASR. La cosa veramente figa? Non è solo un altro wrapper che promette mari e monti. Qui c’è stata una validazione numerica e test WER (Word Error Rate) sistematica per garantire che l’output sia identico alla reference implementation. Niente allucinazioni improvvise perché il modello ha deciso di interpretare la vostra voce come un ronzio di zanzara. E per quanto riguarda la potenza di calcolo? Accelera su tutto quello che è decente: Vulkan, Metal, CUDA e persino TinyBLAS. L’obiettivo è rendere l’inferenza locale così accessibile che persino un chip anemico come quello di un RK356 approcci il tempo reale senza esplodere. È la risposta definitiva a quel modello di sviluppo dove tutto deve finire in un server remoto, processato da algoritmi proprietari che mangiano i vostri dati a colazione. La libreria è in versione v0.1.0, quindi sì, ci sono ancora qualche spigolo vivo da smussare (come ogni software che non è stato scritto da un comitato di marketing di una Big Tech). Però, con binding ufficiali per Python, JS/TS, Rust e ObjC/Swift, sembra che l’autore abbia pensato seriamente a chi, come noi, deve integrare queste tecnologie in app desktop o mobile senza dover riscrivere metà del kernel. In breve: se volete far girare la trascrizione vocale sul vostro laptop, sul vostro Raspberry o sul vostro smartphone senza dover chiedere il permesso a nessun server in California, tenetevi d’occhio questo repository. È il classico esempio di software che nasce dal bisogno reale di chi sporca le mani con il codice, lontano dai megafoni dell’hype aziendale. Source: Transcribe.cpp
webnewsArtificial IntelligenceCLocal Inferenceopen source
🇮🇹 · /root · Lamberto Tedaldi
Se cercate un tutorial su come configurare un server Docker o come ottimizzare uno script Python, avete sbagliato blog. Se invece volete sapere come manipolare elementi chimici per creare un piccolo inferno elettrico in un contenitore di vetro, siete nel posto giusto. Styropyro, il re indiscusso dei progetti che farebbero venire un infarto a qualsiasi consulente sulla sicurezza sul lavoro, ha appena fatto quello che fa lui: ha creato un fulmine in una bottiglia. E no, non parlo di una metafora poetica per descrivere un’idea brillante, parlo di scariche elettriche reali, intrappolate tra mercurio e neon. Per i non addetti ai lavori (o per quelli che non hanno passato troppe ore su Wikipedia), l’idea è folle. L’utilizzo del mercurio non è solo una scelta estetica da cattivo di un film di supereroi, ma serve a creare un ambiente altamente conduttivo e reattivo. Quando si combinano le proprietà del neon con l’instabilità del mercurio sotto alta tensione, il risultato è una scarica plasmatica che sembra uscita direttamente da un laboratorio di un mad scientist di serie B. C’è una differenza enorme tra l’hype vuoto che leggiamo ogni giorno nelle news sui nuovi gadget software, che spesso sono solo wrapper pesanti di qualche API già esistente, e la realtà cruda della fisica sperimentale. Qui non c’è nessun marketing team che cerca di convincerti che ‘questo prodotto cambierà il tuo workflow’. C’è solo pura, incontrollabile energia. È il tipo di hardware che non puoi aggiornare con una patch OTA e che, se sbagli il calcolo, non ti manda solo in crash il kernel, ma ti rideduce il laboratorio a un mucchio di macerie. Certo, guardando la cosa da una prospettiva puramente europea, la prima cosa che ti viene in mente è: «Ma come ha fatto a non farsi chiudere il canale dopo tre secondi?». Qui in Italia, tra norme di sicurezza e burocrazia, un esperimento del genere finirebbe probabilmente con un sopralluogo dei Vigili del Fuoco prima ancora che il neon abbia iniziato a brillare. Detto questo, c’è qualcosa di profondamente stimolante nel vedere la tecnologia usata per esplorare i limiti della materia, lontano dalle logiche di profitto e dai sistemi chiusi che cercano di controllarci ogni singolo bit. Se la fisica permette di fare una cosa così folle, perché non provarci? (Ovviamente, non fatelo in garage, non voglio leggere commenti su Reddit che piangono per colpa vostra). Source: Watch a Mad Scientist YouTuber Make Lightning in a Bottle From Mercury and Neon
webnewsdiyEngineeringmad sciencephysics
🇮🇹 · /root · Lamberto Tedaldi
Mentre il resto del mondo è troppo impegnato a discutere se l’IA ci ruberà il lavoro o se finirà per scrivere poesie mediocri su TikTok, sotto il radar sta succedendo qualcosa che merita un fermo immagine. Alibaba ha appena lanciato un piccolo avviso che ha fatto saltare sulla sedia i soliti sospetti del settore: Qwen3.8 è in arrivo e, cosa fondamentale, sarà rilasciato in modalità ‘open-weight’. Per chi non mastica abbastanza codice o vive in una bolla di benessere digitale, significa che non saremo costretti a mandare ogni singola query a un server proprietario in qualche data center blindato, ma potremo (teoricamente) far girare un modello serio anche sui nostri setup locali, o almeno su qualcosa di più dignitoso di un vecchio laptop da ufficio. Ma non fatevi illusioni da fanboy sfegatato: ‘open-weight’ non significa ‘open source’ nel senso più puro e anarchico del termine. Non avremo accesso a ogni singolo dettaglio del dataset di addestramento o alla ricetta segreta della cucina di Alibaba. È un po’ come ricevere una torta pre-cotta: puoi decorarla, puoi modificarne la glassa e puoi farla girare in casa tua, ma non sai esattamente quanto sale ci hanno messo nell’impasto originale. Però, rispetto al modello ‘black box’ dei big tech americani, dove tutto è chiuso, criptato e protetto da muri di legale che nemmeno l’Agent Smith riuscirebbe a scalare, avere i pesi a disposizione è una vittoria enorme. Per noi che amiamo smanettare, testare limiti e cercare di capire cosa succede quando pushiamo i parametri al limite, questa è la benzina che ci serve. Potremo fare fine-tuning, sperimentare con nuove architetture e, soprattutto, mantenere una certa sovranità digitale. Non importa se la decisione viene presa a Shanghai o a San Francisco; l’importante è che il modello non sia una scatola nera su cui non abbiamo alcun controllo. Certo, restano i dubbi geopolitici e le questioni di privacy che, sebbene lontane dai nostri salotti italiani, influenzano comunque l’ecosistema globale in cui ci muoviamo. Ma per ora, lasciamo stare le discussioni macroeconomiche e concentriamoci sulla cosa divertente: la possibilità di avere un mostro di potenza computazionale pronto per essere smontato e rimontato sul proprio hardware. Preparate i driver e pulite i file di log, perché la sfida sta per diventare interessante. Source: Qwen3.8 is launching and going open-weight soon
webnewsArtificial Intelligencemachine learningopen sourceQwen
🇮🇹 · /root · Lamberto Tedaldi
Costruire qualcosa di tecnicamente perfetto è una droga, lo sappiamo tutti. Passiamo notti intere a rifinire quel kernel custom, a ottimizzare ogni singolo microservizio o a far girare un’istanza locale di un LLM che consuma più RAM di quanto ne abbia il mio vecchio laptop. Ma c’è un problema: il mondo reale non è un ambiente di staging isolato e protetto da firewall. Il titolo dell’articolo che ho beccato su Hacker News, «If You Build It, They Will Come», è una citazione classica che sembra uscita da un film cult, ma che nel panorama tech moderno è diventata una mezza maledizione. L’idea è che se crei un prodotto tecnicamente impeccabile, una soluzione elegante e funzionale, gli utenti arriveranno da soli, attratti dalla pura qualità del codice. Spoiler: non succede. Quasi mai. C’è questa tendenza, molto comune tra noi maker e sviluppatori, a ignorare completamente il lato ‘sociale’ e di distribuzione della tecnologia. Ci concentriamo sul risolvere un problema tecnico — magari un’integrazione super complessa o un’architettura distribuita che fa impazzire i grafici — e pensiamo che la genialità dell’algoritmo basti a farci svoltare. In realtà, se non spieghi perché quel tool serve a qualcuno, rimarrai a parlare da solo nel tuo terminale. Certo, parlando di realtà diverse dalla nostra, questo discorso prende una piega particolare quando guardiamo alle dinamiche americane. Lì il hype è un’industria a sé stante: basta un tweet di un guru della Silicon Valley per far esplodere una repo GitHub. Da noi, in Italia, la situazione è un po’ più… stoica. Spesso le innovazioni più interessanti nascono in garage o piccoli laboratori, ma faticano a uscire dal guscio perché mancano proprio quegli ingranaggi di marketing che trasformano un esperimento in uno standard. Il rischio di questo approccio ‘purista’ è finire intrappolati in una bolla di perfezionismo tecnico. Creiamo tool incredibili che però sono impossibili da configurare o che richiedono una laurea in fisica nucleare solo per l’installazione delle dipendenze. È un peccato, perché la tecnologia open source e le community di hacker sono il cuore pulsante del progresso, ma se non riusciamo a comunicare il valore di ciò che costruiamo, restiamo solo dei geni nell’ombra. Quindi, la prossima volta che state scrivendo quel modulo che cambierà il mondo, ricordatevi di non dimenticare la documentazione e, soprattutto, di far sapere agli altri che esiste. Perché un software perfetto che nessuno usa è solo un bellissimo esercizio di scrittura di codice, ma non è una rivoluzione. Source: If You Build It, They Will Come
webnewsopen sourceproductivitysoftware-developmentTech Culture
🇮🇹 · /root · Lamberto Tedaldi
C’è qualcosa di profondamente rassicurante nel vedere il mondo che si sposta verso Rust senza fare troppo rumore. Non servono conferenze stampa con fuochi d’artificio o annunci di marketing che promettono di rivoluzionare l’universo: basta un aggiornamento silenzioso che, sotto il cofano, cambia la sostanza delle cose. La notizia che sta girando tra i vari repository è che Claude Code (sì, l’interfaccia CLI di Anthropic per scovare bug e scrivere codice) sta già sfruttando la nuova versione di Bun scritta in Rust. Jarred Sumner, quello che sta facendo il lavoro sporco per riscrivere Bun, l’ha detto chiaramente: i benefici sono minimi, tipo un 10% di startup più veloce su Linux, ma «boring is good». E ha ragione. Se il mio tool preferito non crasha e non cambia il modo in cui interagisco con lui, va benissimo così. Non siamo qui per lo spettacolo, siamo qui per far girare i processi. Simon Willison, che ha l’occhio clinico di un detective della cybersecurity, ha deciso di fare un po’ di forensics sulla sua installazione di Claude Code. Usando un semplice `strings` sul binario, ha trovato prove schiaccianti: una versione di Bun v1.4.0 che non è ancora presente nelle release ufficiali, ma che vive nel mondo ‘canary’. Ma la vera prova del nove è stata cercare i file sorgente: ha trovato un elenco di oltre 500 file con estensione `.rs`. Boom. Rust è dentro. Per noi che passiamo le giornate tra terminali e script, questo è il tipo di hype che non ci rovina la giornata. Non è la solita promessa di marketing di una Big Tech che vuole venderti un abbonamento mensile per dirti che la loro AI ‘capisce le tue emozioni’. È pura ingegneria. È qualcuno che decide che un componente crit much deve essere più solido, più veloce e più sicuro. Ovviamente, per noi che viviamo tra i kernel Linux e le distro custom, queste notizie non cambiano la vita quotidiana. Non è come una nuova legge sulla privacy europea che ci costringe a riscrivere i termini di servizio. È solo tecnologia che evolve nel modo corretto. Il fatto che Claude Code stia già usando versioni ‘preview’ o ‘canary’ di Bun ci ricorda però che, anche se amiamo la stabilità, siamo tutti parte di un ecosistema che non dorme mai. Quindi, se vedete che il vostro terminale risponde con un millisecondo di latenza in meno, non fatevi illusioni: è solo Rust che fa il suo lavoro nell’ombra. E onestamente? Preferirei che rimanesse tutto così sottovoce. Source: Claude Code uses Bun written in Rust now
webnewsBunClaudeCoderustSoftwareEngineering
🇮🇹 · /root · Lamberto Tedaldi
Dimenticate i film di Hollywood dove un hacker con un cappuccio e una luce verde sul volto digita freneticamente su una tastiera meccanica per scardinare i firewall del Pentagono. La realtà è molto più banale, decisamente meno ‘cool’ e, onestamente, anche più fastidiosa. L’ultima notizia che arriva dai circuiti dell’intelligence russa ci dice che anche i gruppi di hacker più ‘élite’ stanno scendendo di livello (o forse stanno solo scoprendo che la pigrizia paga) utilizzando il Clickfix. Se non avete mai sentito questo termine, non preoccupatevi: non è un nuovo framework di sviluppo o una distro Linux rivoluzionaria. È una tecnica di social engineering che punta tutto sulla manipolazione psicologica e su quella tipica fretta che ci assale quando un pop-up ci dice che ‘qualcosa non va’. Il meccanismo è di una semplicità irritante. Invece di cercare vulnerabilità zero-day complesse che richiedono mesi di ricerca e budget infiniti, questi soggetti utilizzano finte finestre di errore o messaggi di sistema che sembrano legittimi. Il trucco? Ti convincono che devi eseguire un comando specifico, magari incollando qualcosa nel terminale o cliccando su un pulsante per ‘riparare’ il browser. Una volta che l’utente (spesso distratto o troppo fiducioso) esegue l’azione, il payload viene installato e il gioco è fatto. È un approccio che abbiamo visto spesso in ambito criminale per scopi puramente finanziari, ma l’aspetto inquietante è l’adozione da parte di attori che dovrebbero avere standard molto più alti. È come se vedessimo un Master Chef che, invece di preparare un soufflé perfetto, decidesse di servire una pizza surgelata perché tanto la gente la mangia comunque. Per noi che mastichiamo codice e passiamo la vita tra terminali e script, la lezione è chiara: la sicurezza non è solo questione di patch e kernel aggiornati, ma di quanto siamo capaci di resistere alla tentazione di ‘cliccare su tutto’ sperando che si risolva da solo. Non importa quanto sia blindata la vostra infrastruttura se l’anello debole è un utente che segue istruzioni scritte in un pop-up sospetto. In Italia, come nel resto del mondo, siamo bersagli facili proprio perché spesso sottovalutiamo questi attacchi ‘low-tech’. Non serve un supercomputer per essere infettati, basta un po’ di poca attenzione e una finestra di dialogo che sembra troppo autorevole. Quindi, per una volta, tenete le mani lontane dai comandi che vi vengono suggeriti da siti web dubbi. La prossima volta che un pop-up vi dice che il vostro browser è rotto, ignoratelo e andate a farvi un caffè. È molto più sicuro. Source: Now, even Russia's most elite hackers are using Clickfix to infect devices
webnewscybersecurityhackinginfosecmalware