(Indeed, cosmo libc does exactly that, so it's definitely possible.)

Strictly speaking, that's false, my hobby project chawan[1] supports capsicum :)

Anyway, IME capsicum vs pledge doesn't make much of a difference because seccomp already forces you into a specific sandbox architecture; after implementing that, adjusting the result to support the rest takes (relatively) little effort. So I think the difference in adoption is more because nobody has volunteered to do the work for capsicum (and keep it up to date etc.)

[1]: https://chawan.net

No, the "single while loop" is just harder to implement than a naive recursion, because recursion is a natural way to implement tree traversal. With a while loop, you need an explicit stack, which is more complex.

(A stackless traversal seems unrealistic here, as getting the succeeding node would be too expensive. Not that I've tried...)

> I look at code from the heirloom project and, despite its warts, I think we've lost something in the past 45 years or so.

I've just tried and heirloom rm segfaults on the same test too. Which is no wonder, seeing how that code also recurses.

(It's mentioned somewhere else in the thread, but this is exactly the reason why GNU had to specify "no hard limits" as a policy. Unix used to be full of such bugs.)

    function rm(node) {
        for (const child of ls(node))
            rm(child);
        unlink(node);
    }

(I guess by now you have a solid retirement plan; maybe if the field had been burnt to the ground while you were younger, you'd have had a different opinion.)

Now there is a plagiarism machine built on top of decades of this work that seemingly solves 3 and promises to solve 2 (badly, but usually this matters little), the programmers that (indirectly) helped build it are told they're fools for doing so, and threatened by losing their status if they don't adapt to the "entrepreneurial way" (well, the full promise is "you'll lose it anyway, but if you cooperate in stuffing sama's pockets then maybe you get to keep it a bit longer").

So what really surprises me is not that people are upset but that so few are.

So why is Cloudflare saying the author got blocked because of WebGL?

> > Such things are blocked in WebKit, and have been for years. Meaning it's tracking so awful that even Apple would block it, and as far as I can tell it's not the kind of privacy protection you can easily disable in it.

> This is also false. Webgl fingerprinting works just fine on Safari. They might try to mitigate it by adding some noise, but that's not so different than what firefox does, and is certainly not "blocked".

While I don't have an iDevice to try, the assumption that they are special cased is fair... because they are: https://blog.cloudflare.com/eliminating-captchas-on-iphones-...

(Yes, this is basically WEI in a shinier package.)

CORS has no relation to this issue. Cross-origin means there are at least two origins, but in this case there is only one (where you're trying to navigate).

> But if request is originating from inside the network (as it would from a terminal emulator)

Why would the terminal make requests? Obviously it will dispatch the link to another program specialized in making requests to a protocol, like... a browser?

> Granted, on its own, this should be safe. But attacks are usually composed from multiple bugs and/or weaknesses in design. Hence why security folk keep talking about “defence in depth”

Every feature can be part of an exploit chain, but the "clicking a URL will always lead to the text it is under" ship has sailed 30+ years ago. If your system cannot safely handle this operation then you're in deep trouble, and I don't see how crippling every program in existence is the right solution to that.

> I actually voiced some concerns with this original hyperlink proposal several years back. In fact lots of developers and security researchers did.

Based on what you've written: you and other self-claimed "security researchers" started spamming this spec with concern trolling about hypothetical (non-existent) "security issues", then the author finally got tired and locked down comments, which were obviously intended for people interested in the feature, not those trying to sabotage it.

> Just one persons mission to dictate how everyone else’s terminal, and security model, should operate.

Nowhere does the proposal say that your terminal has to implement this. Indeed, if you have a working ANSI parser the escape sequence is ignored automatically (as the spec also explains).

Have you considered that the person trying to dictate how others' terminals should operate might be you?

Also, this is not limited to HREF, it's defined in URL[0] so you can also put newlines in new URL("...") etc.

[0]: https://url.spec.whatwg.org/#concept-basic-url-parser

An important nuance you seem to be missing is that SUSv3 is equivalent to "IEEE Std 1003.1-2001" (that is, POSIX 2001).

In practice, I've had to work around more POSIX compatibility issues in macOS than in all other actively developed (Free) Unix-likes, combined.

(To differentiate between the case where it's actually two vowels, you have to put an apostrophe inbetween; their example is 小唄 -> ko'uta.)

(You can set a custom w3mimgdisplay command, but it has to speak the same protocol as w3mimgdisplay. If you're feeling adventurous, you can try modifying https://github.com/uobikiemukot/sdump/tree/master/yaimg-sixe....)

Unifont is also dual-licensed under GPLv2/SIL OFL.