Il Giudice federale degli Stati Uniti ha temporaneamente limitato l’accesso da parte dei dipendenti del Dipartimento per l’efficienza governativa (DOGE), guidato da Elon Musk, ai sistemi di pagamento del Dipartimento del Tesoro degli Stati Uniti. La decisione è stata presa dopo una causa intentata da 19 stati, per lo più a guida democratica, che sollevava preoccupazioni circa un possibile accesso non autorizzato a informazioni riservate e l’interruzione dei finanziamenti per importanti programmi governativi.

Il fatto

Il giudice Paul Engelmayer ha stabilito che il rischio di esposizione di dati sensibili e la maggiore vulnerabilità agli attacchi informatici giustificano l’adozione di misure di emergenza. Ordinò inoltre la distruzione di qualsiasi informazione che il team di Musk avesse già ottenuto. Ulteriori udienze sul caso sono previste per il 14 febbraio.

In precedenza, il Dipartimento del Tesoro aveva concesso a due dipendenti del DOGE, Tom Krause e Marco Elez, un accesso limitato di “sola lettura” al sistema di pagamento. Tuttavia, a seguito di un procedimento giudiziario, l’accesso è stato temporaneamente sospeso.

Gli sforzi del DOGE per migliorare l’efficienza del governo hanno suscitato preoccupazioni tra i democratici e i gruppi della società civile, secondo cui Musk potrebbe oltrepassare la sua autorità interferendo con le principali agenzie e programmi governativi.

Il procuratore generale dello Stato di New York, Letitia James, che guida una coalizione di stati, ha sostenuto la decisione della corte, sottolineando che nessuno è al di sopra della legge.

Si prevede che ulteriori contenziosi faranno luce sulla legalità delle azioni del DOGE e determineranno la portata della sua influenza sulle entità federali.

Conclusioni

La decisione del giudice federale Paul Engelmayer di limitare temporaneamente l’accesso del Dipartimento per l’efficienza governativa (DOGE) ai sistemi di pagamento del Dipartimento del Tesoro degli Stati Uniti rappresenta un momento cruciale nel dibattito sul ruolo e i limiti dell’influenza privata nelle istituzioni pubbliche. La mossa, motivata da preoccupazioni legate alla sicurezza dei dati e alla possibile interferenza in programmi governativi essenziali, riflette le tensioni tra l’innovazione tecnologica e la necessità di salvaguardare l’integrità delle informazioni sensibili.

Elon Musk, figura polarizzante e spesso al centro di controversie, si trova ancora una volta sotto i riflettori per le sue ambizioni di riformare l’efficienza governativa. Tuttavia, questa vicenda solleva interrogativi più ampi: fino a che punto un’entità privata può intervenire nelle operazioni federali senza compromettere la trasparenza e la sicurezza?

La posizione del procuratore generale Letitia James, che ribadisce come “nessuno sia al di sopra della legge”, sottolinea l’importanza di un controllo rigoroso sull’operato di figure influenti come Musk. Questo caso potrebbe stabilire un precedente significativo, non solo per il DOGE, ma per tutte le future iniziative che cercano di ridefinire il rapporto tra settore pubblico e privato. La posta in gioco è alta: proteggere l’interesse pubblico senza ostacolare l’innovazione è una sfida che richiederà equilibrio e attenzione nei prossimi mesi.

L'articolo Il Giudice Federale Degli Stati Uniti Frena L’Appetito Di Elon Musk Dopo La Causa di 19 Stati Federali proviene da il blog della sicurezza informatica.

Open source software can be fantastic. I run almost exclusively open software, and have for longer than I care to admit. And although I’m not a serious coder by an stretch, I fill out bug reports when I find them, and poke at edge cases to help the people who do the real work.

For 3D modeling, I’ve been bouncing back and forth between OpenSCAD and FreeCAD. OpenSCAD is basic, extensible, and extremely powerful in the way that a programming language is, and consequently it’s reliably bug-free. But it also isn’t exactly user friendly, unless you’re a user who likes to code, in which case it’s marvelous. FreeCAD is much more of a software tool than a programming language, and is a lot more ambitious than OpenSCAD. FreeCAD is also a program in a different stage of development, and given its very broad scope, it has got a lot of bugs.

I kept running into some really serious bugs in a particular function – thickness for what it’s worth – which is known to be glitchy in the FreeCAD community. Indeed, the last time I kicked the tires on thickness, it was almost entirely useless, and there’s been real progress in the past couple years. It works at least sometimes now, on super-simple geometries, and this promise lead me to find out where it still doesn’t work. So I went through the forums to see what I could do to help, and it struck me that some people, mostly those who come to FreeCAD from commercial programs that were essentially finished a decade ago, have different expectations about the state of the software than I do, and are a lot grumpier.

Open source software is working out its bugs in public. Most open source is software in development. It’s growing, and changing, and you can help it grow or just hang on for the ride. Some open-source userland projects are mature enough that they’re pretty much finished, but the vast majority of open-source projects are coding in public and software in progress.

