A year and a half ago, I bought a laptop that came with a Realtek RTL8852BE wireless card.

At the time, Linux did not include its drivers, and you needed to build them with DKMS. Even Windows 11 did not work with it out of the box after formatting the pre-installed copy.

So, at the time, I ended up buying an Intel AX200, but I still kept the other card in a closet.

I am often annoyed that sharing files from my Android phone to my Linux desktop is always harder than it should be. At least Python’s http.server saves the day for the way around.

Then, today, I remembered Bluetooth, which the card I had lying around supports!

My motherboard (an ASRock B650 PG Lightning) has a m.2 slot for WiFi cards, so I decided to give it a try.

I am currently on Debian trixie with a 6.12.22 kernel. It is the current Debian testing, but it is expected to become the new stable in a few months.

To my surprise, the WiFi worked immediately without installing anything! However, I must say I already had the firmware-realtek package, as my Ethernet card was also made by Realtek. Even the hotspot functionality worked.

So, no more git cloning, DKMS, etc 🎉.

For Bluetooth, I was not as lucky. It could see my phone, but it failed to pair. And my phone could not find my PC either.

However, I also have an ancient Bluetooth USB stick based on a Broadcom BCM2045 module. Even though it is old, it immediately worked!

I still remember the old Windows XP days, when I had to install the Widcomm Bluetooth stack. Luckily, it is just an old memory 😄.

A couple of years ago, after upgrading my Orange Pi Zero to Debian bookworm, I encountered several problems, and eventually, I migrated to Alpine Linux.

Everything worked well until a couple of weeks ago, when my system died. It stopped booting, and I could not read its microSD with my computer, either. I think the cause might be the power losses, which are more frequent than I would like at home.

I have a backup, but I do not remember if it contains the final configuration. Moreover, Alpine is a rolling distribution, so I would have needed to update and possibly reconfigure in any case, and I feared this would have taken much more time than I wanted to dedicate.

So, I gave Debian another chance, but it did not end well. It worked as expected for some days. Then, at a certain point, the system started becoming unreachable after a few hours (and, of course, it broke in the worst moments).

I even tried to set up a cronjob for daily reboots and a watchdog, but I still had the problem.

At this point, I thought that maybe the Orange Pi Zero support in bookworm’s kernel (6.1.x) was not mature enough, and I hoped a newer kernel was more stable. Debian trixie is becoming the next stable this year, so I just anticipated the upgrade… and it worked! (At least for now 😄).

I kept the scheduled reboot, but I think the system would keep working also without it.

My only problem was that the upgrade removed my changes to the kernel command line in /boot/boot.cmd, so I had to restore them manually and re-create /boot/boot.scr.

For my work, sometimes I send contributions to Firefox.

Mozilla has existed for a long time, and this is definitely visible in the integration of the development tools they use.

However, some of them are kinda unique, particularly their SCM: Mercurial.

Today, open source is almost a git monoculture, and it is the versioning system I have used most of the time. Therefore, I got used to forks, PRs/MRs, and so on. But Hg does not have anything of this.

Theoretically, Mozilla also supports git, with a bridge called git-cinnabar. However, I always had trouble when trying to use it. Eventually, I learned a few tricks about Mercurial.

The feature I initially missed the most was branching… It took me an embarrassing amount of time to understand that I could just checkout (err, update -r) existing revisions and add commits to create new heads.

Then, you can use hg heads to see all the heads you have created.

You can also assign names like you would do with git branches with bookmarks, but I do not use them often.

Part of my confusion is also due to hg log listing in chronological order (I believe, but I am still unsure). It starts from the most recent commit it knows and then shows commits that are not ancestors of the one checked out.

Showing the graph with the -G option makes the output a bit clearer for me.

Anyway, Mozilla decided to move Firefox to git as well over one year ago, so all of this will not be needed sooner rather than later.

Nel lontano 2016 (!) avevo scritto qualche post riguardanti il mio setup con un Seagate GoFlex Net liberato con OpenWrt. In particolare, in questo avevo esposto la mia soluzione molto poco ortodossa per ospitare i dischi nello chassis di un vecchio antifurto e alimentarli con un alimentatore da LED 😰.

Poi non ho più scritto aggiornamenti su quel progetto. Devo averlo usato non troppo seriamente per un paio d’anni. In seguito, verso aprile/maggio 2018, ho cercato una soluzione più sicura, soprattutto dal punto di vista elettrico, e più performante.

Quindi sono passato ad un computer normale, vista l’efficienza sempre maggiore anche delle CPU desktop. Ho scelto un Celeron G3930 (Core di settima generazione, ovvero Kaby Lake), 4GB di RAM, un alimentatore che consideravo buono, ma poi è morto, forse a causa dell’umidità. Come sistema operativo ho messo fin da subito Debian stable.

Ho anche aggiunto un paio di dischi specifici da NAS: un WD Red e un Seagate Iron Wolf, entrambi da 4TB. Tra l’altro, per scrivere questo articolo sono andato a rivedere l’ordine: li avevo pagati 120,99€ e 121,99€ rispettivamente. Mi sembra che da allora i dischi non sono più calati più di tanto di prezzo 😒. … [Leggi il resto]

Recently, I wanted to install a legacy OS in a virtual machine with QEMU.

However, for several reasons, I did not want it to be able to access the Internet but still be able to access some services on my host.

I had already done something similar in the past with a tap interface, but it was not very convenient, as you need to bring your own DHCP server or use manual configuration.

So, by reading the fine manual, I found an option I had not heard about before: restricted=yes on the user network mode.

It makes QEMU create a virtual network, with the usual DHCP server and connection to the host, but without Internet access.

In addition, it is possible to specify various guestfwd options.

Sadly, the forward mode opens only one connection when the machine boots. Therefore, if you want to forward every new connection, you will have to go through netcat or a similar program. For example, I used this option to redirect connections to 10.0.2.100 to an HTTP server I created with Python:

-nic 'user,model=virtio-net-pci,restrict=yes,guestfwd=tcp:10.0.2.100:80-cmd:netcat 127.0.0.1 8000'

And that was enough for me to pass a few files without using Samba or swapping isos.