Hello there.
Hope everyone is doing fine.

Around a year ago I created a thread to ask about Linux and for opinions around its topics, which can be found here: https://www.gog.com/forum/general/windows_users_learning_linux/page1/

After all this time, I've been using Linux as my main system and I'd like to say thanks to everyone that answered, read, comented, or anything else really in that thread or in this topic as a whole. (FOSS scenario, Linux, change of main OS..)

I've always used Windows since Win 95/98/XP era to Windows 7/8/8,1/10 and never had any contact with Linux before last year, and I gotta say that to me it feels that Linux has been a better learning environment than Windows ever was. Of course, all these years of experience using Windows count, thus it's also an awesome system for many things.

The intent of the original thread was to make questions humbly, to people more experienced than me, to answer my doubts and of any other who might read those in the future, therefore here are some more questions related to GOG, games and software overall that I've come across during this time, if you want to answer, discuss and feel free to give your honest opinions:

.keys@forum:~$ echo "What would be the next Distro you'd recommend to someone using Linux Mint but wants to learn more about Linux and advance their knowledge? Ubuntu, Fedora, PopOS, Kali, Parrot OS, Void, Manjaro, Debian, Slackware? Arch? (Just kidding :P) Or any other? Why would you recommend it? Or you think it's better for a beginner to stay with Mint for as much time as they can?" _

.keys@forum:~$ echo "Is it possible to use the Linux Virtual Console for gaming, without any Desktop installed? Or at least a Distro that focus on CLI and not GUI and all its dependencies as much. What are the possible advantages?" _

.keys@forum:~$ echo "On the topic of using WINE, I noticed that games performance on WINE are really good, but heavily dependant on community fixes, time consuming configuration and troubleshooting on some cases, therefore, making it unviable to some. By what I tested, Steam's Proton fixes a lot of those issues, but I've not used it outside of Steam. So just inside Steam DRM with games I bought before coming to GOG. I also read a bit about being able to create Linux installers with custom WINE builds for the specific game you want but, honestly, I couldn't figure out how to do it on my own. I also noticed that some GOG Linux builds are using this method. (FlatOut 2, for example) How to do this? Any detailed tutorials out there you'd recommend?" _

.keys@forum:~$ echo "On the topic of Package Managers and Software Usage what is your opinion on Flatpaks, Snaps, AppImages and the like? Do you think they're safe? Or should we only use official repositories for the softwares we download? Why?" _

.keys@forum:~$ echo "Out of curiosity, what is your biggest disappointment with your main OS?" _

Like last time, feel free to answer and discuss those questions and topic with your honest opinions if you want. Thanks everyone once again, really. Your knowledge and honest opinions are really wholesome. With all its variations, we all learn through mature discussions.

And to everyone else curious about Linux and this topic: If you're trying to learn something new and out of your zone of comfort, don't give up, it might be hard in the beginning, but it also might really pay out later. :)

Welcome back. I'll see if i can't answer some of these questions, though i'm sure there's those more experienced than me. Depends on what you want to do. There's tons of distros based on other distros and specialize in things. However i'd suggest Debian, mostly because it's more towards free/software and open source, and has more strict rules.

But before that, getting familiar with the commandline and the various utilities to get things done is more important than which distro you have, you can install apps and try them out even on mint long before you consider starting from scratch. Certainly it's possible. Xwindows is nice for windowing, but there's LibSVGA, and SDL (Simple Direct Layer) based games and apps where they take over the entire screen rather than windowing. If you get good emulators working that support those, then poof full gaming.

As for advantages, other than the OS can run on a far smaller footprint because a lot of visual stuff isn't going to be installed. You'd be surprised how much hardware is a minimal Linux system, which runs TV's, Routers, Phones, security systems, etc. Not sure on tutorials and the like, but i'd check compatibility of said game before considering using WINE. If it isn't easy to work with i wouldn't bother. Personally I'd reserve WINE for tools that are Windows-only but aren't games, and find native Linux-based ports if you can instead. Emulation of course is always an option, but consider a last resort.

