i tried bsd, just couldnt get the hang of it. installing the base system is easy enough, but anything else was too much for me. no real guides out there.

I really like Slax. Unfortunately decompression is so slow it's not practical, if they swap it from lzma back to zlib compression it would be good enough.

edit: Though i'd like to see when they start having hardware decompression for zlib and lzma to use, which would remove this issue.

As far as gaming is concerned, I've only used Linux Mint. It has seemed okay. But the delay in software versions on Debian-based systems does annoy me. I'm somewhat interested in trying out Manjaro - are there reasons you would not use it for gaming?

No particular reason, it probably works really well for that too. But I prefer to use officially supported platforms, for which you can find many more workarounds and fixes if something ever goes wrong with a particular game, and for that Ubuntu is honestly the most reliable (being the most widespread certainly helps). I bet 99% of the time there's no difference, but you never know.

The biggest hitch with using an unsupported distro is when it is either several versions ahead, or take a curveball in terms of lib packages.

Like how OpenRCT2 won't run on Fedora because it expects Libzip 1.4, rather than anything greater, thanks to the Travis Build System running on some decrepit old version of Ubuntu.

Ah the curse of Ubuntu Long Term Support (LTS) strikes again. :)

Quite.

Though some things, like the shuffling of how Libcrypto is contained is entirely on the distro. And .mono games won't work, but I feel that may not be a problem with some dev time thanks to recent sourcing.

If you're looking for something worry-free, Linux Mint is probably the best choice. Personally I use Mint+Mate for years and I find it really polished and stable distro, providing also LTS editions. I love high performance, simplicity and responsiveness of Mate desktop. Hey, I'm interested in MX-Linux. Is it the distro which become more and more popular recently? As far as I remember I wanted to try it, but they do not provide live session mode.
What about performance of these two? How they compare?

Another, easier, option if you just want a bootable system;:

Compile busybox as a static binary, along with a custom kernel, and then boot the kernel with busybox as a userland. Relatively easy, and it's a good way to learn how certain things work. (Try putting busybox in an initramfs, so you don't need any disks after booting!)

For something a little fancier, try making a dynamic binary instead; this will force you to learn about dynamic linking and what you need for that. Also, try adding other programs.

Another distro that I like is buildroot; select which packages you want and buildroot will build a root filesystem for you. Then, just add a kernel (which buildroot can do for you) and you now have a functioning system!

Two other nice small Linux distributions are Tiny Core Linux (~12MB) and Alpine Linux (kernel has a lot of modules, but the root filesystem is otherwise only something like 8MB)/

Arch on my laptop, Fedora on my desktop, Ubuntu on my work laptop, OpenBSD on my server; custom buildroot based "distro" on work equipment, running busybox & userland statically linked aginst musl, all in initramfs..

There really is no best. I'd say they're all rather crap. OpenBSD is without any doubt the most comfortable for me to use and work with (it's simple, has generally sane & tasteful defaults, stable, less churn, good docs, surprisingly large amount functionality without too much bloat, etc.), but it's also got less support than the other systems I run. If that weren't the case, I'd likely switch all over to OpenBSD.

Yes, that's the distro that's getting some notice recently. I've been using it since MX-14 (it's now at MX-18), but it's been my daily driver for well over a year now. I have also, for a bit longer, been using Mint Mate on another laptop. Both are aimed for novices, though Mint is probably simpler to install and easier to use for most people. With a little more work, MX is not really difficult to use.

Performance-wise, both load at about the same speed, but once loaded, to me MX outperforms Mint as it's more responsive and consumes fewer system resources. Games run just as well as on Mint, though you have to take an extra step to install GOG games, which isn't really that bad.

I haven't had problems making live USBs or live DVDs or running them with MX, so I am not sure why you weren't able to run it in a live session. Be sure to download from here - the website has links for a direct download or torrenting.

When I have more time, I may try Manjaro as that looks somewhat interesting.

Naturally I haven't tried out most Linux distros.

At work, I prefer using Red Hat family distros like CentOS, RHEL and Oracle Linux. I dunno, they just seem cleaner and more straightforward to use for professional work, and you can find lots of hints and stuff for them online specifically for professional use (like setting up a server and blaa blaa blaa, especially the official Red Hat pages are a good place for all kinds of hints and stuff). Note though that at work I use them 100% from command line, no desktop user-interface installed for them as they are for server use.

At home, I prefer Linux Mint (Debian-based, not Red Hat), it just seems to be made for generic home users. I know Linux purists hate it that Mint apparently offers some proprietary drivers or software with it, but I find that as a plus because sometimes that proprietary stuff just seems to work better. I specifically use Linux Mint XFCE as it has a simple user interface and takes the least amount of memory AFAIK.