It seems to me that people who expect software to be done already are frustrated by this, and that when we promote super-star open projects like Inkscape or Blender, which are essentially finished, we are doing a disservice to the vast majority of useful, but still in progress applications out there that can get the job done anyway, but might require some workarounds. It’s exactly these projects that need our help and our bug-hunting, but if you go into them with the “finished” mentality, you’re setting yourself up for frustration.

This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!

hackaday.com/2025/02/08/softwa…

Il settore dei robot umanoidi in Cina sta registrando una crescita significativa, con numerose aziende e istituti di ricerca che, alla fine del 2024, hanno presentato importanti progressi nella formazione, produzione e applicazione di questi robot, consolidando il ruolo di primo piano della Cina nelle tecnologie avanzate.

Il Beijing Humanoid Robot Innovation Center ha recentemente lanciato RoboMIND, un insieme di dati normativi per l’intelligenza multi-incarnazione destinato a migliorare l’addestramento dei robot umanoidi. RoboMIND comprende 55.000 traiettorie di dimostrazione reali attraverso quattro incarnazioni, 279 compiti diversi e 61 classi di oggetti distinti, raccolti tramite teleoperazione umana, coprendo la maggior parte degli scenari applicativi in case, fabbriche e uffici.

In termini di produzione, Leju Robotics, con sede a Shenzhen, ha annunciato l’operatività della sua linea di produzione di robot umanoidi a Suzhou, nella provincia di Jiangsu. Attualmente, la linea ha una capacità annua di 200 robot umanoidi, con l’obiettivo di raggiungere la piena capacità produttiva entro cinque anni, per un valore annuo superiore a 300 milioni di yuan (circa 41,1 milioni di dollari).

L’espansione delle applicazioni dei robot umanoidi si estende a vari settori, con le linee di produzione automobilistiche tra le più rapide nell’adozione. UBTECH Robotics ha integrato i propri prodotti nei programmi di formazione di produttori automobilistici come BYD, NIO e Geely. Inoltre, un robot umanoide sviluppato da China Southern Power Grid è stato applicato in contesti di servizi elettrici, dimostrando capacità di comprensione dei compiti, pianificazione autonoma e interazione fluida.

Secondo Hong Shaodun, osservatore del settore, i robot umanoidi sono passati da prototipi di laboratorio a prodotti tangibili, entrando in una fase di maggiore intelligenza e versatilità. La Cina vanta un vantaggio significativo negli scenari di applicazione industriale, accelerando l’iterazione e l’efficienza dei robot umanoidi cinesi.

All’inizio del 2024, sette ministeri cinesi hanno presentato nuove linee guida mirate a realizzare progressi in settori chiave come robot umanoidi, computer quantistici, treni ultra-veloci e reti 6G. Un rapporto rilasciato alla Prima Conferenza Cinese sull’Industria dei Robot Umanoidi prevede che il mercato cinese dei robot umanoidi raggiungerà i 75 miliardi di yuan entro il 2029, rappresentando il 32,7% del totale globale.

L'articolo Robot Umanoidi Made in China: Un Mercato da 75 Miliardi di Yuan Entro il 2029 proviene da il blog della sicurezza informatica.

Generally speaking, writing your own games for retro consoles starts with C code. You’ll need to feed that through a console-specific tool-chain, and there’s certainly going to be some hoops to jump through, but if everything goes as expected, you should end up with a ROM file that can be run in an emulator or played on real hardware if you’ve got the necessary gadgetry to load it.

But NESFab takes things in a slightly different direction. While the code might look like C, it’s actually a language specifically tailored for developing games on the Nintendo Entertainment System (NES). The documentation claims that this targeted language not only compiles into considerably faster 6502 assembly than plain C on GCC or LLVM, but is designed to work around the strengths (and weaknesses) of the NES hardware.

Looking deeper into the example programs and documentation, NESFab offers quite a few quality of life features that should make developing NES games easier. For one thing, there’s integrated asset loading which automatically converts your image files into something the console can understand. One just needs to drop the image file into the source directory, open it in the code with the file function, and the build system will take care of converting it on the fly as the ROM is built. The nuances of bank switching — the organization of code and assets so they fit onto the physical ROM chips on the NES cartridge — are similarly abstracted away.

The obvious downside of NESFab is that, as with something like GB Studio, you’re going to end up putting effort into learning a programming environment that works for just one system. So before you get started, you really need to decide what your goals are. If you’re a diehard NES fan that has no interest in working on other systems, learning a language and build environment specifically geared to that console might make a certain degree of sense. But if you’d like to see your masterpiece running on more than just one system, working in straight C is still going to be your best bet.

hackaday.com/2025/02/08/a-prog…

cdca.it/eni-e-la-cultura-del-g…

