shiomiru

He holds copyright, but to my knowledge he hasn't been an active contributor for a very long time.

(At least I remember reading a discussion on BZFlag licensing a decade ago, when his inactivity was already noted. Looking at the commit log, he made 9 commits since 2011 and they mostly concern licensing.)

Er... nothing? That's the point, if you statically link to glibc 2.51, then you get a version of pledge where "stdio" allows the stdio syscalls made by glibc 2.51 (say, "read" and "write"). Next time if you link to glibc 2.52, you get a pledge that allows stdio syscalls made by 2.52 (maybe "pread" and "pwrite"), etc. Nothing changes for the user because the libc wrappers for "read"/"write" are synchronized with the pledge promises.

This is often repeated in these kinds of threads, but I don't think it's true. You just have to implement it in glibc, which can map the flags to the actual syscalls used on the current architecture and restrict the process to those with a seccomp BPF filter.

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

> A single while loop could do the job correctly and use less RAM. It'd probably also be faster. But that wouldn't be a rusty thing to do?

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.)

I don't think that's related? The bug alluded to looks something like

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

and no amount of tail call optimization will save you here, because this isn't tail recursion. Of course you could rewrite it using an explicit stack + tail recursion, but then you might as well be using a while loop.

I think it's just a divide and conquer approach: if they killed it everywhere at once, there would be a larger backlash, so they are careful to roll out the change gradually.

I meant it as an euphemism for "it's universally sought after (i.e., you'll probably find a job)". Few would think being a programmer gives you some kind of special "social status"; it's always been a "nerd" hobby that happened to pay (relatively) well.

(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.)

There's also the economic problem that programmers had until recently been highly regarded because steps 2-3 were hard. "Open source" solved this partially by utilizing the labor such (relatively) well-paid people gave away "for the love of it", but it was not nearly enough to put most out of work.

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.

I can't speak for the other projects you listed, but at least chawan is actively maintained by yours truly.

I like to have a simple config AND a real scripting language. That way, the UX for changing "simple" things remains straightforward (you can even add a config editor panel), while for less simple things you can use a real programming language (reducing pressure from the "simple" config to turn into a DSL).

> Plenty of internal-only systems are not locked down securely and only thing preventing mass exploitation is browsers CORS settings.

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?

Isn't that effectively the same as or-later? I can always fork your project, change the MAINTAINERS file, and relicense without your consent.