DCKing

I don't mind this in the agent workflows themselves, but I think this is hideous in the code and encourages agents to become even more verbose in the future.

I have a workflow to create PRs where at the end, I spin up a subagent that goes through the PR to 1) remove the bulk of the comments and 2) attempt to normalize it for human consumption (I ask it to optimize wording for junior developers and non-native speakers).

I use Haiku for it, hoping that a dumber model will do a better job. I have noticed in brief experimentation that even Sonnet will sympathize too much with the need of excessive comments and is not a good adverserial reviewer for slop comments.

After that workflow runs I still need to go in and manually correct, but it's a lot less than vanilla Opus. It really feels like the problem of slop comments has gotten worse as models has gotten smarter.

I run various forms of workflows to run dedicated QA, code review (of various flavors) simplification and text simplification agents. Especially the simplification goes a long way to remove dumb padding, duplication and efficiency. Dedicated docs/comment simplification is also becoming more and more necessary on recent models. For things like feature development in my workflow, the majority of time the agents run and tokens spent is critiquing the code from various perspectives and it's not close.

Of course, this doesn't solve the overall issue that agents don't write code like you and still requires a lot of human attention in planning and code review out to clean up leftover issues, and e.g. challenge bad assumptions about architecture and real-world context. A human is still very much needed to cull the slop (or, more gratuitously: align the agent). But IME it does help avoid a lot of pitfalls and makes the code high quality a lot more quickly.

Props to them for including three benchmarks that actually seem to say something, instead of focusing on totally gamed benchmarks like regular SWE-Bench. That could mean this model is actually pretty close to the SOTA as the benchmarks indicate.

Most labs - including OpenAI and Anthropic, but also Google and Chinese labs - highlight their scores in benchmarks that have fixed, widely available answers. Those answers end up in the training data and so models can just regurgitate training data instead of actually doing the benchmark. As a result, most benchmarks often quoted are essentially meaningless for gauging model performance.

Terminal-Bench still publishes answers, but neither DeepSWE and SWE-Bench Pro do. Especially for DeepSWE it's been difficult for models to fake good results so far. SWE-Bench Pro does have weird outliers like good performance for e.g. the atrocious Muse Spark, but it also doesn't provide answers for the training data.

So either they're good, or they found a way to game DeepSWE. Given that the Cursor team previously published the well-received Composer 2.5 a good score here doesn't come out of nowhere, so this might hold up. Cursor has enormous amounts of training data to train good coding models with.

You can put many agent constraints in precommit hooks if they're static checks. I ask agents to make commits, and e.g. in a Python project have the precommit hook fire off type checks, linting and even architectural things like import boundaries (using `tach`). When an agent is prepped to make commits themselves, it will catch pre-commit failing and correct itself. The existence of static checks themselves might also help agents gain awareness of the overall verification flow including larger things like tests, but that's hard to say for certain.

Putting structural code checks in a precommit hook is arguably better than pulling it into the harness, as it will enforce those constraints no matter whether an agent or human is making the commit.

American labs also use gamed and cherry-picked benchmarks extensively. Anthropic used them in their Fable announcement and avoided DeepSWE because it doesn't beat GPT-5.5 in that one. Google's numbers for Gemini 3.5 Flash recently did not at all line up with people's subjective experience using these models, and this also happened with Gemini 3.1 Pro before it.

Everybody has incentives to manipulate benchmark results to show their models in the best light.

Any benchmark is iffy and has weird results, but this is the best we got at the moment. Most people working with Opus and Kimi would likely tell you they're much further apart than the numbers that were quoted for Kimi K2.6, and DeepSWE seems to capture that gap better.

One major thing DeepSWE has going for it is that all other benchmarks (including those quoted by MoonshotAI on this page) don't: the other benchmarks that are completely gamed. The benchmark answers are public and part of each model's training data. This benchmark may still be iffy, but at least it's not gamed.

The moat right now is model performance and what that means for how many tokens and additional time you spend.

