The best kind of Hackaday posts are the ones where there was some insurmountable problem with an elegant solution devised through deep analysis of the problem and creativity. This is not one of those posts. I’m sure you are familiar with bit rot. You know, something works for a long time and then, for no apparent reason, stops working. Well, that has been biting me, and lacking the time for the creative, elegant solution, I decided to attack it with a virtual chainsaw.

It all started with a 2022 Linux Fu about using autokey.

The Problem

I use autokey to give me emacs-style keystrokes in Web browsers and certain other programs. It intercepts keystrokes and translates them into other keystrokes. The problem is, the current Linux community hates autokey. Well, that’s not strictly true. They just love Wayland more. One reason I won’t switch from X11 is that I haven’t found a way to do something like I do with autokey. But since most of the powers-that-be have decided that X11 is bad and Wayland is good, X11 development is starting to show cracks.

In particular, autokey isn’t in the normal repositories for my distro anymore (KDE Neon). Of course, I’ve installed the latest version myself. I’m perfectly capable of doing that or even building from source. But lately, I’ve noticed my computer hangs, especially after sleeping for a long time. Also, after a long time, I notice that autokey just quits working. It is running but not working and I have to restart it. The memory consumption seems high when this happens.

You know how it is. Your system has quirks; you just live with them for a while. But eventually those paper cuts add up. I finally decided I needed to tackle the issue. But I don’t really have time to go debug autokey, especially when it takes hours for the problem to manifest.

The Chainsaw

I’ll say it upfront: Finding the memory leak would be the right thing to do. Build with debug symbols. Run the code and probe it when the problem comes up. Try to figure out what combination of X11, evdev, and whatever other hocus pocus it uses is causing this glitch.

But who’s got time for that? I decided that instead of launching autokey directly, I’d launch a wrapper script. I already had autokey removed from the KDE session so that I don’t try to start it myself and then get the system restaring it also. But now I run the wrapper instead of autokey.

So what does the wrapper do? It watches the memory consumption of autokey. Sure enough, it goes up just a little bit all the time. When the script sees it go over a threshold it kills it and restarts it. It also restarts if autokey dies, but I rarely see that.

What’s Memory Mean?

The problem is, how do you determine how much memory a process is using? Is it the amount of physical pages it has? The virtual space? What about shared libraries? In this case, I don’t really care as long as I have a number that is rising all the time that I can watch.

The /proc file system has a directory for each PID and there’s a ton of info in there. One of them is an accounting of memory. If you look at /proc/$PID/smaps for some program you’ll see something like this:
00400000-00420000 r--p 00000000 fd:0e 238814592 /usr/bin/python3.12
Size: 128 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 128 kB
Pss: 25 kB
Pss_Dirty: 0 kB
Shared_Clean: 128 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 128 kB
Anonymous: 0 kB
KSM: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
FilePmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd mr mw me sd
00420000-00703000 r-xp 00020000 fd:0e 238814592 /usr/bin/python3.12
Size: 2956 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 2944 kB
Pss: 595 kB
Pss_Dirty: 0 kB
Shared_Clean: 2944 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
. . .

Note that there is a section for each executable and shared object along with lots of information. You can get all the PSS (proportional set size) numbers for each module added together like this (among other ways):

cat /proc/$PID/smaps | grep -i pss | awk '{Total+=$2} END { print Total}'

Building the Chainsaw

So armed with that code, it is pretty easy to just run the program, see if it is eating up too much memory, and restart it if it is. I also threw in some optional debugging code.
#!/bin/bash
#- Run autokey, kill it if it gets too big
#- what's too big? $MLIMIT
MLIMIT=500000
#- how often to check (seconds)
POLL=10

#- Print debug info if you want
function pdebug {
#- comment out if you don't want debugging. Leave in if you do
#- echo $1 $2 $3 $4
}

while true # do forever
do
PID=$(pgrep autokey-qt) # find autokey
pdebug "PID",$PID
if [ ! -z "$PID" ] # if it is there
then
# get the memory size
PSS=$(cat /proc/$PID/smaps | grep -i pss | awk '{Total+=$2} END { print Total}')
pdebug "PSS", $PSS
echo $PSS >>/tmp/autokey-current.log
# too big?
if [ "$PSS" -gt "$MLIMIT" ]
then
pdebug "Kill"
echo Killed >>/tmp/autokey-current.log
# save old log before we start another
cp /tmp/autokey-current.log /tmp/autokey-$PID.log
kill $PID
PID=
sleep 2
fi
fi
if [ -z $PID ]
then
# if died, relaunch
pdebug "Launch"
autokey-qt & 2>&1 >/tmp/autokey-current.log
fi
pdebug "Sleep"
sleep $POLL
done

