Yeah, so I've been running Fedora on my desktop since I got a Ryzen 7 1800X (at launch), eh, is that two years ago now? It's worked OK-ish, though the package repos (even with rpmfusion) don't feel quite as comprehensive as Arch's (even before we consider AUR, which I'm not super into).

Then again, since it's not rolling release, updates are big when you do them. From my father's experience (who's used Fedora far longer than I), and from a few others I know who use Fedora, these major release updates break things more often than not. Maybe it's gotten better in the past 2-3 years, IDK, but I've watched people update, reboot, and end up with a system that doesn't boot or that barfs a bunch of errors and barely works. And then you get to pick up the pieces.

For me this kind of thing never happened on Arch.

Here are a few guidelines for you to keep in mind. Some I'm sure have already been mentioned:

1. You are not making a decision for life. If you think you picked wrong, just overwrite it with another choice. Don't feel any pressure in your choice.

2. I should be theoretically possible to tweak, change or abuse any distro into any other. This means that they don't change in what they make possible as much as in what they make easy.

3. Many Linux distributions are specialized in their use: embedded systems, limited hardware, servers, artists, etc.. You may want to go with a general distro.

4. Another general distribution distinction lies in the way the system handles updates. Rolling releases make new versions of software available at very short intervals. The problem with these is that your system may start misbehaving due to the introduction of a bug or incompatibility that was not detected. I would suggest you to avoid these for now, and start with a more stable approach. Should you feel that you are missing out on something (and installing it manually is not an option), you can have a new distro up and running in less than an hour.

5. Choices. Some distros make you choose an email server, a cron system, an init system, and NTP server, a default shell and various other packages, all before you get to know what they really do and how each impacts you. You end up going with the default choice as a safe choice. Other distros ask you a total of 5 questions and set everything up for you. You can change some things later if you are not happy with the defaults. I would suggest you go with a newbie-friendly distro and change once you feel like you have outgrown this shell.

6. If you make a disk partition for you /home directory, you can change distros and not lose your data (e.g., your music, your photos, your documents, your bitcoins... those can be preserved across installs). This really lowers the cost of changing distros since all things of value to you are maintained. (The /home directory or folder is where you store your [a user's] files. I think the equivalent in Windows is "User data"?)

Ubuntu and Mint are stable, easy to use and beginner-friendly, and that is why you will see them recommended often as a good place to start.
Arch and Gentoo are good for tweakers and are rolling releases. You can find an update every day.
Manjaro is Arch with reasonable defaults, so consider it a middle ground. It is really easy to install without having to type commands.
Debian and Slackware are old-timers and quite stable, but may not be a good place to start. You will learn a lot with them, I should say, but leave that to another time.

But take your pick from a top choice in DistroWatch. And try to check out the differences between KDE, Gnome, XFCE and other desktop environments. They should cause a greater impact than the underlying distribution you choose.

Have fun and ask around if you need more help.

Linux from scratch.

Seriously now, I use Fedora. I don't know if it's the best, but it certainly is the one I like most.

What?!
That's like asking what is the best colour of crayon.

That describes my experience exactly, After 4 years of Mint I moved to Debian and I discovered how much hand holding Mint has compared to it. I took it as an opportunity to learn new things.

Very Helpful post :-)

Funny thing: I did it the other way around. I started with Debian quite a long time ago. Getting it installed the first time as a process that took an entire afternoon as I had to setup the kernel modules one by one, out of hundreds of things I had no idea what they were. Should I compile sound support into the kernel or as a loadable module? Hmm...

Now things just work. It is no longer justifiable to tweak things down.

Plus, having an homogenised setup helps you get help. That problem you are having? Maybe someone else had to deal with it before or people can reproduce on their system and provide help.

You did it the right way and I'm glad it worked.

It's rather amazing how recently Debian began support for Systemd, much less any sort of init service that wasn't some crufty old system that hadn't been maintained since before POSIX was a standard.

I'd recommend one of the main offerings i.e. Debian, Ubuntu, Arch or Fedora.
Mainly for support reasons; it's pointless to get lost in the noise of DistroWatch/Reddit/etc and start distro hopping to find the holy grail.

Ubuntu for Linux newbies especially those who wish to play the games from GOG or STEAM with a minimum amount of fiddling required and official support.

Anyone else should have a read of The Linux Command line and get a basic understanding of how UNIX-like systems differ from Windows.

Personally for a desktop system I don't see the point of having fixed releases - this isn't like Windows editions.
I neither see the point of back porting fixes to an old kernel; they must spend hundreds of hours doing this.
I'd always want the latest kernel, packages, drivers and features, etc.
Unless I had special requirements.

So it's Arch Linux for me with MATE (Gnome 2) or XFCE.
The knowledge required to install the basic console-based system is greatly exaggerated; the installation instructions and Wiki are very clear.
And the system isn't inherently more unstable than any other Linux system.

Once you slap on Xorg, some video card drivers and your favorite UI - you've got much the same thing as any other offering.
Except without the rubbish you didn't want!
The hardest part is knowing the syntax, package names and knowing what's needed.

My old Phenom x4 955 + R9 285 is flying along now that I've dumped Windows 10.
GOG's games, STEAM's games, Wine + DXVK, openXcom, GZDoom, Quakespasm, eDuke32, Retroarch, ScummVM, VirtualBox, MIDI/Fluidsynth, Printing, etc.
Looking forward to playing Stalker: Call of Pripyat natively.
Even if I upgrade to Ryzen 3xxx next year I still wouldn't go back.

IMO, speed is not a good reason to choose Gentoo. Customization, however, is.

Also, I recommend Gentoo only if you have a powerful multicore system, as compiling updates can take a very long time, especially for certain packages (chromium is one example; it takes hours to compile and is frequently updated).

QubesOS isn't technically a Linux distribution; it actually runs Xen as its kernel, with (typically) Linux running on top of it.

(This also means that everything you do will be in a virtual machine, which has its advantages and drawbacks, including the need for a system that's capable of such things.)
ReactOS does not fit this description. It isn't a version of Linux at all, but is rather a third-party reimplementation of Windows, including the kernel and main userland libraries. In particular, this means that it suffers from many of the same design issues that Windows has, including the use of a registry. It also means that it can run (some) Windows programs, but can't natively run Linux programs (I'm pretty sure there's no WSL equivalent).

That's actually self-explanatory. When it comes to Gentoo, speed comes from extensive customization from the ground up exactly like the user wants it (well, the latter fits Linux in general)... Compared to Mint and others I can agree on the "hand-helding"-sentiment when it comes to these, but that's the trade off for being out-of-the-box.

And of course, the compile time takes more time the more packages you want in your system. Using the whole day for compiling isn't unusual, but then again Gentoo isn't for those impatient types that dosn't want to learn...

QubesOS: Well, it does count as a distro...

ReactOS: It did fit my description. ;-)

Although, I personally understand your need for being pedantic about it :P

That's a good question. I've been wondering that for the last 25 years. Maybe you can tell me once you figure it out.

But change is hard. The longer you wait, the more entrenched you are in what you are using. I feel stuck with gentoo right now, even though I hate it.

Which is why the -bin packages exist. I only use that for icedtea, though. The other nasty ones, like libreoffice, anything webkit-based, llvm, and rust I just live with, or schedule for times that I can live with. I have used it on a variety of systems, many underpowered.

But yeah, Gentoo may be the fastest penguin, but don't choose gentoo for maximum speed. Chose it for maximum configurability, and to support a systemd-free world. Yes, it does. Just less often. Also, eventually you have to do a major version update, which will break things. I was surprised at how broken Debian was back in the day, and even more surprised at how broken it is even today.

Here's the rant I wrote a few days ago, but didn't post because of poor internet connection:

I abandoned Slackware because it was frequently broken, and I ended up having to manually build all my favorite apps anyway in order to get them working correctly. I switched to Red Hat because I thought Caldera would be nice, and it was RH-based. When Caldera came out, I used it shortly until I decided I just didn't like Red Hat, and Caldera's "improved" Novell support wasn't that great. I used Debian for a long time for its multi-architecture support and the fact that it seemed to have the most available packages, but abandoned it for Gentoo because compiling for Alpha ev4 on an ev56 when most of your software still assumes 32-bit ints was a bad idea, and Gentoo seemed the best source-based distro where I could fix that. Debian also took (and still takes) pride in delivering obsolete, but monstrously patched software (which is why Ubuntu was invented). In retrospect, maybe I should've just used the "install from source" feature of Debian to compile with the correct flags, but now I'm so heavily invested in Gentoo that it's hard for me to switch. I've also used later Red Hat, RHEL, SuSe, and Ubuntu at work or on other people's machines (and various flavors of BSD before Linux was invented). Gentoo's USE flags are one feature I'd really like in any replacement distro, and I do respect their support for systemd-free (openrc) and puleaudio-free (apulse) systems. Nonetheless, I have to maintain over 400 replacement ebuilds and over 100 package tweaks and use unofficial overlays to make even Gentoo work remotely the way I want it to. I recently got pissed off at Gentoo again and looked at a large number of modern non-systemd distros, but they all sucked in various ways even more than Gentoo sucks, so I'm still stuck with Gentoo. My main issue with Gentoo is that it is mind-bogglingly slow to update the system (I'm not talking about compiles; that's to be expected -- I'm talking about "emerge -auNDv world" taking 20+ minutes to figure out what it wants to do, and when it fails, it has a hard time telling me why). They also recently removed a package because the ebuild was too old, not because the package no longer functions. What's the point of having a versioned (E)API if you don't support old APIs any more? I guess it's part of the modern "if hasn't been updated in more than a year, it's abanded and sucks" attitude. In general, their response to bugs is to either ignore the bug or remove the package "if it is unused elsewhere" (in the case of the one I just mentioned, they removed a valid dependency just to facilitate the removal, so I guess they really, really wanted to get rid of it). I don't file bugs against Gentoo any more for fear of the package I'm complaining about just disappearing. That's at least part of the reason why I have over 400 local package overrides. I already waste way too much time maintaining my system rather than using it, so doing everything from scratch is out of the question.

Perhaps the issue is that Linux in general fails me. I have the most common Radeon chipset for laptops for the last 3 years running, at least, but yet the AMD devs continually break support (I can't use 4.19 at all, and earlier versions don't really work as well as they should). 4.19 (and 4.18.19+) also breaks my wireless card, also fairly common in laptops. I don't bother filing bugs any more because they just ignore me or make me do much more work that I want to; I don't want to spend my life fixing my machine instead of using it. Linux and all its software seems to be developed using the code churn at the expense of documentation mode, with little to no benefit to me. I can't even fix driver issues, since "Open Source" doesn't mean "Open Documentation". The documentation AMD provides doesn't even provide enough information to get the chip to display anything. All that stuff is probably hidden behind VESA NDAs, so they couldn't provide that information even if they wanted to (not that they are blameless, since they are part of VESA, too). Getting chip info in general stopped being possible around the mid-to-late 80s thanks to idiotic notions of what ought to be secret (Intel even decided at one point to keep part of its instruction set secret, back when they were even bigger assholes than now). Changing to a BSD variant wouldn't fix the hardware issues, and would likely just result in me not being able to play games at all any more. While I occasionally take long breaks from playing games (in fact, I've been working on a personal project the last few months, and haven't played games more than one or two days), I can't imagine quitting forever. I didn't play much at all for more than half of 2016 and 2017 because of a still-unanswered bug in the AMD drivers, which I only solved by buying a new machine.

Maybe I need to just finally switch to Windows. Supposedly any feature of Linux is available in Windows, as well, and at least if I have a problem with the drivers, there are millions of other people who can help me solve it. In fact, I should've switched to Windows back in 1992 or whenever I swtiched to Linux from the Amiga, since everything supports Windows out of the box, with everyone else a distant afterthought at best. Including gog. Or just drop out and switch back to the Amiga. I hear they even released a new version of AmigaOS recently.

Oh well. I guess I just complained instead of answering the question. Whatever.

That is because you are focusing only in your case. Let us start with the fixed releases.

Imagine I'm using some software called foo 1.0, that depends on libfoo 1.0. I also run bar 1.0 that depends on libfoo 1.0.

Now foo gets upgraded to 1.2, but bar still needs libfoo 1.0, because it was not updated. I need to make a choice here. I can even risk it and upgrade the library and hope bar can work with libfoo 1.2.
With fixed releases software gets to be tested at a single transversal version and is known to work well together at their versions. Also, upgrades are more painless.

I've had to deal with bugs that were introduced after I have upgraded some packages and had to rollback to a previous state. I could not upgrade my system due to package dependencies.

Now, about backporting bugfixes, think about mission-critical systems. If your system misbehaves or has a security vulnerability, it is not a big deal. I mean, sure, it is annoying or problematic, but nobody dies. You may afford your way out of it.
No think about medical systems, emergency systems, industrial machinery, critical services like those running in financial institutions. When you have specialized hardware you often get drivers for a specific kernel version (and that version soon gets old). If you get a system audited, it is verified only for a specific version of the software. So, say, if the AWS Linux machines were declared secure for kernel 4.18, should you audit them for 4.19 and 4.20? Those are expensive and long processes. Maybe you should keep 4.18 for a year or two. Would you risk it?

Some times a subtle change, like a tweaked scheduler or an out of memory manager with different priorities can lead to unexpected behaviour, and that can really bite you.

So, in short, yes, very special requirements, bur in valuable and meaningful fields.

I've just tried MX and it looks really promising. It's blazing fast, even in live-session mode! Now I remember why I was using Lubuntu some time ago.

I also like how XFCE was reconfigured here and how many tools are provided for further customization.

At the moment I'm still in transition from Mint Sarah to Ubuntu Mate, which means I still cannot erase my 2-nd system slot, but as soon as all files and setting are copied, I'll try installing and using it a bit longer.

Thanks!

Far be it from me to barge into a conversation, but the prices for an off lease laptop would be a great path for getting a 64-bit machine.