Yes, with 6.8. That's still a ways off for Debian/Devuan, but one should be aware that X11 support has been in feature-freeze for some time and anything but critical bugs are very unlikely to be fixed.

DNS spoofing is a very old attack, as are most of the others mentioned. There are undoubtedly more which were not, and calling a fix for one a "defence" is like plugging one hole in a colander and calling it "sealed".
What's new here is breaking client-isolation so those old attacks all work again. It's basically ARP spoofing, and that was a gold-mine in terms of what you could do once you had control of the stream. DNS fuckery is a problem, but it's really just the tip of the iceberg.

If you use "coffee shop" style public wifi (which I personally think is a terrible idea), use a VPN or tunnel (preferrably with a pinned host cert).
If you administer the same, use separate access points and segregate them from your main network.

Ed. Ahh, I see I have reached the perfect post count.

There's so much wrong here I'm not even sure where to start.

1) epsonscan2-6.7.87.0-1.src.tar.gz is the source code, unless you feel like building the scanner tool from source yourself, you almost certainly want epsonscan2-bundle-6.7.87.0.x86_64.deb.tar.gz (from the "drivers" section of the download page) instead.

2) You can't just stuff a 'cd' command, a directory name, a file name, and a script with relative path into one line and expect it to work.
'cd' takes exactly one argument (the target directory), you provided three.

3) Adding more random stuff to a syntactically incorrect command-line won't make it more right.

4) Nor will changing the order of said random stuff.

* Get the right file.
* Unpack the archive

tar zxf epsonscan2-bundle-6.7.87.0.x86_64.deb.tar.gz

* Change into the directory created above (use tab-complete if you value your sanity)

cd epsonscan2-bundle-6.7.87.0.x86_64.deb/

* Run the installer script

./install.sh

If you inspect the stream, you'll see that the webserver incorrectly sets "content-type: text/plain" in the response header. Firefox is believing what it's told, as it should.
This is a disturbingly common misconfiguration in javascript-infested eula-gated corporate "download portal"s, and the javascript nonsense they use to make mirroring painful and ensure you agreed to all the things and clicked all the boxes tends to interfere with client-side mime-sniffing that might otherwise work around it.
It's not a browser bug.

Or, ya know, maybe admit that systemd does actually have some good points, and take inspiration and/or code from the things it does well.

Elogind works, it solves real-world problems, and it arrived at a time when the only alternative (consolekit) was an unmaintained mess nobody wanted to rely on if there was any other choice.

Now, we have more options. Turnstile and seatd are things, consolekit2 is actively maintained again. The situation might warrant reevaluation, for a number of valid technical reasons... Which "it's part of systemd, ick, kill it" is decidedly not.

BSD and other unixes had no choice, because removing all the linux-isms in [e]logind was arguably more work than fixing consolekit or implementing your own solution.

Touche, diplomacy is not my forte. My intent was was not personal disparagement but a technical disagreement on the measurement criteria. If I came across otherwise, my apologies.

My confrontational wording was largely due to ongoing frustration (here and elsewhere) with use of code or overall package size as a proxy for quality or usefulness. Obsessing over memory or disk space and perceived "bloat" does, as they say, "pull my chain", and doubly so when the numbers presented are potentially misleading.
None of that has anything to do with greenjeans personally of course, if it sounded like a personal attack, again, my apologies.

"Lol, in 29 mb" sure sounds like throwing shade at keepassxc on account of installed size, and that's a reflection on the developers, no?

Right, so documentation is bloat, and everyone speaks English. Got it.

Sure, I never said your program wasn't good. It's not your code or your contribution I took issue with, rather the misleading comparisons you keep making.

No, I'm giving you misery for making obviously skewed comparisons. Including translations isn't "bloat", it's basic accessibility.
Focusing on code size and/or memory footprint above all else is also rarely the whole picture, and frankly I'm tired of constantly hearing about it.