I say this as a relatively frequent user of Kimi models and generally a big fan. But on not-yet-gamed benchmarks like DeepSWE, Kimi K2.6 is beaten soundly by Claude Sonnet 4.6 ($3 / $15) and even slightly by GPT 5.4 Mini ($0.75 / $4.50).

There's no question Kimi models are very good for a lot of code tasks. They're the best quality open weight model. But to get similar overall outcomes as on Sonnet/Opus, on average you'll spend many more tokens and will have to do more managing of the model. You shouldn't look at price per token, you should look at how much you pay for the entire process.

It's for predictability in upgrades. Homebrew allows you to separate system packages (from apt or dnf) from user packages (from homebrew) [1]. Running apt upgrade or dnf upgrade can render your system unbootable if you're unlucky (or unstable or degraded if you're less unlucky). Running brew upgrade can at worst break some of your own user's setup or tools.

Since everybody runs their own unique permutation of apt or dnf packages, adding as little as possible will keep you as close as possible to what distro maintainers test. There's even OSes like Fedora Silverblue or Bluefin or SteamOS that ship with a fully baked _image_ - where installing system level packages is strongly discouraged - which helps ensure predictability and stable upgradeability.

Homebrew packages also tend to be more recent (this depends on your distro of course) and don't require elevated permissions to install.

[1]: Other unprivileged package managers like Mise or Nix do the same of course

There will be more of this going forward, I think. Systemd is really not just an init system, it's a full cohesive management system for Linux distros and they've never pretended otherwise. A modular one but still a comprehensive one. Because of that its mere existence is an affront to many people with traditional opinions on Linux and Unix.

systemd-appd sounds like it could make some inroads in the threat model that Windows and Linux still have in 2026 (and macOS is still reeling from): anything that runs as my user, can access anything running as _my_ user. I don't think this threat model was tenable in 2016, much less in 2026. But moving away from that also breaks with the Unix tradition.

Systemd as the system management layer is becoming a centerpoint for moving Linux forward, on servers but especially so on the desktop, and it does so at the cost of breaking with traditional views. It's kind of hard to watch: I want Linux to move forward, and there's just a lot of good ideas there. But it will be painful for a large Linux community to break with traditions.

TurboQuant is a runtime optimization for a model's KV cache and doesn't allow for reduction in model size.

I think there was a leap around Opus 4/4.1 that hasn't quite been equalled by self hostable models yet. Perhaps full Kimi K2.6 and Deepseek V4 Pro can achieve Opus 4.1 levels (it's hard to compare anyway, benchmarks are largely a game nowadays), but both of these are also north of 1000B parameters and therefore really impractical to run at home for the foreseeable future.

It's not yet obvious to me that you can achieve the breakthrough performance of say Opus 4.1/4.5 in a number of parameters you can swing at home.

If two things hold up - 1) this is actually a 2-300B parameter model and 2) this is actually competitive with frontier OpenAI and Anthropic models (and not just benchmaxing), the implications are pretty big. It would mean you could run "frontier level" performance in one box at home.

300B models at least fit in a single maxed out Mac Studio or a small stack of DGX Sparks or AMD Strix Halo boxes.

For comparison, DeepSeek V4 Flash is all the rage now for small efficient models. It's very good for its size but far from the performance of the latest GPT Pro and Opus models. The vanilla variant has 284B parameters. It fits on both 256GB and 512GB Mac Studios and hits about 20-30 tokens/second.

The implication of all this here is that you could have a (somewhat sluggish) Opus in a small box at home. At least once competing models and hardware to run them will be available (high end Mac Studios have been discontinued).

Something tells me that this means that Google's performance numbers here are inflated.

I've been using OpenCode Go ($10/month) for personal projects (I have Claude subscription for $DAYJOB) and for the tinkering around that I do for myself the quality of the open weight models and the limits of the OpenCode plan are sufficient. I agree that for a lot of dev tasks they're quite good!

Deepseek V4 came out three weeks ago: https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro

