Things like desktop automation, screen sharing, screen recording, remote desktop etc. are incredibly broken, with no hope in sight because the core design of Wayland simply didn’t account for them(!?), apparently.

Add to that the decision to push everything downstream into compositors, which led to widespread feature fragmentation and duplicated effort.

Add to that antagonizing the largest graphics chipset manufacturer (by usage among Linux desktop users) for no good reason. Nvidia has never had an incentive to cater to the Linux desktop, so Linux desktop users sending them bad vibes is… neither here nor there. It certainly won’t make them move faster.

Add to that the million little bugs that crop up when you try to use Wayland with any of the desktop apps whose developers aren’t snorting the Koolaid and not dedicating oustanding effort to catching up to Wayland – which is most of them.

people dont like change

I cannot use Wayland.

I’m an average Linux desktop user, who has an Nvidia card, has no need for Wayland “security”, doesn’t have multiple monitors with different refresh rates, uses desktop automation, screen sharing, screen recording, remote desktop on a daily basis, and uses lots of apps which don’t work perfectly with Wayland.

…how and why would I subject myself to it? I’d have to be a masochist.

Honestly I’ll just send it back at this point. I have kernel panics that point to at least two of the cores being bad. Which would explain the sporadic nature of the errors. Also why memcheck ran fine because it only uses the first core by default. Too bad I haven’t thought about it when running memtest because it lets you select cores explicitly.

Welp no change. I’m guessing the motherboard firmware already contained the latest microcode. Oh well, was worth a try, thank you.

It’s a pain in the butt to swap CPUs one more time but that may pale in comparison to trying to convince the shop that a core is bad and having intermittent faults. 🤪

This sounds like my best shot, thank you.

I’ve installed the amd-ucode package. It already adds microcode to the HOOKS array in /etc/mkinitcpio.conf and runs mkinitcpio -P but I’ve moved microcode before autodetect so it bundles code for all CPUs not just for the current one (to have it ready when I swap) and re-ran mkinitcpio -P. Also had to re-run grub-mkconfig -o /boot/grub/grub.cfg.

I’ve seen the message “Early uncompressed CPIO image generation successful” pass by, and lsinitcpio --early /boot/initramfs-6.12-x86_64.img|grep micro shows kernel/x86/microcode/AuthenticAMD.bin, there’s a /boot/amd-ucode.img, and an initrd parameter for it in grub.cfg. I’ve also confirmed that /usr/lib/firmware/amd-ucode/README lists an update for that new CPU (and for the current one, speaking of which).

Now from what I understand all I have to do is reboot and the early stage will apply the update?

Any idea what it looks like when it applies the microcode? Will it appear in dmesg after boot or is it something that happens too early in the boot process?

BIOS is up to date, CPU model explicitly listed as supported, memtest ran fine, not using XMP profiles.

All hardware is the same, I’m trying to upgrade from a Ryzen 3100 so everything should be compatible. Both old and new CPU have a 65W TDP.

I’m on Manjaro, everything is up to date, kernel is 6.12.17.

Memory runs at 2133 MHz, same as for the other CPU. I usually don’t tweak BIOS much if at all from the default settings, just change the boot drive and stuff like “don’t show full logo at startup”.

I’ve add some voltage readings in the post and answered some other posts here.

Everything is up to date as far as I can tell, I did Windows too.

memtest ran fine for a couple of hours, CPU stress test hang up partway through though, while CPU temp was around 75C.

Yep, it’s explicitly listed in the supported list and BIOS is up to date.

RAM is indeed at 2133 MHz and the cooling is great, got a tower cooler (Scythe Kotetsu mark II), idle temps are in the low 30’s C, stress temp was 76C.

Motherboard is a Gigabyte B450 Aorus M. It’s fully updated and support for this particular CPU is explicitly listed in a past revision of the mobo firmware.

Manual doesn’t list any specific CPU settings but their website says stepping A0, and that’s what the defaults were setting. Also I got “core speed: 400 MHz”, “multiplier: x 4.0 (14-36)”.

even some normal batch cpus might sometimes require a bit more (or less) juice or a system tweak

