In proof of work, the client performs (relatively) slow & expensive calculations to prove that it’s not spam. If you tried to make too many connections, the work would add up, preventing you from affecting the availability of the service.

For PoW to work, the server needs to generate a challenge, then the client needs to solve it and return the answer. JavaScript can do this without any input from the user.

For JavaScriptless PoW, you need to find a way to perform those slow calculations without access to a programming language.

Like I said in my previous comment, solving the challenge can happen outside of the page, after which the user could paste the answer to a normal HTML form, for example. This allows PoW to work without JS, but requires user interaction & eternal tools.

I don’t know about Dread, but Tor has built-in PoW now. Since Tor runs outside of the document/tab, unlike JS, it can do a lot more. Tor’s PoW happens invisibly between the network request & response, making it unobtrusive & bypassing JS entirely.

It might be pretty difficult to implement the work part of proof of work without JS in a practical way. Of the three languages available on the web, HTML, CSS & JS (+ WebAssembly, which requires a bit of JS IIRC & would probably not be available) JS is the only one that allows you to perform the work in a sane way. (It might be possible to use CSS magic with remote resources, but that has its own problems if it’s even possible.)

It would be possible to use a dedicated program or another website to perform the work, but it would be far from seamless to users.

The Linux kernel is licensed under GPLv2, not v3. The third version of the license forbids tivoization (vendoring unmodifiable copyleft software). Also, the GNU coreutils aren’t limited to Linux.

Unlike the other alternative coreutils, uutils focuses on GNU compatibility. If you depend on GNUisms, uutils allow you to unGNU & unGPLv3+ your system.

I haven’t used either, much less benchmarked them, but the performance differences should be negligible due to the IO-bound nature of the work. Even with compression & encryption, it’s likely that either the language is fast enough or that it’s implemented in a fast language.

Still, I wouldn’t call the choice of language insignificant. IIRC, Go is strongly typed while Python isn’t. Even if type errors are rare, I would rather trust software written to be immune to them. (Same with memory safety, but both languages use garbage collection, so it’s not really relevant in this case.)

Of course, I could be wrong. Maybe one of the tools cannot fully utilize the network or disk. Perhaps one of them uses multithreaded compression while the other doesn’t. Architectual decisions made early on could also cause performance problems. I’d just rather not assume any noticeable performance differences caused by the programming language used in this case.

Sorry for the rant, this ended up being a little longer than I expected.

Also, Rust rewrite when? :P

TL;DR: GIMP 3 is out!

It means that 3.0.0 is released. A git tag has also been made. Not sure why a release hasn’t been added to GitLab yet, as it has already been 8 hours.

In practice, this means that GIMP version 3.0.0 (actual release, not a release candidate) has been released and can be built.