Mysterious Files PH

This week Jonathan chats with Michael Meeks about Collabora! What’s the origin story in this consulting company, why do they have an outstanding office suite, and where is the world headed to accomplish digital sovereignty? Watch to find out!

• Collabora Productivity – https://www.collaboraonline.com/
• Michael’s person blog – https://meeksfamily.uk/~michael/
• Michael’s comic strip – ‘The Open Road to Freedom’ (TOTF) https://www.collaboraonline.com/torf-index/

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or have the guest contact us! Take a look at the schedule here.

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

Car enthusiasts want to know how quickly they can make a quarter mile. Weightlifters are forever trying to add one more plate to the bar. Internet denizens have their own favorite number to brag about: the result from a speed test.

The ritual is familiar. Close a few browser tabs, click the big “Go” button, and watch the needle climb. Perhaps you pay for gigabit service and see 940 megabits per second, which produces a satisfied nod. Perhaps you see 299 megabits and begin obsessing over network hardware. But before you get too excited either way, try another test. There is a fair chance it will give you a different answer.

That does not necessarily mean one test is lying. “Internet speed” is not a single physical quantity waiting to be measured. A speed test measures the performance of a particular device, over a particular local connection, through a particular ISP route, to a particular server, at a particular time using a particular test method. Change any of those things and the answer can change too.

The Usual Suspects

Speedtest by Ookla is probably the best-known test. It selects a nearby server, although you can choose another. It attempts to saturate the connection with multiple simultaneous transfers. That makes it good at answering the question most consumers are asking: approximately how much aggregate bandwidth can this Internet connection deliver?

Running several connections matters. A single TCP connection must gradually increase its sending rate while reacting to round-trip time, packet loss, receive-window limits, and congestion-control behavior. On a high-bandwidth or high-latency path, one connection may not fill the available pipe. Several parallel connections can ramp up independently and make it easier to reach the link’s aggregate capacity. That number is valid, but it represents something like a busy household, a large segmented download, or several applications operating at once. It does not necessarily predict the speed of one file transfer from one distant server.

Google’s built-in search speed test (search “speed test”) uses Measurement Lab’s Network Diagnostic Tool, or NDT. M-Lab describes NDT as a single-stream measurement of bulk-transport capacity. That makes it an interesting counterpoint to Ookla. A single flow may expose latency, loss, or TCP-window limitations that a multi-stream test can partially conceal. You can also use M-Lab’s own speed test directly.

While you may get similar numbers between the two approaches, you also may not get similar numbers, especially on high-latency connections where Ookla’s multiple streams will help hide latency.

Netflix’s Fast.com is deliberately simple. Open the page, and it immediately begins transferring data from Netflix infrastructure. By default it emphasizes download performance, since its original purpose was to answer a practical question: can this connection deliver Netflix video properly? Selecting “Show more info” adds upload speed and both unloaded and loaded latency.

The use of Netflix servers is significant. Fast.com measures the route between you and Netflix’s content-delivery network, while Ookla may test against a server operated by your ISP only a few network hops away. A superb Ookla result and a poor Fast.com result do not prove deliberate throttling, but they do tell you that the destinations — or the routes to them — are behaving differently.

Cloudflare offers two related tests. Its Radar Network Quality Test provides a quick summary, while speed.cloudflare.com  gives an extremely detailed breakdown. The latter reports download and upload throughput, idle and loaded latency, jitter, packet loss, server location, and application-oriented quality estimates.

Loaded latency is especially useful. An otherwise fast connection can become miserable when a large upload or download fills an oversized queue in the modem or router. Your idle ping might be 12 milliseconds, but under load it may jump to several hundred milliseconds. That is the classic symptom usually called bufferbloat.

If you want more options, there is testmy.net, which allows you to test upload and download speeds separately, and speedof.me, which keeps a history for you, among others. It isn’t always obvious which ones are measuring a single connection vs multiple ones, so you may have to dig through whatever documentation you can find.

