The good news is that single-player games tend to age well. Down the line, the bugs are as fixed as they’re gonna be. Any expansions are done. Prices may be lower. Mods may have been created. Wikis may have been created. You have a pretty good picture of what the game looks like in its entirety. While there are rare cases that games are no longer available some reason or break on newer OSes with no way to make them run, that’s rare.

With (non-local) multiplayer games, one has a lot less flexibility, since once the crowd has moved on, it’s moved on.

It looks like it doesn’t support ARM architecture systems at all, or anything other than x86_64.

https://docs.bazzite.gg/Gaming/Hardware_compatibility_for_gaming/

Minimum System Requirements

• Architecture: x86_64

Lead image seems a cyanide and happiness cartoon,

It doesn’t claim to be a Cyanide and Happiness cartoon anywhere in the cartoon.

Systemd is unnecessary bloat. Actually, having an init system is unnecessary bloat. All one really needs is the Linux kernel and emacs.

http://informatimago.free.fr/i/linux/emacs-on-user-mode-linux.html

deleted by creator

The fanboying to the point of blinders is maddening to deal with among Linux users.

Alien who has arrived on Earth: “I’ve heard that you humans drive motor vehicles to get around. I should get a motor vehicle. Could someone tell me the best type to get?”

Human A: “You want a Prius.”

Human B: “No, that’s for tree-hugging, probably-homosexual hippies. You need a proper truck, a Ford.”

Human C: “Actually, Ford trucks are trash, what you need is a Chevy truck.”

https://www.youtube.com/watch?v=ZgeIiREvafQ

Frankly, the right answer is that pretty much any non-specialized distribution (e.g. don’t use OpenWRT, a Linux distribution designed specifically for very small embedded devices) will probably work fine. That doesn’t mean that they all work the same way, but a lot of the differences are around things that honestly aren’t that big a deal for most potential end users. Basically, nobody has used more than at most a couple of the distros out there sufficiently to really come up to speed on their differences anyway. Most end users can adapt to a given packaging system, don’t care about the init system, are aren’t radically affected by mutability/immutability, can get by with different update schedules, etc. In general, people tend to just recommend what they themselves use. The major Linux software packages out there are packaged for the major distros.

I linked to a timeline of Linux distros in this thread. My own recommendation is to use an established distro, one that has been around for some years (which, statistically, indicates that it’s got staying power; there are some flash-in-the-pan projects where people discover that doing a Linux distro is larger than they want).

I use Debian, myself. I could give a long list of justifications why, but honestly, it’s probably not worth your time. There are people who perfectly happily use Fedora or Ubuntu or Arch or Gentoo or Mint or whatever. A lot of the differences that most end users are going to see comes down to defaults — like, there are people in this thread fighting over distro because of their preferred desktop environment. Like, Debian can run KDE or GNOME or Cinnamon or XFCE or whatever, provides options as to default in the installer, and any of them (or multiple of them) can be added post-initial-installation. You wouldn’t say that a car is good or bad based on the setting of the thermostat as it comes from the dealer, like.

…having their own things to tend to.

“NetBSD!” “No, OpenBSD!” “No, FreeBSD!”

If you know how to edit a comma-separated-value text file and how to submit a PR on GitHub, you could make the image larger.

The present-day Linux kernel tree (not the Debian guys) actually has a target to build a Debian kernel package (make bindeb-pkg) straight out of git if you want, so you can pretty readily get a packaged kernel out of the Linux kernel git repo, as long as you can come up with a viable build config for it (probably starting from a recent Debian kernel’s config). I have run off Debian-packaged kernels built that way before, if you want to play on the really bleeding edge.

“The first place to direct new users was to Linux From Scratch, so that they could determine whether they wanted to use a Linux distribution at all, or a more freeform approach.”

Multiple partitions or single. LLVM-managed or not. Block-level encrypted partitions or not. Do you want your swap on a dedicated partition, as a swap file, and do you want it to be encrypted?

If you decide that you want a multiple-partition installation and then let the installer do the partitioning, Debian’s installer still does a 100 MB /boot partition, which is woefully inadequate for present-day kernels as Debian packages them. 1 GB, maybe.

Exactly. One is a package format and/or local package utility, and the other is a frontend to do downloads and updates for that local package utility.

Should be “rpm or dpkg” — assuming that we’re excluding the other options — and then if someone chooses RPM, you can start talking about the frontend:

https://en.wikipedia.org/wiki/RPM_Package_Manager

Front ends

