niz4ts

I did free-running sleep for a while (I mention this in the original 28h day post), but decided on 28h days to weekly match other people's schedules.

I exercised regularly before 28h days, and my sleep was still chaotic with that. I didn't exercise daily though, it was hard to fit everything I wanted to do on a 24h day. Having longer days means I can fit more things, which I think is one of the reasons why I increased the amount of exercise after moving to 28h.

I also haven't read any research on this, I just did what felt more natural and logical to me.

(I'm the post author)

For the few weeks that I'm required to go back to a "normal" sleep schedule, I long every day to go back to my 28h schedule.

I might at some point in the future try moving back to 24h for a longer period of time, but I'm planning to stick to the 28h schedule for at least a couple more years before I do this, and I'll keep doing the yearly updates to document things.

I don't have one yet, but I will definitely make one once I make a public release of nixless-agent. At the moment I use a combination of nixos-anywhere (for initial provisioning), colmena (mostly for quick testing/dev setups, because it lets me push things directly to a machine), and nixless-agent (still experimental and going through lots of testing). Ideally my final setup will be just a mix of nixos-anywhere and nixless-agent.

(I'm the post author)

Thanks! I have to admit that I've had the itch to build my own NixOS-inspired system more than once, and I haven't done that because I just don't have time to dedicate to this among all the other projects I'm working on. I wasn't aware of not-os before, but I'll definitely dig into the code!

(I'm the post author)

As others said, I've moved away from doing nix builds on servers and into a less wasteful (if you're running multiple servers) approach of building once, deploying the bits into a cache, and making the servers fetch them from a cache. I've been slowly working on my own tool to make this workflow easier (nixless-agent, you can find an early version on GitHub).

I didn't attend the talk, but Nix's dockerTools doesn't need to worry about layer ordering because there is no chance of a layer overwriting another (most layers just write to their respective /nix/store/hash-pkgname directories, which is guaranteed to be unique by Nix).

When I read this, I got a little too excited and thought they managed to get wireguard connections happening in the browser with webassembly (this isn't impossible, but the only attempt[0] I know of so far only works because of extra things tailscale has). It's an idea I've had for a project, but one I haven't had time to dedicate to (yet).

In any case, really cool write-up! I wonder if they thought about making `flyctl` do a check with their API for any command that requires talking over wireguard to ensure the keys would be installed in the gateway. Since `flyctl` knows when the last command was run with it, it could do this only after some inactivity. And on the gateway machines, they'd just clean up any inactive peers with a cron (which they seem to be doing already).

Not a solution as elegant as the one they reached (which is super cool), but I'm assuming the considerably lower effort would make it appealing.

[0]: https://labs.leaningtech.com/blog/webvm-virtual-machine-with...

Way simpler than what I was expecting! Any notes to share about Cloud Hypervisor vs Firecracker operationally? I'm assuming the bulkier Cloud Hypervisor doesn't matter much compared to the latency of most GPU workloads.

As far as I know, Fly uses Firecracker for their VMs. I've been following Firecracker for a while now (even using it in a project), and they don't support GPUs out of the box (and have no plan to support it [1]).

I'm curious to know how Fly figured their own GPU support with Firecracker. In the past they had some very detailed technical posts on how they achieved certain things, so I'm hoping we'll see one on their GPU support in the future!

[1]: https://github.com/firecracker-microvm/firecracker/issues/11...

How do you folks manage NixOS from a security/compliance perspective? I'm currently considering NixOS for a few test services in my company, and security/compliance is the biggest obstacle. Have you had to develop your own tooling for this?

To expand on it further: NixOS has modules and packages that come straight from Nixpkgs, and there are concerns with supply chain attacks because of that. How does your company solve this?