Your WiFi Is Part of the Test

A browser speed test cannot automatically tell you what’s hurting your speed. A laptop connected through marginal WiFi may report 180 megabits per second even though the router has a flawless gigabit Internet connection.

In fact, once incoming Internet service reaches several hundred megabits per second, WiFi is frequently the limiting factor. The link rate displayed by the operating system is not the same thing as usable throughput. Wireless protocols have framing overhead, acknowledgments, contention, retransmissions, and half-duplex operation. The advertised 866, 1200, or 2400 megabit link rate is therefore not a promise that application data will move at that rate.

The numbers printed on WiFi boxes add another layer of optimism. A router sold as “AC1800,” for example, does not provide an 1800-megabit connection to one device. The figure is normally the sum of the maximum advertised PHY rates on separate radios — perhaps 1300 Mb/s on 5 GHz plus 450 Mb/s on 2.4 GHz — with some rounding for marketing. A conventional WiFi client connects to one band at a time, so it cannot combine those rates. The total is better understood as the router’s theoretical aggregate capacity while serving multiple devices across both bands. Even then, protocol overhead, contention, signal quality, and client limitations make actual data throughput considerably lower. Newer WiFi 7 equipment can sometimes combine links using Multi-Link Operation, but that exception does not make the old ACxxxx arithmetic any less misleading.

WiFi also uses shared airtime. Devices on the same channel — including neighboring access points that can hear one another — must contend for opportunities to transmit. A slow or distant client takes longer to send a given amount of data and can consume disproportionate airtime while doing so. Modern access points may provide airtime fairness and other mitigations. One old device does not invariably drag every client down to its rate, but it can still reduce the capacity available to the rest of the network. Interference has a similar effect. A weak signal, a crowded channel, microwave noise, or an overlapping neighboring network causes frames to be delayed or retransmitted. Those retries consume airtime without delivering additional data.

Repeaters and wireless mesh backhaul add another complication. A simple same-channel repeater must receive each packet and then transmit it again over the same shared medium. In the worst case, each repeated hop can roughly halve the available throughput. Modern tri-band mesh systems can avoid much of that penalty by using a dedicated backhaul radio, and Ethernet backhaul avoids it almost entirely.

This means it is entirely reasonable to buy gigabit Internet service and obtain only 300 or 500 megabits per second from a WiFi laptop. Whether that represents a problem depends on the client, radio band, channel width, signal level, backhaul, and local RF environment.

For a meaningful ISP test, begin with a computer connected directly to the router by Ethernet. Stop large transfers and temporarily disable any VPN. Record the chosen server, latency, upload speed, and download speed rather than preserving only the most flattering number. Then run the same tests over WiFi. The difference is an approximate measurement of what the wireless portion of the network is costing you.

Remove the Internet From the Experiment

Better still, remove the ISP from the test completely. OpenSpeedTest is a self-hostable, browser-based test. Run its server on a wired computer, NAS, or container, then visit it from laptops, phones, and tablets around the house. Because the traffic remains on your LAN, a slow result points toward WiFi, switching, cabling, or the client rather than the Internet connection.

It is possible to run this on the uhttpd server used with OpenWRT, although you’ll need to coax it to measure upload speeds since the server can’t handle the default method. The trick is to create a CGI script that accepts a large amount of data successfully and then configure uhttpd to run that.

A browser-based local test is convenient, but for serious diagnosis it is hard to beat iperf3, the client/server tool we recently used while testing mesh routers. On one machine (say, 192.168.1.100), start the server:

iperf3 -s

From another machine, run:

iperf3 -c 192.168.1.100

By default, iperf3 uses one TCP connection. Add -P 4 to try four parallel streams, or -R to reverse the direction so that the server sends and the client receives. Those variations can tell you something. If four streams are much faster than one, the network may have enough aggregate capacity but a single TCP flow is being limited by latency, loss, window growth, CPU performance, or offload behavior. If the reverse test is much faster, examine the weaker machine’s transmit path, drivers, antennas, or CPU.