ENI «conferma la volontà di perseguire il business del gas. Anche a costo di realizzare infrastrutture “usa e getta”. È il caso clamoroso di Argo-Cassiopea, il gasdotto che intende sfruttare il giacimento di metano tra Gela, Licata e Porto Empedocle. Intende costruire un’infrastruttura sottomarina lunga 60 chilometri davanti a uno dei tratti di costa più ricchi di biodiversità e reperti archeologici dell’intera Sicilia; il periodo di vita utile del giacimento non andrà oltre i 15 anni. Un’infrastruttura “usa e getta” su un ecosistema particolarmente complesso come quello del» Canale di Sicilia e Canale di Malta, «già impattato dalle precedenti attività petrolifere di Eni – che in quel tratto di mare possiede, tra le altre cose, quattro piattaforme e un ex stabilimento petrolchimico»
#stopfossile
#nofossile
#stopfossilfueledclimatechange
#cdca

In days gone by, a common retail hack used by some of the less honorable of our peers was the price tag switcheroo. You’d find some item that you wanted from a store but couldn’t afford, search around a bit for another item with a more reasonable price, and carefully swap the little paper price tags. As long as you didn’t get greedy or have the bad luck of getting a cashier who knew the correct prices, you could get away with it — at least up until the storekeeper wised up and switched to anti-tamper price tags.

For better or for worse, those days are over. The retail point-of-sale (POS) experience has changed dramatically since the time when cashiers punched away at giant cash registers and clerks applied labels to the top of every can of lima beans in a box with a spiffy little gun. The growth and development of POS systems is the subject of [TanRu Nomad]’s expansive video history, and even if you remember the days when a cashier kerchunked your credit card through a machine to take an impression of your card in triplicate, you’ll probably learn something.

The history of POS automation stretches back to the 1870s, perhaps unsurprisingly thanks to the twin vices of alcohol and gambling. The “Incorruptible Cashier” was invented by a saloon keeper tired of his staff ripping him off, and that machine would go on to become the basis of the National Cash Register Corporation, or NCR. That technology would eventually morph into the “totalisator,” an early computer used to calculate bets and payout at horse tracks. In fact, it was Harry Strauss, the founder of American Totalisator, who believed strongly enough in the power of computers to invest $500,000 in a struggling company called EMCC, which went on to build UNIVAC and start the general-purpose computer revolution.

To us, this was one of the key takeaways from this history, and one that we never fully appreciated before. The degree to which the need of retailers to streamline their point-of-sale operations drove the computer industry is remarkable, and the video gives multiple examples of it. The Intel 4004, the world’s first microprocessor, was designed mainly for calculators but also found its way into POS terminals. Those in turn ended up being so successful that Intel came up with the more powerful 8008, the first eight-bit microprocessor. People, too, were important, such as a young Chuck Peddle, who cut his teeth on POS systems and the Motorola 6800 before unleashing the 6502 on the world.

So the next time you’re waving your phone or a chipped credit card at a terminal and getting a sterile “boop” as a reward, spare a thought for all those clunky, chunky systems that paved the way.

youtube.com/embed/mgOLHIqTgm8?…

Thanks to [Ostracus] for the tip.

hackaday.com/2025/02/08/retrot…

Australia ha introdotto il divieto di utilizzare l’app cinese di intelligenza artificiale DeepSeek su tutti i dispositivi governativi. Questa decisione è stata presa dopo aver analizzato le minacce alla sicurezza, correlato all’ampia raccolta di dati e alla possibilità del loro trasferimento in uno Stato estero eludendo le leggi australiane.

Il blocco di DeepSeek in Australia

Secondo la direttiva PSPF 001-2025, le agenzie governative australiane sono tenute a rimuovere completamente DeepSeek dai loro sistemi e dispositivi e a impedirne l’installazione e l’utilizzo futuri. Sono possibili eccezioni solo nei casi legati alla sicurezza nazionale o a obiettivi di polizia e in presenza di rigorose misure di protezione.

L’Australia è diventata il secondo Paese, dopo Taiwan, a vietare ufficialmente DeepSeek. Nel frattempo, un disegno di legge simile è attualmente in corso è in fase di valutazione anche negli USA. Il divieto in Australia nasce dal timore che l’app cinese possa essere utilizzata per accedere a informazioni sensibili ed eseguire ordini extraterritoriali che violano la legge australiana.

Il governo locale sottolinea che la minaccia non deriva solo dall’applicazione stessa, ma anche dalle sue versioni web, dai servizi e da tutti i prodotti correlati a DeepSeek o alle sue affiliate. Inoltre, è stato stabilito l’obbligo di segnalare al Ministero degli Interni il rispetto del divieto.

Il documento specifica che i modelli DeepSeek open source distribuiti su server locali con misure di sicurezza adeguate possono essere utilizzati senza restrizioni. Tuttavia, qualsiasi interazione cloud con DeepSeek o i suoi derivati ​​rimane vietata.

La mossa dell’Australia è in linea con la tendenza globale a un controllo più attento della tecnologia digitale cinese. In precedenza, divieti simili erano stati introdotti in relazione a TikTok, così come i dispositivi cinesi, tra cui Telecamere di sorveglianza E apparecchiature di rete. Questa tendenza evidenzia le persistenti preoccupazioni circa la possibile ingerenza della Cina nella sicurezza informatica dei paesi occidentali.

