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.

Chimera Linux founder q66:

At the point of entering alpha, the cports tree had roughly 1000 templates, most of them in main. There was a single large desktop (GNOME) and a single major web browser (Firefox) and an assortment of other software.

At this point, the tree contains ~2800 templates, i.e. almost 3x more. We have all major desktop environments, all major browsers, and overall much larger collection of both small and large programs.

The repo was also at ~6000 commits at the time, by 11 authors; now it’s almost 20000 commits, by over 100 authors.

Significant under-the-hood improvements have been made in service management, our build infrastructure, the cbuild build system which is now significantly more powerful and has much better UX, global switch to the mimalloc allocator, stateless /var and progress towards stateless /etc, improvements in core userland, introduction of libdinitctl, introduction of sd-tools, and a lot more.

My favourite up and coming Linux distro continues to mature. I’ve been running it since the alpha release in June 2023. I’m now running it on three servers (the ones powering this website), as well as in WSL on my laptop (where I’m writing this post), and dual booting my desktop.

If you haven’t encountered Chimera Linux before, the project aims to build a Linux distribution that sheds some legacy baggage, and is smaller and easier to understand. To achieve this it combines the Linux kernel, LLVM toolchain, musl libc, FreeBSD userland, dinit init, apk package manager, and home grown cports package build tooling. There’s more details on the about page.

Julio Merino:

One reason for this choice is NetBSD’s build system. Once you look and get past the fact that it feels frozen in time since 2002, you realize it is still one of the most advanced build systems you can find for an OS. And it shows: the NetBSD build system allows you to build the full OS from scratch, on pretty much any host POSIX platform, while targeting any hardware architecture supported by NetBSD. All without root privileges.

Good insight into the NetBSD build system, and how to use it to cross-compile a custom image for a Raspberry Pi. In particular how it achieves unprivileged builds without tools like sudo or fakeroot is quite neat.