iperf3 can also generate UDP traffic at a specified rate and report packet loss and jitter. That is often more informative for evaluating a wireless link than merely chasing the largest TCP number.

Can Linux Make It Faster?

Linux offers an impressive array of network tuning knobs, which naturally tempts us to turn them. But first, you need to understand what needs tweaking.

Check the negotiated Ethernet rate and interface counters:

ethtool eth0
ip -s link show eth0

A gigabit adapter that has negotiated 100 megabits per second usually has a cabling, connector, or switch-port problem. Increasing TCP buffers will not repair it. Rising interface errors and drops point toward a physical, driver, or congestion problem. TCP retransmits (view with ss -ti) may indicate loss elsewhere on the path.

You can inspect the active queue discipline with:

tc qdisc show

Linux supports queue disciplines such as fq_codel, which combines per-flow queueing with active queue management. It attempts to prevent one large transfer from building an enormous queue and delaying unrelated interactive packets. The kernel documentation specifically lists fq_codel as a sensible queue discipline that works without extensive configuration.

It can be selected as the default for newly created interfaces with:

sudo sysctl -w net.core.default_qdisc=fq_codel

That may improve queueing on traffic leaving the Linux machine. It does not, however, fix a large queue in the cable modem or Internet router. Queue management must be applied at the bottleneck. If the ISP link is limited to 20 megabits upstream, controlling a queue on a gigabit Ethernet interface after it has already handed packets to the router is too late.

For a home connection, the most effective bufferbloat treatment is usually Smart Queue Management on the router. OpenWrt’s SQM system supports both fq_codel and CAKE. CAKE generally provides better performance. However, fq_codel requires less CPU overhead.

High-latency paths introduce a different problem. TCP must keep enough data in flight to fill the bandwidth-delay product. Modern Linux generally autotunes TCP buffers, so the old advice to assign enormous fixed values to tcp_rmem and tcp_wmem is less universally useful than it once was. Before changing them, use ss -ti during a transfer and look for retransmissions, round-trip time, congestion-window size, and whether the receiver window is actually limiting the connection.

Linux also supports selectable TCP congestion-control algorithms:

sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control

Algorithms such as BBR can improve throughput and queue behavior on some long-distance or lossy paths. But changing the algorithm affects connections sent by that Linux machine; it does not control the remote speed-test server, repair poor WiFi, or eliminate a queue in the router. Congestion-control tuning is therefore a useful experiment for a server, VPN endpoint, or long-haul transfer machine — not a universal solution to slow networking.

Finally, inspect hardware offload features when a Linux system cannot keep up with a fast LAN:

ethtool -k eth0

Advanced network tuning is a bit beyond the scope of this post, but there are plenty of roadmaps down this rabbit hole.

The Lesson

The lesson here is that there is no universally correct speed-test result. Ookla tests how effectively multiple transfers can fill a route to one of its servers. M-Lab examines a single bulk flow. Fast.com tests the path to Netflix. Cloudflare pays unusual attention to latency under load and overall connection quality. OpenSpeedTest and iperf3 can determine whether the Internet connection is even the problem.

Run enough tests, and you will eventually obtain a number worth bragging about. Run the right tests, though, and you may find ways to truly increase real-world performance. If you want to chase that extra 1 kbit per second speed, be our guest — we know how it is. But the truth is that if the Internet is doing what you want it to do, then it is fast enough.

The combination of hardware required to make use of this project is specific enough that we imagine only a relatively limited number of readers will actually be able to try it out. But if you do happen to own a YubiKey and either a laser engraver capable of marking it or a fancy UV printer, [madeinoz67] has put together an awesome tool for adding some visual flair to your two-factor authentication device.

Running it is as simple as opening a web page, because that’s exactly how it’s implemented. You can either host it yourself or just launch it right from the GitHub repository. After opening the HTML file, you’re presented with a fairly intuitive user interface that lets you draw on top of a 2D outline of the YubiKey itself so you can get a better idea of what the final product will look like.

