TL;DR : Everything works fine out of the box except backlight and HD resolution. The fix : pkg install drm_kmod, enable it sysctl kld_list=i915ms and set backlight 100

I had the opportunity to buy the famous ThinkPad x61s for just a few euros. I’ve owned many different ThinkPads because I find them well-built and particularly compatible with operating systems other than Windows. But I’ve never owned a model as old as this x61s.

Released in May 2007, it’s just under 20 years old. Many models would have given up the ghost by now, but not this behemoth, which, despite the transition to Lenovo, still carries its IBM DNA. Even though its reputation of tank, the weight of the years and a reputation for overheating had me a little skeptical. It’s the smallest model, with its Intel Core 2 Duo L7300 CPU @ 1.40 GHz and 3 GB of RAM … not exactly a powerhouse. And yet, it came with Windows 10 and turned out to be surprisingly fast and cool … until I opened a 1080p YouTube video, at which point it nearly took off like a helicopter because the fan was spinning so fast. Final note for the awesome 3/2 ratio, yet the screen quality is far from modern standards.

#The installation

The Intel Core 2 Duo L7300 is one of the first 64-bit CPUs for the consumer market. Great, FreeBSD seems to have dropped 32-bit support in its latest version, 15. After downloading an AMD64 ISO and copying it to a bootable USB drive, I immediately configured the BIOS to set the USB port as the boot priority. I was expecting a complicated installation, but not at all. Yes, the interface is a far cry from Ubuntu, but everything is very easy to do.

• First, select the “Distribution Sets” installation type to select the minimum options and remove kernel-dbgand lib32components.
• Set up the network. I had read a few tutorials beforehand that explained the post-installation method using /etc/wpa_supplicant.conf. But that wasn’t the case at all, everything is done within the installation interface, including scanning for networks, selecting the SSID, and entering the WEP key. Everything worked perfectly the first time.
• Select the UNIX file system. UFS is lightweight and uses fewer system resources than more advanced file systems like ZFS. Since the x31s has limited RAM and CPU power, UFS helps keep the system faster, more stable, and easier to manage. I don’t need the advanced features of ZFS. Use the entire disk since the machine will be dedicated to this purpose, and choose the GPT partition scheme (which replaces MBR I wasn’t able to test this for the exercise).
• The root user is created by default; all that’s left is to set a password.
• After going through a few steps to select the HTTP mirror, choose the keyboard layout, and set the date and time, I’m prompted to add a few components. I select powerd for CPU frequency scaling and moused to start the mouse driver.
• I’m adding a user and adding it to the group wheel.

#The optimization

Right out of the box, FreeBSD on my x61s required very little tweaking :

• I limit the power consumption of the Wi-Fi chip (which is known to be a power hog) : vi /etc/system.conf and set dev.iwm.0.twpower = 50.
• Since powerd was set on during the install, I set configure the CPU with high speed when AC on and power-save on battery : vi /etc/rc.confand set powerd_flags="-a hiadaptive -b adaptive".
• A very obvious system update freebsd-update fetch install and the same for packages pkg updateand pkg upgrade.
• The backlight was very low and the resolution was limited to 800x600. So I installed the Direct Rendering Manager GPU driver pkg install drm_kmod and enable it sysctl kld_list=i915ms, after a reboot, the HD resolution was on and a simple backlight 100 was enough to set a full screen brightness (yet quit low but never mind).

#Claude’s Tab Window Manager

CTWM is a very light window manager and yet very configurable. When idle, it uses almost no RAM or CPU. It’s even easier to install :

• First, I installed the graphical environment components: the Xorg X server along with the lightweight window manager CTWM using: pkg install xorg ctwm
• Then, using the regular (non-root) user account I created during installation, I set up a ~/.xinitrc file to tell X what session to start. For now, I kept it very simple: exec ctwm &
• After that, I launched the graphical session with: startx
• And … yeah, the default CTWM look is pretty rough, very retro in the not immediately lovable sense. So I decided to customize it by creating a ~/.ctwmrc configuration file with my own settings. You can find some themes in the officiel site.

#Final words

The screen’s 3/2 aspect ratio is great, and everything works almost out of the box with FreeBSD. The machine is fast, quiet, and stays cool. The keyboard is high-quality, a nice change from the ultra-flat keys on a MacBook. I hope to achieve my goals with this setup. See you in a few weeks to talk more about it.