Kimi K2.5 has also been superseded by a finer tuned Kimi K2.6 three weeks ago. Moonshot's Kimi models appear to be the favored Chinese model, at least for coding, and not Deepseek V4. z.AI's GLM 5.1 is also worth mentioning as rather competent for coding, also released in April.

Those models too will not be beating US AI labs by your metrics (although for coding, Kimi K2.6 might beat the very uneven Gemini depending on the situation), but in your critism at least consider the state of the art in your comparisons.

Why should Apple have done this?

For money, probably.

Apple is presumably leaving a lot of money on the table by not trying to sell Apple Silicon for AI inference and training. They're the only ones who can attach reasonably large GPUs (M3 Ultra) to very large amounts of cheaper memory (512GB SO-DIMM per GPU). Apple could e.g. sell server SKUs of Mac Studios, heck they can sell M3 Ultra chips on PCIe cards. And they could further develop Apple Silicon in that direction. Presumably they would be seen as a very legit competitor to Nvidia that way, perhaps moreso than Intel and AMD. I'd assume that in the current climate this would be extremely lucrative.

Now, actually doing this would disrupt Apple's own supply chain as well as force it to spend significant internal resources and cultural change for this kind of product line. There's a good argument to be made it would disproportionally negatively affect its Mac business, so this would be a very risky move.

But given that AI hardware is likely much higher margin than the Mac business an argument could probably (sadly) be made that it'd be lucrative for them to try it. I personally don't think Apple is inclined to take this kind of risk to jeopardize the Mac, but I'm sure some people at Apple have considered this.

systemd nowadays has a lot of sandboxing built in [0]! You can achieve jails using just systemd and no separate container manager.

[0] https://wiki.archlinux.org/title/Systemd/Sandboxing

they should really look at kernel CVE database

When quoting kernel CVEs as evidence as signs of insecurity, especially so seemingly authoritatively, please make sure you're informed about how what Linux kernel CVEs mean.

A CVE (for any product) does not automatically mean there is actually a vulnerability there or even if one is exploitable unless explicitly noted (in the CVE or credibly by someone else). Proof of concepts, reproducibility or even any kind of verification are not a part of the CVE process.

For the Linux kernel in particular, the CVE process is explicitly to be "overly cautious" [1]. In practice, this means the Linux security team requests a CVE for anything that has a mere whiff of being theoretically exploitable. Of course that doesn't mean that the bug that was fixed was actually exploitable, not even theoretically but certainly not in practice.

As a result, you can't use CVEs reported by the Linux kernel to make claims about the (lack of) practical security of any Linux system, including your desktop. The CVEs reported by the Linux kernel are there to notify you to very well informed users of the kernel to do further risk assessments, not to be taken at face value as a sign of insecurity. [The latter is true for the entire CVE system - they're not to be taken at face value as signs something is wrong. But it's especially true for the kernel.]

[1] https://docs.kernel.org/process/cve.html#process

under this model, every application is let to defend itself in an ad-hoc and specific manner.

This description of the macOS model doesn't really apply so I'm not sure if I'm misunderstanding you or you're misunderstanding the model.

Another approach is to police everything behind rules (the way selinux or others do), which is even better in theory. In practice, you waste a ton of time bending those policies to your specific needs. A typical user won't take that.

While SELinux could probably provide this kind of data protection on Linux, the method of technical enforcement is only one part. There's a lot of UI involved to get right, and that will require far more effort.

Then there is the flatpak+portal isolation model, which is probably the most pragmatic, but not without its own compromises and limitations.

That model doesn't really apply here. Flatpak et al allow applications to self confine in order to protect the other things the user is doing. What I'm talking about is for an app to have some protections of its own data from the other things the user is doing. I'm not talking about sandboxing, this data protection.

I mean, if my threat model starts with "I have a mal/spyware running alongside my browser with access to all my local files", I would pretty much call it game over.

This is a big problem I have with desktop security - people just give up when faced with something so trivial as user privileged malware. I consider it a huge flaw in desktop security that user privilege malware can get away with so many things.

