Endeavor OS. Its an excellent arch based system and people REALLY over emphasize how tricky arch is. Its not difficult, its not just for power users, and the rolling release means you have access to updates faster than other distros…this is particularly nice for gaming as you’ll also get updates to graphics drivers sooner.
Nothing unsolvable, but it can be a pain when you want to run something not in nixpkgs. My solution is to have Ubuntu on a separate partition, and I was using docker to solve this problem for a while but have moved away from it.
Linux mint is amazing. I’ve used Linux for many years and it’s still nice. I do wish Linux mint had a more free software install option but that’s a minor complaint.
You can just download the app from Flathub right now and it should hopefully make its way directly into GNOME in the future. At least some work was being done to implement this directly into it.
It seems stable enough already TBH, at least from my small testing with the app. It’s more about getting things ready to be exposed in the settings app and in the system.
I was surviving with Ubuntu, I had my complaints but I figured ‘that’s just how it is’ on Linux, that it was the same everywhere. I didn’t even realise what I was missing until I switched.
I got a hardware upgrade at one point, so in order to get those new drivers ASAP I tried an Arch-based distro, with plans to switch back once drivers became available. I never moved back.
The two big reasons I stayed was ironically enough the lack of good Ubuntu documentation, and the PPA system. Ubuntu is used a lot, but there’s not really formal documentation anywhere, only random tutorials online (most likely out of date and never updated) and people on forums talking about their problems. By contrast the Arch wiki is the gold standard of Linux documentation, there’s just no comparison. Even on Ubuntu I found myself using it as a reference from time to time.
Regarding PPAs, the official Ubuntu package list is strangely small so if you’re like me and find yourself needing other software, even mainstream software like Docker, you’ll be faffing about with PPAs. So if you want to install Docker, instead of typing sudo apt install dockerYou instead have to type:
These are the official install instructions, by the way. This is intended behaviour. The end user shouldn’t have to deal with all this. This feels right out of the 90’s to me.
Instead of PPAs, Arch has the Arch User Repository (AUR). Holy moly is the AUR way nicer to work with. Granted, we’re not quite comparing apples to apples here since the AUR (typically) builds packages from source, but bear with me. You install an AUR package manager like yay (which comes preinstalled on my flavour of Arch, EndeavourOS). yay can manage both your system and AUR packages. Installing a package (either official or AUR) looks like yay packageNameHere. That’s it. A full system upgrade like sudo apt update; sudo apt upgrade is a single command: yay -Syu, a bit cryptic but much shorter. The AUR is fantastic not just for the ease of use, but for sheer breadth of packages. If you find some random project on github there’s probably an AUR package for it too. Because it builds from source an AUR package is essentially just a fancy build script based on the project’s own build instructions, so they’re super easy to make, which means there’s a lot of them.
You might argue ‘but building from source might fail! Packages are more reliable!’, which is somewhat true. Sometimes AUR builds can fail (very rarely in my experience), but so can PPAs. Because PPAs are often made to share one random package they can become out of date easily if their maintainer forgets or simply stops updating it. By contrast AUR packages can be marked out of date by users to notify the maintainer, and/or the maintainer role can be moved to someone else if they go silent. If a PPA goes silent there’s nothing you can do. Also, since an AUR package is just a fancy build script you can edit the build script yourself and get it working until the package gets an update, too. PPAs by comparison are just a black box - it’s broken until it gets updated.
Moral of the story? Don’t be afraid to just give something a go. Mint will always be waiting for you if you don’t like it.
If you decide later to test other distros I would highly recommend using a virtual machine in virtualbox. Saves the hassle when it comes to testing distros 👍
KVM is indeed a much better hypervisor, but it does require some setup with the terminal.
Since he is a beginner I decided to recommend virtualbox since it just works after installing. But if he doesn’t mind setting up things via terminal then KVM is definitely the way.
@agr8lemon The other person mentioned virt-manager, but there’s a much more easier app: Gnome Boxes. It uses the same backend (libvirt/KVM) but it’s much more easier to use - in fact, I’d say that it’s even more easier to use than VirtualBox. For starters, Boxes automatically detects OS ISOs on your drive and allows you to just click on them directly to install it - or you can even choose to download and install a distro directly from within Boxes. Also, when you consider the post-setup phase: there’s no need to install any guest modules/drivers because it’s already built-into Linux distros.
I’ve worked extensively with both virtualbox and kvm/qemu. While I prefer kvm since it’s open source, I could never reproduce the video performance of virtualbox. I’m not even trying to game, just use regular applications that I cannot run under Linux.
Welcome, friend! Glad you decided to try out and stick with Mint. That’s the distro I used as my daily driver for at least 1.5 years. When you have a chance, do try out some of the other Linux distros, especially Arch!
+1 here for the arch recommendation as an ex ms sys op. Browsing their repos was outstanding for retooling, most of the config problems you hit are a great way into the ecosystem.
unrelated but does Ableton work with Linux yet? I did a quick search and someone says it works “flawlessly” but the comments indicate this is not true.
You may be interested in reading this post about the process of packaging Steam.
tl;dr: It’s mostly an annoyance reserved for packagers to deal with. Dynamically linked executables can be patched in a fairly universal fashion to work without FHS, so that’s the go-to approach. If the executable is statically linked, the package may have to ship a source patch instead. If the executable is statically linked & close-source, the packagers are forced to resort to simulating an FHS environment via chroot.
I would say it’s actually easier in many cases. Nix has really fantastic packaging tooling. You do have to learn a bit of the nix language, however (not become an expert).
The issue comes when trying to build from source. In most other distros, ou just follow the readme. In nix, you have to package it.
If I am packaging software for gentoo, all I have to do is translate the build instructions from the project’s documentation to gentoo’s package recipe. In nix, it seems that it is not that simple and you’ll have to do some exploration. Am I wrong?
It’s just that most (if not all) build system in the source code package would assume some level of FHS compliance.
For example, they would install:
executables under /bin /usr/bin
libraries under /lib or /usr/lib
sysconfigs under /etc
manpages under /usr/share/man
and so on…
These build systems would include options to change these, but you’d then have to change all these values to adapt to nix structure. While it’s all been done by the nix package maintainers, you’d have to do all that if you’re to come up with a new package.
In the FHS compliant distros, the maintainers wouldn’t need to change anything since these values are already set to the values they want (there are actually minor details they’d change, but that’s another topic).
If I am packaging software for gentoo, all I have to do is translate the build instructions from the project’s documentation to gentoo’s package recipe.
It’s the same for Nixpkgs.
In nix, it seems that it is not that simple and you’ll have to do some exploration. Am I wrong?
In well behaved build systems, it’s likely easier to package than most other distros. If it’s not as well behaved you will have to do some “exploration” and the complexity can get quite out of control if the build system is exceptionally terrible.
Here is the package for the GNU hello program which uses a well-behaved build system:
If you ignore the optional passthru.tests, this is very simple. You provide metadata, sources etc. to the generic mkDerivation function and that’s it. The most complex non-standard thing this derivation does is enable the build system’s tests.
You don’t even need to run the provided build instructions because Nixpkgs’ stdenv abstracts those away. If it finds a makefile, it’ll automatically run make and make install with the correct flags for instance. Same for other standard build systems; if you pass cmake into nativeBuildInputs, it’ll attempt to build, install, check etc. using cmake’s standardised interfaces.
If the build system is poorly behaved however (like for instance Anki’s), you will have to get into the weeds and do some rather advanced things:
linux
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.