OR... you could do the inverse. Years back i noticed you can do VirutalBox, with the tools installed if it all is good you can have fully integrated Linux & Windows at the same time, then run Windows games/programs natively and run linux stuff within the VM running as a full second OS. (You'll then have 2 app bars).

Personally having linux as a secondary system, one that doesn't need anything heavy duty or games where you are fighting with it, experimenting and having something where you can throw it all away if worse comes to worse. As a secondary OS it's great for programming, scripting, servers stuff, etc. Making it your main OS.... I remember headaches from RedHat 6 and earlier, and not having a clue what to do. (Nothing quite like not having internet or help and working blind)

Anything that isn't Debian based. Staleness as a feature is not a feature. You sound like you want a window manager. You don't need to switch distros to install a different desktop/wm, and I blame *buntu for starting that myth. Conveniently, I happen to have a table of Window Managers on hand. Any of the ones updated within this decade should be on many popular distros; and some are dead simple to build yourself. (Others are insane, and require you to build them to reconfigure.) Tutorials? No. But vv221 would be the sort of person to seek. Flatpaks and Snaps can [explicative] right off. Flatpaks for introducing bloat and hairy code; being the Unity of solutions. One-size-fits-all it is not. Snaps for being proprietary to a company that often can't find their buttocks with two hands. Appimages are the only ones I tolerate, because they're self contained and sandboxed. They champion GNOME as their primary desktop, when GNOME has proven time and time again to be a desktop for people who would rather talk philosophy in crystal spires & togas, rather than design a sane UX. And GNOME's developers record of working with other developers is non-existent, as is their record for fixing outstanding issues over chasing trends.

If their purpose is learning how Linux works, without going all the way to Linux from Scratch, I'd suggest Slackware. By far my best experience of an old-school, stable OS with no handholding.
The only reason it's not my desktop OS these days is lack of time. It requires a bit more manual work to keep updated, but you're rewarded by an OS that does what you've told it to.
(And, IIRC, the guy behind it shares my low opinion of GNOME. :-) )

Another option would be to get a Raspberry Pi 4, or 400.
That's a great learning platform for Linux, and software development too. And it runs from an SD card, so you can quickly get up and running again, if you clock it up somehow.

If going purely off that, Slax may also be an option (x86/x64 only). More specifically the initrd.img and bootstrapping components are particularly interesting to walk through. (Curiously v15 is slackware based, v11 is debian based)

---

I'm still learning myself, but after the kernel boots, it runs the init command. That is to set up the environment, NOT to drop you into a command-line like say MS-DOS would; init has to load all required hardware drivers, mount filesystems, etc (And with encrypted filesystems this is especially important). Once it's in a place where it can access the main filesystem(s) it would switch with OS init which then sets up any daemons background processes, and drops you to CLI login or XWindows.

Building your own kernel from scratch is... arduous. Well not too terrible, from 2.4.x i remember a nice GUI where you basically check what you want included, which usually is modules that can be separate or built into the kernel. (Need an encrypted filesystem and use ext4? Include crypto and ext4 as part of the kernel!). Generic kernels tend to not be as optimized for your specific hardware, but a custom built one may run a bit faster and be a bit leaner. But it may also take 4 hours to compile and require a lot of tools. Though if you know what you're doing you can include every driver/module you'd actually use and never need to insert modules later.

If your main point is to LEARN more about Linux OSes, then I would say something from the RHEL-family, e.g. Rocky Linux, Alma Linux or even Fedora. The reason being that as far as I can tell, the Debian/Ubuntu based Linux distros, and RHEL-based distros, are the two most common and prevalent Linuxes.

Since you've been using an Ubuntu/Debian-based Linux Mint already, I don't see much more learning to be achieved by using some other Linux from the same distro-family. You already know for the most part how Ubuntu, Debian and all their (other) derivatives work.

