The Great Nix Flake Check
let’s start with some context: I’m currently writing unflake, which is essentialy a userspace reimplementation of nix flakes. to do that, I need some understanding of what flakes are: I want my implementation to be compatible with the upstream one. unfortunately, flakes don’t have a specification, are barely documented and upstream doesn’t really know how they work either (which is a big part of the reason why they’re still unstable).
so, naturally, I downloaded every flake I could get my hands on to run some tests and find potential incompatibilities.
while I was primarily interested in incompatibilities in unflake, I also ran every test with both CppNix and Lix, so I found some differences there too.
debugging egui on Wayland
this is a horror story about Wayland, scaling and debugging multi-layered abstractions.
I’m currently working on a project that requires me to write a GUI app. egui is generally a pleasure to work with, at least for simple cases, so I went with it. to start, I needed a fixed-size window: for various reasons, making my app flexible-size didn’t make much sense.
I’m not a fan of Deno’s security model
this has been bothering me for a while now, so I want to write down my thoughts so I can get it out of my head and move on. we’re gonna talk about how Deno approaches security, specifically with its permissions system, and why I think this approach is fundamentally insecure and misleading.
the progress pattern for error reporting
there’s an annoyance that comes up regularly when dealing with error paths: returning an error (or raising an exception) means you lose all the context you had stored in local variables. this prevents you from printing a nice error message, emitting useful metrics or just otherwise acting on this information. this is especially problematic when task is terminated from outside, like on timeouts.
one solution to this problem is really simple, but I didn’t see it written down anywhere, so I did that.
deref specialization in const contexts
there is one useful trick in rust that’s usually called “autoref specialization”. it allows to select a method implementation based on traits some type implements. if you’re not familiar with the technique itself, dtolnay described it nicely here. this post is going to be using a variation of this idea that uses autoderef instead of autoref, but the principle is the same: (ab)use the method resolution to select behaviour based on a trait bound.