On a Meshtastic mesh, discovery is almost free. Radio is a broadcast medium : a node transmits once and every other node within range hears it. There’s nothing to guess, no address space to search. The only constraint is the proximity of each node.

At the same time, I’m interested in peer-to-peer networks over the Internet and the transposition does impose quite a few constraints. There’s no “radio range” on IP : two hosts a few meters apart and two hosts on opposite sides of the planet are equally reachable (or equally invisible actually) to each other. Reachability over the Internet is not a physical proximity constraint, it’s a function of knowing an address that could be almost anything. Discovery becomes more about random guessing than a search within the area.

In a centralized network, peer discovery is easy : a directory, a tracker or a central authority tells where the network nodes are. But that comes at a cost : a single point of failure. For a network whose purpose is to resist censorship, a central server is an obvious target : block the directory’s IP address and the entire network disappears. The promise of total decentralization is that peer discovery becomes as resilient as the network itself. A fully decentralized network has no central authority and delegates peer discovery to the peers themselves. But a node’s ability to find another node with no intermediary is limited by two basic constraints : the size of the address space (the IP adress space) and how long nodes stay reachable. On the Internet, none of these constraints can be guaranteed.

Let’s dig into it.

#The address space

For an IPv4 network, the global address space is the set of all 32-bit binary vectors :

The total number of addressable addresses is:

Let $n$ be the number of active nodes belonging to the peer-to-peer network at a given time $t$. Define the network’s density $\delta$ as the probability that a uniformly randomly sampled address belongs to the set of active peers:

This is a simplified model : it assumes that peers are uniformly distributed across the IPv4 address space and that any address belonging to a peer is directly reachable. In practice, NAT, firewalls, ports, routing and service availability make the real situation even more complex.

Searching for a peer by random sampling can be modeled as a geometric distribution, where each query is an independent Bernoulli trial with success probability $p = \delta$. The expected number $E[X]$ of queries needed to make first contact is :

For a network starting up with $n = 100$ peers :

Now let $v$ be the scan rate (queries on the address space per second). The average discovery time $T$ is:

Assuming a (very) optimistic scan rate of $v = 10^3$ requests per second :

So, brute-force discovery of a single node on an authority-free network takes close to 12 hours. For a network that already has 100 peers running.

For a very new network of just $n = 2$ peers, the theoretical discovery time increases to roughly … 24.9 days ! And on a IPv6 adress space, it completely stops being a practical number at all : $\approx 5.4 \times 10^{27}$ years (390 quadrillion times the current age of the universe).

#The problem : addresses change

The scale of the address space alone would be a solvable engineering problem (well, you could, in principle, scan forever). But peers can’t scan forever, because the addresses they’re scanning for don’t stay put. DHCP lease duration isn’t fixed : it varies by router vendor, ISP and network type, but a reasonable working approximation would be between 7 to 14 days.

Take $T = 14$ days (1,209,600 seconds) as an upper bound. The total number of scan attempts a peer can realistically make in that window is :

Each discovery attempt is a Bernoulli trial with two outcomes : hit or miss. The probability of exactly $k$ hits is :

with :

• $S = 1.2096 \times 10^{9}$ trials,
• $p = \dfrac{1}{4\,294\,967\,296} \approx 2.33 \times 10^{-10}$, the probability of a hit on any given attempt.
  
  

By the Poisson limit theorem ($S \to \infty$, $p \to 0$), the binomial distribution $B(S,p)$ converges to a Poisson distribution $P(\lambda)$ with $\lambda = Sp$ :

The probability of finding at least one peer ($X \ge 1$) over the whole lease window is :

A peer has roughly a 1-in-4 chance of ever finding another peer on IPv4 over an entire DHCP lease and that’s the very best case, assuming :

• the searching peer dedicates 100% of its time and bandwidth to scanning, continuously, for the full 14 days, at $v = 10^3$ requests/second
• nodes being searched for keep their IP for at least 14 days.

None of these assumptions are realistic.

That’s why fully decentralized networks aren’t really fully decentralized. Bitcoin comes with hardcoded seed nodes and DNS seeds. BitTorrent leans on trackers. Tor has directory authorities. I2P has reseed servers. Pure peer-to-peer discovery is almost impossible when the address space is so large and constantly changing. These authorities, trackers and hardcoded nodes are needed for decentralization to work at all.

So, a fully peer-to-peer network with no authority, as sexy as it is, would be almost utopian over the Internet.