In practice, you’ll probably want to remove the cp command that saves the old log, but while troubleshooting, it is good to see how often the process is killed. Running this once with a big number gave me an idea that PSS was about 140,000 but rising every 10 seconds. So when it gets to 500,000, it is done. That seems to work well. Obviously, you’d adjust the numbers for whatever you are doing.

Bad Chainsaw

There are lots of ways this could have been done. A systemd timer, for example. Maybe even a cgroup. But this works, and took just a few minutes. Sure, a chainsaw is a lot to just cut a 2×4, but then again, it will go through it like a hot knife through butter.

I did consider just killing autokey periodically and restarting it. The problem is I work odd hours sometimes, and that means I’d have to do something like tie it to the screensaver. But I agree there are dozens of ways to do this, including to quit using autokey. What would your solution be? Let us know in the comments. Have you ever resorted to a trick this dirty?

hackaday.com/2025/04/14/linux-…

I ricercatori della PCAutomotive hanno evidenziato diverse vulnerabilità nel veicolo elettrico Nissan Leaf. Gli esperti hanno dimostrato che i bug potrebbero essere utilizzati per l’hacking a distanza delle auto, la sorveglianza e l’intercettazione completa di varie funzioni.

PCAutomotive è specializzata in test di penetrazione e analisi delle minacce per il settore automobilistico e finanziario. La scorsa settimana, alla conferenza Black Hat Asia 2025, gli esperti hanno parlato dettagliatamente dell’attacco hacker alla Nissan Leaf.

L’oggetto dello studio era il veicolo elettrico Nissan Leaf di seconda generazione, lanciato nel 2020. Le vulnerabilità riscontrate al suo interno hanno consentito l’utilizzo delle funzioni Bluetooth del sistema di infotainment dell’auto per penetrare nella rete interna.

Gli esperti sostengono che queste problematiche hanno consentito di aumentare i privilegi e di stabilire un canale di comunicazione con il server di controllo tramite comunicazioni cellulari, garantendo un accesso nascosto e costante al veicolo elettrico direttamente tramite Internet.

L’aggressore potrebbe sfruttare le vulnerabilità scoperte per spiare il proprietario di una Nissan Leaf, monitorando la posizione dell’auto, catturando screenshot del sistema di infotainment e persino registrando le conversazioni delle persone all’interno dell’auto.

youtube.com/embed/56VreoKtStw?…

Inoltre, i problemi consentivano il controllo a distanza di varie funzioni dell’auto, tra cui l’apertura delle portiere, dei tergicristalli, del clacson, degli specchietti, dei finestrini, dei fari e perfino del volante, anche durante la guida.

Alle vulnerabilità sono stati assegnati otto identificatori CVE: da CVE-2025-32056 a CVE-2025-32063.

I ricercatori hanno affermato che il processo di divulgazione delle informazioni sui bug è iniziato già nell’agosto 2023, ma gli specialisti Nissan hanno confermato l’esistenza dei problemi solo nel gennaio 2024 e l’assegnazione degli identificatori CVE ha richiesto circa un altro anno.

Oltre al loro rapporto, gli esperti hanno pubblicato un video in cui hanno chiaramente dimostrato come hanno utilizzato i loro exploit per hackerare da remoto una Nissan Leaf.

I rappresentanti della Nissan hanno dichiarato ai media che l’azienda non può divulgare dettagli sulle vulnerabilità e sulle misure di protezione adottate per motivi di sicurezza. Allo stesso tempo, l’azienda ha sottolineato che continuerà a sviluppare e implementare tecnologie per combattere gli attacchi informatici “per il bene della sicurezza e della tranquillità dei clienti”.

L'articolo Shock Hacking: Come Guidare una Nissan Leaf Da Remoto! La ricerca al Black Hat Asia 2025 proviene da il blog della sicurezza informatica.

The ESP32 series of microprocessors with their cheap high-power cores and built-in wireless networking have brought us a wide variety of impressive projects over the years. We’re not sure we’ve quite seen the like of [Jonathan R]’s video walkie talkie before though, a pair of units which as you might guess, deliver two-way video and audio communications.

