stratts

You can see this in the Artificial Analysis benchmarks - GPT 6.1 Sol on medium thinking scores 10 points higher than DeepSeek 4.1, but is actually cheaper per task, as it only outputs 15 million tokens instead of 250 million.

Though for longer sessions I think DS4.1 would still come out cheaper... it's hard to beat that 98% cache discount

I thought this was very interesting - there's the map upfront, but you can also drill into individual countries and regions with some nice tables. Some "obvious" things here, though a few surprises:

* The solar potential of a gloomy, northern locale like the UK is "only" half of somewhere sunny like Australia. Though I can imagine the swings between seasons are greater.

* Northern Canada has a surprising amount of potential, compared to European regions at the same latitude

This happens with everything LLMs write - code comments, readmes, user facing UI text, etc. It just can't help but include every irrelevant detail from the context.

It's definitely gotten worse over time as well. Looking at older README files I generated using Opus/Sonnet 4.5, its actually quite shocking how clear and concise they are. Whereas eg, Opus 5 will write paragraphs and paragraphs about random things I prompted, or a partial solution that was then scrapped for something else.

My theory is that the increasing strength in performing long-context tasks has led to this particular quirk.

Codex does this too, I've noticed. LLMs seem to love documenting irrelevant implementation details in what should be user-facing text. I guess because the context is overwhelmingly the technical side of things, so without a later directive to steer it, that's what's most likely to come out.

Except on that page there's immediately a claim that isn't backed up by any of the citations, eg:

"The hunting-safety effect has been substantial. The non-fatal hunting accident rate in the United States fell substantially over the decades following blaze-orange adoption, with state hunter-safety data consistently identifying the orange mandate as a major contributor to that decline."

None of the sources have any national hunting accident data - there's a single link to data from New York, and nothing that would support the claim that state data "consistently" identifies anything...

OP here. I thought this was quite interesting as it's built around the RP2040, using GPIO to communicate with the DS - the firmware is completely open source and reprogrammable via USB.

Additionally, the launcher supports a bunch existing flashcards all the way back to the original R4 which released in late 2006.

Also, it's cheap! Unsurprising given the hardware, but I picked up a couple for $10 each, compared to the $40-50 you'd pay back in the day

This is an awesome idea and really resonates with me.

I did something similar for my site:

https://stratts.au/_editor/?preview=%2F&file=_site%2Fcontent...

You can edit and rebuild the site from within the browser, then download a .zip that contains everything. The editor can even edit itself.

Beyond self-modifying sites being just plain cool, there's a longevity aspect to it that I find very important as well.

There's also https://www.sparktype.org/ (a browser based CMS) which is also along similar lines.

Daily isn't the only option - you can still get monthly lenses.

The idea of writing a draft on paper, or cutting out squares to prototype layouts on a table, sounds like a nightmare to me. But I never did like pen and paper much and have lived and breathed computers since I was young. My ideal method of writing is a full screen monospaced terminal

That said, I do much prefer reading on paper, or at least on e-ink, for many of the same reasons outlined in the post. Computers and phones are just too distracting, and too dynamic.

And I'd love some way to write down shopping lists or appointments, and have them available wherever, without having to pull out the phone. Our current method is a whiteboard + a photo whenever we need it, which doesn't quite cut it.

I think this is a risk with anything that promotes itself as "unlimited", or otherwise doesn't specify concrete limits. I'm always sceptical of services like this as it feels like the terms could arbitrarily change at any point, as we've found out here.

(as a side note, it's funny to see see them promoting their native C app instead of using Java as a "shortcut". What I wouldn't give for more Java apps nowadays)

It was always possible to write large amounts of crappy code if you were motivated or clueless enough (see https://github.com/radian-software/TerrariaClone). It's now just easier, and the consequences less severe, as the agent has code comprehension superpowers and will happily extend your mud ball of a codebase.

There are still consequences, however. Even with an agent, development slows, cost increases, bugs emerge at a higher rate, etc. It's still beneficial to focus on code quality instead of raw output. I don't think this is limited writing it yourself, mind - but you need to actually have an understanding of what's being generated so you can critique and improve it.

Personally, I've found the accessibility aspect to be the most beneficial. I'm not always writing more code, but I can do much more of it on my phone, just prompting the agent, which has been so freeing. I don't feel this is talked about enough!

Not only that, but so many people are reluctant to pay for anything so your average installation is chock full of freemium plugins. I've worked on plenty of sites whose admin page looked a bit like the IE6 toolbar meme.

It is, but OP said you need both a NAS and a mini PC

You don't need a NAS, really. My setup is a second-hand i5-7300U fanless mini-PC I got for $90, 2 x second-hand 4TB HDDs, and 2 x USB 3.5" enclosures. It's messy but it works... I haven't measured power in a bit but I reckon it pulls around 20-30W, which is around $15-20 a year at my current prices.

We back it up daily using restic to an old 2TB NAS that's at my parents place + the occasional manual backup

Both my wife and I are reluctant to upload our entire photo collection spanning 20+ years to the cloud. Immich has been working really well for us, the experience for her is just as seamless as it would be for Google Photos, I think.

And at $180/yr for the 2TB of storage we'd need to pay for, vs. maybe $200 in hardware, it pays itself off pretty quickly... if you exclude the time spent setting it up and administering it. But I don't mind, it's a bit like digital gardening for me.

It's a spectrum, isn't it? From targeted edits that you approve manually - which I think you can reasonably take credit for - all the way to full blown vibe-coded apps where you're hardly involved in the design process at all.

And then there's this awkward bit in the middle where you're not necessarily reviewing all the code the AI generates, but you're the one driving the architecture, coming up with feature ideas, pushing for refactors from reading the code, etc. This is where I'm at currently and it's tricky, because while I'd never say that I "wrote" the code, I feel I can claim credit for the app as a whole because I was so heavily involved in the process. The end result I feel is similar to what I would've produced by hand, it just happened a lot faster.

(granted, the end result is only 2000 LoC after a few weeks working on and off)

> Ubuntu in 2026 is pretty much the same as Ubuntu from 2006.

Well, Ubuntu MATE perhaps :)

