All posts by Tim Anderson

Kimi K3 and Qwen 3.8: is AI becoming a commodity?

Last week Moonshot AI introduced Kimi K3, with the promise that “the full model weights will be released by July 26 2026;” while Alibaba said on X that “Qwen 3.8 is launching and going open-weight soon”.

These are capable LLMs (large language models), and the open weights promise means that developers will be able to download them from Hugging Face and run them locally.

There are two reasons why local AI is inferior to pay-as-you-go cloud AI from one of the big providers: the LLMs are not as good, and the hardware is much inferior to data centres stuffed with massive amounts of RAM and GPUs.

However, there are also two reasons why local AI is much preferable to cloud AI: it is free to use, and more private. As an individual developer the notion of a constant trickle of spend while coding is disturbing, though I also see how the figures can make sense in a business context if there are corresponding benefits in productivity or staff numbers.

LM Studio using Qwen 3.6 to write some C# code

Joining the dots though, it seems possible that as local AI improves the premium (and uncertain) cost of what is sometimes called frontier AI will no longer be worth paying for.

Someone has to pay for the LLMs and there are political as well as technical aspects to this, as there are in other areas of IT. The implications of commoditised AI though are considerable, and means that we can expect further shifts in the tech landscape in this space.

No Mono in Microsoft’s cross-platform MAUI framework on .NET 11 – and a quick hands-on

Microsoft has released preview 6 of .NET 11, for which release is expected in November, including a big change to MAUI (Multi-platform App UI): it now runs only on .NET Core, rather than the Mono runtime.

Principal product manager David Ortinau reports that “your app builds and runs on CoreCLR, the same runtime behind ASP.NET Core, your cloud services, and desktop .NET.”

According to Ortinau, performance is generally faster than Mono on iOS and Mac Catalyst. The implication is that it is slower on Android, though he does say that it is within 10% on startup and app size. Selecting Mono is no longer an option, and the only use of Mono in .NET 11 is for Blazor WebAssembly.

There is a key remark in Ortinau’s post. “We have worked closely with first party .NET MAUI apps validating our progress, and have received feedback from several others,” he says. The question developers may ask: what first party .NET MAUI apps? Microsoft does not use MAUI for its well-known cross-platform apps such as Teams or Office. In 2023, the company said it uses MAUI for its 365 admin, Azure admin and Store Commerce apps, though I do not know if this is still the case.

Slide from .NET Conf 2023 showing some limited use of MAUI at Microsoft

Developers would have more confidence in MAUI, both for its quality and its long-term future, if Microsoft itself made more use of it.

That said, the company does seem to be putting substantial effort into MAUI for .NET 11. Along with the CoreCLR work there are other updates in this preview. Microsoft states that the focus in .NET 11 is “to improve product quality” and this is something developers will be happy about; in some cases a statement like this might imply neglect but for MAUI it is exactly what is needed.

I have a demo MAUI project and decided to upgrade it to the new preview, working with Visual Studio Code on a Mac. It was not as easy as I had hoped. The process involved not only updating the target framework, but also the minimum versions of Android, iOS and Mac Catalyst. Then the Android SDK had to be updated, with an annoyance related to the recommended:

dotnet build -t:InstallAndroidDependencies -f net11.0-android “-p:AndroidSdkDirectory=[your path to the Android SDKs]”

The command failed with an error about the Android SDK licenses not being accepted. The fix is to set an environment variable:

export AcceptAndroidSDKLicenses=True

and then it works, though I’m not sure how this satisfies the lawyers. I also had an error where

builder.Logging.AddDebug();

could not find the AddDebug method; the fix was to add a package reference to Microsoft.Extensions.Logging.Debug to the .csproj file.

With all that done, the “Start debugging” command is not working for me in VS Code. I get a message that the “configured debug type ‘coreclr_mobile’ is not supported, and an instruction to install coreclr_mobile Extension; clicking this button gets me “no extensions found.” Update – this was resolved after updating both the C# and C# Dev Kit extensions to pre-release versions (.NET MAUI was already pre-release).