Le autorità australiane raccomandano che organizzazioni e individui valutino anche i potenziali rischi derivanti dall’utilizzo di DeepSeek. Sebbene il divieto si applichi attualmente solo alle agenzie governative, precauzioni simili potrebbero essere introdotte in seguito anche nel settore privato.

Non è ancora nota la reazione della Cina al divieto, ma è prevedibile che Pechino lo consideri un atto di pressione politica. Nel frattempo, le autorità di sicurezza australiane continuano a esaminare le minacce poste dalla tecnologia estera e potrebbero essere previste ulteriori restrizioni.

Conclusioni

Se la raccolta dati e il trasferimento di informazioni sensibili all’estero sono un problema quando si tratta di aziende cinesi come DeepSeek, perché non dovrebbero esserlo anche per le big tech americane come OpenAI, Google o Microsoft? OpenAI, ad esempio, raccoglie enormi quantità di dati dagli utenti di tutto il mondo, compresi quelli australiani ed europei, e li elabora principalmente negli Stati Uniti.

Dovremmo allora chiederci: la protezione della privacy è davvero una questione di sicurezza nazionale, oppure viene applicata in modo selettivo, colpendo solo chi non è “amico” o allineato geopoliticamente? Se la Cina è vista come una minaccia per la sovranità digitale dell’Australia, perché gli Stati Uniti no?

Alla fine, il concetto di privacy rischia di essere solo una chimera: un principio che vale solo quando fa comodo, mentre nella pratica le informazioni personali vengono concesse a chi è più vicino politicamente ed economicamente. Forse è arrivato il momento di guardare oltre i doppi standard e affrontare la questione in modo equo, indipendentemente dalla bandiera che sventola dietro una tecnologia.

Dopo tutto, visto che OpenAI elabora i dati negli USA, proprio negli USA esiste una legge chiamata Foreign Intelligence Surveillance Act (FISA) and Section 702. E a qualcuno dovrebbe dire qualcosa.

L'articolo Se l’Australia e Gli USA Vietano DeepSeek Perchè i Dati Vanno In Cina, Perchè L’Europa Usa OpenAI? proviene da il blog della sicurezza informatica.

Graphene always sounds exciting, although we aren’t sure what we want to do with it. One of the most promising features of the monolayer carbon structure is that under the right conditions, it can superconduct, and some research into how that works could have big impacts on practical superconductor technology.

Past experiments have shown that very cold stacks of graphene (two or three sheets) can superconduct if the sheets are at very particular angles, but no one really understands why. A researcher at Northeaster and another at Harvard realized they were both confused about the possible mechanism. Together, they have started progressing toward a better description of superconductivity in graphene.

Part of the problem has been that it is hard to make large pieces of multi-layer graphene. By creating two-ply pieces and using special techniques, an international team is finding that quantum geometry explains how graphene superconductors resist changes in current flow more readily than conventional superconductors.

Another team found that adding another layer makes the material behave more like a family of conventional higher-temperature superconductors. The research appears in two different papers. One covers the two-ply material. The other talks about the material with three layers.

Making little bits of graphene isn’t hard. Making it in quantity is a different story. We keep dreaming of what we could do with a room-temperature superconductor.

hackaday.com/2025/02/07/whod-h…

Spese meno di un terzo delle risorse a meno di due anni dal termine del piano, previsto per metà 2026, e tre anni e mezzo dall’approvazione dello stesso, nel luglio 2021.
5,66 miliardi di euro è quanto si dovrebbe spendere, in media, ogni mese da gennaio 2025 fino all’ultima scadenza del piano, nel dicembre 2026. Ciò pone dubbi sulla possibilità di riuscire a rispettare i vincoli di spesa del piano.
La campagna pubblica ha visto protagoniste centinaia di associazioni e organizzazioni della società civile, riunite nelle sigle Dati bene comune e Osservatorio civico PNRR. Il rilascio dei dati da parte del governo è la dimostrazione plastica che la mobilitazione paga.

radioradicale.it/scheda/750830

La società israeliana Paragon Solutions, il cui spyware Graphite è stato utilizzato per colpire almeno 90 persone in due dozzine di Paesi, ha interrotto il suo rapporto con l’Italia. La decisione è stata presa in seguito alle accuse secondo cui il malware sarebbe stato impiegato contro un giornalista investigativo italiano e due attivisti critici. La notizia della rescissione del contratto è stata riportata per prima dal The Guardian, citando una fonte anonima a conoscenza della questione.

Secondo la fonte, il governo italiano avrebbe violato i termini del contratto con Paragon, che vietavano l’uso del software per monitorare giornalisti o membri della società civile. La vicenda ha suscitato un forte dibattito politico in Italia, con l’opposizione che ha chiesto chiarimenti immediati al governo. WhatsApp aveva recentemente avvertito le persone coinvolte che i loro dispositivi erano stati infettati tramite l’invio di documenti PDF malevoli, senza la necessità che gli utenti cliccassero su di essi.

