- RsmFz parentBut I never maximize my web browsers, either
- We have that here at Firezone. To deal with I/O we don't use Tokio inside the test boundary at all, just futures. So no I/O, no sleeping, etc. Thomas explained it here https://firezone-git-docs-blogsans-io-firezone.vercel.app/bl...
I haven't dealt with it directly on Firezone but I wrote one or two games this way for game jams years ago, and I keep wishing it would catch on. It was harder with the games because floating-point math doesn't like to be deterministic across platforms.
- Well that's also true for Firezone :)
It's a tradeoff between in-process and out-of-process though. It's nice that Firezone Gateways don't have access to the service's memory space and can't crash the process, but it's also nice that an in-process Gateway equivalent doesn't need to loop through the network to reach its service.
- Firezone employee here. I believe we have an idea to let customers sign their keys so that they don't need to trust our portal not to rewrite keys. This is probably the same idea Tailscale hit on.
(I can't find this idea in the issue tracker and I don't think it's on the roadmap yet, but we've discussed it.)
Unfortunately there is a big convenience-security tradeoff, managing your own keys and certs is a lot of work.
- I don't remember any big insights except that I'm pretty bad at estimates.
Everything that feels like a "half-day" task took an entire day or two. I would look back on every feature and think, "No way was I working on that for X days straight?"
Basically nothing takes less than half a day.
- Oh I built one of those with Rust and FLTK: https://six-five-six-four.com/git/reactor/annoying_journal
I figured if it works for software profiling it oughta work for people. And I set the interval to some Golden Ratio thing like 37 minutes, with the hopes that it wouldn't log the same times every day, but also wouldn't be purely random.