rrradical

But that CI is very easy to setup.

Take a given start point; feed a set of inputs; compute a checksum on the resulting state. Check that the checksum matches on different platforms.

And if your language is good you can parameterize your logic on a particular numeric type, so that a particular fixed point implementation is consistently used

> The fixed randomness and determinism thing sounds great on paper (all of this does), but in reality this is an extremely confining way to build a video game. Ensuring you maintain determinism across many platforms is where things get super nasty.

Why 'nasty'? I agree it's a problem to solve, but you just use a fixed-point math library and it's fine. Determinism is freeing, not confining. It allows you to do things like rollback netcode, replays and easy debugging. You can't just say that 'reality' happens to be what you in particular are used to.

Very neat project. Could I use this code to generate skin tones in my own project? Or more meant to just be educational/inspirational? I guess I'm wondering if you've considered adding a license.

I thought 'stacking' PRs was useful in two circumstances.

1. The PRs are across different related repos, so they literally can't be combined into one PR.

2. You want to keep producing work while the first PR is in review. So you stack subsequent PRs onto the same branch. Basically just pipelining.

But this feature doesn't seem to hit either use case, and instead just seems to be a different form of stacking commits into a single PR. The standard advice has always been to make atomic and meaningful commits (using e.g. rebase to tell a nice story for the reviewer). And reviewers can go through commit by commit if they like.

What am I missing?

I've always wondered why I can't pay some small fee (20 cents? $1?) to read an article. Why it have to be an entire subscription? If I put $20 / month into an account and then spend that bit by bit on high quality articles from different sites I'd gladly do that.

Well it was definitely a bug. It worked in some cases (I think it even worked in google at first, and then a few days later it manifested). And the feature was advertised, even though, again, they never claimed the software to be release quality.

But my point is that, similar to security, you don't want to build this kind of feature piece meal. Either the containers are fundamentally walled off or they aren't.

I tried Orion about a year ago. I tried using the profile sandboxing. Logging into my google account in one profile also logged me in in another profile.

I can definitely excuse some bugs (there were crashes for example that I didn’t overly mind; I understand I was using prerelease software). But something like account containers should be built fundamentally to disallow any data sharing. If data sharing is a bug, and not fundamentally disallowed by the architecture, then it’s going to happen again later.

So for that reason I’m not bullish on orion.

As a haskell programmer, all of that was easily readable.

So the AI wrote a bug; but if humans wouldn’t catch it in code review, then obviously they could have written the same bug. Which shouldn’t be surprising because LLMs didn’t invent the concept of bugs.

I use LLMs maybe a few times a month but I don’t really follow this argument against them.

I'm having a lot of trouble understanding your definition of work. Even if you meant perform- most athletes have to perform continuously outside out of games in order to earn minutes in game. And touring musicians are performing way more hours than you cite.

Imagine if programmers were like NFL players, constantly measured on their performance against their peers.

I believe also quads also deform better during animation.

I switched from opengl b/c I was tired of staring at a black screen with no debugging information (sure...glGetError) when I tried to implement a non-trivial feature. After tons of work to learn vulkan and getting it up and running, I still think it was worth it.