The trick involves not one but two ESP32s: an ESP32-S3 based camera module, and a more traditional Tensilica ESP32 in a screen module. It’s an opportunity for an interesting comparison, as one device uses the Cheap Yellow Display board, and the other uses an Elecrow equivalent. The audio uses ESP-NOW, while the video uses WiFi, and since the on-board audio amplifiers aren’t great, there’s a small amp module.

The video below has a comprehensive run-down including the rationale behind the design choices, as well as a demonstration. There’s a small lag, but nothing too unacceptable for what is after all an extremely cheap device. Perhaps after all this time, the video phone has finally arrived!

youtube.com/embed/rfnsuzQIYbs?…

hackaday.com/2025/04/14/a-chea…

An occasional series of mine on these pages has been Daily Drivers, in which I try out operating systems from the point of view of using them for my everyday Hackaday work. It has mostly featured esoteric or lesser-used systems, some of which have been unexpected gems and others have been not quite ready for the big time.

Today I’m testing another system, but it’s not quite the same as the previous ones. Instead I’m looking at a piece of hardware, and I’m looking at it for use in my computing projects rather than as my desktop OS. You’ll all be familiar with it: the original Raspberry Pi appeared at the end of February 2012, though it would be May of that year before all but a lucky few received one. Since then it has become a global phenomenon and spawned a host of ever-faster successors, but what of that original board from 2012 here in 2025? If you have a working piece of hardware it makes sense to use it, so how does the original stack up? I have a project that needs a Linux machine, so I’m dusting off a Model B and going down memory lane.

Rediscovering An Old Flame

My first Pi from 2012. The heatsinks are my addition.
It’s fair to say that Raspberry Pi have never had the fastest board on the block, or the highest specification. At any point there’s always some board or other touted as a Pi-killer because it claims to do more, but somehow they never make much impact. The reason for this is simple; alongside your Pi you are also buying the ability to run Raspberry Pi OS, and their achievement in creating a solid and well-supported operating system that still runs on their earliest boards is something their competitors can’t touch. So when I pulled out my Model B I was able to go to the Raspberry Pi downloads page and snag a Debian Bookworm image for its 32-bit processor. I went for the “lite” version; while an early Pi will run a desktop and could even be my desktop daily driver, it would be so painfully slow as to be frustrating.
This is what my word trend analysis tool can do. Everyone was talking about Brexit in the UK in 2016.
My purpose for using the Pi is to run a language analysis package. Aside from fiddling with old cameras and writing about tech, I have a long history in computational language processing, and I have recently returned to my news trend analysis code and made it open-source. It’s a project whose roots go back nearly two decades, so there’s been an element of working out what my younger self was thinking. It builds and processes a corpus of news data over time from RSS feeds, and presents a web-based analysis client. 2000s-era me wrote it in PHP (don’t judge!) and I evolved a corpus structure using a huge tree of small JSON files for fast access. An earlier version of this package ran on my first Pi for many years, sitting next to my router with a USB hard disk.

Firing up an original Pi in 2025 is easy enough, as with any Pi it’s simply a case of writing the image to an SD card, hooking up the Pi to screen and peripherals, and booting it. Raspberry Pi OS is as straightforward to set up as always, and after rebooting and logging in, there I was with a shell.

Remembering, Computers Weren’t Always This Quick

Yes. it’s slow. But it’s got a shell. macrophile, CC BY 2.0.
My main machine is a fairly recent high-end Thinkpad laptop with an Intel Core i7, 32 GB of memory, and the fastest SSD I could afford, equipped with a hefty cache. It’s a supercomputer by any measure from the past, so I have become used to things I do in the shell being blisteringly quick. Sitting at the Pi, it’s evident that I’ll need to recalibrate my expectations, as there’s no way it can match the Thinkpad. As i waited – rather a long time – for apt to upgrade the packages, I had time to reflect. Back in the day when I set up Linux on my 486 or my Pentium machine, I was used to waiting like this. I remember apt upgrade being a go away and have a coffee thing, and I also remember thinking that Pentium was pretty quick, which it was for its day. But stripped of unnecessary services and GUI cruft, I was still getting all the power of the Pi in my terminal. It wasn’t bad, simply visibly slower than the Thinkpad, which to be fair, also applies to all the other computers I own.