Windows LTSC I find comes pretty close to the less intrusive Windows I remember from the XP/7 era.

Beyond the pricing part of it, just having media that isn't dependent on an external device is so nice.

But for TV series in particular, watching on disc is quite clunky after a decade+ of streaming services, and DVR boxes prior to that. I'll buy them in principle, but ultimately they end up ripped and viewed via Jellyfin.

Making homebrew for the Nintendo DS was how I got into programming in the first place. Devkitpro was too confusing for me back then, so I used something called PALib, essentially a pretty hacky library built on top to make it "easy".

Nice community at the time though, I made a pong clone where the main selling point was that you could switch between different "themes", and a bunch of people contributed some really nice custom ones to be included.

But there was (and still is) a flood of amazing indie games. Due to the lower barrier of entry it was just naturally accompanied by a deluge of crap.

GitHub seems to be the worst of both worlds - partially rendered on the server, but then the frontend inexplicably pulls in additional data like... commit messages??

It's a double hit of latency, and for bonus points, the commit messages won't load at all if your browser is slightly out of date

Android already has this strict oversight, in theory, in the form of the Play Store. And yet.

Personally I feel much more safe and secure downloading a random app from F-Droid, than I do from Google, whose supposed watchful eyes have allowed genuine malware to be distributed unimpeded.

My understanding is that the current plans are to implement async in userspace, as part of a broader IO overhaul.

This would involve removing async/await as keywords from the language.

What's the state of the art here?

Most of Zig's safety, or lack thereof, seems inherent to allowing manual memory management, and at least comparable to its "C replacement" peers (Odin, C3, etc).

Package management in Zig is more manual than Rust, involving fetching the package URL using the CLI, then importing the module in your build script. This has its upsides - you can depend on arbitrary archives, so lots of Zig packages of C libraries are just a build script with a dependency on a unmodified tarball release. But obviously it's a little trickier for beginners.

SDL3 has both a native Zig wrapper: https://github.com/Gota7/zig-sdl3

And a more basic repackaging on the C library/API: https://github.com/castholm/SDL

For QuickJS, the only option is the C API: https://github.com/allyourcodebase/quickjs-ng

Zig makes it really easy to use C packages directly like this, though Zig's types are much more strict so you'll inevitably be doing a lot of casting when interacting with the API

Looks nice! Some thoughts:

  const now = ctx.flag("now", bool); // type-safe flag access

This is type-safe, but only at run time. Since your flags are (or could be) known at compile time, it would be nice to have this throw a compile error if the type is invalid.

Or even better - fully lean into comptime and generate a struct so you can use field access without specifying a type:

  const now = ctx.flag.now;

This is what works for me, assuming an clean project created using 'zig init-exe':

At the top of your build.zig, import the raylib build.zig inside raylib's /src folder (exact path will depend where you've cloned raylib)

  const raySdk = @import("raylib/src/build.zig");

Use the imported addRaylib() function to build raylib, then link to the exe and add include path

  var raylib = raySdk.addRaylib(b, target, optimize, .{});
  exe.addIncludePath(.{ .path = "raylib/src" });
  exe.linkLibrary(raylib);

After that, you should be fine to just use @cImport to use raylib within your project

  const ray = @cImport({
    @cInclude("raylib.h");
  });

  pub fn main() void {
    ray.InitWindow(800, 450, "raylib [core] example - basic window");
    ...

You don't even necessarily need bindings to use Raylib in Zig. It uses Zig's build system so you can just clone Raylib's repo, add a couple of lines to build.zig, and it's ready to go with autocompletion and everything.

Both Raylib and Zig include all dependencies too, so I was able to build a single 700kb .exe from Linux, copy that to my Windows machine, and it just worked immediately without any issues. Pretty amazing.