rook

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.

Um, actually it’s called a typestate.

I’m aware he isn’t there now, but it bears remembering that he was there at the beginning when these goals were being shaped, and as we have seen with twitter there’s nothing to stop him coming back, even if nostr is his new best friend for now.

I read that posts on BlueSky are permanently stored in a blockchain,

So, this is complex and hard to find concrete information on, but:

1. Bluesky use a merkle tree based things. Don’t call em blockchain… that’s the sort of thing cryptocurrency boosters want so as to present their technologies are useful.
2. Posts are stored in a merkle search tree, but attachments are stored separately. Attached blobs (like images) can be (and are) deleted independently of the tree nodes which reference them.
3. The merkle trees are independent and can be modified without having to rewrite the whole history of every post on bluesky, because there isn’t one central official ledger of all posts.

From bluesky’s own (non technical) blurb on the subject,

it takes a bit longer for the text content of a post to be fully deleted in storage. The text content is stored in a non-readable form, but it is possible to query the data via the API. We will periodically perform back-end deletes to entirely wipe this data.

The merkle trees are per-user, which makes history-modifying operations like rebasing practical… this facility apparently landed last summer, eg. Intention to remove repository history. Flagging tree nodes as deleted, and then actually destroying them in a series of later operations (rebase, then garbage collection) would explain the front end respecting deletions but lower-level protocols showing older state for a little while.

They can sell out to someone else instead? Amazon seems to want to be an AI company, for example, and their current offering isn’t great even by the relaxed standards of LLMs.

When we hit AGI, if we can continue to keep open source models, it will truly take the power of the rich and put it in the hands of the common person.

Setting aside the “and then a miracle occurs” bit, this basically seems to be “rich people get to have servants and slaves… what if we democratised that?”. Maybe AGI will invent a new kind of ethics for us.

But the rich can multiply that effort by however many people they can afford.

If the hardware to train and run what currently passes for AI was cheap and trivially replicable, Jensen Huang wouldn’t be out there signing boobs.

Exciting times in wordpress/automattic land. Mullenweg and co are being sued by WP Engine, who apparently have a wordpress commercial offering which is awful and evil, unlike his own commercial wordpress offering which is just fine, and you can tell because he can use the wordpress(.)org blog which is the mouthpiece of the FOSS project he builds upon to tell you that people who don’t pay him lots of money are cancer.

https://notes.ghed.in/posts/2024/matt-mullenweg-wp-engine-debacle/

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.