rob.rho.org.uk

On a recent episode of ATP, Casey mentioned that one of the issues with an ultrawide Mac display, such as the one now provided by the Vision Pro, is the long trek to the left side of the screen to access the menu bar. This wasn’t an issue in 1984 when the screen was only 9”, but as displays have grown it’s become more and more of a factor. This apparently lodged somewhere in the back of the brain, and percolated up again in the form of a strange idea:

(Click for a full width version — this is of course a mockup, rather than implemented software.)

The idea is hopefully simple and obvious; the menus, starting with the Apple menu, starts in the centre of the menu bar and goes left, whereas notification area, starting with the clock, grows to the right, again from the centre. On modern Mac laptops this means they grown from either side of the notch, as shown, but on older hardware and external displays the Apple menu could act as an anchor.

This design stems from the observation the the easiest place to reach on the menu bar is the centre, rather than either end. Traditionally, the most used items are placed at the extremes (for example, the application and File menus, and the clock and control centre) — these end up closest to the centre¹.

The only downside of this change is that you only have half the available width for each side of the menu bar, but Apple have largely crossed that bridge by introducing the notch, and in my experience it doesn’t seem to be a major problem in practice. The new design would require a different solution (perhaps an overflow menu?), but it seems like a win overall.

I don’t expect that Apple will make this change, but if they did it wouldn’t be entirely without precedent. Way back at the turn of the millennium, Mac OS X Developer Preview 3 put the Apple menu squarely in the middle of the menu bar, mirroring the placement on the iconic iMac. That never made it to the final release, but perhaps it’s an idea who’s time has come.

Back in July, I encountered a bit of weirdness in the way that the ZX81 addresses RAM when it only has a single kilobyte. I was reminded of this listening to the latest episode of Risky Business, which reported on an interesting and decidedly 21st-century attack.

AMD’s recent processors offer SEV, a suite of features to protect Virtual Machines from compromise even when the attacker (say, a cloud hosting provider) has physical access to the processor. The BadRAM undermines a key plank of this in a pleasingly straightforward way, by causing the system to report that it has twice as much RAM as it actually has. Just as with the ZX81, the additional bit of the address (just the one in this case) is ignored, meaning each physical location can be referenced by two address. One of these is correctly protected by SEV, but the other is up for grabs.

It’s some fascinating security research in its own right, but also highlights the similarity of computers today and those of forty (and more) years ago. We’ve added many layers of capability and complexity, and scaled up by orders of magnitude on every axis, but underneath all of that many of the fundamentals are unchanged. Understanding those fundamentals is still important.

About the same time as my educational foray into multicolour printing¹, I decided to put the printer to work doing something useful: my first functional print. I had an almost-complete design already, that I’d produced while getting started with OpenSCAD, so it was just a matter of turning it into reality.

Regular readers may recall my project at the start of the year to revive a Mac SE in honour of the 40th anniversary of the Mac itself. At the heart of that was a BlueSCSI SCSI emulator. I chose to mount this internally in the location of the old hard drive, which was great for preserving the feel of the machine, but made access to the SD card storing the data an issue. I alleviated this somewhat by adding a simple extension adapter, but there was no easy way to mount it, and so it just dangled out of the back of the case.

The obvious solution was to make a custom blanking plate to fit into SE slot in the back of the Mac (if you’re not familiar, picture a PCI slot and you’re in the right ball park), with a hole sized to fit the extension cable’s card reader. This turned out to be pretty straightforward and a good started project in OpenSCAD (the leftmost image). I exported the design, imported it into Bambu Studio (the middle image), and sliced and printed it without issue.

I tried the finished piece in the bracket into which it would be installed, and found a few things. Firstly, I’d assumed I’d be using small self-tapping screws to fix the plate in place, and designed in a couple of pilot holes. On the off chance I tried a couple of M2 bolts I had laying around, and these fit perfectly. Less positive was that my measurements had been a bit off — the screw holes were a few millimetres too close to the centre, and the slot for the card reader was a little too small.

I grabbed a set of files and started to try and correct the latter problem, but the realised that I didn’t need to. I could just go back into OpenSCAD, adjust the model, and print out another version. While there, I made the whole panel a little thicker as well. This new version was spot on, and I epoxied the reader in place (the rightmost image), and reassembled the Mac with its new, tidier storage.

This workflow wasn’t something that I’d thought about, but on reflection is a major advantage of having your own 3D printer rather than using a service or MakerSpace. A key use case for 3D printing has always been rapid prototyping, and this still applies when the final item is 3D printed itself. Printing another version of a part isn’t as light-weight or cheap as recompiling software, but it’s a hell of a lot cheaper than fabricating a silicon wafer or retooling a factory. Having a (relatively) rapid turnaround means you can iterate on a design and get to the best final version quickly, rather than try to anticipate every problem up front, and bodge the ones you don’t catch for a sub-optimal result. It brings some of the agility of software into the real world.