However, dotnet run from the command line works:

Demo of MAUI using .NET 11 Preview 6 on a Mac

I plan to do some more experimentation; note that this is a preview of .NET so some friction is expected.

JetBrains Resharper for Visual Studio Code adds C# debugging support

One of the oddities of Microsoft’s Visual Studio Code is that it is free to use for almost anything other than the company’s own .NET platform. That is, there is nothing to stop developers from coding in C# with VS Code and using the .net command-line tools without paying Microsoft for a license; but the official C# Dev Kit extension requires a license for teams of 6 developers or more:

For personal, academic, and open-source projects, C# Dev Kit can be used at no cost. For commercial purposes, teams of up to 5 can also use the C# Dev Kit at no cost. For 6+ developers, those users will need a Visual Studio Professional (or higher) subscription.

In addition, there are licensing restrictions on Microsoft’s .NET debugger which impact VS Code forks:

The C# extension for Visual Studio Code includes the Microsoft .NET Core Debugger (vsdbg). Unlike VS Code, and most other parts of the .NET Core ecosystem, vsdbg is not an open source product but rather is a proprietary part of Visual Studio. It is licensed to work only with IDEs from Microsoft — Visual Studio Code, Visual Studio, or Visual Studio for Mac.

JetBrains has now introduced C# debugging support for the ReSharper VS Code extension, which means there is now another high quality option for developers who either prefer not to use the C# Dev Kit, or are using a VS Code fork such as AWS Kiro, Cursor, Windsurf or Google Antigravity, for which the official .NET debugger is not licensed.

ReSharper is free for non-commercial use, or costs £119.00 ($149.00) per year for an individual or £295.00 ($389.00) per year for developers working for an organization. The cheapest standalone Visual Studio Professional plan is currently $540.00 per year, though some developers will get it bundled with other plans.

Leaving aside licensing and cost considerations, how does ReSharper compare to C# DevKit and the Microsoft .NET debugger? I have yet to use ReSharper so do not have a personal opinion; but will note that Microsoft’s recent change which removed the Solution Explorer is unpopular.

Finally, my personal view is that Microsoft has more to gain by making .NET and its tooling fully open, than by playing games with licensing restrictions in an effort to keep developers hooked to Visual Studio or VS Code.

Notes from the field: when Remote Desktop cannot connect

Following a power outage, all my Windows servers (hosted on a single Hyper-V server) rebooted. They are configured to come back up, but I found that Remote Desktop was not working to many of them, including the domain controller.

I found a workaround using the Hyper-V manager on one server to which I could connect; this lets you connect via a different route.

Today I focused on what was causing the issue. Microsoft has quite a reasonable troubleshooting guide here which pointed me in the right direction: on the Mac I use for day to day work, for example, port 3389 was blocked on the target server. In the Windows firewall this port was open for private and domain profiles, but not for the public profile, which is what one would expect.

Microsoft’s guide says to enable port 3389 on all profiles but that seems wrong to me. Likely OK for a server, but not for a laptop, for example. And why would it matter?

The answer was that even on the domain controller, the local network was set to the public profile.

The local network on the domain controller I was trying to reach was set to the public profile.

Oddly, as I explored the network settings, this changed by itself to the domain profile, and Remote Desktop started working again.

There is a detailed post here on the intricacies of network profiles and why they can go wrong. It is potentially quite a tricky problem since of course you need access to the server in order to fix it, and if your setup is like mine, the servers do not have keyboards or screens attached.

Cloudflare’s vinext project reaches beta 1 – not just an AI experiment

Cloudflare’s vinext project, which implements the Next.js API using Vite as the bundler instead of Turbopack or Webpack, has released its first beta, suggesting (if there was any doubt) that this is a project intended for production use and not just an AI experiment.

