Intel GPUs on Raspberry Pi Is So Wrong it Feels Right

While you might not know it from their market share, Intel makes some fine GPUs. Putting one in a PC with an AMD processor already feels a bit naughty, but AMD’s x86 processors still ultimately trace their lineage all the way back to Intel’s original 4004. Putting that same Intel GPU into a system with an ARM processor, like a Raspberry Pi, or even better, a RISC V SBC? Why, that seems downright deviant, and absolutely hack-y. [Jeff Geerling] shares our love of the bizarre, and has been working tirelessly to get a solid how-to guide written so we can all flout the laws of god and man together.

According to [Jeff], all of Intel’s GPUs should work, though not yet flawlessly. In terms of 3D acceleration, OpenGL works well, but Vulkan renders are going to get texture artifacts if they get textures at all. The desktop has artifacts, and so do images; see for yourself in the video embedded below. Large language models are restricted to the not-so-large, due to memory addressing issues. ARM and RISC V both handle memory somewhat differently than x86 systems, and apparently the difference matters.

The most surprising thing is that we’re now at a point that you don’t need to recompile the Linux kernel yourself to get this to work. Reconfigure, yes, but not recompile. [6by9] has a custom kernel all ready to go. In testing on his Pi5, [Jeff] did have to manually recompile Mesa, however–unsurprisingly, the version for Raspberry Pi wasn’t built against the iris driver for Intel GPUs, because apparently the Mesa devs are normal.

Compared to AMD cards, which already work quite well, the Intel cards don’t shine on the benchmark, but that wasn’t really the point. The point is expanding the hardware available to SBC users, and perhaps allowing for sensible chuckle at the mis-use of an “Intel Inside” sticker. (Or cackle of glee, depending on your sense of humour. We won’t judge.) [Jeff] is one of the people working at getting these changes upstreamed into the Linux kernel and Raspberry Pi OS, and we wish him well in that endeavour.

Now, normally we wouldn’t encourage a completely unknown fellow like this [Jeff] of whom no one has ever heard of to be poking about in the kernel, but we have a good feeling about this guy. It’s almost as if like he’s been at this a while. That couldn’t be, could it? Surely we’d have noticed him.

youtube.com/embed/ewDJpxQEGo4?…

hackaday.com/2025/11/14/intel-…

Precision Current Sources by the Numbers

It isn’t unusual to expect a precisely regulated voltage in an electronic project, but what about times when you need a precise current? Over on EDN, prolific [Stephen Woodward] explains how to use a precision Zener diode to get good results. [Stephen] takes you through the math for two topologies and another circuit that uses a pair of bipolar transistors.

You might wonder why you need a precise current source or sink. While it is nice to drive things like LEDs with a constant current, you probably don’t need ultra-precise currents. However, charging a capacitor with a constant current produces a very nice linear voltage ramp. When you use a resistor to bias collector current in a bipolar amplifier, you are just poorly imitating a constant current source, too. That’s just two of many examples.

The circuits use a MOSFET to handle the actual current path, so there are a few differences depending on whether you want to sink or source current. You may wonder why a precision Zener diode needs an external Zener. However, if you read the text, you’ll note that’s only if the input voltage is too high for the “real” Zener.

There are many techniques for manipulating currents. All good to have in your toolbox.

hackaday.com/2025/11/14/precis…

Building a Drivable, Life-Size 3D-Printed LEGO Technic Buggy

The 8845 LEGO Technic Dune Buggy original. (Credit: Matt Denton)
It’s part of the great circle of life that toys and scale models that provide a reflection of macro-sized objects like vehicles and buildings will eventually be scaled up again to life-sized proportions. Case in point the LEGO Technic dune buggy that [Matt Denton] recently printed at effectively human scale, while also making it actually drivable.

The basis for this project is the 8845 Dune Buggy which was released in 1981. Unlike the modern 42101 version, it’s more straightforward and also seems more amenable to actually sitting in despite featuring more pieces for a total of 174 pieces. Naturally, [Matt] didn’t simply go for a naïve build of the 8845 buggy, but made a few changes. First is the scale that’s 10.42 times larger than the LEGO original, based around the use of 50 mm bearings. The model was also modified to be a single-seater, with the steering wheel placed in the center.

With some structural and ergonomic tweaks in place, the resulting CAD model was printed out mostly in PLA with a 1 mm nozzle and 10% infill using a belt FDM printer to help with the sheer size of the parts. After that it was mostly a LEGO kit assembly on a ludicrous scale that resembles a cross between building a LEGO kit and assembling Ikea flatpack furniture.

At merely the cost of most of his sanity, [Matt] finally got the whole kit together, still leaving a few suspension issues to resolve, as it turns out that so much plastic actually weighs a lot, at 102 kg. With that and other issues resolved, the final touch was to add an electric motor to the whole kit using a belt-driven system on the rear axle and bringing every LEGO minifig’s dreams to life.

After a few test drives, some issues did pop up, including durability concerns and not a lot of performance, but overall it performs much better than you’d expect from a kid’s toy.

youtube.com/embed/RyM0SPHocUA?…

hackaday.com/2025/11/14/buildi…

Meet Me on My Rotary Phone

We suspect kids today — and some adults — are confused about phone terminology. In today’s world, “hanging up” and “dialing,” for example, are abstract words without the physical reference that older people remember. But some people have a soft spot for the old rotary dial phones, including [Stavros], who wired a rotary phone to his computer for use on online meetings. Check out the video below.