macOS is really the only desktop OS that doesn't just give up when faced with same user privileged malware (in good and bad ways). So there it's likely a good mitigation - macOS also doesn't permit same user privileged processes to silently key log, screen record, network trace and various other things that are possible on Windows and common Linux configurations.

The opsec reason I use Safari as a work browser today is that Safari has a much more blunt tool to disrupt cookie stealers: Safari and macOS do not permit (silent) access to Safari's local storage to user level processes. If malware attempts to access Safari, its access is either denied or the user gets presented a popup to grant access.

I wish other browsers implemented this kind of self protection, but I suppose that is difficult to do for third party browsers. This seems like a great improvement as well, but it seems this is quite overengineered to work around security limitations of desktop operating systems.

Strix Halo is impressive, but it isn't AMD going all out on the concept. Strix Halo's die area (300mm2 ish) is roughly the same as estimates for Apple's M3 Pro die area. The M3 Max and M3 Ultra are twice or four times the size.

In a next iteration AMD could look into doubling or quadrupling the memory channels and GPU die area like as Apple has done. AMD is already a pioneer in the chiplet technology Apple is also using to scale up. So there's lots of room to grow for even higher costs.

I don't think AMD really uses the name "Strix Halo" to market it to a large audience, it's just an internal codename. Just two other recent internal names are "Hawk Point" and "Dragon Range" internally, where Hawk and Dragon are names that MSI and PowerColor use to market GPUs as as well. Heck, PowerColor even exclusively sells AMD cards under the "Red Dragon" name!

AMD's marketing names for especially their mobile chips are just so deliberately confusing that it makes way more sense for press and enthusiasts to keep referring to it by its internal code name than whatever letter/number/AI nonsense AMD's marketing department comes up with.

The full SteamOS experience is pretty tied up in Linux' open source graphics stack, moreso than regular Linux desktop environments because Valve built it for high performance on the Steam Deck's AMD GPU. Nvidia's proprietary driver has traditionally done its own thing and has been quite incompatible with things targeting the open source stack. So it's hard to replicate the Steam Deck experience on Nvidia, no matter the distro.

That said, over recent years Nvidia has made some efforts to improve compatibility. Just a few days ago Bazzite announced a Steam Deck beta image for Turing and later Nvidia cards [1]. It's too early to run though if you want the seamless experience you get on Intel and AMD, and progress mostly depends on Nvidia and Valve, but I hope they get there.

[1] https://universal-blue.discourse.group/t/new-bazzite-deck-nv...

If you are demanding or particular about your gaming experience, then Linux isn't there yet. Compatibility with the very latest AAA titles can sometimes trail behind Windows, anticheat for competitive multiplayer often blocks out Linux compatibility, and you need to adapt to different tools for customizing and surrounding your gaming experience if you're so inclined.

What I'm highlighting if you just want to sit down to play some damn games already in your library, especially on a dedicated "console" like a handheld or HTPC, then the Linux experience is superior to Windows. And I expect that there's a sizable audience for that.

They mean "cloud native" in the sense that it adopts atomic system updates and containerized application installs, which has been common in "the cloud" for years but is much less commonplace in personal Linux installations. Working in this way is a large part of why Bazzite "just works". It is also actually exactly how SteamOS works (with some implementation differences under the hood), so SteamOS is "cloud native" in the same sense.

I do think this marketing is unnecessarily confusing. The dayjob of the original master mind behind Bazzite and Universal Blue is working with cloud systems IIUC, so they find it an important thing to highlight.

You don't need to wait for Valve to get this experience today. The HTPC build of Bazzite [1] brings an experience identical to SteamOS to all computers with an AMD or Intel GPU from the past 8 years or so.

It works amazingly well and I can't imagine going back to Windows for a PC that is built only for video games. I use it on my "Gaming HTPC" (Ryzen 3600, Radeon RX6600, Fractal Design Node 202) and it brings a great console experience to my TV, with access to my PC game library, without being locked into a console ecoystem, and without the enormous cruft and user hostility that Windows has you manage these days.