Graphite, lo spyware sviluppato da Paragon, è paragonabile a Pegasus, il noto software di hacking del gruppo NSO. Il malware può infettare un telefono senza che l’utente ne sia a conoscenza, consentendo a chi lo controlla di accedere a dati sensibili, inclusi messaggi e chiamate crittografate su app come WhatsApp e Signal. L’uso di Graphite contro giornalisti e attivisti solleva gravi interrogativi sull’abuso delle tecnologie di sorveglianza da parte dei governi.

Le rivelazioni hanno anche attirato l’attenzione del Parlamento Europeo. Nel frattempo, Francesco Cancellato, direttore di Fanpage, è stato il primo giornalista italiano a dichiarare di aver ricevuto un avviso da WhatsApp sul suo telefono compromesso.

L’uso dello spyware è stato scoperto con l’aiuto del Citizen Lab dell’Università di Toronto, che monitora attacchi contro giornalisti e attivisti. Le indagini hanno rivelato che gli attacchi si sono estesi a diversi Paesi europei, tra cui Belgio, Germania, Spagna e Svezia. Paragon, recentemente acquisita dalla società statunitense AE Industrial Partners, ha anche avuto contratti con l’agenzia federale americana ICE, ma il loro stato attuale rimane incerto.

Mentre Paragon ha rescisso il contratto con l’Italia per motivi etici, rimangono molte domande aperte su chi abbia effettivamente commissionato gli attacchi e su come le tecnologie di sorveglianza vengano impiegate dai governi. L’opposizione ha chiesto un’indagine approfondita, mentre il governo italiano continua a respingere le accuse.

L'articolo Paragon Solutions Rescinde il Contratto con l’Italia Dopo le Rivelazioni su Graphite proviene da il blog della sicurezza informatica.

The many YouTube workshop channels make for compelling viewing. even if their hackiness from a Hackaday viewpoint is sometimes variable. But from time to time up pops something that merits a second look. A case in point is [BUM]’s go-kart made entirely from Harbor Freight parts, a complete but rudimentary vehicle for around 300 dollars. It caught our eye because it shows some potential should anyone wish to try their luck with the same idea as a Power Racer or a Hacky Racer.

The chassis, and much of the running gear comes courtesy of a single purchase, a four-wheeled cart. Some cutting and welding produces a surprisingly useful steering mechanism, and the rear axle comes from a post hole digger. Power comes from the Predator gasoline engine, which seems to be a favourite among these channels.

The result is a basic but serviceable go-kart, though one whose braking system can be described as rudimentary at best. The front wheels are a little weak and require some reinforcement, but we can see in this the basis of greater things. Replacing that engine with a converted alternator or perhaps an electric rickshaw motor from AliExpress and providing it with more trustworthy braking would result in possibly the simplest Hacky Racer, or just a stylish means of gliding round a summer hacker camp.

youtube.com/embed/f89LCrEqDZs?…

hackaday.com/2025/02/07/all-yo…

[Jim Colabro] is a little underwhelmed with the experience of low-level debugging of Linux applications using traditional debuggers such as GDB and LLDB. These programs have been around for a long time, developing alongside Linux and other UNIX-like OSs, and are still solidly in the CLI domain. Fed up with the lack of data structure support and these tools’ staleness and user experience, [Jim] has created UScope, a new debugger written from scratch with no code from the existing projects.

GBD, in particular, has quite a steep learning curve once you dig into its more advanced features. Many people side-step this learning curve by running GDB within Visual Studio or some other modern IDE, but it is still the same old debugger core at the end of the day. [Jim] gripes that existing debuggers don’t support modern data structures commonly used and have poor customizability. It would be nice, for example, to write a little code, and have the debugger render a data structure graphically to aid visualisation of a problem being investigated. We know that GDB at least can be customised with Python to create application-specific pretty printers, but perhaps [Jim] has bigger plans?

Anyway, Uscope currently supports only C and Zig, but work is in progress to add C++ and Go support, with plans for Rust, Odin and Jai. Time will tell whether they can gather enough interest to really drive development to support the more esoteric languages fully. Still, Rust at least has a strong support base, which might help get other people involved. It looks like early doors for this project, so time will tell whether it gets traction. We’ll certainly be keeping an eye on it in the future!

If you wish to play along at home, you’ll want to start with the GitHub page, read on from there, and maybe join this discord.

If you’re new to debugging on Linux, we’ve got a quick guide to GUI frontends to ease you in. If you’re less interested in code and more of a script junkie, here’s how to debug BASH script or even SED.

hackaday.com/2025/02/07/uscope…

Bear with us for a moment for a little background. The Rideau Canal Skateway in Ottawa is the world’s largest natural skating rink, providing nearly 8 km of pristine ice surface during the winter. But maintaining such a large ice surface is a challenge. A regular Zamboni can’t do it; the job is just too big. So the solution is a custom machine called the Froster, conceived by Robert Taillefer and built by Sylvain Fredette.
Froster spans almost twenty meters, and carries almost 4000 L of water. There’s no other practical way to maintain almost 8 km of skating rink.
A patent was filed in 2010, granted by the Canadian Intellectual Property Office, and later lost because important notifications started going to an apparently unchecked spam folder. The annual fee went unpaid, numerous emails went unanswered, an expiry date came and went, and that was that.

