rook

I like the idea of small communities, but a major issue (possibly the biggest issue) as demonstrated by many mastodon servers over the years is longevity. What happens when your admin gets bored/burns out/dies/goes fash/is replaced with an asshole/is unable or unwilling to moderate effectively?

I don’t particularly like the big mastodon hosts (eg. mastodon.social) but they’re probably still going to be here tomorrow, unlike eg. octodon.social who are winding down because adminning was too much (after 8 years, which was a pretty good run!) and they didn’t have any plans or processes in place to handle this eventuality.

Between that sort of thing and stuff like matrix cryptography being full of holes and large matrix room management being a nightmare and email really being gmail, I’m slowly coming round to the idea that federation is too hard to do well and that if we could just manage a decentralised identity service and decent client software then it wouldn’t matter if servers didn’t talk to each other because we’d still have 90% of what people wanted from federation in the first place. Just a simple matter of engineering, I’m sure.

Oops, I’ve been trying to avoid calling it “clownstrike”, and didn’t quite manage to fix that initial syllable.

Summary of the recent crowdstrike report: 🧵https://infosec.exchange/@munin/112916974811882522

Munin wonders if the weird writing style of the report might be because crowdstrike used an LLM to generate a summary of several source documents, which would be funny-yet-depressing if true.

The actual causes of the incident probably won’t suprise anyone… “didn’t bounds-check, didn’t test parser on bad data, didn’t stage rollouts” in order of should-have-done-this-first-ness.

They could have just sat there and slurped up enormous profits from the bubble as all the people who can’t find a use for their “AI” systems buy nvidia hardware, but no. They had to get high from their own supply. I can’t see this boding well for them.

Ploopy kinda fills that niche, as the bits are replaceable and the non-generic parts don’t require stuff like your own injection moulding equipment. Not quite there yet, nor do they have a the full range of stuff you might want (and what they do have isn’t cheap), but it’s a nice start.

What do you mean RAG is basically LLM flavored elasticsearch

I always saw it more as LMGTFYaaS.

Xe Iaso joked about this sort of thing happening, not so long ago…

https://xeiaso.net/landing/alvis/

Meanwhile, for investors it can make it harder to identify genuinely innovative companies.

The problem here isn’t AI, it’s that the investor class is fundamentally stupid. They got lucky, either by birth or by winning the startup lottery, and they’ve convinced themselves that this means they’re vastly more perceptive, intelligent and capable than everyone else.

I’m working for a startup right now, and investment rounds feel a lot like a bunch of idiots standing around waiting to see who’ll jump first, and when one goes the rest follow, because they haven’t a fucking clue what they’re doing but desperately need to believe their peers do.

Eh, there’s a chance that machine learning might help here… there’s some interesting stuff come out of that area of research, like radio antennae and rocket engines and so on, but I’d bet anything that a) no LLMs were involved and none ever will be, and b) “ai” only appears in marketing copy and funding pitches.

I spend an inordinate amount of time at my C# day job adding documentation comments about exclusive access and lifetimes and ownership… things which are clearly important but which dotnet provides little or no useful support for, even though it has a perfectly good garbage collector. The dotnet devs were well aware that garbage collection has its limits, especially when interacting with resources managed outside of the runtime, and so they added language features like IDisposable and finalisers and GCHandle and SafeHandle and so on to fix some of the things GC won’t be doing for you.

I’d happily use a garbage collected language with borrow checking.

If you don’t have a perf requirement like “all these things need to be in contiguous memory” then you probably don’t need a generational index anyway… it is effectively a weak reference, after all. ECS stores are optimised for repeatedly iterating over all the things, and games might have complex notions of “reachability”, but most things aren’t like that. There does seem to be a lot of “I don’t like using Rc RefCell” in object arena design that isn’t always justifiable, though nested generics don’t make for the most readable code in the world.

You can always use something like generational indices. They pop up a lot in ECS systems. A suitable container with an opaque index type prevents creation of invalid references, lets you check reference validity at runtime, and generational indices prevent reuse. The compiler can’t help with lifetime tracking, but that’s a problem with any shared reference type pointing to a resource with a lifetime that can only be known at runtime, eg. Arc.