What does that involve? I wouldn’t know where to begin changing voltages or other parameters. I suspect I shouldn’t just faff about in the BIOS and hope for the best. :/

They just need to tunnel the data and let the client decrypt it. Basically what Proton does with their bridge app. And also basically what Tuta’s client does.

https://misskey-hub.net/en/

Only the Tailscale pairing server is proprietary but there’s a FOSS self-hostable alternative called Headscale.

The Tailscale clients are FOSS.

There isn’t much of a guide, you install the Tailscale clients and make an account on their website. After you enroll your devices to the account with a code they’ll be able to access each other via private IPs on an encrypted network based on WireGuard.

You can connect among devices with unsecured protocols like VNC because they’ll be inside the encrypted network. And this works with any app and any protocol not just remote desktop — you can use Syncthing, access files, access any services you want securely etc.

rsync -avxH will copy the files between drives.

You can simply mount the new drive in the same place as the old one after the copy, that way you don’t have to change any paths.

The real dependency problem is that when an AUR package updates and Manjaro’s packages are not new enough for the update, it will cause breakage.

How many AUR packages do you use? I have about 70 installed right now. Never had a source-level incompatibility happen. You’d have to let system updates lapse for years to lose source compatibility with a current AUR package.

Nobody’s perfect, all Linux distros out there have had a rough start. The ones that endure and stick around are the ones that eventually improve. If you were around when Arch came out you may recall very similar attitudes from fans of other entrenched distros disparaging their efforts. Arch wasn’t born perfect either, they made plenty of mistakes in their early days.

But if you’d demand perfection all the time you’d never use the vast majority of distributions that are trying something new. We need to rise above partisan and petty differences because Linux is a hotbed of innovation and freedom and we as a community need to encourage and nurture trying new things, not dump on it.

This is most importantly true in terms of delayed security updates.

Security updates aren’t delayed in Manjaro, they’re pushed through out of band.

You also don’t understand how the AUR works in conjunction with outdated Manjaro packages, which will cause dependency problems and lead to breakage.

Once you’ve compiled an AUR package it will remain compatible with the system you compiled it on until you update and introduce an incompatibility.

This is true for any Arch or Arch-based distribution. It has nothing to do with when the distro updates packages. It’s purely a coincidental factor of whether a particular AUR package breaks binary compatibility with any particular distro update. Users who don’t regularly update their AUR packages to keep them in sync with the system will seemingly randomly experience breaks, depending on what AUR packages they use. It can and does happen on Arch just as well as any derivate distro. You need to either automate AUR updates or update them by hand to avoid it.

you can read what Arch’s security team thinks about Manjaro here

That’s not the “Arch’s security team”, it’s one person on a 3rd party forum, with a history of issuing personal statements reeking of personal grudge. Yeah I know that comment unfortunately. It’s a singular, isolated piece of flamebait and it makes me sad to see it’s still being bookmarked and passed around 5 years later.

“Countless” mistakes meaning two which were easily fixed.

There’s nothing wrong with Manjaro, in fact it’s probably the most user-friendly Arch distro. I’ve been using it for years and I chose it after trying several various distros and this was the one where everything worked out of the box: graphics, audio, peripherals (including controllers and exotic mice), and of course Steam and gaming.

They package drivers and stable kernels out of the box. They provide an easy to use tool for switching and installing drivers and kernels. They attempt to add extra stability to the distro (not all of us like or need to stay on the very bleeding edge all the time). Delaying the packages has zero relevance for AUR and anybody who believes otherwise should probably stop using AUR because it’s obvious they don’t understand how it works.

People who keep on linking those outdated hate lists about it are actively doing themselves and everybody else a disservice. Promoting hate against an Arch derivative for no good reason will not help Arch’s cause, on the contrary, it makes newcomers to shy away from the whole can of worms and drives them to Ubuntu.

I’m waiting for the day Google Recaptcha will ask me “is that traffic light red?” and after a couple of seconds “hurry up, I’m approaching the intersection!”

If by “easy” you mean someone else already spent 5 years and a nice chunk of cash training a model for it, which you get to use. And if you accept that it will not be accurate across all possible species and environments, only very specific subsets.