You can pick from an array of vector icons, upload your own images, and add custom text. There’s a pull-down at the top that lets you pick which specific YubiKey you want to work with, and there are different views depending on whether you plan on blasting your handiwork onto the device with a laser, doing a full-color UV print, or cutting it out of vinyl with something like a Cricut.

Even if you don’t have a YubiKey that’s begging for some custom artwork, we think there’s a lot to learn from this project. Obviously there are some very valid reasons to be concerned about how much of our modern software can only be accessed through a browser. If you’re going to use web technologies to create a piece of software, the least you could do is make it offline and self-contained like [madeinoz67] has.

Now if you’ll excuse us, we’ve got to go warm up the UV printer.

Sometimes that retro gaming itch strikes, and you just have to source components for a Pentium 4 build, like [Computer Retro Bus] did recently. Unfortunately, along the way he learned that you can actually get counterfeit mainboards. Case in point the purported ‘Asrock P4i45GV’ that was purchased as the core of this Pentium 4 build, which turned out to have many issues that included a fake AGP slot.

The mainboard was bought off Facebook Marketplace, with the first sign of trouble being spotty GPU support for the AGP slot, and an inability to install a driver for a card that seemed to work. Following this, issues with the installed Soundblaster soundcard popped up, with the use of Windows ME as OS being of course a factor, but even ME is generally not this sketchy.

At some point he decided to actually dig into this Socket 478 mainboard that he had purchased, only to find out that there was a reason why there were no real markings on it. After an image search it turned out to be a clone of the aforementioned Asrock mainboard, including the original’s ‘feature’ of connecting the ‘AGP’ slot to the PCI bus. This explained why only the AGP GPUs that are compatible with PCI worked with this mainboard, as it’s actually Asrock’s ‘AGI’ slot.

Effectively just a way to scam buyers into believing that they bought a mainboard with an AGP slot when it was just a regular PCI slot cosplaying as an AGP slot. This doesn’t just mean lower speeds and spotty support with AGP cards, but also also potentially dead GPUs, as this mainboard inherited the same 3.3V-only card support.

Unlike PCI slots that are keyed for 3.3/5V voltage support, AGP slots are keyed for either 3.3V or 1.5V, or no key for universal support. These ‘AGI’ slots are sadly keyed for 1.5V AGP cards and thus will expose 1.5V-only AGP cards to potentially fatal voltages.

On the bright side, these are at least genuinely old mainboards, using the same AGP-less Intel chipsets, made back in the day to sell to unsuspecting buyers. Clearly the pain that these fake boards as well as genuine Asrock boards that these ripped off caused back in the day continues in 2026. Caveat Emptor, as they say.

In an ideal world, the role of technology would be to make all of our lives easier. And although all the ads suddenly appearing in our smart TVs and gaming systems might make it seem otherwise, some technology can still improve our lives if we work hard at it. For [Cian], that meant training a neural network to read his gas meter so he wouldn’t have to do it himself.

The root issue here is twofold, first that [Cian]’s gas company hasn’t upgraded their own technology to modern, remote-readable meters, and second that the meter can’t be read by a gas employee because it’s hidden in the depths of [Cian]’s basement. This latter fact requires him to delve into Moria-like depths to get to the meter, so the solution here was to place a Raspberry Pi in this location instead. With a camera pointed at the meter, it’s not quite capable of discerning digits on its own so a neural network was trained in order to get accurate readings of the dial. And, finally, since the machine is networked already [Cian] set it up to automatically notify the gas company of its reading so he is now completely out of the loop.

For automating tedious tasks like these, the Raspberry Pi with something like OpenCV as a computer vision tool is a fairly mature platform for light machine learning duties like these. We’ve seen license plate readers as well as neighborhood traffic surveys built on these platforms to help automate human labor away, making our lives easier one single-board computer at a time.