I'm a pretty casual and patient gamer, and for that use case this Steam machine experience is unmatched - despite being built on desktop Linux, it works out of the box and requires zero manual maintenance. For dedicated gaming boxes this Linux user experience is significantly better and easier to use than Windows - we're truly living in the future.

[1] https://bazzite.gg

[2]: It's built on top of Fedora and Universal Blue, so under the hood it's different from SteamOS which is built on a custom immutable version of Arch Linux. However, that implementation detail is actually almost totally irrelevant if you want to play games since all software is managed by Steam and Flatpak on both systems.

The Nintendo 3DS (and DSi too) contain a version of the ARM7TDMI CPU used in the Game Boy Advance [1]. On the 3DS, this chip was used for the Game Boy Advance Ambassador titles [2], which effectively run "natively" on the 3DS - when launching a game, the 3DS reboots into a different firmware and just runs the GBA game.

Later, homebrew was able to sideload GBA titles [3], which essentially has perfect software compatibility. However, emulating GBA titles still has advantages over rebooting the device so software emulators are available for the 3DS. The New 3DS is fast enough to provide pretty high quality GBA software emulation.

I don't think a similar path to directly use the DSi's ARM7 to boot GBA games was ever found by homebrewers (it may just be that the DSi is not able to reboot in a "different mode", which Nintendo did release for the 3DS?). The best available on the DSi seems to be a "compatibility layer" solution that tries to run the ARM7 code on the main ARM9 CPU [4], which seems to work surprisingly well.

[1] https://www.3dbrew.org/wiki/ARM7_Registers

[2] https://nintendo.fandom.com/wiki/Nintendo_3DS_Ambassador_Pro...

[3]: through "Virtual Console injection" tools, or through https://github.com/profi200/open_agb_firm

[4] https://emulation.gametechwiki.com/index.php/GBARunner3

I wish other distros documented ways to make it easy to customize the initramfs like this. I'd love to build a setup like this, but I don't want to use Alpine as I don't like musl for compatibility reasons or RC scripts for managing services.

There are other options, but they have considerable barriers to entry as well, like NixOS which requires learning their specific DSL. I like the idea of `bootc` but that doesn't support running from RAM best I can tell. Other distros really only document customizations to the initramfs as a means to provide an installer for a stateful system, which makes running a server like this a bit of uncharted territory.

Then yes, you have a regular Linux (although based on musl, instead of usual glibc) on which you can install Docker.

The OnePlus 6/6T are also supported by Mobian [0], which is just regular glibc-and-systemd based Debian, and so a pretty familiar Linux server experience.

it might indeed be a good idea to avoid Android

It's a good idea to avoid Android because of kernel security as well. Old Android devices always use out of date Linux kernels even when using custom ROMs, and when running (containerized) network services you really depend on the security of your Linux kernel to keep those things properly isolated. Both PostmarketOS and Mobian do bring current mainline Linux support to these devices, so you can be quite a bit more confident in your kernel that way.

It's a shame PostmarketOS and Mobian don't really support many newer devices well. Last I checked the OnePlus 6(T) were still the highest performance devices that had okay support. The Snapdragon 845 - a 2018 flagship SoC - in the Oneplus 6/6T made them real high performance device to repurpose for a long time. In 2024 though it's now beaten in performance by the Raspberry Pi 5 or RK3588 based Armbian based devices. Those SBCs of course already have much better I/O and more straightforward ways to get a supported Linux running on them (and don't require disconnecting the battery with custom soldering). So you need to be really committed to reusing your old hardware to go down this route.

[0] https://wiki.debian.org/Mobian/Devices

Nintendo optimizes for cost, not maximum performance and almost always selects older technology. AMD Z2 chips go into $600+ bulky low margin PC gaming handhelds whereas Nintendo likely will want to hit $300-350 while keeping a healthy margin.

This also means that the Switch SoC doesn't use an expensive cutting edge manufacturing process. And it probably won't be made in TSMC factories at all. Leaks pretty clearly indicate an Nvidia Ampere based SoC built on Samsung's 8nm process, so it's the same tech as Nvidia's consumer line circa 2020.