Yesterday, a group of MIT researchers released an article titled “Sparks of Weight-Space Programming: LLMs can natively read & write neural network weights”. The piece describes a set of experiments which convincingly show OpenAI’s latest Astra model is able to understand and successfully alter raw weight data. Wowzers! It’s a rough analogy, but an LLM’s weights are sort of like its brain. A set of weights is a large pile of numbers generated during training, and an LLM’s output is derived by running input through the weights using some matrix multiplication and a bit of randomization. While the steps to generate weights are well understood, the weights themselves are extremely opaque. There’s ongoing work to try and explain how weights work, but researchers currently have a limited understanding of what these numbers do. Based on this, I was quite surprised to learn that LLMs are able to act on raw weight data — even if it’s still just in limited cases. It’s unclear if OpenAI’s model was trained on weight data. Even if it was, I still find these results surprising. The article shows the model accurately predicting what a never-before-seen set of weights was built to do, fixing another model by updating its weights, and creating new sets of weights that performed simple tasks. I would not have guessed any of that would be possible a couple of days ago. This whole thing is slightly unnerving. The whole “weights as a black box” thing has always felt a bit sketchy to me, even when I was working with much simpler machine learning models. Now these experiments hint at a future where LLMs could be self-improving in ways that aren’t human-verifiable. Machines building machines, and we can only hope that they’re not doing anything weird. I don’t know if this strategy is scalable, but I’d guess that it’s something more people will be exploring very soon. More and more often these days, I wish we were living in less interesting times.

After living with Apple’s 27.0 OSs since launch, I have some more annoyances to get off my chest. This time, it’s all about how tabs and menus have gotten worse. I’ve already ranted about the Liquid Glass material in general, but these two design changes in particular have really been grinding my gears. I’ll reiterate that Apple’s latest OSs look substantially nicer to me than the previous set… but that only makes these setbacks more glaring. Also, many of these issues aren’t nearly as bad in light mode — but I use dark mode exclusively on all platforms. Apple offers this appearance setting, so I think it’s fair to criticize them when it’s not holding up. First up, let’s talk tab bars. I think these looked awful in the original Liquid Glass redesign, and in 27.0 they look even worse. Below is an example of three tab bars from Safari in macOS. All of them are in dark mode. The top example is from macOS 26 with the “clear” Liquid Glass setting, the middle is macOS 27 with the default (mid-slider) version of Liquid Glass, and the bottom is macOS 27 with Liquid Glass at its most tinted. In each, the middle tab is selected (though I think the word “tab” is being quite generous to these globs). In macOS 26, there was practically no difference between the clear and tinted versions of tabs. Similarly, the clearest and default/middle tabs in macOS 27 are effectively the same. Because of this, I’m leaving out the redundant examples. Even though I still think it’s ugly, I vastly prefer the macOS 26 version of these three options. It offers the most contrast, and it makes more sense in dark mode: the background is darker and the foreground of the active tab is lighter. The middle example is what tabs look like in the default (mid-slider) version of Liquid Glass in macOS 27. There’s now only a very faint outline around the active tab, and practically no difference in background colours. To me, this is unreasonably subtle. The effect is even worse when there are a lot of tabs open. Lastly, there’s macOS 27 with the fully tinted Liquid Glass setting. It’s better, but it still looks less correct to me than the tab design from macOS 26. It’s difficult to put into words how much I loathe the look of this new tab bar design. I don’t mind the more “bubbly” look of Liquid Glass throughout the 27 OSs for the most part. It gives UI elements more dimension than in the 26 OSs. But it doesn’t work for tabs. Because the bubbly look is inside a trough, the active tab’s glass effect ends up looking like a blur on the top and bottom. This reduces contrast further and makes the active tab harder for me to pick out. Even in dark mode with full tint, I find the active tab less visually clear than in 26’s clear mode. Now, I’m sure there are at least a few people reading who don’t see what the fuss is about. If that’s you, I assure you that the difference is more stark when you’re not comparing things side by side. It’s not impossible for me to pick out the active tab, but I think it’s trickier than it needs to be! But, if you still don’t believe me, here’s a little experiment. Which of these do you think is most legible? The text/background colours in the above image are based on the foreground/background colours used in the tab bar instances above. First is clear in macOS 26, then the default from macOS 27, then fully tinted in macOS 27. I think they’re all pretty awful, but I prefer the macOS 26 clear version. Again, this is because I’m using dark mode. In dark mode, light text appears on a darker background. Similarly, active UI elements have a lighter background than their surrounding elements. I’m sure there are counter-examples, but this is how just about everything else works in Apple’s own apps! It should be noted that Safari uses the system default tab bar design. I also see this design in Apple’s Terminal app, in Pixelmator Pro, and elsewhere. I don’t use Xcode daily anymore, but you’ll also find them there — though in true Xcode fashion, they’re ever so slightly nonstandard and also don’t respect your tint setting. Below is a screenshot of Xcode using my current settings of dark mode with fully tinted Liquid Glass. Up next: menus. Below is an image showing four versions of the same menu in macOS. Top left is macOS 26 clear, top right is macOS 26 tinted, bottom left is macOS 27 default (mid-slider), and bottom right is macOS 27 fully tinted. It’s a similar story here. In macOS 26’s dark mode, I had no problem with system menus even when Liquid Glass was set to clear. In macOS 27, even in the fully tinted mode, the menus have much lower contrast. They also now lose all of Liquid Glass’s refractive effects when at their most tinted. I think this is less of an issue than the tab design changes, but it’s still a downgrade. Again, I’m certain many people don’t care about this. Some might wonder why I’m not turning on accessibility settings to help with these things, if they bother me so much. I’ve flirted with this (especially the “Increase Contrast” setting), but those settings have many knock-on effects. 1 But honestly, I don’t think accessibility settings should be required to have a reasonable amount of contrast in a design system. Maybe Apple disagrees, but I really hope more dark mode tweaks are coming. The “Increase Contrast” setting is under System Settings -> Accessibility -> Display -> Increase Contrast. Interestingly, you can use this setting along with the clearest version of Liquid Glass to almost get back to how things looked in macOS 26’s version of tinted. However, it adds contrast-y lines around many UI elements that I find extremely distracting. It also alters colours on some elements to, strangely, make them less contrast-y. It feels unevenly applied and poorly implemented in several apps. ↩

