I always wanted to build a local mesh network of pay phones on the playa and call it Black Rock Telecom. Maybe 12 or more phones set on plazas. Geographically not being located in the US made this project tricky to realise.

Shouldn't a sufficiently powerful laser be able to cook the sensor quickly and easily?

You can buy very powerful handheld green laser pointers on Amazon for around 20 bucks. You absolutely shouldn't shine one into a camera sensor, ever. It says so on the box!

I had an idea years ago to hook up a bunch of old payphones on the playa at burning man. Solar powered and connected over VoIP on a mesh network. Sadly never got to make it happen but would have been a fun art project.

Why stop at getting AI to write Rust? If everything is vibe coded and code is no longer reviewed, get an LLM to devise its own ultra terse, super dense language intended solely for minimal token use and speed.

/s... sort of

Why stop at writing code? We should all build our custom ASIC chips, or if you don't have a chip fab, at least do FPGA!

so in other words... simply binary?

Maybe we can skip the compiler...

It's the most ridiculous situation with council technology that they all use different providers for what are fundamentally the same functions. It's the same for council tax and a host of other services as it is for planning. Consequently, at least from the various portals I've used, they all do it badly. This absolutely could and should be done by a single, well funded central team.

Unless you use a nationalised product for this; this is the best outcome.

GDS was a national level effort and they certainly did a better, albeit not perfect, job than the myriad of private solutions councils use. There just doesn't appear to be the capability to properly specify and source IT at a council level.

Am I alone in not wanting banal homogeneity even on a work trip?

Probably after a certain quantity of work trips/year, yes.

Which Claude literally uses.

Given their username I would raise you that they're on the victoria line :-)

Supporting 10 different languages in regex is a drop in the ocean. The regex can be generated programmatically and you can compress regexes easily. We used to have a compressed regex that could match any placename or street name in the UK in a few MB of RAM. It was silly quick.

I think it will depend on the language. There are a few non-latin languages where a simple word search likely won't be enough for a regex to properly apply.

Exactly this. Unicode is a big beast to consider in regex concats.

woah. This is a regex use I've never heard of. I'd absolutely love to see a writeup on this approach - how its done and when it's useful.

You can literally | together every street address or other string you want to match in a giant disjunction, and then run a DFA/NFA minimization over that to get it down to a reasonable size. Maybe there are some fast regex simplification algorithms as well, but working directly with the finite automata has decades of research and probably can be more fully optimized.

This was many moons ago, written in perl. From memory we used Regexp::Trie - https://metacpan.org/release/DANKOGAI/Regexp-Trie-0.02/view/...

We used it to tokenize search input and combined it with a solr backend. Worked really remarkably well.