Why does vinext exist? The introductory post grabs attention with its claim that using AI, Next.js was rebuilt in a week – though we note that some 20 weeks have passed since then, and here we are at beta 1.

The rationale for vinext given in that original post was that Next.js build output hooks it to Vercel’s platform – a problem that presumably matters to Cloudflare because it would like more Next.js projects to run on its own Workers platform instead.

The paragraph headed “Why” in the vinext readme has a different emphasis, claiming that “Vite has become the default build tool for modern web frameworks” and that vinext now provides a “full React Server Components framework on Vite.”

Neutral observers will note that whereas Next.js defaults to Vercel, vinext “natively supports Cloudflare Workers,” with support for additional platforms still in a planning phase. This is mitigated though by a Nitro plugin, Nitro being a server for Vite applications, that enabled deployment anywhere Nitro (or Node.js) can run. Cloudflare Workers is still recommended as the “best developer experience”.

Performance figures for vinext show that while builds tend to be faster and client bundle sizes smaller, Next.js is faster from a cold start. There is another nuance here: Next.js pre-renders static pages to HTML at build time but vinext does not; it caches them after the first request. There is an open issue to fix this.

The existence of vinext is a good thing for competition and will perhaps indirectly benefit the OpenNext project, in which Cloudflare is also involved, which takes another approach to making Next.js independent of Vercel, via a Next.js deployment adapters API which is now stable (since Next.js 16.2). Vercel has an incentive to make Next.js an open platform, to reduce interest in vinext.

That said, Cloudflare is a strong competitor because it owns its own infrastructure, whereas Vercel deploys to AWS.

TypeScript 7 is done

Principal product manager Daniel Rosenwasser reports that TypeScript 7 is now generally available – a big release, since this is the first to have the native port of the TypeScript compiler built in Go. Rosenwasser claims “speedups between 8x and 12x on full builds.”

There is a snag. Although TypeScript 7 is production-ready, it has no API; that will not come until TypeScript 7.1. It may come as a surprise to you that TypeScript has an API; it is not something highlighted in the TypeScript docs. You will find it covered in the official Wiki where there is an article on using the compiler API dated October 2023 and advising that “this is not yet a stable API.”

Despite the compiler API being somewhat obscure, Rosenwasser says this means that “workflows that use Vue, MDX, Astro, Svelte, and others will likely not yet be able to leverage TypeScript 7. Similarly, specialized type-checking within templates like Angular will also likely not use TypeScript 7.” That is a significant blocker to adoption.

The dedicated TypeScript 7/0 extension for Visual Studio Cdde

Users of Visual Studio Code should install the dedicated TypeScript 7.0 extension which already has enthusiastic reviews. “Saves us lots of time in CI/CD. The difference in speed is huge!” said one.

Personally I now use TypeScript rather than JavaScript almost exclusively, when targeting browser scripting, and will endeavour to switch to 7.0 immediately. I would much rather have the compiler find errors, than have them turn up in production.

My writing here and elsewhere

I am no longer writing regularly for The Register or DevClass – I have loved writing there but made the decision to stop in order to free up more time for other things. I may still write there occasionally, and/or do freelance work elsewhere.

One of the consequences is that I have a bit more time to post here on things that interest me – which includes running, music and audio as well as software development.

I have pretty much de-Googled the site in order to improve the reader experience; and because I can see hardly any benefit in showing Google ads or donating the site analytics to the company. At one time the ads generated a small but useful income which at least more than paid for the hosting; that is no longer the case, in part because of reduced activity, and in part because the model no longer works well, with the rise of AI overviews being the latest blow to the economics of online publishing.

Google has never been a content provider; it profits from other people’s content. The question of whether it benefits Google to keep readers on its own site via AI overviews, at the expense of the content providers on which those overviews depend, is an interesting one which deserves more attention than I have time to give it now.

