Trying to fetch the package file returns 404, because old packages aren’t retained forever. I’m not sure if they’re kept around at all, or deleted the moment a new version is fetched, but so long as you update the sync db, (run pacman -Sy) you have nothing to worry about in that regard.

That’s true about personal devices, but at least my server doesn’t have nano installed. Though, in that case, you might manage with sshfs or something similiar. Also, for the ‘Learn Vim’ step, you only need to know the absolute basics, like entering input mode, saving & quitting.

Using Vim on other people’s computers may not always work. I know someone who remapped ‘next match’ from ‘n’ to something else, though --clean helps with such configurations.

Also, nano may not always be installed.

The safest way to edit a file on someone else’s machine for a emacs “user” might be something like emacs -q || nano || vim --clean || vi --clean || vi, assuming a sane shell. (the || vi --clean step is probably unnecessary, becuse if it’s supported, it’s just vim, which would then also be available)

No, no. You’re supposed to drop tables, not throw them.

I’d recommend attempting to scam ten thousand euros or pounds instead. Likely more stable, given the current situation.

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.