mackman

In theory the parsing could run at a low privilege level subprocess. Root/admin is only needed to get the bytes.

The other interesting trick is you need a separate RNG for visual only affects such as particles than the one you use for the physics simulation. Depending on the game during replays, you could position the camera differently and then particle effects would render differently depend, depending on what’s on screen. Obviously that shouldn’t affect the way objects decide to break during the physics simulation.

One of the hardest determinism bugs I had to solve on the PlayStation three was that the PPU and the SPU actually used a different instruction set and had a different internal floating point register size. We had a multi threaded physics simulation, and during instant replay, we had to ensure that the job scheduler sent the exact same work to the correct cores or we got back subtly different floating point values, which of course, immediately caused major divergences.

Instant replays that require long-term deterministic behavior have to be bit perfect in a way that is dramatically hard harder to implement if trying to also do network synchronization. The hard parts of each of those is fundamentally different and trying to do them at the same time terrifies me. I have shipped console games doing both (independently) and was responsible for de-bugging determinism.

E13 was a great, simple, good looking WM I used for years. Eventually moved to Fluxbox then back to macOS when it went Unixy.

You are comparing orbiting earth in a shuttle to a lunar flyby in a pod. Very different risk profiles.

Messaging platforms where people receive and promptly respond to messages are more successful in the long run. That's why SMS overtook email. If you own a messaging platform there isn't anything inherently nefarious about pushing people to enable notifications.

OK who is gonna turn this into a functional terminal emulator for me?

I was down there recently on a helicopter-based expedition and they set up a forward base of operations with a few days of emergency rations in case of unexpected weather that prevents you from returning to ship. I asked them what happens if the blizzard lasts more than a couple of days. Someone somewhere has a recipe book for penguins.

The transit version of a turducken.

As best I can tell we've never sold the same product twice. Product roadmap is "whatever the last person I spoke to asked for." And tech debt maintaining a grab bag of 5,000 almost-but-not-quite-entirely-production-grade "must have" features that the customers rarely if ever use despite claiming that not having it was a deal breaker, is, well, debty.

> It is possible to create threads by using the OS syscalls bypassing completely the requirement of pthead. (Un)fortunately, I couldn’t find any popular libraries that implement the functionality by using the syscall interface instead of relying on pthread.

I have tried and failed to do this for a C++ program because the amount of C++ runtime static init/shutdown stuff you would need to deal with isn't practical to implement yourself.

Is this just a case of waiting to stay private while still giving current employees some liquidity?

Yeah I thought LIDAR was used for actual focus and depth map was then computed from the multi-camera parallax.

CORE only works on kernels that support BTF. This post introduces one workaround which is to generate BTF data for kernels without it. That's still only half the problem though. You also need to write your eBPF program so every kernel verifier passes it, even though every kernel's eBPF verifier has different bugs, capabilities, and complexity limits. I maintain a large eBPF program that supports 4.14 through 6.14. We implemented our own version of CORE before CORE really existed. In reality, it's a lot more work than "compile once run everywhere."