Sure there are also other "families" like ArchLinux/Manjaro, SUSE etc., but as far as I can tell they are much less common that the other two, so learning "RHEL" can be more productive, especially if some employer ever asks about your Linux experience etc.

Sure if you have interest, you may just as well try out other distros as well. I have been running e.g. Manjaro somewhat, just to see how it works and differs from the Debian/Ubuntu and RHEL-derivatives that I am more familiar with. The main difference for normal use usually seems to be what kind of packaging system they use, ie. what exact commands you use to install software and update the system, LOL.. I guess I was mainly interested in Manjaro because it is a rolling release. Snap appears to be too much controlled by one company (Canonical), as far as I can tell. I am not aware of any actual safety concerns with those, though.

https://phoenixnap.com/kb/flatpak-vs-snap-vs-appimage

I would probably choose to use AppImages, but I guess you could even use all the three if you want. With Linux Mint though, I've tried to stay away from all of them, for now. I guess they have their place, though, but I kinda dislike it how much Ubuntu tries to push you into using snaps all the time. Even when you install Ubuntu 22.04 Server, it tries to lure you to install various snaps. I am not even sure what is my "main OS" at the moment. I am writing this in Windows 10, in another PC I have both Windows 11 and Linux Mint installed side by side, at work I administer mostly Linux servers but also some Windows servers and connect to them from a remote Windows server machine, etc. etc...

I would say that at the moment I use Windows and Linux 50/50. I have Linux installed on more PCs in the household because I have some old laptops etc. which I've revived for a new life by installing Linux on them, as they can't run Windows 11, or even Windows 10. I e.g. recently got some old Acer laptop free, with mere 4GB RAM and it had Windows 10 barely running on it (it can't run Windows 11), but I installed Linux Mint XFCE on it instead, and it now serves me as a light work PC (I can do my work also with it, it is even lighter than my main work laptop), and my son can run Team Fortress 2 quite good on it.

If you meant what I dislike about the Linux distro I use most:

1. Home: Linux Mint... it appears there is no handy way to upgrade to a new Mint release, like there is in Ubuntu? I usually end up starting from the scratch and reinstalling the whole OS, when I want to "upgrade" to a new main release of Mint. At work I have successfully upgraded Ubuntu servers to new releases without having to reinstall everything.

2. Work: Ubuntu: I don't like how Ubuntu seems to constantly be pushing me to use snaps and stuff like that. It starts to feel too much like Microsoft constantly pushing their own services in Windows.

As a learning process, I highly recommend giving a try to Gentoo. This way you will learn a lot about dependency chains and build systems, something that is much more abstracted in deb-based and rpm-based systems.

On the other hand, staying with Mint will not limit you in any way. Trying more complex distributions to learn new things is a good idea, but not mandatory in any way.

--- You can spawn a graphical server only for games requiring one. I did that for a while. I would not recommend it ;)

--- If you want to use specific WINE builds for some games, this is exactly what PlayOnLinux was developed for. I think Lutris does that too, but I never tried this one.

But I would not recommend doing that, it is often a better bet to stick with up-do-date WINE instead of keeping a collection of outdated builds.

--- The perfect packages manager is apt. Everything else is inferior.

On a more serious note, the official repositories for your distribution are always better maintained than whatever can be found through Flatpak/AppImage/Snap/Whatever. Software development and software distribution rely on distinct skill sets, you can not expect the developer of some software to be the most competent to distribute their software.

--- (my main system is Debian Sid)

I would love the ability to set global build flags like can be done on Gentoo, that would be applied automatically each time I build binary packages from source using dpkg-related tools.

You can run a different program in place of init by passing init=[path] to the kernel command line (in, for example, GRUB). For example, init=/bin/sh will start a shell in place of init, which is useful if the system is not booting properly (provided that /bin/sh and the libraries it needs are still intact and not corrupted, of course; if that doesn't work, it's time to boot from removable media if you need to fix things, and you might consider replacing the hard drive at this point).

