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.

Oh dear, I guess we had better chuck dpkg in the bin then.
Here's a nice "replace $hated_thing with a stub that does nothing" package which breaks bootloader updates. I see that bug has still not been looked at, and the maintainer is still nowhere to be found. *Filed 2 years and 255 days ago*

While not directly comparable, it's exactly the kind of unexpected borkage that will ensue if we start intentionally breaking things, pretending services are available when they aren't, and lying to applications.

Xorg doesn't use dbus, it uses unix sockets for IPC. You only need dbus if you enable [e]logind support, which is only needed for "rootless" (i.e. brokered permissions) operation and is a compile-time option.

Uhh, so why not just do that then, rather than "quarrelling"? It's not rocket science, and no binary distro can please everyone with their choice of configuration.
Debian builds Xorg with logind support, and that pulls in dbus. Deal with it, or recompile to suit your taste.

FFS, just compile the things without dbus, then they won't try to use it to begin with and "somebody" won't need to do anything.

IPC, strangely enough.
Any modern DE will need some kind of IPC, the dbus spec is kind of a mess and everyone is doing their own random things with it, but it's what we have so it's what most projects use. Whether that's better than everyone having completely different solutions (e.g. dcop in kde3, corba in gnome) is a matter for debate.
There are dbus alternatives in the wild, but none of them have any real adoption.

"Just take my word for it, it feels faster (totally not confirmation bias, trust me bro)".
FTFY.

Thanks, but no thanks. In my testing on low-latency RAID NVME the best i/o scheduler is consistently [none]. I run Gentoo not Arch, so my ricing is data-driven.