It’s true that emailed reminders (the agreed-upon — and only — method of contact) going unnoticed to spam was what caused Robert to not take any action until it was too late. We’d all agree that digital assistants in general need to get smarter, and that includes being better at informing the user about automatically-handled things like spam.

But what truly cost Robert Taillefer his patent was having a single point of failure for something very, very important. The lack of any sort of backup method of communication in case of failure or problem meant that this sad experience was, in a way, a disaster just waiting to happen. At least that’s how the Federal Court saw it when he took his complaint to them, and that’s how they continued to see it when he appealed the decision.

If you’ve never heard of the Rideau Canal Skateway or would like to see the Froster in action, check out this short video from the National Capital Commission of Canada, embedded just under the page break.

youtube.com/embed/-k1-A0DsU-w?…

hackaday.com/2025/02/07/when-i…

As great as silicon is for semiconductor applications, it has one weakness in that using it for lasers isn’t very practical. Never say never though, as it turns out that you can now grow lasers directly on the silicon material. The most optimal material for solid-state lasers in photonics is gallium-arsenide (GaAs), but due to the misalignment of the crystal lattice between the compound (group III-V) semiconductor and silicon (IV) generally separate dies would be produced and (very carefully) aligned or grafted onto the silicon die.

Naturally, it’s far easier and cheaper if a GaAs laser can be grown directly on the silicon die, which is what researchers from IMEC now have done (preprint). Using standard processes and materials, GaAs lasers were grown on industry-standard 300 mm silicon wafers. The trick was to accept the lattice mismatch and instead focus on confining the resulting flaws through a layer of silicon dioxide on top of the wafer. In this layer trenches are created (see top image), which means that when the GaAs is deposited it only contacts the Si inside these grooves, thus limiting the effect of the mismatch and confining it to within these trenches.

There are still a few issues to resolve before this technique can be prepared for mass-production, of course. The produced lasers work at 1,020 nm, which is a shorter wavelength than typically used, and there still some durability issues due to the manufacturing process that have to be addressed.

hackaday.com/2025/02/07/growin…

In studio Deca e Simone, regia Massimo. Ascolteremo Analog Africa, Crystal Phoenix, Jamaican Jazz Orchestra, Distant Relatives e molto altro!! @Radio Unitoo

iyezine.com/frontiere-sonore-r…

Frontiere Sonore Radio Show #13

Frontiere Sonore Radio Show #13 - In studio Deca e Simone, regia Massimo. Ascolteremo Analog Africa, Crystal Phoenix, Jamaican Jazz Orchestra, Distant Relatives e molto altro!! -

^{Simone Benerecetti (In Your Eyes ezine)}

Whenever I play an RPG, whether it’s Fallout or Cyberpunk 2077, I complete every single quest available to me. The quests grab my attention in an unprecedented way – doesn’t hurt that there’s rewards and progression markers attached. Of course, these systems are meticulously designed to grab attention, making sure you can enjoy the entirety of the game’s content.

Does quest progression in an RPG tangibly impact my life? No. Do they have control over my attention? Yes, for sure. My day-to-day existence is the opposite – my real-life decisions impact me significantly, and yet, keeping attention on them is a struggle. Puzzling, disturbing – and curious. I feel like I’ll never forgive myself if I ignore this problem any longer.

So, I wrote a simple quest system prototype. As usual, it worked, it failed, and it taught me things. Here’s how I did it.

Adjusted To Self First

Quick prototyping is a bane of mine, and I’m forced to study it – I can only spend so much time on any given topic before I can barely pay attention to it. So, no fancy UIs, no roadmaps, I’m writing software that has the lowest interaction resistance possible for me specifically.

My laptop remains my platform of choice – I’m no phone app developer, really, I hate developing for smartphones. Modern smartphones are content consumption machines first, everything else second, and it feels like the user’s actual wellbeing is barely in the top 10. Besides, typing on a physical keyboard is the fastest prototyping and hardware interaction method I know. Smartphones no longer have physical keyboards, you know, the focus on content consumption means that screen real estate is king.

Oh, and I do have Notepad++ constantly open on my laptop! What about storing my quests in a text file, say, quests.txt, in a somewhat computer-friendly format? Then, a constantly running program could reads changes from this file, rewriting it when appropriate. Sounds simple enough, and so the parser.py was born.

I had a few wishes for this program. The main one was: never deleting any file contents by mistake or to enforce structure; everything I type into the file is important and can’t be lost. Aside from that, leaving comments on tasks and quests felt paramount, too – the text file isn’t just a data storage, it’s a user interface, and it needs human-friendly features.