He took an old rotary phone and wanted to program a Raspberry Pi Zero to act as a sound card and a keyboard. That way, he could connect to the meeting by picking up the handset and disconnect by hanging up. He also planned to read the dial and convert that into keyboard input.

If that sounds like a big project, it’s because it is. [Stavros] decided to use Claude Opus 4.1 to write the code for him, but was stymied by the $200/month price tag. So he wrote some code to send queries on a pay-as-you-go plan. After $50 was spent, the code was in worse shape than the first version. So much for vibe coding.

Plan B was — his words, not ours — shameful. He used a cheap USB sound card, an RP2040 to act like the keyboard, and a hub to make it simple to connect. Cases were removed, and boards were integrated into the phone to make a working project.

We do appreciate that [Stavros] tries not to irreversibly damage the old gear when he makes a mod like this. He uses a 3D printed connector to replace the old press-fit connections on the phone’s PCB, and it is all highly reversible.

While Claude didn’t help the development much, perhaps [Stavros] can use the phone to talk to Claude. We’ve seen a number of rotary phone hacks over the years.

stavros.io/posts/i-converted-a…

hackaday.com/2025/11/14/meet-m…

Bias cognitivi e cybersecurity: l’errore fatale del “non ho nulla da nascondere”

In Italia, ogni anno oltre 3.000 persone perdono la vita sulle strade, nonostante tutti conoscano le regole basilari della sicurezza. Nel cybercrime, lo scenario non è poi così diverso: milioni di vittime ogni anno, anche se ormai è risaputo che i link sospetti sono trappole da evitare. E se il phishing continua ad esistere in tutte le sue forme, questo significa che qualcuno ancora ci abbocca.

Allora, come spiegare questa contraddizione? Entrano in gioco i bias cognitivi, scorciatoie mentali che ci fanno pensare “TANTO”: “tanto non ho nulla da rubare”, oppure “tanto a me non succederà mai”, oppure “tanto io ci faccio sempre attenzione” e così via. Si tratta di un errore fatale, perché chiunque può diventare una porta d’accesso per obiettivi più interessanti, o un capro espiatorio perfetto per attività criminali, oppure banalmente un automatismo dei cybercriminali ha trovato un buco nel computer o nel telefono e ci si è infilato dentro.

Il “Manuale CISO Security Manager” nasce per aiutare i professionisti della sicurezza a capire e fronteggiare questi meccanismi psicologici, che mettono in crisi anche le tecnologie più avanzate.

L’illusione del “tanto non ho nulla da nascondere”

Pensare di non essere un bersaglio per i cybercriminali è il bias più rischioso. Ogni utente è, di fatto, un asset prezioso per almeno tre motivi chiave:

• Ponte di accesso: ogni persona è collegata a reti di amici, familiari e colleghi più interessanti. I criminali usano queste catene di fiducia per raggiungere obiettivi di alto valore.
• Capro espiatorio: le identità rubate servono per effettuare frodi, aperture di conti bancari e attacchi nascosti a nome di ignare vittime.
• Fonte di credenziali: password riciclate e dati personali diventano munizioni per sferrare attacchi più sofisticati.

Ma quindi cosa ci insegna la sicurezza stradale?

I dati ISTAT raccontano una storia drammatica: morti causate da comportamenti evitabili quali guida distratta o abuso di alcol, nonostante le campagne di sensibilizzazione che vanno avanti da decenni. E quindi, se la gente rischia la vita fisica ignorando regole note, perché dovrebbe rispettare norme che sembrano invisibili perchè stanno dietro ad uno schermo?

Anatomia dei bias nella cybersecurity

• Bias di invulnerabilità: “A me non succederà mai”. Il cervello ignora che i criminali cercano accessi e identità, non solo ricchezze.
• Bias del controllo illusorio: “So riconoscere un attacco, e se succederà, ci starò attento”. Il cervello sottovaluta l’astuzia e il continuo aggiornamento delle minacce.
• Bias della delega tecnologica: “Ci pensa l’antivirus, l’amico esperto, il supporto IT” o comunque qualcun altro / qualcos’altro. È un’illusione pericolosa: il fattore umano resta il vero anello debole.

Nonostante i supercomputer più potenti abbiano capacità di calcolo e memoria superiori al cervello umano, non possono sostituirne l’intuizione, la capacità di correlare informazioni non strutturate e il giudizio contestuale. La “grande bugia” della tecnologia è quella di credere che risolverà da sola ogni problema di sicurezza.

Cosa fare nelle aziende?

Attenzione! I bias non sono errori, sono strategie di sopravvivenza per processare rapidamente una montagna di dati. Nel mondo reale funzionano per salvarci, mentre nel cyberspazio possono aprire la porta ad un disastro irrecuperabile.

Infatti, il futuro è interdisciplinare: tecnologia, psicologia e comportamento umano devono convivere. La sfida è usare i bias in modo positivo per andare oltre le semplici difese tecniche.

• Progettare sistemi che funzionino “con” i bias, non contro.
• Formare le persone alla sicurezza tenendo conto delle resistenze psicologiche, non solo informando.
• Usare “nudge”, cioè spinte gentili verso comportamenti sicuri, non barriere rigide.

Per approfondire il rapporto tra fattore umano e cybersicurezza, il “Manuale CISO Security Manager” dedica ampio spazio a queste tematiche fondamentali per la sopravvivenza.

L'articolo Bias cognitivi e cybersecurity: l’errore fatale del “non ho nulla da nascondere” proviene da Red Hot Cyber.