the game's uncommon method of generating galaxies of incomprehensible scale on device consistently for all players from a single-seed happening on a phone is remarkable for those of us who remember phones performing far behind consoles or desktop PCs.

No it isn't. Your phone is a supercomputer by 1980s standards, and seeded generation (whether from a PRNG or hashing coordinates or whatever) goes back to at least then (and probably '60s/'70s). I'm not slamming the game, and seeded generation is often a good idea, but the idea that you can do it on handheld supercomputers is not remarkable, even the tiniest little bit.

You wanna see something super-fucking-impressive on an iPhone? Go back to the very first model and behold that it runs a truly-remarkably decent web browser. That was way more futuristic than this.

I really wanted to like the game but even a few hours of gameplay showed that it was repetitive and kind of bleak and depressing.

I found this other article that talks in more detail about what he's been doing with it.

You are right. Maybe Linux Foundation members have been pressuring him to use it for something in the kernel. They pressured him successfully in the past.

No one else wants them.

This article does a better job showing what Linus has been working on with LLMs.

I guess the key is to use AI to do something you're bad at. Apparently you are good at making lovely documents, so that wasn't effective.

People who talk about "junior devs" don't know much about the software industry.

Those are functional tests, not unit tests (unless your specification was so detailed it was written in UML).

That is begging the question. What I mean is, a lot of people want more complexity, because they want things to take longer, because they make more money. Middle managers want programmers to be busy but go slowly so they can justify hiring more people. There was an interview with Marc Andreesen about that, and Bjarne Stroustrup earlier.

Bottom line: faster isn't better.

Generally if you document your interfaces, that's enough. The comments end up being useful because then I can just read the comment to figure out what a function does (and what values are valid, how it behaves on error) instead of spending time looking through the code to figure it out.

Get the interfaces pretty. The internal code can be fixed later if needed.

If you want to do a good job with code review, it takes about as much time as writing the code. You need to test every line, etc.

Most of the time we trust the developers so as reviewers we just skim through the process, but that's harder to do with AI.

Of course people should beware. Anyone who has a problem with Flock is surely aware that they are only a fraction of "the problem," though among the more visible.

I'm concerned that some Flock haters might take us down a slippery slope to where you can't have a camera in your house if it looks out onto the street, or that you shouldn't be allowed to record cops, or that I shouldn't be allowed to have a camera attachment on my Manhattan apartment balcony telescope that I normally just use to furiously goon to the good people of NYC who don't close their curtains. (Oops, forget that third example.)

I can't say I'm a fan of Flock but if their rights are infringed in a way that might possibly expand to everyone else, then they will need to be defended.

That said, I have a modest proposal for the law-enforcement-related problems of surveillance vendors. Require non-warrant sharing with LE to be unreliable. For every geo search, remove a random half of the applicable results and replace them with deliberate, randomized false positives, so that LE will know the data shouldn't be taken too seriously on its own. If cops act without confirmation while KNOWING it's _at least_ 50% likely to be wrong, that'll help with the civil suits for false arrests.

Probably not.

25 cents is two bits (in auctioneer talk https://en.wikipedia.org/wiki/... )