I don’t use Gnome, but they hate to expose settings in general it seems and like to dumb down everything (and that is why I don’t use it). The issue here is that the you need KDE, Sway, Niri, Xfce, etc all to implement a setting for this. Middle mouse paste is useful and has been standard on Unix-likes for decades. There is literally no reason to remove it.

No, it was your assertion that a wheel being too fiddly. It seemed quite broad (stating it as an universal truth). It might be for you, but not for most people (but you wrote it as an unqualified statement).

Not true, if there is no user visible setting for it. Changing a hidden gsetting via a command line is essentially removing it since it will likely bitrot and then be fully removed in a few years.

For many people this is a non-issue. I think this a case of just accepting we are different and don’t need to force our view on everyone else.

Maybe 15 years ago I had a mouse with a tilting scroll wheel (for side scrolling), on that one I did have issues with middle click, for about a month until I got used to clicking straight down.

So maybe it is just a question of practice? Maybe not. But since both options exist there is no need to get upset.

I ran Gentoo from 2005 to 2009 or so. Took too much time compiling the software, nor doing that again. Apart from that it had some pretty neat ideas.

V2 is about Nehalem. V3 is approximately Haswell (iirc it corresponds to some least common denominator of AMD and Intel from around that time). V4 needs AVX512 (that is really the only difference in enabled instructions compared to V3).

Both my daily driver computers can do v3, but not v4. (I like retro computing, so I also have far older computers that can’t even do 64-bit at all, but I don’t run modern software on those for the most part.)

As far as I know they do a few things (but it is hard to find a comprehensive list), including build packages for newer microarchitectures such as the aforementioned x86-64-v3. The default on x86-64 Linux is still to build programs that work on the original AMD Athlon 64 from the early 2000s. That really doesn’t make sense any more, and v3 is a good default that still covers the last several years of CPUs.

There are many interesting added instructions and for some programs it can make a large difference, but that will vary wildly from program to program. Phoronix has also done some benchmarks of Arch vs Cachy, and since Phoronix Test Suit mostly uses it’s own binaries, what that shows is the difference that the kernel, glibc and system tuning alone makes. And those results do look promising.

I don’t want to spill some memes worth Arch elitism here, but I just doubt Arch derivatives crowd knows what x86-64-v3 thing is. Truth be told, I barely understand that myself.

I think you just did show a lot of elitism and arrogance there. I expect software developers working on any distro to know about this, but not necessarily the users of said distros. (For me, knowing about low level optimisation is part of my dayjob.)

Also, for Cachy in particular they do seem to have some decent developers. One of their devs is the guy who maintains the legacy nvidia drivers on AUR, which involves a fair bit of kernel programming to adapt to changes in new kernel releases (nvidia themselves no longer do so after the first year of drivers becoming legacy).

I too run an Arch and am happy with it, and I would like to know why Cachy. The only reason I can see is having x86-64-v3 packages instead of baseline. That is nice, but on it’s own doesn’t feel worth the effort of switching over.

Defaults don’t matter to me much, as I automate and manage my system config in git (using a tool I wrote myself: https://github.com/VorpalBlade/paketkoll/tree/main/crates/konfigkoll inspired by https://github.com/CyberShadow/aconfmgr). It makes it a breeze to set up a new computer as I want it.