Have you ever found out that something you remember from your youth is now gone, and you didn’t even notice? If you are a certain age, you might feel that way when I deliver the news: You haven’t been able to buy International Reply Coupons (IRCs) at a US Post Office since early 2013. By the end of 2026, you won’t be able to buy them anywhere. The age of the IRC is over.

What’s an IRC?

If that didn’t mean anything to you, you might be too young to remember, or maybe you just weren’t into shortwave listening or ham radio. Although there were other reasons to get IRCs, a radio hobby is the most likely reason a Hackday reader would have bought an IRC.

For radio purposes, here’s the problem. You’ve worked on your station for months, and one winter night, you finally pull in that rare station from Luxembourg. They’ll send you a QSL card to verify that you heard them. You only have to send them a letter telling them what time you heard them, what frequency, and some details about the program you heard. But they probably don’t want to pay the postage required to send hundreds or thousands of cards overseas.

While this is a radio-specific problem, you might find the same issue with pen pals or when trying to buy things from an overseas company.

SASE

If everyone were in the same country, the solution would be easy. Take a stamp, put it on an envelope that has your address on it, and stuff it in with the letter. Or, you could just drop a stamp or two in the letter you sent.

The problem is, US postage won’t help Radio Luxembourg. On the other hand, the effort required for you to buy postage that works in Luxembourg would have been a nightmare.

Enter the UPU

The Universal Postal Union is a UN agency that is effectively an association of post offices in 192 countries. Their charter is to facilitate mailing things worldwide.

The IRCs date back to 1906. The idea is you buy an IRC at your post office. You send it to Radio Luxembourg, or wherever. There, the mail person at the radio station could go to their post office and trade the coupon for enough local postage to send a surface letter worldwide.

Slow Death

As demand has dwindled, post offices worldwide have quit selling IRCs. As of last year, Australia still did. But Germany, Britain, the United States, and many other countries gave up on them long ago. In fact, Britain’s Royal Post claimed that the average post office sold less than one IRC per year at the time it threw in the towel.

UPU decided to end IRCs altogether by December 31, 2026. The end of an ear and, apparently, not just for radio hobbyists. It is telling that the UPU’s recent editions of IRCs had print runs of 1,000 or even 500. So they obviously weren’t selling very many.

IRCs Other Claim to Fame

If you’ve heard of these before and you aren’t interested in radio, then it might have been in economic history. Have you heard of the Ponzi scheme? It has become a generic term for any business scheme that relies on raising money from new investors to service debt owed to old investors.

However, the original Ponzi scheme dates back to 1920, when Charles Ponzi realized he could buy IRCs in a country where they were cheap and sell them for more in another country. He was happy to accept investors, of course.

The problem is that profits are thin, and the costs of acquiring and transporting large numbers of IRCs quickly swamp most potential profits. Fluctuations in currency exchange rates take the rest.

Goodbye!

So the end of the IRC marks a closed chapter for ham radio and swindling. There were probably other uses, too, that are now consumed by electronic mail, payment systems, and the like.

You have to wonder what adventures IRCs went on during their global travels. The video below shows one’s story.

What if you want to do something in Linux for a lot of files? [Numerator] was tired of using xarg and other ways to handle this job and created bashumerate.

Some examples in the post of the “other ways” include:

find . -name '*.log' | xargs rm
find . -name '*.sh' -exec wc -l {} \;

You can, also, use a for loop, and if you are a programmer at heart, you may well do this:

for f in *.txt; do
  wc -l "$f"
done

Bashumerate handles all of the common cases in one tool and uses the same syntax for multiple kids of enumerations.

For example, the above translates to:

enumerate -f '*.sh' -- 'wc -l {}'

The -f means enumerate files. You can also enumerate lines, numbers in a range, or lists. What’s even more interesting is that you can add your own source. As an example, there’s an add-in function that enumerates running docker containers.

The source is all in bash, so it should be very portable. Will you try it? What’s your favorite way to enumerate in shell? Let us know in the comments. You know how we love strange bash tricks.