It may be a good thing to go with a popular distro because then it is easier to find hints online for it (if you are using CentOS, RHEL hints apply to you, and if you are using Mint, Ubuntu hints apply to you). Having to work with several different Linux distros and their different versions at work has taught me that it is always a good idea to double-check online how to do even some basic things on that particular Linux distro version. For instance from the past two weeks my learnings:

How to add sudo privileges to a user:
- In CentOS 6.x (and I think Ubuntu etc.), you add that user to the "sudo" user group.
- In CentOS 7.x, there is no "sudo" group, but you add it to the "wheel" group instead. Ummm ok...

Configuring NTP:
- In Ubuntu 18.04, by default ntpd is not used, but something called timesyncd instead. Ok, have to remember that (wasted 30 minutes wondering why the heck ntpd was not enabled by default, when I wanted to configure which NTP servers to use)

Adding a static IP address:
- In CentOS etc., you edit /etc/sysconfig/network-scripts/ifcfg-ethX
- In Ubuntu 16.04, you edit /network/interfaces
- In Ubuntu 18.04, you edit the .yaml files under /etc/netplan/ instead

And then the difference between service and systemctl commands... Of course none of this really matters much if you are using only one Linux distro, but as said, finding information for your Linux distro is easier for the more popular distros I guess.

I still can't figure out why people use Fedora, unless there are some bleeding-edge new features they really need. Isn't it (still) basically the buggy beta version of some future RHEL release?

For RHEL family, I'd use CentOS instead (which basically is the free RHEL release).

Interesting, I have a completely different experience. Our customer uses RHEL and we need to support it; I sometimes work with CentOS because I'm tired of the RHEL license bullshit and the fact that nothing works OOTB or without EPEL. These are still some of the clumsiest distros to use and manage day to day, things are often so outdated that anything that works just fine on Ubuntu, Arch, Fedora, Alpine, Debian, etc. is not nearly as likely to work on RHEL. I see this quite often since I use Ubuntu for development and Alpine, Debian and some other containers for automation & testing.. so all works great until I run the final batch of tests on RHEL :(

Doesn't help that Red Hat wants to silo knowledge on their shite where you need to log in to see answers. Seriously fuck that. This is a good example for what I mean by churn, which OpenBSD has far less of. Three billion Linux distros, all with their own ways to do and configure things, are also constantly reinventing and changing the way things work. Information gets outdated, documentation gets outdated, and you get bitten in the ass all the time because things changed and you didn't notice.

In OpenBSD, things don't change nearly as much. And even when they do, such as when they completely rewrite and replace some system tool, they usually try to preserve the old user experience so the same commands, configuration files, etc. will just work most of the time. They find ways to implement new stuff and improve the system without constantly moving things around and reinventing configuration file formats, system management tools, etcetra. And when things really have to change, that's almost always documented in the upgrade guide, which tends to be a short document anyway.

As a concrete example, services used to be started by a very simple set of rc scripts. You could add a bunch of commands that run at bootup in rc.local; you could enable built in system services by setting flags in rc.conf.local. This was the only supported way to manage services. Someone wanted something fancier; in Linux world, this would've meant that the whole goddamn init system gets replaced by something else entirely (sometimes with a poor compatibility/emulation layer so it looks like you have two systems acting together in a ugly spaghetti mess), and you must figure out the new tool to keep using your new system. Instead, OpenBSD added a new tool, rcctl, using which you can enable, disable, list, start, stop, and reconfigure services. It doesn't replace the old rc scripts however, so all that worked before still works. If the old rc subsystem was sufficient, well, it still is.

EDIT: Upgrade guide to the version that introduced rcctl. Notice how "rc.conf.local is no longer a shell script" is the only rcctl related change that the user may be required to take action for. In practice, most users needn't do anything, because the typical configuration was a bunch of variables one per line anyway.

http://www.openbsd.org/faq/upgrade57.html

Thank you for explanations! I'll definitely give it a try.
I'm just reading about it and it seems to be based on Debian Stable (so repos may be a bit outdated) and XFCE desktop (which I used years ago, before switch to Fuduntu/Gnome and later Mate), but, hey, it looks nice, should be highly customizable and if you say it's faster, it's enough to try it.

Regarding Manjaro - repositories closer to bleeding edge and rolling release mode. Also it's Arch based. Totally different distro. But may be interesting experience :) Good luck!

You're welcome! MX is indeed based on Debian Stable, but you can also switch to Debian Testing (either during installation or later), and the developers update many of the packages (i.e. Firefox, LibreOffice, and some other frequently updated applications) themselves. A main difference from Debian is that it uses sysvinit rather than systemd, but unlike Devuan, systemd packages are installed so that those who want to use it can switch fairly easily. XFCE used to be fairly ugly, but it looks much nicer now and can be customized further.

Yes, I'm aware that Manjaro is Arch-based, so it handles some things differently in addition to being more bleeding edge, which means it could be fun to try.