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.

Fish shell project:

About two years ago, our head maintainer @ridiculousfish opened what quickly became our most-read pull request: #9512 - Rewrite it in Rust.

Now that we’ve released the beta of fish 4.0, containing 0% C++ and almost 100% pure Rust, let’s look back to see what we’ve learned, what went well, what could have gone better and what we can do now.

We’re writing this so others can learn from our experience, but it is our experience and not an exhaustive study. We hope that you’ll be able to follow along even if you have never written any rust, but experience with a roughly C++-shaped language should help.

“Rewrite it in Rust” (RIIR) is often a joke or unwelcome suggestion from uninvested bystanders. However, when it does happen it’s great to get a detailed first-hand retrospective like this to inform others considering something similar. Overall it seems like the rewrite was a success with a few of the usual missteps that come along with a rewrite.