aktau

> The OS should also allow marking pages as piority to stop them from being swapped out.

This is IIUC possible using the mlock(2) family of syscalls: https://man7.org/linux/man-pages/man2/mlock.2.html. (On Linux, though I'm guessing other UNIXen and operating systems have it or something equivalent.)

Anecdata, but still:

I ordered a Xyber NAS (N150) back when they were still in stock, wiped the Ubuntu that came with it and built up a NixOS config [1]. The power usage is very good (12W with 2 internal SSDs, bluetooth, wifi and a bunch of services running).

If it dies, I won't be too sad since it was about $210. But it's doing pretty well (24/7) so far.

[1]: This ended up being useful. The built-in eMMC chip that I had installed the OS on gave out after ~1 month of usage and I had to reinstall. Thanks to the NixOS config, it took me much less time.

Great read. This is (unbelievably) impressive. Both from the model and the human. Congratulations. I also liked the postscriptum about the GPU driver.

Mac hardware is some of the best there is, but I lost faith in macOS around 2015 when I experienced a bug where XNU would shut down my device without warning if the wireless driver produced an invalid packet. (The shutdown code was in the open-source XNU part of Darwin. I don't know why the invalid packet was produced, perhaps there was a hardware issue, but the response shouldn't have been to hard reset the device immediately.)

Running Linux on this hardware, and being to use most of its capabilities, is awesome. Thanks to all the AsahiLinux contributors (directly and indirectly) for their work.

