I'm involved in a new workers cooperative, and I've been thinking about how organizational structures relate to the workplace. Cooperatives are fantastic, where they exist. In the tech world, two prominent examples are Igalia and Bocoup. (I worked on SpiderMonkey at Igalia, and collaborated with Bocoup on test262 tests.) Both are highly specialized consultancies, and both are internally democratic. To get some idea of what it's like to work at a coop, I recommend the 2023 FOSSY talk "Inside Igalia: Scaling a Co-Op Beyond 100 Members": https://www.youtube.com/watch?v=du7fC8VCbXg

Workers coops have structural limitations, though: with some exceptions, they're new entrants to the market and have limited access to capital. Unions interact with existing businesses, which I think is why they're so much more controversial than coops, and they can bring some of the benefits of workplace democracy to a much larger group of people than coops presently can.

Forgejo is actively developing ActivityPub-based federation support as a set of experimental features (https://forgejo.org/2023-01-10-answering-forgejo-federation-...), including federated starring: https://codeberg.org/forgejo/forgejo/pulls/1680

If by actively you mean: after 3 years, nothing shipped but federated stars (maybe, none of the links in that PR work or contain the content promised, Codeberg still has no actual support for federation with other instances). Forum entirely dormant since August 2025.

mrustc (a handwritten Rust compiler in C++) is already used for that in Guix and likely other distros: https://guix.gnu.org/blog/2018/bootstrapping-rust/ This would have other benefits though, as it's both a second bootstrapping path and could potentially compile Rust programs for platforms not supported by LLVM

Guix uses mrustc for bootstrapping Rust, as required for compiler packages; it's a really impressive project and has worked well in that role for some time. This new project is interesting for other reasons though, because mrustc is targeted at the de fact "subset" of Rust in use by rustc at any given time. This looks like it could have broader applications, like compiling Rust programs for platforms not supported by LLVM. If it really targets ANSI C (C89 or so), that's potentially many more platforms than are possible with ordinary rustc

More on the Rust bootstrapping process (2018): https://guix.gnu.org/blog/2018/bootstrapping-rust/

> compiling Rust programs for platforms not supported by LLVM

For this, gcc-rs[1][2] is the most promising candidate.

[1] https://rust-gcc.github.io/

[2] https://github.com/Rust-GCC/gccrs

Gccrs is valuable for various reasons (bootstrapping, refining the spec, etc), but for the main purpose of "compiling to targets supported by gcc but not llvm", it's definitely not as promising as https://github.com/rust-lang/rustc_codegen_gcc. It's a rustc backend, at the same level as llvm or cranelift, it's much further along than gccrs (already available as a rustup component and can compile any rust code) and will not suffer from lagging behind rustc.

But OP has wider ambitions: the real niche targets are supported by neither gcc nor llvm. A rust-to-c transpiler that can adapt to weird C compilers should have a very wide reach.

But what about platforms that even GCC doesn't support well? I'm thinking mostly retro stuff like 16-bit x86.

I might have seen that Bootstrapping Rust article, how interesting. I've been curious about Guix for a while, one of these days I need to dive in and explore deeper. I really enjoyed their article on full-source bootstrap, it's relevant now more than ever.

Building from Source All the Way Down - https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...

This is also not guaranteed to be adopted widely, but the RISC-V Server Platform Specification was recently standardized with mandatory UEFI and ACPI support: https://github.com/riscv-non-isa/riscv-server-platform/relea... I'd rather have OpenFirmware like enterprise POWER, but anything is better than static device trees.

CL-HTTP or AOLserver

sure looks like VB there, what’s the plugin? Didn’t see anything like that before.

That's Go.

Which runs on what computer in 1995?

I'm not sure what point you're trying to make. Here it is in C, so you can run it on you computer in 1995? Because servers could make decisions in 1995.

int main() { int s = socket(AF_INET, SOCK_STREAM, 0); setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &(int){1}, sizeof(int));

    struct sockaddr_in addr = { AF_INET, htons(8080), .sin_addr.s_addr = INADDR_ANY };
    bind(s, (struct sockaddr*)&addr, sizeof(addr));
    listen(s, 10);
    printf("Listening on :8080\n");

    while (1) {
        int c = accept(s, NULL, NULL);

        char req[1024] = {0};
        read(c, req, sizeof(req) - 1);

        time_t now = time(NULL);
        int tuesday = localtime(&now)->tm_wday == 2;

        const char *status = tuesday ? "404 Not Found" : "200 OK";
        const char *body   = tuesday ? "Not Found (it's Tuesday)" : "Hello from 1995!";

        char resp[256];
        snprintf(resp, sizeof(resp),
            "HTTP/1.1 %s\r\n"
            "Content-Length: %zu\r\n"
            "Connection: close\r\n\r\n%s",
            status, strlen(body), body);

        write(c, resp, strlen(resp));
        close(c);
    }
}

A post claimed CGI led to bad standards around query parameter formatting and parsing. I was merely pointing out that, prior to the advent of CGI, if you wanted to actually do anything with those parameters on the server, you had to extend whatever primitive HTTP server you were running, write some custom code and invent your own “standard”. There were no server side frameworks or standards.

this seems to be how PEG parsing became popular during the last couple of decades, for example; see https://bford.info/pub/lang/peg/ (peg.pdf p11: "This work is inspired by and heavily based on Birman’s TS/TDPL and gTS/GTDPL systems [from the 1970s ...] Unfortunately it appears TDPL and GTDPL have not seen much practical use, perhaps in large measure because they were originally developed and presented as formal models [...]")