This site is still on WordPress though that could change; I do intend to preserve the existing content even though most of it is obsolete and on some matters I have been too ignorant or have changed my mind; it is still part of my history.

There remain plenty of things I want to write about so I expect to be posting quite often but make no guarantees; if you enjoy any of the posts or find them useful, than that pleases me too.

Avalonia UI vs Microsoft’s .NET MAUI

What framework to choose for a cross-platform .NET GUI application continues to be awkward, with multiple good-ish options but no obvious first choice.

The three leading contenders are Microsoft’s MAUI (multi-platform app UI), third-party Avalonia UI, and third-party Uno Platform.

Joseph Tomkinson, head of software engineering at the British Heart Foundation, has an excellent post on the pros and cons of MAUI vs Avalonia UI, noting the fundamental difference that MAUI wraps native controls while Avalonia UI does all its own rendering. Tomkinson argues that MAUI has stronger mobile support (since this has only come recently to Avalonia) but that Avalonia has advantages in consistency, desktop performance, and Linux support.

A concern with Avalonia UI has been the drift towards important features becoming commercial-only, not unreasonable but a barrier to adoption for some developers. That has improved though since a sponsor appeared to fund Avalonia open-source development. CEO Mike James (formerly at Xamarin and then Microsoft) has posted about the difference this has made.

According to James, the Avalonia UI team has more than doubled, to 20 people, and now includes a QA lead. He says usage is growing:

“In the whole of 2025, Avalonia projects were built over 122 million times. In the first six months of 2026 alone, that figure has already passed 410 million.”

I am not sure exactly what this metric is counting – telemetry every time a developer builds a project? – but presuming it is like with like, that is impressive.

On the MAUI side though, one thing Tomkinson notes is that third-party components are more widely available, because it is an official Microsoft framework, and that quality is much better now than it was early on.

The BigCorp factor is not entirely in MAUI’s favour though. Microsoft might change direction and decide MAUI is no longer important, particularly as its own internal usage of the framework still seems minimal.

I am inclined to try building an example project in both frameworks to get my own feel for which would work best.

Microsoft authenticator cannot be backed up for Microsoft or Entra ID accounts

Multi-factor authentication (MFA) improves on username/password authentication by requiring the user to have a second proof of identity, traditionally “something you have” as well as “something you know.” In the Microsoft ecosystem MFA is typically implemented using an app called Microsoft Authenticator which generates one-time passwords (codes), used in addition to a password to sign in, or passwordless authentication where a request is sent to the authenticator app. The user enters a number displayed by the service they are signing into.

What happens though if you lose or replace your phone (iPhone or Android) that has the authenticator app on it? Microsoft has a post explaining how to restore account credentials from Microsoft Authenticator. The instructions differ for iOS and Android. They work for any codes you have set up in Authenticator for third-party accounts where you have configured MFA with the app.

One should pay attention though to the paragraph entitled: what account information is restored in Authenticator. In particular, for Microsoft personal accounts:

If the account also provides passwordless sign-in, then only the account name is backed up. When you restore, you will need to sign in again.

and for Work or school accounts, also known as Entra ID:

Only the account name is restored. When you restore, you will need to sign in again.

What does it mean, “you will need to sign in again?” How will you do this if you have lost access to the Authenticator which you backed up and restored?

The answer depends on whether any other authentication methods have been set up for the account. When the authenticator method fails, you can tap “Sign in another way” or “I can’t use my Microsoft Authenticator app right now”. If you have a phone number set up, it can send a code there instead (often by WhatsApp rather than SMS).

If you don’t have another authentication method set up, you cannot sign in. Contact your administrator.

You are the administrator? If you are the only global administrator for the Entra ID tenancy, you will have to call Microsoft’s Data Protection helpline and hope that you can prove your identity sufficiently that you can sign back in.

See here for an official response to this problem:

