TL;DR: A step-by-step installation of Linux Mint on real hardware and setting it up for typical gaming tasks.
I don’t really care much for SOG’s other content but his forays into Linux over Windows were incredible for demystifying the operating system to a mainstream audience (i.e. people who watch his content).
Some nitpicks:
- Muta should have used the flatpak version of Steam instead of the system package, the Steam client updates itself (with its own runtime and all) so using a system package over just sharing with flathub is a bit wasteful (it does complicate external storage devices a bit since you have to manually set permissions via flatseal but that’s it). (Edit: this is just a small nitpick, the native system package is fine as well).
- There should also have been mention of Bottles over installing Wine as a system package as well as things like the Heroic Games Launcher for GOG and Epic Games titles, Lutris is fine though.
- On long term stable release systems like Linux Mint or Debian, Flathub (or foreign package managers like Nix/Guix) should be your go to for installing software, let the distribution itself manage its core system components which I wish he clarified when he saw Flathub taking multiple GBs on first download.
Other than that, Linux stays winning.
For beginners it doesn’t really matter and this advice will get them going, but I do want to push back on this a bit.
There are two methods of solving the problem of dependency hell. Package managers are the correct way. Distribution package managers are incredibly robust and should always be the first option. These are state-of-the-art systems. They look at what is compatible, they restrain you from doing things which won’t work, and they make sure EVERYTHING gets upgraded when a new exploit is discovered. The other way of solving dependency hell is bundling. Bundling is when every application ships with its own versions of its own dependencies. Bundling tends to work with a lot less up-front effort, but it takes up more space (on disk and in memory), and it also means you have several versions of these dependencies lying around, and they don’t get updated automatically. They might never get updated unless the individual producers of the software decide so (and you remember to keep track of their announcements). This essentially reproduces the security model we’re familliar with under Windows. Where we fetch software from all corners of the internet, install it, and it never gets updated.
It takes a little longer for everything to come together in a distribution package repository, but this is due to the amount of effort distribution maintainers invest in testing, as well as stripping out bundled dependencies and ensuring they can be independently tracked and updated. Distributions will keep software running on the newest available dependencies even if upstream development has been dormant for some time.
Now, not every package repository has a laser focus on every discipline. Where they fall short, this is where things like AppImages and FlatPaks (or cloning a Git repository and compiling it yourself) come in handy. But this is all technical debt. This is stuff you end up becoming responsible for maintaining yourself, which won’t update along with your distribution. The more work you let your distribution do for you, the less effort it will take to keep things running smoothly.
If something packaged by your distribution doesn’t work, trying out a bundled package (AppImage, FlatPak, or a language-specific package manager like cargo/pip/npm etc) can be a great sanity check. If your VLC is broken and you try an AppImage of it and it works, A: you get to watch your movie, and B: You’ve learned something. Try to figure out why one works and the other doesn’t.
watashi no
sudo flatpak update
:static-linking-shining:
That’s bundling (library code with the program code). What shines here are Nix and Guix, where variations of one thing can coexist in
/nix/store