Recent Posts

I think, in part, I regret upgrading any of my Apple devices to the 27 line of operating systems. While my experience as a whole has been pretty favourable, the one thing I was looking forward to is not just disappointing, but is a huge step backwards.

I don't use Siri for many things, but I do use it a lot for a small number of core things. On any given day I'll lift my watch up and speak to it to set a timer or a reminder. Occasionally I'll ask other things, but they're the main uses. Thanks to the fairly recent addition of on-device voice handling, these requests have been near-instant.

With the new Siri that comes with iOS 27, etc., if I'm really lucky the reply will be super slow (getting on for 20 seconds or so to do the job), but more often than not it just doesn't work at all. Either it tells me that my main device isn't available right now¹ (which I take to mean my iPhone, which is wild given it's always in my pocket at the time), or it just busy spins for ages and then simply times out and does nothing.

If I try to use Siri on the iPhone itself, it either just busy waits for ages without getting anything done, or it finally tells me it isn't working.

I was one of the people who upgraded to the 16 Pro because of the promise of "Apple Intelligence". I was, unsurprisingly, kind of annoyed that they didn't deliver. But it was fine, the phone is a good one and it's still serving me well. Also, if I'm honest, I was comfortable with the idea that they chose to not really implement anything² rather than implement something bad.

Sadly though, based on my experience so far, they've implemented something bad. Since upgrading, on the Watch and iPhone, I've found that it's either horrifically slow or it just doesn't work. On top of that, I've lost all the benefit of the on-device voice handling of my watches.

Actually a little sooner than I was expecting -- look what turned up today!

When I saw this morning, based on tracking, that it had made it to the national distribution centre down in England, I was expecting it to head up this way today and perhaps be out for delivery tomorrow. But, no, a little later in the morning I got an email to say it was up here and would head out this afternoon.

I probably won't be giving it a spin this evening, mainly because I had plans to stream some more Atomfall and I'm actually really into the story right now. The other reason is that I'm still waiting for the charger and ergonomic pack to show up. Not that I need them (it's not like I don't have a charger that'll work), but it would be nice to have those extra items to hand when I first have a play.

Realistically, I'm probably not going to get the chance to fire it up until Friday evening. That's fine, I'm in no rush. I've gone this long without playing much VR; a couple more evenings won't hurt.

Meanwhile, I've found out that Gunman Contracts - Stand Alone will actually work in standalone mode on the Frame. Yes, I know the name might suggest that, but the "Stand Alone" in the name is in reference to the fact that it's no longer an Alyx mod. This makes me quite happy. This is a game I've been looking forward to playing for a couple of years now and the prospect of being able to dive into it on the Steam Frame, without needing to faff with my PC, very much appeals.

I'll be sure to jot down some impressions once I've had a proper session.

I've just made a small update to GopherMap. While doing some work on Rogallo I noticed that, somehow, I wasn't showing a type "badge" for PNG files (p). I spent a moment or two trying to figure out what was wrong with the code in Rogallo, and then realised that I'd managed to miss out both PNG and RTF files in GopherMap itself.

So this release adds those types.

At this point I believe that GopherMap now knows about all the canonical and most useful non-canonical types.

At some point I should probably look at Gopher+, which I suspect will also mean some changes to Port70.

I sat down at my desk at about 08:40 this morning and, five minutes later, got an email from Valve to say they were preparing my Steam Frame for shipping! On visiting the site, it said it was shipped.

Checking with the carrier, there's the usual message to say they're aware of the package but haven't picked it up yet. At this rate, it does look like I'll have my hands on it this week.

Time to have a proper look into what games and apps will run standalone on it. The updated Alyx I know about (which does have me wondering if the workshop items will work -- the original Gunman Contracts should be fun), but I've not really checked yet what other actual VR titles will run without the need for a PC.

It looks like things are moving a wee bit quicker than I remember when I bought the Steam Controller, with the status of my Steam Frame purchase moving to "packaged" pretty quickly.

I'm curious as to when it will arrive. The small number of times that I've purchased Valve hardware, I've generally found the actual shipping (once it's shipped) to be reasonably swift.

I could be in the position of being able to play with my new headset before next weekend. While I'm most interested in the standalone experience, I might have to dig out the VR gaming PC, update a bunch of things on it, and give it a general tidy. It's getting on a bit now, but it will be interesting to test out the wireless PCVR mode.

