While you're still in your makepkg.conf, don't forget to set march=native (and remove mtune) in your CFLAGS! (unless you're sharing your compiled packages with other systems)
- Are you tech-savvy / willing to learn more about Linux and your PC / read the wiki/forums?
- Do you have the time/patience to keep up with the Arch news so you're aware of breaking changes?
- Do you have the time/patience/skills to fix things when they break?
- Do you have the time/patience to get your hands dirty to do manual configuration occasionally?
If the answer to all that is yes, then skip EndeavourOS and just install Arch directly. If you're not considering Arch because it's "too hard" or you don't have the time/patience, then trying to cheat by installing EndeavourOS will only result in pain down the line. The only thing EndeavourOS is doing is making the instalation process easy - it's not making Arch itself any more easier to use.
The manual way of installing Arch is a rite-of-passage that tests your patience and comprehension skills. It familiarises you with the Arch wiki, and forces you to learn more about how the OS works behind the scenes. So when things break in the future, or the time comes for you to do a manual intervention - you already have all the skills and knowledge (or know where to look). If you can pass the test of a manual install, then using Arch is easy-peasy. At this point, you wouldn't care about silly things like stability, because you already know about automated snapshots and restores, bug reports, building/using the latest patch/package from upstream etc... and it's all second-nature to you. Fixing a broken thing is just another day at the office and your brain won't even register it as an issue.
So, don't cheat - if you want to use Arch, just use Arch.
Edit: For those who disagree with me, here's a recent example of a manual intervention I was referring to: being on EndeavourOS or any other Arch derivatives won't save you from having to keep up with Arch news and occasionally having to take manual action like this: https://lemmy.nz/post/7648427
Also please do read the full thread - from the discussions there, you'll see that the steps you'd need to take for that piece of news is not entirely straightforward: some folks might need extra/different steps that's not explicitly described in the news/wiki. This is the kind of stuff you should be prepared to deal with.
Same, except skip the cheese and try some butter and soy sauce, or butter and togarashi.
I am not a fan because they install all that WINE stuff on the system level which is a huge security degradation.
I disagree with this. Sure, it could be made more secure, but Wine, on it's own isn't, any greater security risk compared to any other scripting runtime such as say Python, which is also installed at the system level. Ultimately it's up to the user to get their executables from trustworthy sources - and whether it's a random bash script or an exe, doesn't really make a difference.
As for Firefox, if you're truly concerned about security then you wouldn't be using it in the first place, you'd be using Librewolf, which you can install without any issues.
Which AMD systems? I've got a Zen 2, Zen 3+ and a Zen 4 and haven't experienced any freezing with 6.7.
I am! I run it both on my gaming PC and laptop.
But it doesn't seem like a "typical" distro for a daily driver? How does Bazzite for example differ from Nobara which is another gaming-oriented distro?
Well, for starters, if you get the Bazzite-deck edition, your PC boots straight into Steam's game mode - in this mode, everything runs thru gamescope so you get all the awesome benefits like being able to use FSR even with games that don't support it, HDR and more. You get a console-like experience on PC, and it's awesome.
Another cool thing about this mode is that all your updates - including OS, Flatpak, firmware/BIOS, container, Nix, pip etc - all of it is presented as if it's a Steam update like in SteamOS - and it's automatic too, and it doesn't interrupt your gaming experience. Basically a unified update backend and frontend, which is awesome.
Compared to Fedora/Nobara, one advantage this has is that the updates are image based and atomic, so when you reboot, the new update goes live instantly so there's no wait-time. Another advantage is that your previous image is available in the GRUB menu, so in case the update broke something, you can always boot from the previous image - no need to even restore anything, no need to edit your fstab etc (unlike btrfs snapshot restores where the subvolid changes). And you can also pin "good" images to your GRUB menu (and I highly recommend doing that), so you can always fall back to a known good version. This came in handy on my laptop recently where after one of the Feb updates I was experiencing some weird graphics corruption in game mode, but thanks to image pinning I always had a working image to fall back to. Also, the rebase feature allows you to go back and forth between 90 days of images (stored on github), so it's easy to switch between various versions for testing. The rebase is also interesting because with just a single command you can switch between any other Fedora Atomic distro, so if you're bored of Bazzite or you want to try out a new DE, it's just one command to switch. And with pinning, you can always switch back instantly.
Finally, there's the whole immutability aspect. Personally I'm ambivalent on this, but the fact that it allows image/atomic updates (with easy rollbacks/rebases), I think of it more as a convenience - especially on a gaming-oriented machine, where I just wanna jump straight into my games without worrying about updates and broken systems.
So having used Fedora, Nobara, and finally Bazzite, I can highly recommend Bazzite as a daily driver - and it's 100% worth switching. AMA.
Anther exciting release! Looking forward to the new bcachefs performance improvements (and fsck, finally) and KSM advisor - hopefully with this, KSM becomes more practical.
Thanks! And yeah, CAT is indeed the old Alley Cat game.
Not too sure about that, have installed primus_vk and do you see the cube?
A ton of difference!
marchstands for microarchitecture levels (or feature levels). "x86-64" is the baseline feature set targeting common x86_64 instructions found in early 64-bit CPUs, circa 2003. Since 2003 obviously there have been several advancements in CPUs and the x86_64 arch, and these have been further classified as:So if you're still on x86-64, you're missing out on some decent performance gains by not making use of all the newer instructions/optimisations made in the past two decades(!).
If you're on a recent CPU (2017+), ideally you'd want to be on at least x86-64-v3 (v4 has seemingly negligible gains, at least on Intel). There's also CPU-family specific marches such as
znver4for AMD Zen 4 CPUs, which would be an even better choice than x86-64-v4.But the best march you want use is of course
native- this makes available all instructions and compiler optimisations that's specific to your particular CPU, for the best performance you can possibly get. The disadvantage ofnativeis that any binaries compiled with this can run only on your CPU (or a very similar one) - but that's only an issue for those who need to distribute binaries (like software developers), or if you're sharing your pkg cache with other machines.Since the flags defined in makepkg.conf only affect AUR/manual source builds (and not the default core/extra packages), I'd recommend also reinstalling all your main packages from either the ALHP or CachyOS repos, in order to completely switch over to x86-64-v3 / v4.
Further reading on microarchitectures:
Benchmarks:
cc: @[email protected]