At the same time, I needed to make it software-friendly – always parseable and modifiable, letting me do things like automatically marking quest tasks as complete or incomplete, or tying task completion into each other, or auto-marking them, or tying them to real-world events. This resulted in two main features: a rigid-ish structure for quest formatting, and auto-adding machine-parseable quest IDs. Still, I made sure it was easy for me to edit quests and tasks, and put the IDs somewhere they wouldn’t get in the way!

Built, Tweaked, Working

A day-two was spent intensely building parser.py into a self-sufficient prototype, and it grew from 20 lines of parsing code experiment into a full program, left to constantly run in the background monitoring for quests.txt file changes. Then, I split my Notepad++ window into two panes, and put the quests.txt document into one of them, open semi-permanently – thankfully, my laptop screen is wide enough for that.

Easy enough to use day to day, always at my fingertips, collecting data – this script satisfied a few of my human-friendly device design guidelines. I went on making new quests and adding tasks as I remembered them, as well as updating the script itself, adding features and fixing bugs as needed. For brevity, I’ll call this whole process “questing”.

The most useful feature, without a doubt, was auto-sorting quest tasks, so that completed tasks would immediately go to the bottom of the quest’s task list – way easier on the eyes. Another feature was task completion/clear logging, as usual, JSON separated by newlines – which unexpectedly gave me timestamps that helped me remember and track time-sensitive medication.

Some features were less expected but still necessary. I am intimately familiar with data loss, so I wrote a quick quests.txt backup script, and added a daily task for myself – do backups. As luck would have it, I accidentally deleted half of the quests.txt file contents, just as I was about to back it up. So, I had to spend about an hour restoring the file state from the day-old backup file and task log items – those really came in handy!

I’ve used the script for about a month – quite a jump from the “two weeks constant”. A lot of smaller hack-on-self projects stay in my life for two weeks at most – any longer than that, and I struggle to pay attention to them. This one worked for longer – a very good sign. Most importantly, even though I’m currently not using this questing system, I keep mentally coming back to it throughout my days, and my main thought is “wish it worked better for me right now”.

A Focus Point

The best thing about this questing system, I started building habits at a surprisingly fast rate. This was genuinely shocking, in all of the good ways, and seriously reassuring. The questing system helped me find some extra focus – as long as I stayed within the “dailies” quest, that is.
One thing about .txt file as frontend – to have the file be processed, I need to Ctrl+S, alt-tab to other program, alt-tab back, and click “Yes” in this box.
The “Dailies” quest was the only one that actually worked all throughout. As I’ve added quests and tasks, the file grew a ton, currently sitting at 530 lines. Well, my screen fits 40 lines at a time, so most quests stayed always out of reach, easy to forget – just the Dailies quest has 80 lines. There was no ability to highlight tasks I wanted to suggest to myself, or to make a task stand out as more important.

The main limiter this questing system was definitely the UI – the more it grew, the harder it was for me to scroll through the text file and notice the tasks I needed to do. In a way, the system was a good augment, helping me overcome my struggles with Doing All The Things I Want Done, until it grew to the point where it no longer gave me a consistent single point of focus, an always-accessible line in the .txt file that I could look at to spot my daily-tasks-to-do. It’s a predictable limitation of the text file UI, and I could only push it so much.

There was another fun failure mode: the more I used the script, the more I did things in the real world, the less I’d be spending next to my laptop. On days where I wasn’t next to my laptop, the script’s powers would break completely, of course. Basically, the more off-my-laptop tasks I was doing, the less my script would work – so much for helping me exercise, move, and get out more!

“Dailies” were the most fun part of the system, still – as I’m writing this, I’m becoming more and more certain that this UI could work well for me again if I did a few more upgrades to it and limited it to the “Dailies” quest. So, same interface but less overwhelming, a tighter focus, and a few more most-needed ease of use features – feels like I should try that out sometime soon!

Lessons

A lot of fruit lays unpicked on the parser.py field, even with the current text-file UI. Automatically marking all of the “Dailies” tasks completed on a “start of day” trigger, for one! Reminders for medication. Tracking ‘underappreciated’ daily tasks, giving me summaries or notifications that point out ‘daily’ tasks I’ve been neglecting but might still want to do. Quick action keybinds for common actions, just like I do with my anti-crash and anti-distraction scripts, so that I can quickly mark common tasks as completed – without having to unlock my laptop, find the task in the file, and mark it as complete. Graphing of my activity, too, of course it always feels like graphing my data will give some good insights, but it’s not easy for me to do just yet – hopefully it will be easy soon!

No regrets on picking text file as the UI&backend for the initial prototype, though! I’d do it the same all over again – the flexibility has really helped. I even think that a text file format is a great UI for desktop using the quest system – as long as it’s not the backend, so, the quests are actually stored somewhere else. Basically, an editing option, or a human-readable backup format, we could always use more of those.

What about features I could implement given a different UI and backend? More context sensitivity, for one. For example, suggestions on tasks to do depending on how long I’ve been awake, where I am physically right now (home/work/travel/etc), and other context that’s relatively easy to get but still missing. Cross-device task control and sync. Perhaps, the most fun aspect – a “points”/”levels” score keeping system, maybe even with “streak” features!