I didn't have to spend too long in the Steam Frame reservation queue. I'd just sat down on the sofa, after having dinner yesterday evening, opened the MacBook to hack on some code, and had this turn up:

I didn't hesitate. However, during the checkout journey, there was a glitch. I opened the email, clicked on the link to go and confirm the purchase, and on the Steam site I was greeted with a message to the effect that the quantity I was buying was too great! It wouldn't let me proceed to the payment. I clicked on the button to view my basket and this is what I saw:

This did make me slightly nervous for a moment. It was an obvious glitch, but was it double-counting the same unit, or had it somehow added two units to my basket? Given that I couldn't progress without doing something, I removed one and... it was all okay.

So as of right now I'm paid up, I have an active order, and now I wait for physical delivery. The estimated delivery time seems to be between 3 and 5 (working?) days.

Meanwhile, I now need to figure out what to do about prescription lens inserts. The inserts that Valve recommend on the Steam Frame page are currently "coming soon", which is mildly annoying. I have noticed in the Steam Frame subreddit a couple of people mentioning other companies who are already manufacturing and shipping inserts. I might take a look at them.

The need for prescription lenses is one annoyance of VR for me. Sure, it's easily fixed, but it's a bit of a shame when, upon opening the box, I have to go with a blurry experience for a wee while. Of course, I could wear my glasses in the headset, but based on my experience when I got my Quest 2 back in late 2020, that's not comfortable and there's the danger of scratching the glasses, headset lenses, or both.

It's not worth the risk.

It's getting on for six years now since I got my first VR headset, and it's the best part of five years since I sorted myself with a PCVR setup. Between then and now I've played a lot of VR games and spent a lot of time in VR.

This last year, though, aside from a quick dabble with the PS5 version of Zero Caliber, I've not really been in VR. Mostly this is down to me moving late on last year, and evenings and weekends now being busier with other things. It's sort of always felt like a hassle to have to set up the PCVR rig (when you live alone it's fine to have your PCVR rig lying around the living room all the time; when you share with other people and your cat... not so much).

So when I saw the Steam Frame announced and realised that it would likely give me standalone access to some PCVR-level games (yes, I know, not really PCVR, but I would hope that there will be a push to get many games running standalone), I was tempted. Very tempted. Not only does it offer a good-quality standalone headset, it's also still designed as a full PCVR headset. Feels win/win.

Fast forward to yesterday evening...

I don't know that I'll return to recording PCVR quite yet -- I guess that'll depend on what the Frame offers in terms of being able to record -- but I aim to dive back into any parts of my catalogue that will work with the device. I think a full revisit to the world of Half-Life is necessary if nothing else.

Late on last week I was doing a PR review at work and noticed that, for some odd reason, the author of the PR seemed to have absolutely nuked all of the indentation in the code. While not a problem given the nature of the files I was reviewing, I wasn't happy with their apparent disregard for style and good practice, and was about to leave a remark and a request for changes. But something seemed off. So I did a refresh of the page and... everything fell into place.

Weird.

Since then I've seen the issue on multiple machines. To be fair, each time it's been in Safari, and each time I've been busy with something else so haven't had the chance to really dive into it. But given it's suddenly cropped up, at the same time, on multiple machines, with nothing else changing, it feels like something on the GitHub side of things.

Perhaps I'm letting a bit of bias creep in here, but I feel like this sort of thing is happening more and more on GitHub. It's not that long back since social previews suddenly broke, for example. It's hard to shake the idea that changes are being made without regard to comprehensive testing, and likely without regard to how things connect.

Now, at this point, it would be easy to reach for the "well they're obviously using agents to do most of the work" argument -- and I'm sure plenty of people would -- but that doesn't quite fit with my experience. Having experimented with such tools for a good chunk of this year now, both for personal and, more recently, professional projects, I've generally found that such tooling easily helps with catching such issues.

Plenty of times now, when using something like Antigravity or Claude Code to work on some code, I've found that with reasonable care (you know: the sort of care you'd put into your work anyway) you can quickly and easily uncover connections and knock-on effects you might not have immediately noticed. Moreover, if LLMs are useful for anything when it comes to coding, it's for writing tests¹. With that in mind you should be able to reasonably expect the number of silly bugs to go down.