When I took the plunge and bought a Bambu A1, I got the AMS Lite multi-material system that allows you to load four different filaments at once and automatically switch between them. I decided to go for this as it’s significantly cheaper to get it bundled that buy it at a later date, and it seemed like a big step up in quality-of-life in terms of not having to swap spools all the time, and automatically switch over to a new one when the old one runs out.

The headline capability of the AMS Lite, though, is multicolour printing. I don’t see myself doing much of this, but it’s nice to have the option, and after I’d tried a few standard prints with the included filament sample I decided to give it a go. The way the AMS implements multicolour printing, namely swapping multiple filaments in a single print head, entails quite a bit of overhead both in time, and in waste plastic as the printer flushes out the previous one. However, I’d not quite steeled myself for just how much an overhead this was.

Firstly, time. The standard, single-colour Benchy that was my first print took 21 minutes. In contrast, the identically sized four-colour Benchy I found as a test¹ took over nine hours — so long that we had to pause overnight (on the plus side, the print resumed perfectly in the morning). This is a massive increase, but in the grand scheme of things is probably manageable.

More striking is the amount of waste plastic. Every time the printer feeds in a new filament, it needs to extrude a small amount of plastic to clear out the nozzle. Each poop (this appears to be the term of art) is only a fraction of a gram, but if you need to do up to four for each layer, over hundreds of layers, it adds up. Moreover, when printing multicolour, it’s also advisable to print a priming tower, an extra area on each layer to ensure the new colour is coming through cleanly before printing the model itself. Together, the tower and the poop added up to more than ten times the material used in the model itself:

This model is intentionally a bit of a stress test for multicolour prints, but nevertheless isn’t doing anything pathological — it’s probably a good analogue of what you’d get if you applied colour to an existing model without any particular thought about optimising it. That said, I also didn’t put any effort into the print settings; I just hit go.

The amount of waste in this print is somewhat shocking, but it represents a worst case. This video contains some tips to significantly reduce waste, and the latest version of Bambu Studio is smarter about the purge amounts between different pairs of colours (basically, you need to purge less going from a lighter colour to a darker one). What’s clear is that this isn’t going to be something that works straight out of the box; a bit of effort and thought is required.

One key takeaway is that the waste is very dependent on the number of layers, rather than the volume of the model as a whole. Hence, I can see myself using it for things like signs — large, flat pieces that would benefit from embedded colour changes but have relatively few layers. This seems like an instance of a larger point; you need to consider the printability of your model throughout the whole process, rather than just throwing it into the slicer at the end and assuming you’ll get good results. It’s this kind of lesson that makes picking up a new hobby enjoyable.

Back in the early 2000s, when I first bought this domain and started this site, self-hosting your own email was common. If you were running a personal web server, it was just something you did. Over the years, though, things got more complicated. An arms race developed between spammers and anti-spam technology, and for your email to be useful you needed to keep up. Encryption became an increasing requirement, bringing with it the hassle of managing certificates. Later, an alphabet soup of technologies (DKIM, DMARC, SPF) sprang up that you needed to follow to prove you were a legitimate sender. All of this happened against a background of email becoming increasingly centralised — if you weren’t one of the big providers, it was hard to get your mail delivered at all. By the start of this decade, the received wisdom was that hosting your own email wasn’t a practical option.

Through a combination of inertia and ill-advised pigheadedness, I’ve been a holdout. However, I was starting to waver — even though I jumped through all of the hoops, and was careful not to be running an open relay, my mail was still finding itself on the naughty list more than occasionally, and I was contemplating throwing in the towel and moving to Fastmail or similar. Then I came across this one weird trick that solves the problem, and with the move to Mythic Beasts I finally got around to fully implementing it.

I’ve been using Mailroute for years for spam filtering. The integration is incredibly simple and clean — you just point your MX record to their servers, which scan and filter the incoming mail and then pass the legitimate messages on to your own server via normal SMTP. About a year ago I decided to investigate their outbound service, included in the subscription, and realised it would address the deliverability problem.

Again, it’s a very simple integration; you just configure your MTA to send all outbound mail to theirs, and they’ll route it on. The mail clients on your laptop or phone still talk to your own server; Mailroute’s is limited to specific IP addresses to prevent abuse. The net result is that your mail gets sent with their reputation, and maintaining that reputation is the responsibility of experts who are paid to do it. Even better, it means you no longer have to run an MTA accepting connections from the entire internet, and so can sleep a little easier.

When setting up my new VM, I decided to ditch my decades-old, crufty Exim configuration and start afresh. I’ve now got a largely stock “smarthost”, with a few local tweaks, and everything is running like clockwork.

Mailroute isn’t the solution for everyone; in particular, the price quickly mounts up if you have multiple users. Self-hosting email itself is probably not the right option for most, either — there are plenty of good managed email providers, and as long as you own your domain you’re not tied to the first you pick — but, if you do want to give it a go, Mailroute or a similar intermediary solves a lot of the problems that have cropped up over the years. There aren’t many of us left, but we can hold out at least a little longer.