aidanhs

I also loved 3, "Songs of Conquest" has been an enjoyable spiritual successor for me recently even if the base game is quite limited on factions and a number of mechanics differ. I'm also keeping an eye on "Heroes of Might and Magic: Olden Era" when it eventually releases.

I know it technically isn't true and I use the word 'practically' deliberately. The problem is that as soon as you opt into one part of nixpkgs (say a compiler) you end up implicitly opting into large parts of it because of common code in nixpkgs that make assumptions about undocumented magic environment variables etc that other packages (e.g. libc) may make use of or set.

I feel like a core problem though is the assumption you use Nix for everything - as soon as you try and pull in prebuilt pieces for pragmatic reasons, or output something you can use somewhere outside of nix, it starts making life hard.

I don't really like Nix but it's probably fine for this - you have files that come in, a build step, and output files. Your derivations (build recipes) are functions that can take arguments to e.g. provide a set of patches to apply. There are recipes for building a kernel in nixpkgs already which you could fork.

The main annoyance I'd have in your case is probably the number of file copies of large images it may do to keep things isolated, but most hermetic build systems will do something similar.

Nix is very awkward (and slow) to use for fine-grained caching, which is price of entry for a decent build system.

It also comes (practically) shackled to nixpkgs which is a barely-documented cataclysm of packages that extensively bake in assumptions that you are also going to use Nix as your runtime environment.

The principles behind Nix are nice but the implementation is sorely lacking in my experience.

Every single time Claude has confused me and I've asked what it's talking about, it's because it's got something completely wrong and has managed to obfuscate the wrongness behind never-introduced terminology, poor analogies and (what I can only assume is) exposure to wording it's used in its chain of thought reasoning.

A single question is enough for it to retract the error and correct itself. Suggesting that not understanding some of these messages is a lack of human comprehension rather than the agent being flat out wrong is...a bold take.

Typically a feature of good human technical communication is the ability to concisely explain key ideas so one can quickly identify any divergences between understanding. Opus 5 is dreadful at this.

The single saving grace is the intuition that if I don't understand it's probably wrong.

I think you've linked to a private repository.

Fair enough, would love to see another writeup on the performance you observe even if it fails - in practice numbers are hard to come by.

I've recently been going down the rabbit hole of creating a "fast start dev env" and it's interesting to see how this article differs from other approaches (codesandbox has some fantastic blogs, the fly.io blog on sprites has interesting pointers, e2b and daytona are related open source tools). Everyone has a different solution based on their tradeoffs.

I thought the memory snapshotting part in particular was clever since most container based systems don't bother (VM/firecracker based ones can use UFFD and call it a day), but by having emulated syscalls you can actually do single-process restore pretty well.

I am a bit dubious of the use of fuse (though it clearly works well!), and I wonder if ublk (what I ended up using) might alleviate some of the pain/magic in fuse tuning. I'd personally also be looking at forking gvisor to take a memfd which you enable UFFD on for the page loading (I have some firecracker patches where I do the same). It's nice because you can optimistically push pages, rather than waiting for the requests to come in. The series of three codesandbox blog posts are good background reading.

I'm super interested to hear more on anything you can share about your projects, or the niche of gov projects you're aware of - I've been doing some work with gov and haven't seen this requirement yet, so want to be prepared if it does come up.

(contact details in profile if you prefer)

One annoying part of using chroot if you're creating them on the fly is teardown - you have to manually invoke umount, and also take care to get this right for partially created chroots (maybe you detected an error after mounting proc, in the process of getting other files in place).

This was my original motivation in creating machroot (mentioned elsewhere in this thread) and having it use namespaces.

Out of curiosity, what would you say the current state of the art is for full compilable decompilation? This is something I have a vague interest in but I'm not involved enough in the space to be on top of the latest and greatest tooling.

Interesting, that's helpful, thanks - so with the eventual arrival of memory64 and assuming I only wanted to target desktop systems and assuming browser implementations permit large allocations (e.g. 8GB) - large 64bit apps could work fine. I have a use case for this I've been poking at for a bit, but implementing my own version of cheerpx would be a lot of work, maybe I'll just wait!

On open source - I can only give you feedback as an outside fresh pair of eyes :) I incorrectly interpreted that it was full stack OSS based on the overall blog post 'vibe' and had to deliberately double check because I was aware of cheerpx beforehand. Perhaps it's just me. I look forward to the cheerpx blog post!

All the emulation of desktop machines in WASM I've seen so far have been for x86 - do you think there are significant additional hurdles for x86_64? Or is it just a matter of time?

Separately, one bit of feedback - it's cool that webvm is open source, but I think it's fair to ask you to be upfront that cheerpx itself is not (which is fine!) in the blog post itself where you talk about webvm licensing. If I wasn't already familiar with the wasm emulation space I would have felt rather misled.

Right, because Anyscale found a niche that distributed compute matters in (AI) and built great libraries/hosted platforms/services around that. I would venture that the money they make from people who pare back things to just ray core is ~0, which is why it's open source.

Put another way - building such a platform doesn't preclude commercial success, but (at least for us) it isn't sufficient. Fly.io might be able to pull it off if they want to explore that direction imo.

Fwiw if you dig around in the ray core codebase (as I did when I was doing competitor analysis years ago) you can use the core C code from other languages to build such a platform for Rust if you like - they had Java and C++ interfaces at the time, but I haven't looked in the last 5 years.