TomatoCo

You're talking about a secure hardware element to ensure that the algorithm can't be exfiltrated and the dates brute forced against it. If you have a secure element that knows what time it really is, so you can't lie to it, just have it withhold the key until the specified date.

> a modern processor is very resilient against losing its functional blocks during operation

I'm very curious, can you elaborate on that?

With how modern video codecs use data from previous frames you could make a not-entirely-specious argument that we already have a tool that can do this and it's called ffmpeg.

Basically, any impact with a drone will disable it. The trick is actually hitting it. So you either need volume of fire (which implies a buttload of small rounds), precision (which might imply lower mechanical or sensor reliability) or proximity detonation. If you're going for the latter and are optimizing for cost you don't (necessarily) want the smallest round possible.

That'd go against the (implicit?) idea of your message being viewed by the literal next person but I like where you're thinking. If it were upfront about there being two queues, one for a sentence or less and the other for greater than one sentence then it might work.

It's not exactly what you're looking for but one of the big three contenders in the AI space (after OpenAI and Anthropic) is Mistral, based in France.

Sounds like a labor version of Jevon's Paradox, https://en.wikipedia.org/wiki/Jevons_paradox where increases in efficiency cause a resource to be consumed more, not less.

Is there a game in this genre where you script your character? As a kid I made a few RuneScape bots and found that getting the logic right like "the world is in this state, what actions do you perform?" was the fun part about that.

I also never got the random events automated so I just read a book while it ran and killed it whenever one of those popped up.

To belabor the point and repeat a bit from Wikipedia, this was bar-none the absolute perfect flight crew possible. A flight crew with over 65000 hours experience and, riding as a passenger, a training pilot with a further 23000 who had specifically practiced this exact failure (total loss of hydraulics) after a lost craft four years prior.

For further reading, https://admiralcloudberg.medium.com/fields-of-fortune-the-cr...

The ubershader is the thing that emulates Flipper at a low enough level to use the precompiled "shaders" directly. Prior to that the precompiled "shaders" were examined and recompiled into individual shaders, a process that took time.

(Why "shaders" in quotes? Because they weren't shaders as we know them today but really more like lists of hardware flags for how to flow data through a fixed function pipeline)

That's the trick, they actually don't provide precompiled shaders as you know them. The graphics hardware back then was fixed function pipelines with a tremendous number of options to configure how they work. The downside is that you can't run truly arbitrary code but the upside is that they can instantaneously switch behavior as fast as setting a register.

Prior to ubershaders the emulator took a configuration for the hardware pipeline and turned that into a shader, which took time to compile. Ubershaders work by emulating the entire fixed function pipeline in one glorious shader until the smaller, more efficient shader can be compiled and slipped in.

Basically, the ubershader is the only thing that can actually understand the "shaders" packaged with the game and start using them with zero latency.

Why not just precompile all the possible hardware combinations? There's far more combinations than atoms in the universe. Why not just precompile all the hardware combinations that the game actually uses? There's no way to tell before hand without examining every branch of the game's code which ranges in difficulty from "computationally prohibitive" to "fundamental theorems of how computers work says this is impossible".

The article mentions that some users actually passed around cached shader packs, but that solution was brittle.

I can't recall which standup comedian it was, but he had a bit about games where they're the only form of entertainment that tests you. A song doesn't make you dance along to continue. A book doesn't quiz you on its themes and slam shut if you're wrong. For some games, being hard to play is their point. That's why accessibility is great to make games where that isn't their point more, uh, accessible. And maybe even those hard games should have accessibility, I haven't given that front enough thought yet.

The article makes it sound like this sensor is only to avoid the handle itself heating up to the point that it would burn the user.

For all of these "how can we batch predicting the next n tokens?" the intuition is basically that it takes a buttload of math to predict some of the tokens, but that most tokens are actually easy to guess. For example, if I asked "What was that phone number from that 80's song?" as soon as a model generates 867- it shouldn't take that much math at all to finish predicting 5309.

To learn Go, I made a small app that supports encrypting files with a public key where the keypair is generated from a password. Because I want my backups to be encrypted but it offends me to keep symmetric keys lying around. With this you can just generate a file containing the public key, stream your file through the app, and decrypt it later with just the password. It's very minimum viable product, but I'm confident that the crypto is done well.

https://github.com/TomatoCo/warren

(It wasn't exactly over a weekend but it only had two or three days of effort put into it, which I think meets the spirit.)