Antranig Vartanian:

Initially, when I heard about freebsd-rustdate I was very skeptical. I have a fear of “Written in <new hip language>”. I thought, however, I’ll wait, and when the time comes, I will try and see how it works.

For the last couple of days I’ve been updating hosts and jails for my customers and my company, and one of the best resources I found was the FreeBSD Update page on FreeBSD’s Wiki, specially the “ freebsd-update Reverse Proxy Cache” section. It has saved me hours when updating the hosts. For some hosts we even did an NFS mount of /var/db/freebsd-update/files directory.

But when it came to upgrading the jails, I realized that this is going to take a very long time. Each host has at least 15 jails, up to 50. There’s a host which has 100+ jails.

I arrived to my parent’s house, installed freebsd-rustdate on a host, and tested it on a single jail. Here is my initial reaction:

holy fuck freebsd-rustdate is fucking fast

freebsd-rustdate by Matthew Fuller is a compatible implementation of the freebsd-update tool used to update the base system of a FreeBSD installation. As the name suggests it’s implemented in Rust, in contrast to freebsd-update, which is implemented in shell script.

The freebsd-rustdate website includes a lot of information about the motivation for the tool, how it achieves its speed, and some differences from freebsd-update. Picking one example from the speed page:

OK, let’s get serious now. Add /usr/src into the mix. Again, going from 13.2-RELEASE to 14.0-RELEASE-p10, but now we have to touch the filesystem a lot more. North of 90k paths.

freebsd-update:

• -r 14.0-RELEASE upgrade takes a painful 5:51.
• install is a staggering 24:38.
• As above, these numbers are for 14.0-RELEASE-p9; it’s close enough.

freebsd-rustdate:

• upgrade -r 14.0-RELEASE takes 5 seconds.
• install -a takes 1:41.

Ash Wolf:

I’m a bit of a retro tech enjoyer, but I’m also pretty bad at it – I don’t have the space or the motivation to try and acquire actual old computers. Playing with 86Box/PCem is pretty fun, but it’s not quite the same.

So, instead, I make do with what I have. And the most ridiculous x86 machine I own is the Asus Eee PC 1000H, a netbook that I got in 2008 when that category was still new and exciting. It’s borderline useless nowadays (it can’t even run most up-to-date Linux distros due to its lack of x86_64 support), so sticking weird and anachronistic OSes on it is one way to keep it relevant!

I’d like to write a full-fledged blog post about these adventures at some point, but for now I’m going to focus on one particular side quest: getting acceptable video output out of the 1000H when it’s running Windows 3.11 for Workgroups.

Strap in this is a long one, but as with most technical deep dives into software and hardware of yesteryear it’s fascinating. Kudos to Ash for persevering with this project, making some sense of the situation, and finding some solutions to the issue. Extra kudos for writing it all up for us to enjoy—complete with screenshots and a nice site design.

Diana MacDonald:

What does it look like to retire a web project? I don’t hear about project endings as much as project beginnings. Even then, among endings I mostly hear about failures. People tend to share stories of the aftermath of train wrecks more than quiet, satisfied conclusions. So I wanted to contribute my little story of retiring a silly pet project: Label Your Icons.

I get a mention in this post, which covers a bunch of considerations for winding down a website without breaking links on the internet. There’s also a bunch of tips for making maintenance of side projects easier.

Personally I try to archive a site and use redirects where possible. Most recently I did this with decentralised.social, where I replaced a Pleroma instance with static HTML.

I needed to minimise the amount of effort required to maintain the site. Static sites are a lot easier than dynamic sites to update over time. Buildless projects are a lot easier to keep running than projects that use complex build systems.

You really can’t beat a static HTML and CSS. We’re spoiled for choice with static site generators nowadays too. If you pick your static site compiler carefully it’s likely to be very low maintenance. My personal favourite is Zola, which is just a single binary—no runtime or dependencies to manage.

James Thomson:

So, we are coming up on a little anniversary for me this weekend. On the 5th of January 2000, Steve Jobs unveiled the new Aqua user interface of Mac OS X to the world at Macworld Expo.

Towards the end of the presentation, he showed off the Dock. You all know the Dock, it’s been at the bottom of your Mac screen for what feels like forever (if you keep it in the correct location, anyway).

The version he showed was quite different to what actually ended up shipping, with square boxes around the icons, and an actual “Dock” folder in your user’s home folder that contained aliases to the items stored.

I should know – I had spent the previous 18 months or so as the main engineer working away on it. At that very moment, I was watching from a cubicle in Apple Cork, in Ireland. For the second time in my short Apple career, I said a quiet prayer to the gods of demos, hoping that things didn’t break. For context, I was in my twenties at this point and scared witless.

Not sure how loved the Dock is these days, but it certainly made for impressive demos in the early Mac OS X days¹. James writes about his experience at Apple working on an early implementation of the Dock that was developed as part of the Finder on Mac OS 9.

Itamar Turner-Trauring:

What can you as a software developer do to fight climate change? My first and primary answer is getting involved with local politics. However, if you write software that operates at sufficient scale, you can also reduce carbon emissions by making your software faster.

Itamar tackles a tricky topic in this post, performing tests to compare implementations of different efficiency. At the same time that’s kept in perspective with other carbon emitting activities:

This suggests that if you’re writing software that isn’t widely used, making it faster isn’t particularly impactful activity from a climate perspective, even if it’s a generally useful improvement. So if you want to take individual action outside of political engagement, you’re better off switching from beef to chicken (or better yet, beans), or swapping your car trip for an e-bike ride.

In a related post, Gathering Data On TLS Power Draw Measurements, Nicolas ‘CounterPillow’ F. argues using a small experiment that the use of TLS does not constitute a significant contributor to climate change. That’s not to say it’s not worth making your software more efficient—especially if it has any kind of scale—but to keep it in perspective with other actions you can take.