In the last few months, in my free time, I have been developing a small application to elaborate RGBD datasets capturing people. In particular, my goal is to create 3D scans of heads. I do not expect these models to be well-made or even usable without some processing, but I wonder if I can transform this data at least to starter models.

I first started to work with RGBD cameras during my internship at Altair. At the time, I built a small pipeline to reconstruct models based on Kinect Fusion.

Sadly, Kinect Fusion is an online method. The advantage is that it will give immediate feedback if it loses the camera tracking. But the disadvantage is that it needs a pretty powerful GPU. I have one on my desktop, but I took all my datasets using laptops.

Also, in my experience, getting a usable dataset with Kinect Fusion requires several attempts and time (the acquisition must proceed very slowly), which, generally speaking, is not always compatible with… people 😄️. They might move, or lose patience, etc etc… … [Leggi il resto]

Two weeks ago, I needed to mass-download a few IMAP mailboxes before migrating them to another provider.

Gist contains many scripts to do so, and I tried one of them, but it did not work as I wanted. I wanted to download all the IMAP folders, not only Inbox.

Therefore, I wrote my version of that script 😄️.

I used imapclient instead of the built-in imaplib because it is more Pythonic and handles all the tedious conversions between bytes, strings, and other types.

The center of the script is the process function. It connects to an IMAP server, queries the list of folders, and downloads all the messages from each one but trash and spam (but notice that the comparison is case-sensitive!).

client.fetch downloads all the messages you provide to it, which caused an OOM in my case. Therefore, I split the list with the message IDs into chunks. I had to write the batches function because I was running on Python 3.11. From Python 3.12, you can use itertools.batched instead. … [Leggi il resto]

Once upon a time, the Tor Browser Bundle was an actual bundle. It included Firefox, the Tor daemon, and Torbutton, the extension to turn on and off the Tor mode in the browser.

This toggle model was not great and extremely confusing to some users. This and other problems led to the creation of Tor Browser: this article contains more details about this story.

From a technical point of view, Torbutton did not really go away. The visible button disappeared, but much of the related code remained.

Part of the state isolation code was not necessary anymore because Tor Browser always runs in private browsing mode or was dropped over the years thanks to Firefox improvements and the Tor Uplift initiative. However, the circuit display, the first-party domain circuit isolation, and other parts of the existing code were still needed. As a result, Torbutton continued to live for many years as a Tor Browser-only built-in extension on its separate repository and included in the browser with git submodules (even though the browser was non-functional without it). New patches and functionalities were written in the Firefox code that constitutes Tor Browser, and the Torbutton code was changed only to fix existing bugs or to keep it working in new versions of Firefox. … [Leggi il resto]

Motivation

A few years ago, I bought an Orange Pi Zero to run a Telegram bot I use to open and close my garage door.

It worked very well for several years. Then, when Debian bookworm became stable, I decided to reinstall the system, and the trouble began.

After more than one month of frequent crashes, I first tried to upgrade the kernel. However, apt was unusable, and the system reinstallation was my only choice. So, I decided to also check other distributions out.

First, I tried with OpenWrt. It was a good setup, except I could not use GPIO through /dev/mem. This was a big problem because memory-GPIO is more versatile and performant.

So, I decided to also try Alpine Linux. Before this adventure, I had used this distribution only for containers, but I felt this could also be a case in which it can shine. But the effort it took me to get it working as I wanted reminded me of the old days 😅️. It also made me appreciate how easy setting up Debian is these days. … [Leggi il resto]

A couple of months ago, Debian bookworm became stable and I decided to upgrade my Orange Pi Zero. I wanted to re-install the system with the smallest amount of physical access and that made the whole process tiresome and longer.

The new system did not work well. It often crashed, and I continuously had to reset the system by power cycling it. As stated in my previous article, physical access to that system is not easy, which made the problem even less bearable.

After one of the crashes, I managed to get some logs, and I saw they mentioned a “kernel bug”. However, I believe high temperatures were to blame, as July was very hot here. Anyway, I had a little hope that installing a more recent kernel could solve my problem, so I tried to run apt upgrade, which gave me this output:

Preparing to unpack .../base-files_12.4+deb12u1_armhf.deb ...
Unpacking base-files (12.4+deb12u1) over (12.4) ...
dpkg: error processing archive /var/cache/apt/archives/base-files_12.4+deb12u1_armhf.deb (--unpack):
 unable to stat '.' (which was about to be installed): Value too large for defined data type
Errors were encountered while processing:
 /var/cache/apt/archives/base-files_12.4+deb12u1_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

I do not have a minimal clue about what this means. It might be related to the Orange Pi being 32-bit and me having created its system from a 64-bit system. But the error is so generic that I struggled to find its cause. … [Leggi il resto]