linux

Because I love doing things quite backwards, I found myself in a predicament: I had only a wired direct connection between my laptop and the Raspberry Pi where I was running LibreELEC. Using mDNS I could connect to it directly connected at LibreELEC.local, and that's great...

But I wanted to join it to a WiFi network, and I only had a not-great 6-button remote control to plug into the Pi, so entering in long passwords via the UI (if that's even possible without a keyboard?) was not something I wanted to attempt.

Since I could ssh [email protected], I figured I'd connect to the available WiFi network, so it would be more convenient to update the device and put more content on it. Not to mention it expands Kodi's capabilities if you give it an Internet connection!

Enter ConnMan

LibreELEC uses ConnMan to manage network interfaces, and setting WiFi is a little strange, but doable:

While logged into the LibreELEC machine, enter connmanctl to get into the ConnMan shell.

Then do the following:

The Raspberry Pi 5 includes 5 active PCI Express lanes—4 go to the new RP1 chip for I/O like USB, Ethernet, MIPI Camera and Display, and GPIO, and 1 goes to a new external PCIe connector:

By default, all PCIe lanes operate at Gen 2.0 speeds, or about 5 GT/sec per lane. Currently there's no way to change that default for the RP1 chip's 'internal' lanes, but on the external connector, you can add the following lines inside /boot/firmware/config.txt (and reboot) to upgrade the connection to Gen 3.0 (8 GT/sec, almost double the speed):

If you haven't already, check out my full video on the Raspberry Pi 5, which inspired this post.

Raspberry Pi OS 12 'Bookworm' is coming alongside the release of the Raspberry Pi 5, and with it comes a fairly drastic change from using wpa_supplicant for WiFi interface management to everything network-related running through nmcli, or NetworkManager.

nmcli is widely adopted in Linux these days, and it makes managing WiFi, LAN, and other network connections much simpler.

It's less than 12 hours since the Pi 5 launch, and already there's a few hundred questions whizzing about—I thought I'd answer some of the things I see people asking most frequently, like:

Does the new Case have room for the Active Cooler, or other Pi HATs?

Yes, indeed it does! You can pop out the fan bracket in the new Case, and fit many normal-size Pi HATs. This is useful also if you want to stack cases—assuming the HAT has mounting points, you could put some spacers in and stack another Pi or Pi + Case on top!

If you haven't heard, the Raspberry Pi 5 was announced today (it'll be available in October).

I have a full video going over the hardware—what's changed, what's new, and what's gone—and I've embedded it below. Scroll beyond to read more about specs, quirks, and some of the things I learned testing a dozen or so PCIe devices with it.

I recently tried setting up an M.2 Coral TPU on a machine running Debian 12 'Bookworm', which ships with Python 3.11, making the installation of the pyCoral library very difficult (maybe impossible for now?).

Some of the devs responded 'just install an older Ubuntu or Debian release' in the GitHub issues, as that would give me a compatible Python version (3.9 or earlier)... but in this case I didn't want to do that.

On new Debian 12 Bookworm and Ubuntu 24.04 Noble Numbat installs, when I try running pip3 install [something] (whether that's Ansible or some other Python tool), I get the following error message:

I recently had a server with some bandwidth limitations (tested using scp and rsync -P), where I was wondering if the problem was the data being transferred, or the server's link speed.

The simplest way to debug and verify TCP performance is to install iperf3 and run an iperf speed test between the server and my computer.

On the server, you run iperf3 -s, and on my computer, iperf3 -c [server ip].

But iperf3 requires port 5201 (by default) to be open on the server, and in many cases—especially if the server is inside a restricted environment and only accessible through SSH (e.g. through a bastion or limited to SSH connectivity only)—you won't be able to get that port accessible.

So in my case, I wanted to run iperf through an SSH tunnel. This isn't ideal, because you're testing the TCP performance through an encrypted connection. But in this case both the server and my computer are extremely new/fast, so I'm not too worried about the overhead lost to the connection encryption, and my main goal was to get a performance baseline.

We're at the stage in the Red Hat drama where everyone is consulting history, trying to figure out what parts are being repeated in 2023 after Red Hat effectively locked down the sources used to build RHEL clones.

One talk linked quite often was Fork Yeah! The Rise and Development of illumos, by Bryan Cantrill over a decade ago. Bryan was a software engineer at Sun, who went over to Oracle after the buyout, then left to join Joyent, and now resides as CTO of Oxide.

The talk focuses on Sun Microsystem's handling of Solaris and OpenSolaris, both before and after their Oracle acquisition, and the whole talk is worth a listen—so much context about the history of ZFS, Solaris, Illumos, dtrace, and even UNIX and Linux history are contained within.

But there was one section (around the 32:00 mark) where if you substitute "Red Hat" for "Sun," rhymes with this year's "open source company" drama:

I went back and looked at some of the mail trails about this and like, "oh, my God!"

As someone who champions truth, yet knows truth is bent to espouse many ideas, I realize clever phrasing often turns irrational lies into strong beliefs—especially when passion takes over.

And we in the open source community are a passionate bunch.

But to clear the air a little bit—especially as I have seen some zingers going both directions (from Red Hat employees to the community, and vice-versa):