Same goes for the hair-shirt minimalism shtick in general, as popular as it appears around here. 4MiB or whatever is nothing, and translations are only loaded when needed.
Trading away features to be able to brag about how small something is is dumb, and not everyone needs or wants to compute on a turnip.
Debian/Devuan is a general-purpose distribution, running on 20 year old hardware is not and should not be the priority. There are whole distros dedicated to minimising memory and disk use.

Like I said, Gentoo isn't really a time-sink once you have it set up the way you want it.

Endless Space 2 is on my GoG wishlist awaiting a decent discount, and Galactic Civilization 4 appears to be steam-only, DLC-everything, and kinda expensive... so I haven't paid it much attention.
Time is finite and games that are both steam-free and GNU/Linux native take priority. Stellaris is both, so that's the 4X I've been playing most recently. vOv

Is a classic for sure, and I did play it way-back-when (didn't everyone?). But it's also a 4X/grand strategy, so a comparison to Stellaris might be apt but one to Starsector is not.
Starsector is not a 4X (though there is a mod to add 4X elements), nor is it really a strategy game. The real-time arcade(ish) fleet combat is the core, and while you can play that a bit like an RTS it's at its best when you're piloting a ship directly.
My comparison to Star Control might not have been ideal, I was thinking specifically of the top-down combat in SC 1 & 2, or SC2 gameplay overall - which is more action-adventure than strategy.

My argument is (and always has been) that refracta-installer needs a consistent UI, with a real workflow that supports such elementary principles as going back a step or cleanly aborting an install.
Whether it's GUI, TUI, or CLI isn't the point, the point is that as it stands it's an incoherent mess of random dialogs and terminal windows with completely inconsistent behaviour and no mechanism for maintaining coherent state or running steps in anything but one narrow linear order.

For example: Most of the process is random yad dialogs, then suddenly up pops a terminal window with a TUI debconf prompt. If I abort that prompt, I expect an option to do it again, go back a step, or abort the install... But instead we're back to yad and the script continues with missing configuration as if nothing happened.

GUI or TUI, scripts and yad or debian tooling... Pick one and stick with it for the whole process.

Lol, if we're playing the "oldest working drive" game... Conner CP-210 (1984) no issues, no bad sectors. Not much use nowadays being 42MB, but still occasionally boots DOS in one of my vintage boxes.
Most of this is really just survivorship bias of course. To get any real idea of HDD vs SSD reliability you need a much bigger sample size than any of us have.

IMO trying to gauge how many SSDs last 14 years is a bit silly at this point in time anyway, since most SSDs available back then have long been retired... Not because they failed, but because they were miserably small. A HDD from 2012 is probably a size that's still useful today, but an SSD from the same period is eclipsed by commodity SD cards and USB flash drives at a fraction of the cost.

375GB(ish) platters were state-of-the art in 2010, and 2 platters is about all you can do in a 2.5x3/8" laptop drive. These days areal density is a fair bit higher, so the multiples are different.

If you're installing on a toaster perhaps. I'll take answering more questions to have more control any day, and the actual install process is the difference between invoking dpkg repeatedly to install .debs and just doing a straight copy from the squashfs / live media. On any competent machine the overhead of using the packaging tools as intended is minimal.

Gparted is bloat, like any other GUI. I use parted, fdisk, or sfdisk if I want to pipe in a saved layout.
Chuck Norris edits the partition table in binary, with ed, which is also a valid approach. IMO.

Doesn't count when the "brief" code is a script and all the heavy-lifting is being done by external applications though. The same quantity of code spread out is... Still the same quantity of code, and probably slower due to all the forking and context-switching going on.

I see all you need is to drop promotions for your "best" thing for no reason, just because you like to promote.

This thread had nothing to do with i/o schedulers, nobody asked which one is the best.
When told out of left-field that something is "The best" (without an "in my opinion"), asking for some proof isn't unreasonable.