Ubuntu vs. Arch Linux On The ASUS ROG Strix G15 / Ryzen 9 5900HX

[mdedetrich]

People using Ubuntu generally don't want to apply patches to packages. I'm with Linus, I just want my distro to work without having to mess with it. Ubuntu gives me that, and still allows me to install a different kernel or newer mesa if I desire it. I've never had a problem with Ubuntu, although I tend to stay with the latest releases or dev releases since I don't like to be too far behind.

Which works great until it doesn't because you hit some bug that has been fixed recently in upstream but hasn't been backported. I have used Ubuntu LTE before in enterprise, never touching it again

[mdedetrich]

I don't recall Arch ever performing terribly well in the Phoronix multi-distro benchmark contests. This result seems pretty typical.

This is usually more due to kernel configurations than anything else. If you have a kernel that is tweaked for latency/realtime it will always perform worse in batch style tasks (including multithreaded).

Unless you are doing something like Intel's Clear linux where you recompile everything with optimal flags for your architecture you can typically replicate any kind of results with the correct kernel settings (or even patches if you want something like realtime Linux).

[curfew]

People using Ubuntu generally don't want to apply patches to packages. I'm with Linus, I just want my distro to work without having to mess with it. Ubuntu gives me that, and still allows me to install a different kernel or newer mesa if I desire it. I've never had a problem with Ubuntu, although I tend to stay with the latest releases or dev releases since I don't like to be too far behind.

I first gave up on Ubuntu and moved to "plain" Debian... Then I gave up Debian and moved to Arch. For the same reason as you: I just want to use my computer and not have to deal with the OS doing things behind my back nor up to my face.

[curfew]

Since Michael is known for his absolutistic refusal to perform any sensible optimization on the out-of-the-box experience on various Linux distros, it begs the question: What the hell did he do with Arch?

The vanilla installation doesn't even have most of the system services installed, while other are turned off, let alone a desktop environment. And if you do a simple pacman -S gnome, you don't really even know if it's gonna boot the Xorg or Wayland version, nor what kind of power configuration it is running. (Critical on a laptop!!!) We can even see from the hardware specs summary table that e.g. Vulkan library was not installed nor enabled.

Well, it's apparent that this piece of text (not qualified enough to be an "article") is trolling since he was pissed about people bringing up Arch all the time. I wouldn't hesitate to say that he even wanted Arch to lose, which it really didn't, but whatever.

[bug77]

Since Michael is known for his absolutistic refusal to perform any sensible optimization on the out-of-the-box experience on various Linux distros, it begs the question: What the hell did he do with Arch?

He probably used an archinstall profile that includes Gnome.

[perpetually high]

I first gave up on Ubuntu and moved to "plain" Debian... Then I gave up Debian and moved to Arch. For the same reason as you: I just want to use my computer and not have to deal with the OS doing things behind my back nor up to my face.

This is true on Ubuntu. Had to mask that bs "tracker-store" and "packagekit" services. They do lots of things behind the scenes and it makes the computer unpredictable. Now, I have nothing running in the background. Few interrupts, the shell, and the essentials

For those on Ubuntu, you'll like want to do:

$ sudo systemctl mask tracker-store.service
$ sudo systemctl mask packagekit.service

Don't disable or delete this, might mess with Ubuntu, but you can safely mask these with no adverse side effects (but look up tracker-store first and what's it purpose is) and your system will run better

[curfew]

I'd bet that most of the benchmark differences could be chalked up to GCC 10 on Ubuntu vs. GCC 11 on Arch.

There are GCC 10 vs 11 benchmarks on Phoronix for both software compiled using them and actual compilation time benchmarks as well... And there is very little difference.

I'm noticing that Ubuntu wins the compilation time benchmarks. So could it be down to disk access speed? I don't know if there are kernel settings that affect it or is it just a simple, dumb mount option difference. Or maybe the SSD was throttling in the Arch tests or there was a Gnome/Tracker file indexer running in the background. Who knows.

[curfew]

He probably used an archinstall profile that includes Gnome.

That install profile seems to quite literally be the pacman -S gnome that I mentioned in my previous comment...

https://github.com/archlinux/archinstall/blob/master/profiles/gnome.py

[andyprough]

This is usually more due to kernel configurations than anything else. If you have a kernel that is tweaked for latency/realtime it will always perform worse in batch style tasks (including multithreaded).

Unless you are doing something like Intel's Clear linux where you recompile everything with optimal flags for your architecture you can typically replicate any kind of results with the correct kernel settings (or even patches if you want something like realtime Linux).

Michael usually sticks with the defaults unless he is testing specific kernels, like today's comparison of Liquorix and XanMod kernels. Are you saying that Arch is pushing for a realtime or low-latency kernel to be the default now? I haven't installed it for about a year, but I don't recall that being the case.

The reason Arch typically does poorly in these comparisons is simply that it runs with newer packages with their own issues and regressions.

[krzyzowiec]

I first gave up on Ubuntu and moved to "plain" Debian... Then I gave up Debian and moved to Arch. For the same reason as you: I just want to use my computer and not have to deal with the OS doing things behind my back nor up to my face.

That's funny. I went from Arch to Ubuntu for the same reason.