Given that Dutch is the ancestor here (not that Dutch hasn't changed since the split), I wouldn't call it "as if".

> For example, one of the unique features of my harness is that the filesystem is completely virtualized and all filesystem I/O is part of the session...

What are the mechanics of this? You mentioned bash so I asssume you don't "control" all the tooling. Is it running in a VM with an overlay filesystem that takes snapshots at every file interaction? Or perhaps outside a VM but containerized with a FUSE-based overlay filesystem?

My view is this isn't sufficent. They're pretty good at breaking out of stuff. A VM would be the minimal isolation boundary for me.

Hi Kenton!

One thing I'm wondering about (and was happy to see) is how you seem to have your (childhood) friends close by, at least on occasion.

I live in Europe and am considering what a move somewhere else in Europe (+/- 1000km) would mean. Seeing much less of my long-time friends, I imagine. But Austin seems much further from the earlier places you've stated you've lived. Did some of your friends just move with you? Are they visiting often?

> transparent matte coat for my exterior walls

I'm curious about this. Do you mean a layer of paint-like substance that makes the walls isolate better?

On Linux, "self" is /proc/self/exe. In general, I've seen people use `os.Args[0]`. But on checking again, I see there's even `os.Executable()` (https://pkg.go.dev/os#Executable) for this purpose.

I'm quite sure go test compilates can spawn themselves, I'm doing it on many platforms.

But, the test setup I was referring to was explicitly not that: the tests are spawning the main binary, not themselves. Using bazel+runfiles this is pretty easy to do. With the pure Go build tool, I'm not sure what approach I'd use to "guarantee" that I get a binary build for the same environment as the test.

+1, I like to test in a similar way. For example if I'm making a CLI, the test will spawn the CLI for each test-case, instead of invoking the code directly. This provides a more realistic flow, and makes it clear which user journeys one is supporting.

Faking responses I often do with environment variables, like:

  ts := httptest.NewServer(...)
  cmd := exec.Command(...)
  cmd.Env = append(os.Environ(), fmt.Sprintf("MYCLI_PROD_ADDR=%s", ts.URL))

Of course, it's better still to go down this turtle stack (e.g. by spawning a local instance of your backend server instead of some faked handlers), but that adds more cost. I find the trade-off OK here.

My favourite Delphi program, and the one I learned to program with, was Dev-C++ (https://sourceforge.net/projects/dev-cpp). AFAIK there is a more recent fork, but I also clearly recall the 4.9.9.? versoin number from back then. It was very fast (including startup). I enjoyed it a lot back when I was still on Windows. Funny that Delphi was used to create a C/C++ IDE.

Reminds me of VirGL [1] and Venus [2], which I think do something similar for OpenGL and Vulkan.

I use this with Baguette/Crostini on ChromeOS to get some light gaming done. Works very well [3].

[1]: https://docs.mesa3d.org/drivers/virgl.html

[2]: https://docs.mesa3d.org/drivers/venus.html

[3]: For Baguette, the Crostini-replacement, one needs to do a minor amount of tweaking to get 3D acceleration to work well (https://www.reddit.com/r/Crostini/comments/1sftdu1/comment/o...).

Much more resource heavy. I tried NixOS and Bazzite (and other spins purporting to be lighteweight) and the difference on a 2010-era mid-range laptop was noticeable in terms of sluggishness. Not that this laptop was going to be my daily driver, but I like experimenting. It was a good showing for NixOS and that decided which one I would take. All of the other nice things about NixOS (fast rebuilding, easy install images, remote deploy, easy build tweaks, ...) were cherries on top.

I'm curious. Do you have more information?

Yea, both Westpark itself and the open-air cinema inside the park are stellar.

It surprises me that no-one has mentioned Munich's premier city park though: the English Garden (Englischer Garten): https://maps.app.goo.gl/ug5fg8KUBHPWvRPD7.

It is, frankly, amazing. I've never seen infrastructure of this kind so close to the people, so sprawling and so well kept. People swim in side arms of the Isar too, many floating (see pictures near the start at https://maps.app.goo.gl/krgaM2tTKdzCzW398, where people surf on the mini-river).

Of the places I've been, Munich is by far the best one in this area (and many others) that I know.

I have the same question. It seems like a decent amount of posters here don't require (non-standard) interactivity. Plain HTML+CSS (perhaps via static site generators) would work.

It made me think about the Javascript present on my blog. The site works fine without JS (syntax high-lighting is pre-baked server-side).

There is some optional JS enhancement:

  - MathJax is used for turning LaTeX expressions into nice graphics on the client-side. A search reveals this could be done on the server-side, but I'd need to deal with the node.js ecosystem.
  - PJAX is enabled [1]. This is completely optional, but it noticeably made page navigation faster (feel instant), especially when navigating between pages already visited (forwards/backwards).

UPDATE: Reading https://triptychproject.org/, it seems like what PJAX does is item #3: "Partial page replacement"

[1]: The library is at https://www.aktau.be/js/pjax-standalone.js. It is invoked at the end of <body>:

  pjax.connect({
    "container": "content",
    "complete": function() { MathJax.typesetPromise(); }, // Reload mathjax after a pjax load.
    "autoAnalytics": false
  });

> If it’s important they will leave a message and I’ll get back to them.

I can't really do that. For some things (urgent and important), loved ones need to be able to reach me.

But yes, a lot of this advice would work.

Respect.

I hope to find the strength to be more like that. Also to give a better example to others.

I notice making the screen go grayscale (can configure volume up+down to do this in android) already makes doom-anything much less long-lived. The next step, since apparently I can't go cold turkey, is to try one of these alternative minimalist launchers to see if it helps. And to teach people that if they want something from me urgently, they need to call.

On the topic of watches, I used a smartwatch the company gifted me for a while. Went back to an analog watch. Much better.

I lot of people echoing the same sentiment. It made me recall a quote from early 2026 that made waves in a few programming communities (https://x.com/ThePrimeagen/status/2026771192191824108).

Quote:

...i hate the code it generates, i hate the feeling of getting everything i ask for and nothing i want. I hate the subtle offness around vibe coded things. It is just driving me nuts.

Not sure about RA, but for RA2 see https://chronodivide.com/

I think Neovim itself has been stabilizing quite a bit in terms of upgrade breakage.

A common reason for breakage is/was:

  - Neovim changes some API (deprecating, ...).
  - User upgrades Neovim and theres some incompability, OR user upgrade plugin and that plugin assumes a much newer version of Neovim. (I've often seen Neovim plugins "mandate" either the latest stable Neovim or even HEAD).

But:

  1. Neovim has been including some popular plugins (or at least their functionality domain) in the past few years. This obviates the need for plugin-for-$THING, and reduces breakage.
  2. ISTM that the pace of (new) plugin development in the Neovim-sphere has slowed down.

The latest example of #1 is vim.pack, which is a plugin manager similar to vim-plug, mini.deps (vim.pack is based on mini.deps), lazy et cetera.

I can remember removing vim-commentary (from tpope) a while ago because Neovim included something like it in the main distribution. Granted, that specific plugin never broke because it uses the stable viml API.

> Rayforce is a pure C17 zero-dependency embeddable engine where columnar analytics and graph traversals share a single operation DAG, pass through a multi-pass optimizer, and execute as fused morsel-driven bytecode. No malloc.

Sounds great. I hadn't seen an (explicitly) C17 project before. I wonder which features of it they use. I can only find very scant references in the depot (E.g.: https://github.com/RayforceDB/rayforce/blob/6c4b1eddad0ea728...).

Anyone know?

I clicked around in the kernel section and the other commenters highlighting the simplicity weren't lying. It's beautiful in its simplicity.

Seeing the screenshots I was kind of expecting this was a pre-emptive multi-tasking OS (forgetting what I read in the submission).

Things that thus surprised me on a cursory look:

  - noticed krn_main() ends with `while (1);` [1]. I would've expected a "schedule" call or something. I assume there's no real busy loop burning CPU, maybe it's never meant to reach this code?
  - I'm reminded of the "bare metal OS" when I see one of the apps call `krn_\*` functions directly [2].

[1]: https://github.com/luke8086/gentleos32/blob/main/kernel/main...

[2]: https://github.com/luke8086/gentleos32/blob/ea691f14635c023d...

Spot on. Heaven forbid it turns into a C++ (I'm not a Rust practitioner but from the outside it seems to accrete features pretty quickly as well).

The ease of grokking Go (both reading and writing) are big advantages, and facilitated by the "small" feature set of Go.

I have a feeling that after enough slop has entered the system, the AI will also have difficulty debugging/understanding it.

My questions are: will the AI get to be above our level at creating grokkable source code before it comes unmanageable? And even if not: will the models' ability to understand and modify slop outpace it's ability to create it?

For our jobs, I hope neither is true. But we'll see. Even in the best case we'll have a lot of cleaning up to do.

> As of writing this, I have not seen anyone describe a process that "scales" agent-driven development in a large company. There is, however, evidence from the past that it is possible. I would point to Microsoft in the 1990s, which did not have mandated review-before-commit practices. <...>. This is regarded as "old-fashioned" "cowboy" style development <...>. But it did work. It created some of Microsoft's most long-lived successful products, like the win32 API.

> Little appears to be written about this period of Microsoft history, if you were there I would love to hear or read about your experiences.

I, too, would love to hear about this. And which projects (including the win32 API) were actually the result of no code review. Also, what the (observed) prerequisites were for this to work.

Thanks for the notes. Different as/link is definitely a way for incompatibilities to creep in.

I remember when we still had tcc in Neovim CI. I think it got removed eventually for being too much of a burden to maintain.

How are slimcc/kefir different/easier to drop in?

This reminds me of a great adventure. A long time ago I was travelling through Brazil, in the Amazonas state. I was in Porto Velho and needed to get to Manaus quickly to catch a flight. The boat that would take us there (as I had found in the Lonely Planet) was present on the quay. But the captain didn't feel like going. If I remember correctly, he was waiting for more people. We needed an alternative route quickly.

The captain told us that if we took the bus to Humaitá (a smaller provincial city), we could take a smaller boat that would take us to Manaus. But he warned us that the boat only goes once in three days, and that it would leave soon. The last bus to Humaitá would also leave from Porto Velho promptly.

Despite this flimsy instruction, we didn't see any alternative. So we went. With great luck, we caught the bus and made it to Humaitá (I still have a picture of the boat river transfer the bus took: https://bashify.io/i/CdNcLf).

Our time in Humaitá was surreal. When asked about a boat to Manaus. Everyone told us a different story. There was no harbour (hydroviaria) personal. One person told us the boat to Manaus was named "Caçote". Another person said the boat was named something else. Then someone said it had stopped ferrying years ago. No, we heard from someone else, it would come in 5 hours! Yet another one said it was tomorrow. Someone else felt sorry for us because it had just left. I felt like I was in a (difficult) point and click adventure. There weren't a lot of people in town close to the river, so we ran into the same people from time to time. They would often give different answers to the previous time.

No one was willing to tell us they didn't know. Not a single person out of the 20+ we must have talked to.

In the end, a boat arrived. It went in the direction of Manaus. The captain said that he would only go up to Auxiliadora, and that was still a long way from Manaus. Once again without alternatives (going back to Porto Velho would surely mean we'd miss the flight), we chanced it. In the hopes that getting closer was worth it.

When we arrived at Auxiliadora, it was the smallest inhabited place I had ever been to. Perhaps about 13 houses. Some fishermen. No passenger boat would come for days, they told us. Not to take us to Manaus, neither to take us back. The fishermen had boats, I tried to offer them money so they would take us further. But their day was at an end and they wanted to relax, regardless of what I offered them (we were on a tight budget, but I was desperate enough to offer a significant chunk of a monthly wage, no dice).

Then we found out that on the boat with us, a woman had come who was in a similar predicament as us. She was Brazilian, living in MT and wanting to visit family in Manicoré (which was bigger, and closer to Manaus). Exasperated, she ended up convincing her family to come and pick her up with a speedboat. We hitched a ride. We were very thankful.

When we arrived in Manicoré, I felt like exploring the place. It looked so different from anywhere else I had been, like something out of a movie. But I couldn't. The docks were little more than a collection of wooden jettys (trapiche) that ran everywhere in criss-cross fashion. In order to even get to the quayside we would have to pass through many other boats. In the first one we went through, the captain walked past and I asked him whether he knew of a boat going to Manaus. He signalled where to put my bags. We were leaving.

We reached Manaus in the nick of time.

I love this story, and that time. These anecdotes definitely triggered my memory.

I tried btrfs on three different occasions. Three times it managed to corrupt itself. I'll admit I was too enthousiastic the first time, trying it less than a year after it appeared in major distros. But the latter two are unforgiveable (I had to reinstall my mom's laptop).

I've been using ZFS for my NAS-like thing since then. It's been rock solid ().

(): I know about the block cloning bug, and the encryption bug. Luckily I avoided those (I don't tend to enable new features like block cloning, and I didn't have an encrypted dataset at the time). Still, all in all it's been really good in comparison to btrfs.