EVs are inherently cheaper that CE-based alternatives.

So unless this is about stopping the 24/7 propaganda of fossil fuel lobbyists, it’s just some useless PR stunt.

Trust the slob! Learn to love the slob! Slob is life!!

it’s getting more prevalent as more stuff (especially servers) run on Linux […] Linux’s days of living in “security through obscurity” are over"

Servers are primarily running Linux for decades. So any security through obscurity would be gone for as long, if it even existed ever…

though I’ll admit to not having tested that sort of thing with Wine/Proton installed

The more primitive the better the chances. And there are some really primitive cases of ransonware perfectly happy with running through Wine and encrypting your files. So limiting Wine’s file access (or better running it as a separate unpriviledged user with no access to anything but your games) is always a good idea.

pacman -S vulcan-mesa-implicit-layers

Which will then probably tell you that it conflicts with vulkan-mesa-device-select and asks if you want to replace it. Which might either work or just get you another conflict because vulkan-mesa-device-select is required by some other package.

Btw… pacman -Qi <package name> usually tells you anything you need to know about a package. In this context mainly why it was installed (as a requirement for which package) and which other packages are required as a dependency.

So maybe you should take one step back first. Check why 'vulkan-mesa-device-select` was installed in the first place. If it’s not dependency of something else you can either remove it (or replace it) alongside its lib32 version.

That’s a totally separate error… It can happen that the keyring itself is so out of date that it blocks the update, and with it the upgrade to a newer keyring. For this reason it’s often safer after a long time to do pacman -Syu cachyos-keyring (pretending I guesse right and that’s the name of the package) first to avoid the whole update getting blocked by signature with an out-of-date-key. Yet that should not apply here.

But Ignoring the warnings you get for now… This looks like vulkan-mesa-implicit-layers did not replace vulkan-mesa-device-select but now the 32bit library version lib32-vulkan-mesa-device is supposed to be replaced by cachyos/lib32-vulkan-mesa-implicit-layers, which would in turn need vulkan-mesa-implicit-layers as a dependency.

What happens when you answer ‘no’ to that first question? Alternatively, is there anything keeping you from installing vulkan-mesa-implicit-layers (thus replacing vulkan-mesa-device-select)?

Not using CachyOS but Arch… but after a long break from updates you should probably start by checking if your mirror is still up-to-date (doesn’t look like it when you local stuff is newer…).

Again… not my OS but this seems to be the file you could use to manually replace the mirrorlist in your /etc/pacman.d/ directory.

Edit: Also just to be sure… -Syyu will force a refresh of all databases (doubling the u would force “upgrading” even it’s an actual downgrade from your local version). You normally don’t do it because it puts extra load on the mirror, but in case of problems it won’t hurt.

PS: For the future (and although partial upgrades are normally to be avoided)… after a long break in updating the key breaking points are mirrors, then keyfile (they can be so out of date that you can’t start the update; so do them separately first - If CachyOS keeps with its usually sane naming structure the package you should first update, just to be sure, will named cachyos-keyring, but no guarantees there…), then pacman itself…

The latter is very rare but there have been a handful of major changes in pacman’s lifetime that broke down compatibility after a long time. Arch keeps a static pacman version available for these cases, so you can still do a proper update to fix it, but don’t know where CachyOS keeps it’s equivalent.

2nd Edit for sake of completion: A quick searched seems to indicate that CachyOS does not have a separate static pacman. So if everything else fails and it’s an actual problem of pacman itself (and only then, so please don’t try that just now) https://pkgbuild.com/~morganamilo/pacman-static/x86_64/bin/pacman-static has the static standalone version of pacman. So you can download this file, make it executable and run it.

💀 Manjarno

The ‘O’ stands for manipulation…

Being lazy and having update-related issues with nextcloud too often for my taste I went back to the basics (as that’s all I actually use 99% of the time) with Syncthing for file syncing and Radicale for caldav/carddav.

“We want to show the automotive industry that sustainable and practical design really is achievable”

Funny to think they don’t know already. But sustainable isn’t the goal, maximising profits is.

Sure, there is a usecase for this. But sperate buffers and varying (and often unintuitive) behavior of software and which buffer is used how is a much bigger hurdle for people not used to it than that “middle-click pasting is confusing” bullshit…

No, what actually makes sense is a proper unification of different copy/paste buffers that is nowadays still mostly improvised and only achieved through very different 3rd party tools (for me using the panel from xfce it’s xfce4-clipman for example that keeps highlighting text and middle-click buffers synchronised with ctrl-c/ctrl-v or ctrl-insert/shift-insert…).

The problem is not accidently pasting something with a middle-click, but not knowing what is in one buffer, what is in another one and which one a program is using.

I don’t quite get why Gnome people see this as a negative.

Because GNOME decisions are correct, always and exclusively so. Everyone who disagrees is obviously clueless and can be disregarded.

That’s basically the GNOME mantra.

GNOME guys complaining about someone trying to force unilateral decisions upon them and being totally uncoopertaive must be satire…

“Users will stop suggesting Linux as a realistic alternative to Windows for non-technical users”

Then their users will simply be wrong…

Non-technical users don’t have any problems with Linux as an alternative. They don’t know nor care what is running on their PC as long as they can click on icons opening the handful of basic programs they actually use.

It’s the pseudo-technical users that think their constant MS indoctrination means they are the pinacle of experienced PC users that are the problem.

Yeah, the majority downloads a random program to do it for them from some website. Which might or might not do what it advertised, sometimes even without installing a lot of trash ranging from ads to viruses…

I do manage them via git. But I only do it so have settings (and their changes) synchonised between 2 PCs and a laptop.

With just one main device I don’t even see a reason to “manage” anything… a basic backup strategy completely independent of just dotfiles aside.

None.

I use Signal for messaging. In fact I only use it on mobile devices for short stuff.

Any discussion that takes more time than typing s few short sentences (but is usually also less time-sensitive) I do on the desktop app already.

So Signal is definitely not the right platform for me to talk about hobbbies or other interests. That’s not what it was originally designed for. And that’s not what I will ever use Signal for even if it can nowadays cover that area somewhat.

Just set the timezone environmental parameter accordingly. Librewolf might pretend to be in UTC but doesn’t care if the time given by your system is wrong to get the correct time again.

Oh, they really fixed this.Didn’t notice as Librewolf is only my backup.

And if you try often enough it maybe even be a working one…