@feld

unless the domain is taken away from you. Or the TLD is retired. Or the registrar shuts down and the domain expires and you can't renew it because it's stuck in limbo.

Assuming an old-school TLD (com/net/org/iso 3166 country) that's not run by muppets, any of these things happens less often than hosting providers going under and a lot less often than fediverse hosts throwing in the towel.

I'm not saying it's a panacea nor is it available to everyone, but it's still a shitload easier than self-hosting your fediverse instance. "It's ok to lose your fediverse presence and have to start again because it's also possible to lose your domain name" doesn't strike me as a particularly great argument given the relative probability of those events.

And it doesn't even seem like it'd be especially hard to fix, if the software folk wanted to. A tool to export the database as plain text (JSON, whatever) and another tool to import it in the new place.

@Jeremiah @EUCommission @EC_NGI @NGIZero @nlnet that's really useful, thanks - co-signed https://ww.telent.net/2024/7/16/the_european_union_must_keep_funding_free_software

@clacke @lowqualityfacts I don’t “like” nearly as much as I probably should, perhaps because I still have the association with “favourite”, and “favourite” is a very high bar

@james I dunno, I saw “Common Lisp” and “assembly” and went… is this an SBCL maintainer?

qemu arm will not successfully load an uncompressed kernel because it hardcodes the load address as 0x40010000, which is not an offset of 0x8000 from a nice round number and apparently that offset is required. It will load a zImage (#liminix doesn’t currently build this target because we use U-boot everywhere else and why ship a self-extracting compressed kernel when that task can/should be performed by the bootloader) because they can relocate while uncompressing, and apparently it will also load a U-boot uimage - but looking at the source code I think it’ll only load the old-style uimage and not the FIT uimages that #liminix is using on arm{32,64}. Or I could use -device loader instead of -kernel and have full control of where it loads into, but then it’s not called with the DTB address in r2 as the linux kernel expects it to be.

So many options, none of them really very good…

Background reading upon which some of these assertions are based: https://people.kernel.org/linusw/how-the-arm32-kernel-starts