I really enjoy John Gruber’s podcast The Talk Show. However, I’ve noticed that it’s been a while since it was in my feed. I decided to chart previous episode dates to check some of my assumptions about release frequency. Cutting to the chase, here’s a link to The Talk Show Timeline. You can click/tap on days to get a pinned tooltip, which lets you link out to a particular day’s episode. I’ve tried to make this work well on mobile devices, but you’ll likely find it works best on desktop. A note about this: Gruber has mentioned in the past that there has been a personal situation that he’s been working through. He’s also mentioned something to this effect on the podcast at points, but hasn’t gone into detail. I don’t need to know more than has been said, and I just hope things are alright. I’ve read Gruber’s site since 2002 1 and listened to his podcasts since 2007. In that time, I’ve learned that he operates on his own timeline… and has a penchant for procrastination. No shade here! He’s set himself up with a work situation that I envy. I also don’t want to seem grumpy about the lack of podcast episodes; I’m just trying to understand how this current break compares to those in the past. Because it was easiest, and because it would answer my immediate questions, I only looked at the current iteration of The Talk Show. Happily, there’s a single page which lists all the episodes. It had a tiny bit of data weirdness, 2 but I was able to turn this into a JSON file with the details I cared about. With that, I used the calendar heatmap chart in Apache ECharts to display the episodes over time. Some things I noticed: While it’s been a while (29 days) since the last episode (on August 10), this isn’t unheard of. The average is about 12 days between episodes, but there have been 6 other times when the episode gap has been at least this long. The longest gap was 62 days between December 24, 2024 and February 24, 2025. There’s exactly one day with two episodes: July 19, 2014. It was “Cat Pictures” with Marco Arment, which got split into two “sides”. Here’s a link to side 1, and here’s side 2. I mentioned procrastination: 73% of episodes take place on the 16th of a month or later. 28% of episodes take place on either the last or second-last day of the month. Again, no shade! It’s something I chuckle about whenever I notice it. At the current rate, this year is about in line with output going back to 2023. While it has been a while since a new episode dropped, it’s not out of whack statistically. Anyway, this was a Labour Day project that was mostly for my own amusement. I expect there will likely be a new episode of The Talk Show some time fairly soon after tomorrow’s Apple event. I also don’t know if I’ll keep this chart up to date… though it’s not terribly onerous to do now, so who knows. I found Daring Fireball because I was researching the purchase of my first Mac around this time. It wasn’t until October of 2002, but I ended up buying one of the machines he wrote about in his first post that August. ↩ The following dates don’t match the main format: Sunday 30 November, 2025 Mon, 24 Feb 2020 16:05:34 EDT Tuesday 31 December 2019 Tuesday, June 25 2019 Sat, 16 Mar 2019 19:43:49 EDT Wednesday 31 December 2014 Monday, 30 Jun 2014 ↩

I mostly use my web stats service because I get a lizard-brain kick from watching numbers go up, but it also provides some fun insights. For example, it’s how I found out about bubbles.town. At first I thought this might be a Mastodon instance. I get a lot of referral traffic from Mastodon, but each instance has its own URL. You can guess at mas.to, but dice.camp doesn’t provide many clues. Bubbles, as it’s known, is a very nice service. It aggregates a curated list of indie blogs. People can sign up and vote for posts they enjoy, but they can’t submit new articles. Authentication and comments are both handled using Fediverse technologies. In my case, I was able to log in via my Mastodon instance. The idea is to highlight cool indie writers around the web. I love this sort of thing so very much. Anyway, this is all to say that you should check out Bubbles. Seeing a blog-based reaction to one of my posts on the service filled my heart with immense joy.