Therefore, if you are the only administrator in your organization, then you need to involve Microsoft data protection team. Please try to find the related hotline number to call the frontline let them raise a ticket for you: Customer service phone numbers – Microsoft Support 

It seems odd to me that Microsoft provides the ability to backup and restore all the Authenticator accounts except the ones it provides itself. And that when users register for MFA they are not able to to get recovery codes for that account.

Book review: Running on Air by Sophie Raworth

This is both an easy and a hard book for me to review, because it echoes some (not all) of my own journey of running; I am not sure how the book will come across for non-runners.

Cover of Running on Air by Sophie Raworth

Sophie Raworth is a BBC broadcaster and something of a celebrity; I tend to be impatient with books by celebrities but I make an exception for this one because it is almost entirely a book about running rather than a book about being a well-known TV presenter. There are a few pages about questioning former UK prime minister Boris Johnson in February 2022 about “partygate,” a political scandal relating to government parties during COVID lockdown, but Raworth argues that marathon training and running was what prepared her for such high-stress tasks – though she got no answers.

Raworth began with running in 2006, aged 38, when she was invited to be a celebrity runner in the Great North Run, a popular half marathon. She ran in 2 hours and 5 minutes, felt “utterly elated” to have finished the race, then stopped running until 2010, when she was inspired by an acquaintance of her own age to sign up for the London Marathon. “The training takes over my life,” she writes. Her BBC colleagues tease her about always talking about running; if she mentions it more than once a day, she has to buy all the tea. 

In 2011 Raworth ran London, and this is how the book opens, with a collapse on the London Embankment at around mile 25, caused by heatstroke. It is related to inexperience but not to undertraining; she had a coach and trained hard. Rather than giving up on running, she doubles down, completing all six of the Abbott World Marathon Majors by 2017.

Chapters 4 -6 describe what is perhaps the centrepiece of the book, Raworth’s adventure running the Marathon des Sables, a gruelling 6-day run across 250K of Sahara desert, including a mention of a runner chasing a scorpion out of his tent. This does not appeal to me at all, but is an example of the amazing capabilities of the body after training, even starting relatively late in life.

Raworth was in her early forties when she took up running in earnest, I was in my sixties. I have never run an ultra, but nevertheless relate to what she describes, that endurance running leads to unthought-of achievements, new friendships, almost a new identity, even for someone who never thought of themselves as an athlete at all.

Running is a great leveller. “No one asked me about my job or treated me any differently because I was on TV. I was just another runner,” Raworth writes of a running group she joined. “We didn’t discuss careers and work. It took me years to find out what some people actually did when they took their trainers off. Yet I knew everything there was to know about their fastest times, their running niggles, and their race plans and dreams for the months ahead … I found a new easy kind of camaraderie that required no front.”

This is my experience too. It also happens that our running times are similar. Raworth’s best parkrun is 20:31. Mine is 20:37. We are both good for our age, but not race winners; and it does not matter.

The book is quite short (248pp) and an easy read, though emotional in places, particularly as she describes the physical decline of her parents and the death of her father. “How will I age,” Raworth asks herself.

I enjoyed the book, it is nicely written, warm, human and honest.

I have a few quibbles. Running is not bad for your knees, Raworth argues in chapter 8, based mainly on the research of a physio called Paul Hobrough. And in chapter 12 she describes a stress fracture caused, she says, by training too much in carbon-plated shoes which “weaken your intrinsic muscles,” according to a podiatrist she saw. These are important but complex questions and I am not sure there is scientific or medical consensus on either matter; I find Raworth too confident in giving these verdicts, though it is good to see the topics covered.

That said, I liked the real-world accounts of running injuries and the emotional lows that come with them; something most runners will relate to. I loved the race reports, the self-awareness of becoming a bit obsessive, the description of the agony and elation that characterises the sport. Recommended.

Running on Air by Sophie Raworth (Bloomsbury ISBN 978-1-399-42633-6)