Unless, of course, there's no human in the loop anywhere, or the human in the loop lacks adequate training and experience, or, I guess, they simply lack the ability to give a shit.

I wonder when this particular issue will get fixed? I should probably go and see if it's reported in the GitHub forums anywhere. I know for sure that there's little point in actually reporting it as a bug; my experiences with that in the past haven't been great, and the GitHub subreddit has seen enough stories of people getting nowhere.

I've released Rogallo v2.4.0, which contains two new features.

The first is the addition of a feature related to the Gemini Protocol, and it's something I've been meaning to add for a wee while: a trusted host browser/manager. It's a simple enough idea: you might want to have a look at all the host/port pairs that exist in your trusted hosts list and, perhaps, revoke the trust for one or more.

From the dialog you can either visit the host/port combination (perhaps you got curious about what you've trusted in the past and want to see what was there), or you can forget the trust. This also somewhat follows on from work done in Rogallo v2.1.0, except rather than having to make the decision when you visit a capsule, you can review all the capsules you currently trust.

If this seems useful, it's called up with the new BrowseTrustedHosts command, bound to Ctrl+Shift+t by default.

The second new feature is something that's been on my TODO list for quite a while, and has mainly been sat there because I wanted the viewer widget in the application to settle down a bit before I tackled this. I'm talking here about in-viewer search. It's a simple enough requirement, but one that's not that straightforward when you're dealing with views of different kinds of text files, views of the source of such documents, and also having to handle things like embedded ANSI escape sequences.

The work is now done, so if the viewer itself is focused, you can press Ctrl+f, enter some text to search for, and then press Ctrl+n to keep moving through all the hits. Once you hit the last match, you'll be told there are no more matches, but then the search will start again from the top.

You can also cancel an ongoing search with Ctrl+Shift+f.

I'm glad to finally get this added to Rogallo as it's a feature I've been finding myself needing on a good few occasions.

Rogallo v2.3.0 is now available. The main addition to this release is support for the Titan Protocol.

First up, there's a small fix. The other day I discovered Scriptonite. While looking at the examples I noticed none of them worked with Rogallo. This struck me as odd because the whole point of Scriptonite is that it all happens on the server-side; nothing on the client-side should affect how well it works.

It turns out that Wasat had a bug when it came to slicing and dicing Gemini URIs, where parts of a URI that followed a ; were being lost. Somewhat amusingly, I didn't even need to do any work on a fix because it had already been taken care of in the branch that existed to support Titan.

The point here being: as of v2.3.0, Rogallo now works fine with the Scriptonite examples.

As I mentioned, the main change in this release is support for the Titan protocol. It's been on the TODO list for a wee while, partly because I was struggling to follow the idea of it, and also partly because I'd not played with it and just didn't see the purpose. The other day I sat down and properly dived in and it finally all clicked.

With v2.3.0, if you now visit a titan:// URI, you will be presented with a rich input dialog. It is a tabbed view, with one tab being for text input/upload:

and the other being a file attachment and upload:

As per the Titan specification, there is support for setting the MIME type for the attached data. If using the text view, this will always be set to text/plain. If using a file attach/upload, you have full control over it, but it will default to the best guess based on the file selected.

There is also support for entering an upload token.

As well as supporting the core Titan specification, I've also added support for the proposed ;edit extension. This means that it is safe to enable Titan-based editing on bbs.geminispace.org, making it easier to modify text you've already written.

One final change in this release of Rogallo also relates to user input. I've given the Gemini-based input dialog an overhaul. Originally this was, by design, as simple and as bare-bones as possible. It was simply a free-text input box that would grow as you added lines, and the prompt from the server was shown as a title in the border of that box. While testing out editing on BBS, I realised that this doesn't always work so well; most of the time the prompt would get truncated.

Not a great user experience. The redesigned input box works more or less the same, but now ensures that the prompt is fully visible.

Between this change and the new Titan edit/upload dialog, I feel Rogallo is now in a good position to act as a near-zero-compromise daily driver when it comes to wandering around the small web.

I guess adding tabs will get it closer to zero. Perhaps in-terminal image viewing. Okay, perhaps a sprinkle of http(s) support too? Also...