Also, you can enter a shell in the initramfs that boots before the main system by passing rdinit=/bin/sh to the kernel. Thing is, a typical Linux system (any desktop system that uses a standard distribution and doesn't expect the user to compile their own kernel) will actually load a cpio archive into a RAM-based filesystem and then attempt to execute /init there, and that init's job is to bring up the real system. (Note that it doesn't *have* to do this. Tiny Core Linux, for example, just uses the ram file system (actually tmpfs) as the root filesystem for the final system.) Alternatively, if your root filesystem is to be an encrypted ext4 filesystem, you can compile ext4 and crypto as modules and put them in the inintramfs image, then have the initramfs image load the modules at boot. Most modern desktop/server distributions do this automatically.

By the way, if you know you won't need to insert modules later, you can actually disable the loading of modules entirely when compiling the kernel, which might be useful when higher security is desired. (Remember that there's often a trade-off between security and usability.)

While init=/bin/bash can be useful in some cases (or whatever /bin/*sh you want to use), init=/bin/sh might sound like a smarter idea but is not: most shells will run in a special POSIX compatibility mode if called from this path, with poor or no support for interactive use.

Unless /bin/bash is corrupted, and /bin/sh actually points to a different shell that is still intact.

TCL seems to be the only more or less recent disto my old P233 MMX could dual boot to, but thanks to TCL's boot loader apparently failing to install itself and tmpfs preventing me form getting TCL detected by any other way installed boot loaders, I can only use it in its liveCD environment which pretty much ruins the idea of quickly booting to Linux whenever I want access my file server...

Check your UEFI or BIOS settings, there are has to be an option for changing loaders priority (GRUB has to be first). The problem is that many UEFI vendors name this option differently, so you may not to understand at once what is it.
Also you can turn off hibernation in Windows 10, it gets more problems for dual-boot.

Don't forget about Fedora. It is basically RHEL but with no corporate overhead. Dandified YUM (DNF) is also quite the pretty package manager.

You're welcome. They're also good for the occasional change of pace. Also, might I suggest learning how to manually execute a WM from a TTY? As for those weird framerate issues, presumably some of those don't even have a compositor.

That's not a bug, it's a feature. A very stupid feature. Basically, since Mint is based on Ubuntu LTS which is built on Debian LTS, by the time it comes to upgrade, a bunch of important library files have gone obsolete, so it'd be easier to recompile from scratch than deal with the mass of reconfiguration that it would entail. I've tried, and got stuck in a dependency loop.

Unlike every Fedora upgrade, and I've been upgrading since 25. Sure.

Get rid of GRUB. That's not a joke, either.
Grub is scary, bloated, and largely built on ideas that were good in 1995. It is an antithesis of the Unix philosophy. I suggest ReFind (https://www.rodsbooks.com/refind/) or Systemd-Boot, (https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/) if you can swing either.

Yes, I did. This time there was a problem with fast boot settings, or something aparently. Thanks for the tip about Hybernation on Win10. :)

Red Hat and Fedora are next on my list for experimentation when I have the time, thanks. :)

I learned to start them using 'starx' through ttys, yes. Really nice feeling and much faster too!

Sorry, what you mean by some of them not having a compositor?
To explain a bit more on how some of the tested games behaved; they started fine, but, when they take control of the display, everything began to glitch white and blink a lot while I moved the mouse or typed something.
This happened specially with older WM's like 9wm or based on 9wm, otherwise they worked fine.

Thanks for the explanation. I know nothing about Fedora. This seems to save a lot of work in some cases, as I also understand that depending on how we maintain our distros, many things can go wrong and cause trouble, so it might be subjective - in some cases.

I've actually heard about ReFind around while searching for solutions for Dual Boot problems, albeit I need to study/research more on how to do this. Also thanks for systemd-boot recommendation too.