Several front-ends to RPM ease the process of obtaining and installing RPMs from repositories and help in resolving their dependencies. These include:

• yum used in Fedora Linux, CentOS 5 and above, Red Hat Enterprise Linux 5 and above, Scientific Linux, Yellow Dog Linux and Oracle Linux
• DNF, introduced in Fedora Linux 18 (default since 22), Red Hat Enterprise Linux 8, AlmaLinux 8, and CentOS Linux 8.
• up2date used in Red Hat Enterprise Linux, CentOS 3 and 4, and Oracle Linux
• Zypper used in Mer (and thus Sailfish OS), MeeGo,[16] openSUSE and SUSE Linux Enterprise
• urpmi used in Mandriva Linux, ROSA Linux and Mageia
• apt-rpm, a port of Debian’s Advanced Packaging Tool (APT) used in Ark Linux,[17] PCLinuxOS and ALT Linux
• Smart Package Manager, used in Unity Linux, available for many distributions including Fedora Linux.
• rpmquery, a command-line utility available in (for example) Red Hat Enterprise Linux
• libzypp, for Sailfish OS

Then for dpkg, you can choose from among aptitude, apt, apt-get/apt-query/etc, graphical frontend options like synaptic that one may want to use in parallel with the TUI-based frontends, etc.

That adds the “which windowing system do you want to use” question and under the “Xorg” option, a “do you want to use a window manager without a desktop environment”, and then under “yes”, for the “Which window manager” question, you get Ratpoison as one of the options.

Clearly there’s an unwarranted assumption baked into this comic that one needs a desktop environment. I have my non-headless Linux systems set up to run the emptty display manager using the Linux console:

Which then launches the Sway compositor without having Sway start any desktop environment if I want to log into a graphical environment. That’s my favorite option. Let’s not impose an artificially-restricted set of choices, here. :-)

How many are there?

It depends.

See, that’s not helpful. The right answer is to direct someone to this GitHub project:

https://github.com/FabioLolix/LinuxTimeline

The releases page contains a 3420x12488 PNG to provide a simple and concise answer.

https://files.catbox.moe/7q4v52.png

This appears to be the page in question:

https://www.tomshardware.com/news/linux-desktop-environment-face-off

It doesn’t appear to do so for me on either desktop or mobile, but it might be that I’m using Firefox or some add-on or configuration setting that I’ve set.

tries Chromium, without add-ons

Doesn’t seem to do it for me there either.

EDIT: Also tried navigating across pages on the site in case the mechanism depends on both the first and second page being on the site. I dunno how web devs go about that.

Dunno. Might be that there’s some way of blocking that behavior if you don’t like it, though, if I’m not seeing it.

They didn’t keep up with the arms race when websites designed something new that acts like a pop up and is a lot harder to block.

The “Behind the Overlay” extension for Firefox and Chrome doesn’t have the ability to intelligently detect whether something is an desired overlay or an undesired overlay, but it can pretty consistently, with a click on its button or a keyboard shortcut, remove them.

https://addons.mozilla.org/en-US/firefox/addon/behind_the_overlay/

I imagine that someone could probably make something fancier, with a lot of logic, kinda like Dark Reader or something, to guess whether a given overlay is “obnoxious” and just hide it by default.

I mean, in that kind of timeframe, there were pretty major shifts in transportation.

For a long, long time, ships up rivers and along coasts was the way serious transportation happened.

Then we had the canal-building era in the US. I assume that the UK did the same.

searches

https://en.wikipedia.org/wiki/Canal_age

Technology archaeologists and industrial historians date the American Canal Age from 1790 to 1855[1] based on momentum and new construction activity, since many of the older canals, although limited by locks that restricted boat sizes below the most economic capacities[b], nonetheless continued in service well into the twentieth century.[c]

By 1855, canals were no longer the civil engineering work of first resort, for it was nearly always better—cheaper to build a railroad above ground than it was to dig a watertight ditch 6–8 feet (2–3 m) deep and provide it with water and make annual repairs for ice and freshet damages—even though the cost per ton mile on a canal was often cheaper in an operational sense, canals couldn’t be built along hills and dales, nor backed into odd corners, as could a railroad siding.

So that was maybe sixty, seventy years before rail was really displacing it.

EDIT: I guess what I’m trying to get at is that I don’t think that rail had a uniquely short era where it was the prime, go-to option compared to other transportation technologies…and I don’t think I’d say that the golden era was short enough to make the technology not a worthwhile investment, even if it was later, in significant part, superseded. A hundred years is a long time to wait around without engine-driven transportation, which would have been the alternative.