hamishwhc

The model doesn't have image input capabilities (yet, it seems from the post), so for the Doom demo, a harness is extracting a bunch of structured information from the game (map layout, enemy locations, player ammo, health, etc) and providing it as a massive JSON blob to the model so it can make its decisions. This model _could_ be hooked up to make the decisions for a self-driving car, but it would need to be fed a structured blob of the situation around it, so all the computer vision problems of self-driving are still there. And that's before you get into the confidence and accuracy of this model.

Now someone’s going to write a react-manim renderer I’m sure.

> cdk8s is like this, but it is not a good example of what you can do with a generator

As a die-hard fan of cdk8s (and the AWS CDK), I am curious to hear about this more. What do you feel is missing or could be done better?

Because if you are working with CSS, there’s a decent chance you’ll be using npm and/or Vite, and it’s convenient to integrate your tools to save yourself time. Don’t like it, pick another installation method, like the standalone CLI build option, that needs neither.

Very curious about the context of that first comment, do you have a link?

How can the “attesters” verify the integrity of the user agent? Sure the attestation is signed, but why can’t we mess with the data sent to the attester and just nullify the entire point of the proposal? The “browser acceptance criteria” in the spec, that would presumably contain this info, is just “TODO”. Thanks Google for conveniently omitting that key detail.

Also interesting that its implied in the explainer that attesters are just HTTP endpoint dealing with “billion-qps” traffic. Again, point above, but also how can we trust any attester to not use the (completely unobfuscated) information the user agent is sending them?

I guarantee that big websites will host their own attesters, only allow use of their attester, and require attestation for every request, allowing them to fingerprint every single user.

This completely misses the part where Discord is keeping the server nicknames system and adding a display name (that will be your existing username), like Twitter’s username + display name system. You can absolutely keep having different names for different servers. I still think this change is dumb, but you concerns you’ve expressed aren’t going to be a problem.

Not OP, but I would recommend Kysely as a great example. I’m on mobile so don’t have a link at hand sorry.

I think a large chunk of this is the tendency in larger Rust projects to split themselves up into smaller library crates, rather than single crate monoliths: single libraries that you use may depend on 5 different crates all from the same project, that count as separate in the number you’ve quoted. On top of that, C bindings tend to live in their own crate, so while you might depend on the openssl crate, it in turn depends on openssl_sys which contains raw bindings (rather than a nice Rust wrapper). That all said, I think crates.io is still at the initial stage of “tiny crates each doing a single thing” that I think every registry goes through to begin with.

Anything stopping us from just creating a CNAME to our tailnet domain and registering certs for it instead of whatever.ts.net? This seems like it should work in my head...