So my little Pi 1 model B now sits again hooked up to my router and with a hefty USB drive, again waking up every couple of hours and number-crunching the world’s news. I’ve got used to its relative sloth, and to working again with nano and screen to get things done on it. It’s a useful little computer for the task I have for it, and it can run all day consuming only a couple of watts. As long as the Raspberry Pi people still make the Pi Zero, and I hope for a few years after they stop, it will continue to have OS support, and thus its future as my language processing machine looks assured.

The point of this piece has been to reflect on why we shouldn’t let our older hardware collect dust if it’s still useful. Of course Raspberry Pi want to sell us a new Pi 5, and that board is an amazing machine. But if your task doesn’t need all that power and you still have the earlier model lying around, don’t forget that it’s still a capable little Linux board that you probably paid quite a lot less for. You can’t argue with that.

hackaday.com/2025/04/14/jennys…

dalla pagina di Roberto Vallepiano
(grazie a Tano D'Amico)

facebook.com/share/p/1AZRzkFwZ…

Mancavano pochi minuti alla mezzanotte quando la prima manganellata si abbatté sulla spalla sinistra di Mark Covell, il giornalista inglese che stava dormendo alla Scuola Diaz assieme ad altri 92 mediattivisti di diverse parti del mondo.
Covell urlò in italiano che era un giornalista, ma in pochi secondi si trovò circondato dagli agenti dei reparti antisommossa che lo tempestarono di colpi dei Tonfa, i manganelli "spaccaossa" inaugurati proprio in occasione del G8 di Genova.
Riuscì a restare in piedi solo per pochi secondi, poi una bastonata sulle ginocchia gli spappolò una rotula e lo fece crollare sul selciato.
Mentre giaceva faccia a terra nel buio, contuso e spaventato, un'orda di 346 Poliziotti stava dando il via a quella che venne presto ribattezzata la "Macelleria Messicana".
Proprio in quel momento un agente gli saltò addosso e gli diede un calcio al petto con tanta violenza da incurvargli tutta la parte sinistra della gabbia toracica, rompendogli una mezza dozzina di costole. Le schegge gli lacerarono la pleura del polmone sinistro.
Mentre i battaglioni punitivi della Polizia iniziavano il massacro della Diaz, alcuni agenti cominciarono a colpire Covell con gli anfibi, passandoselo da uno all'altro, come se fosse un pallone da calcio.
Mentre avveniva ciò Mark Covell, che è alto 1,73 e pesa 50 chili, sentiva gli agenti ridere.
Una nuova scarica di calci gli ruppe la mano sinistra con cui tentava di proteggersi e gli danneggiò in maniera irreversibile la spina dorsale.
Rimase qualche minuto inebetito a terra in una pozza di sangue. Poi due poliziotti tornarono indietro e si fermarono accanto al giornalista inglese ormai semi-incosciente, uno lo colpì alla testa con il manganello e il secondo lo prese a calci sulla bocca, frantumandogli i denti. Mark Covell svenne.
Rimase sospeso tra la vita e la morte, in coma, per 15 lunghissime ore.
Arrivò in sala operatoria in condizioni disperate: trauma cranico con emorragia venosa, mano sinistra e 8 costole fratturate, perforazione del polmone, trauma emitorace, spalla e omero, oltre alla perdita di 16 denti.
Mark Covell è un sopravvissuto. Uno dei tanti sopravvissuti alla mattanza genovese nei giorni del G8, a quella che perfino Amnesty International denunciò come "La più grave violazione dei diritti umani in Europa dopo la 2° Guerra Mondiale".

E anche se la Corte di Strasburgo ha condannato l'Italia per tortura e trattamenti disumani e degradanti, nessuno o quasi ha pagato.
La verità è stata insabbiata e i responsabili della Premiata Macelleria Messicana sono stati tutti coperti trasversalmente dai governi di Destra e di Centrosinistra e addirittura promossi.

Ma noi siamo ancora qui. Oggi come ieri.
Fianco a fianco con Mark Covell e tutti gli altri.
Per sputargli in faccia la verità e ricordargli che la memoria è un ingranaggio collettivo.

Cosa c’è nel “decreto Sicurezza” appena entrato in vigore.

Voglio vedere se con un eventuale prossimo governo guidato da chi oggi sta all'opposizione queste norme saranno abolite oppure ormai ci sono e ce le terremo per sempre.

ilpost.it/2025/04/13/decreto-l…