It was also pretty common to use more capable machines to get some headroom for development tools, either by compiling for one (DOOM on NeXT) or by cross-debugging the system under test from it (a still-in-progress Lisa when developing the Macintosh; a DEC minicomputer, IIUC, when developing MS-DOS). You still do the former when you run an x86-64 image in your Android emulator; you probably still do the latter if you are targeting a microcontroller.

[1] https://en.wikipedia.org/wiki/SWEET16

[2] https://media.ccc.de/v/34c3-9064-the_ultimate_apollo_guidanc...

Thanks to huge protracted union fights. You’ll find the credits in an old US-produced movie—say, Gone with the Wind—are much more sparse than in one from the last decade or two. Incidentally, those fights happened too early to include CGI artists, and those often do go uncredited (undercredited?) even today.

Not that the Hollywood unions are a definite positive in all respects, or that the whole idea of fighting an oligopsony by establishing a monopoly in the shape of a cooperative doesn’t ring warning bells in my mind. But the movie industry absolutely would not credit most people if it could get away with it, and I wouldn’t expect the software industry to be any different (barring rare early pre-financialization examples[1]).

[1] https://www.folklore.org/Signing_Party.html

3a. rdpru (similar issues to cpuid) or rdpmc perhaps surrounded with lfence or cpuid inside the same assembly chunk

For obvious reasons, this is somewhat niche and may not even make it into production code, but it’s also important when you do need it. It’s also memory safe. I guess in such cases you’d use fast C rather than Fil-C though.

4a. rseq

Probably even less feasible than atomics TBH, as such blocks will usually also contain control flow (at least that implied by to the nature of rseqs).

> Before the advent of AI, writing a parser for x86_64 assembly would have been such an annoying task that I might have never gotten around to implementing support for memory safe inline assembly [...].

It is annoying, but even before the advent of AI that didn’t stop the developers of TCC for instance.

With that said, given Fil-C is Clang/LLVM-based, shouldn’t an assembly parser, at least, be already available somewhere? I was under the impression that Clang (unlike GCC) actually parsed asm blocks.

[1] https://github.com/lifthrasiir/wah/

We recently (finally) got __attribute__((musttail)) in GCC[1], I’ve just tried it between functions with mismatched __attribute__((target))s and it does work, so theoretically you could code your interpreter that way. But it seems like you’re still bound to keep loading and storing vector state from and to memory and VZEROUPPERing your registers after each bytecode, and that doesn’t sound like a particularly good time.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119616

For example, there's no explicit property in schema's Person type [1] for a nickname. But the FOAF standard does [2].

Just add FOAF to the JSON-LD context:

    {
      "@context": {
        "@vocab": "https://schema.org/",
        "foaf": "http://xmlns.com/foaf/0.1/",
        "pronouns": "https://schema.org/pronouns" 
    }

    "@type": "Person",
      "givenName": "Timothy",
      "familyName": "Berners-Lee",
      "foaf:nick": "TBL",

[1]: https://schema.org/Person

[2]: https://xmlns.com/foaf/spec/#term_nick

I think you should just think about what metadata you actually care about, and the main metadata I care about (choose your own list) is authorship, publish date, last update, subject keywords, thumbnail (OpenGraph 1200x630), and summary.

There’s a long list of additional metadata that I could put in my webpages because there are standardized ways to do it, but, why bother?

And yes, you should use whatever metadata is applicable to your site and test it against the search engines/etc. you want to support to make sure that they are reading the metadata correctly.

Json-ld says: if you want to know whether the “title” property means the schema.org or the dublin core variant then you can find out which it is by <json-ld algorithm>

So you’d always use json-ld _with_ schema.org or something.

I tried using RDFa and liked the property that it was theoretically less redundant, but switched to JSON-LD because it JSON-LD is just easier to get working. And this is speaking as somebody who uses a hand-rolled static site generator—the issue here is that whether information is present in the raw HTML is something contextual, and if something isn’t present in the HTML then you need to put it somewhere else or it’s not mechanically parseable from the page. Like, to a human reader, a post on “Alice’s Blog” is assumed to be authored by Alice, so I may omit the “by Alice” text from the document, and then I would want to put that metadata in the page some other way.

Putting the metadata in JSON-LD lets me just be dumb about it. The metadata is always in JSON-LD, and the HTML may or may not contain an explicit representation of that same metadata. Easy.

But the JSON-LD does not need to contain the URL of the page (which is <link rel=canonical>) or the title (which is in <title>), for example.

For me, it depends on the project. For personal projects, I tend to use RDFa; otherwise, JSON-LD.

Granted, all of this is not for SEO purposes, but part of the ActivityPub ecosystem, which also uses JSON-LD for data encoding.

The kernel puts the vDSO in memory and tells ld.so where it is, but where if anywhere ld.so will put it in the search order it implements is its own concern. (TBH I don’t actually know whether ld.so will actually allow LD_PRELOAD to override the vDSO, but there’s no reason for it not to, except I guess for the syscalls that are needed to perform the dynamic linking itself.)

Since CXMT was _not_ blacklisted, this is good for global RAM supply.