The concept works, even if it struggles to scale. It needs a better UI, a way more well-suited backend, tighter integration into my day-to-day life, influencing me in a more context-aware and kind way. Quests are good, the current system is good, and it will work better after an upgrade. In particular, you are soon to see a way more suitable and flashy user interface – as always, stay tuned!

The answer is: Elliot Williams, Al Williams, and a dozen or so great hacks. The question? What do you get this week on the Hackaday podcast? This week’s hacks ran from smart ring hacking, to computerized tattoos. Keyboards, PCBs, and bicycles all make appearances, too.

Be sure to try to guess the “What’s that sound?” You could score a cool Hackaday Podcast T.

For the can’t miss this week, Hackaday talks about how to dispose of the body in outer space and when setting your ship’s clock involved watching a ball drop.

html5-player.libsyn.com/embed/…
Where to Follow Hackaday Podcast

Places to follow Hackaday podcasts:

• iTunes
• Spotify
• Stitcher
• RSS
• YouTube
• Check out our Libsyn landing page

Download the MP3 tariff-free.

Episode 307 Show Notes:

News:

• Hackaday Europe 2025 Tickets On Sale, And CFP Extended Until Friday

What’s that Sound?

• Take your shot at our trademark sound challenge!

Interesting Hacks of the Week:

• Hacking The 22€ BLE SR08 Smart Ring With Built-In Display
• Do, Dare Or Don’t? Getting Inked By A 3D Printer
  
  • 3D Printed CNC Wood Burner

  
  

• A Closer Look At The Tanmatsu
  
  • Need A Small Keyboard? Build Your Own!

  
  

• Electroplating DIY PCB Vias At Home Without Chemical Baths
• Bicycle Adds Reliability With Second Chain
  
  • patents.google.com/patent/US11…

  
  

• Custom PCB Is A Poor Man’s Pick And Place
• What Is The Hour? It’s XVII O’ Clock

Quick Hacks:

• Elliot’s Picks
  
  • What Is The Hour? It’s XVII O’ Clock
  • Investigating Electromagnetic Magic In Obsolete Machines
  • Understanding The T12 Style Soldering Iron Tip

  
  

• Al’s Picks:
  
  • The Clever Design Behind Everyday Traffic Poles
  • The Lowest-Effort Way Yet To Make 3D Printed Lenses Clear
  • Communicating With Satellites Like It’s 1957

  
  

Can’t-Miss Articles:

• What Happens If You Die In Space?
• Telling Time Used To Be A Ball

hackaday.com/2025/02/07/hackad…

Il CISA avverte sulla necessità di aggiornare una grave vulnerabilità di Microsoft, che è già sfruttata dagli aggressori in attacchi attivi. L’avvertimento vale in particolar modo per le agenzie federali.

La Vulnerabilità CVE-2024-21413 consente l’esecuzione di codice arbitrario su sistemi remoti, aggirando i meccanismi di sicurezza di Outlook.

L’errore è stato scoperto dai ricercatori di Check Point ed è correlato alla convalida errata degli input durante l’apertura di e-mail con link dannosi nelle versioni vulnerabili di Outlook.

Sfruttando il bug, gli aggressori possono eludere la Visualizzazione protetta, progettata per bloccare i contenuti pericolosi. Ciò fa sì che i file di Office dannosi vengano aperti in modalità modifica, consentendo il download e l’esecuzione di codice dannoso.

Microsoft lo ha risolto il CVE-2024-21413 ma ha avvisato che la vulnerabilità rimane attiva anche in modalità anteprima documento. Il report di Check Point afferma che gli aggressori utilizzano una soluzione alternativa aggiungendo un punto esclamativo e testo casuale dopo l’estensione del file ai link con il protocollo.

Questo approccio consente di aggirare le difese di Outlook e scaricare contenuti dannosi.

Esempio:

CLICK ME

Sono a rischio diverse versioni dei prodotti Microsoft:

• Microsoft Office LTSC 2021;
• App Microsoft 365 per le aziende;
• Microsoft Outlook 2016;
• Microsoft Office 2019.

Lo sfruttamento riuscito della vulnerabilità potrebbe portare al furto delle credenziali NTLM e all’esecuzione di codice arbitrario.

Le agenzie federali devono correggere l’errore entro il 27 febbraio, in conformità con la direttiva BOD 22-01.

Il CISA sottolinea che tali vulnerabilità sono spesso prese di mira dagli hacker e rappresentano una seria minaccia per le infrastrutture governative. Sebbene l’ordinanza si applichi alle agenzie governative, gli esperti raccomandano vivamente a tutte le organizzazioni di installare urgentemente aggiornamenti di sicurezza per prevenire possibili attacchi.

L'articolo Per Un Punto Esclamativo In Più, Outlook Cadde Giù! Grave RCE Avverte il CISA proviene da il blog della sicurezza informatica.