xrandr is Xorg only, it doesn’t work with Wayland. You should be able to make SDDM use your Plasma display configuration - https://wiki.archlinux.org/title/SDDM#Match_Plasma_display_configuration

No clue if that’s going to fix your issues, but at least it’s supposed to work with Wayland.

So I did look more into it, and apparently the open firmware is technically compatible with PCIe cards using this chip, but doesn’t provide any advantages over just wiping the firmware and letting the chip default to its built-in fallback firmware, and so the maintainer doesn’t see any value in explicitly supporting it.

Now the question is whether you consider the proprietary fallback firmware to be acceptable to run - this might sound weird, but for example FSF has explicitly made exceptions for devices with built-in firmware to be able to qualify for the Respects Your Freedom certification, so if your view aligns with theirs, you might consider this to be completely OK. If not, the free firmware appears to have a similar feature set, you’ll just have to jump through more hoops.

Also do note that both the fallback firmware and the free firmware are missing many features of the proprietary firmware, so make sure to check it’s not missing anything you need (wake on LAN, Jumbo frames and PXE boot seem like the most notable missing features to me).

More info on support for various PCIe cards

It’s less about the computer and more about the card itself - Talos II and Blackbird both use the BCM5719 chip for their integrated NICs. Basically, you’re flashing part of the motherboard with this firmware. A PCIe card built around the same chip might connect the interfaces in a different way, and firmware doesn’t generally have a way of poking around to find out how everything’s set up from the hardware side of things - it needs to just know this, and that’s why there are separate firmware builds for different hardware.

If you flash one of these files to that card, it might just so happen to work perfectly, but it most likely won’t. You would need to figure out how it’s wired up and modify the firmware with that knowledge. And then you could use the modified open firmware with that specific card model on any computer that supports the proprietary firmware, because IIUC this is meant to be functionally identical.

So in short, no, you cannot currently use this open firmware on any computer other than Talos II and Blackbird, but for slightly different reason than you might think.

Also, the Arch repos are pretty much just an “AUR with binaries” - they contain the same PKGBUILD files used by AUR packages, because that’s how Arch packages are built. So you can just download an Arch package PKGBUILD, modify it however you wish, and then build and install it.

If it is an Arch-based distro (sorry, I don’t recognize the package manager), then this might just be the recent Wine update that made it 700 MB smaller (which would mean the rest of your system grew 300 MB)

I made a post here about it: this one

Btw, is there a way to link to a post in a way that resolves on everyone’s separate instance instead of hard coding it to my instance?

Also, some programs, such as many terminal emulators, can cache you PW so you don’t have to enter it multiple times.

Terminal emulators don’t (or at least shouldn’t) do any such thing. sudo itself is responsible for letting you do privilege escalation without password for some time after successfully passing once - whenever you run it and successfully authenticate, it saves your user id, current time and a session identifier (each open shell gets a unique identifier) into a file. Then, when you attempt to do anything, it will check this file to see if you’ve if you’ve authenticated within the last few minutes in this terminal, and only ask for a password if you haven’t.

For more info, see man sudoers_timestamp

I’ve explained my reasoning for all the points I disagree with. Which one do you have a problem with? CS:GO? The last version of CS:GO is still available on Steam and fully playable, the only missing part is matchmaking servers - you can play with bots or on third party servers without any problems. That seems far from gone.

CS:GO got a controversial update and got renamed. Old versions are still available under CS2, you just can’t use Valve’s servers anymore. Playing old versions on private servers is possible. But OK, I give you half a point for this one - you can’t play matchmaking with old smoke physics anymore (but then again, it’s not like it’s the first CS:GO update to change the gameplay in a fundamental way).

Moving on, Artifact. It’s in my library, ready to be played - Valve definitely didn’t “make me lose Artifact” like you claimed. The community is dead, but there are still 40 people playing right now according to SteamDB and servers are up. One point down for easily verifiable lie.

And finally, Team Fortress 1. I assume you don’t mean the Valve’s game called Team Fortress Classic, because that one is still available for purchase on the Steam Store and oscillates between 40 and 100 active players at any time. So that leaves us with Team Fortress, a mod for Quake. But that one is available from ModDB without any problems, so… What’s the issue supposed to be, exactly? No points, because I have no idea if there’s more to your claim.

Hint: blatantly lying about some points heavily undermines the other points you make. So at least try to be subtle.

It should not be controlled by a company that is known to make you lose your games.

Are you referring to the fact that Valve promotes digital game distribution (which is a very fair view), or are you talking about some incident where Valve removed games from people’s libraries? Because if it’s the second one, then I would really like to hear about it.

Not a fair comparison IMHO - Ethernet is designed to be a connection between two or more otherwise independent peers (on L2), while USB’s goal was to allow connecting simple peripheral devices to computers. There was never meant to be a situation where it’s unclear which side is the Host.

Also note that the bridging “cable” is literally just two USB devices, one for each computer (although they are both on the same chip, so there’s that), with some internal link to pass the data.

You could put your .desktop files in a separate directory and just symlink them to ~/.local/share/applications. If you want to have all your aliases together, you could have a directory like Aliases or whatever and then have Aliases/desktop for .desktop launchers, Aliases/bin for scripts or binaries (and have it in PATH), Aliases/bashrc for your bash aliases (and just put source .../Aliases/bashrc in ~/.bashrc), etc.

Of course everyone has their own opinions on how to organize stuff, but this is IMHO pretty clean for what you probably want to do.

Edit: and to quickly (re)create the symlinks, you could use a bash one-liner like for f in .../Aliases/desktop/*; do ln -s "$f" "~/.local/share/applications/$(basename "$f")"; done - put it into your bashrc as a function and remember to run it whenever you create a new .desktop launcher, and you should be golden.

I don’t think that’s a similar situation - the Linux kernel lost some functionality there, but in this case Ext2 filesystems are still fully supported by the Ext4 driver, so there’s no difference in “hardware” support.

The separate Ext2 driver was being kept for embedded devices with extreme memory or storage limitations where saving some kilobytes by not having all the new Ext3/4 features was useful, but when you can afford the extra memory, there’s no reason not to just use the Ext4 driver for all Ext2/3/4 filesystems.

Does UEFI initialize all the cores? I know the OS always starts with only one core available, but I’m not sure if UEFI just disables the cores after it’s done its thing, or if it doesn’t touch them. Because if it stays on core 0 and never even brings the other ones up, then this issue with core 2 could let it boot this far just fine.

Maybe. To be clear the delay isn’t that large (my very rough guesstimate is somewhere between 100 and 300 ms, probably more towards the lower end), and if I just click somewhere on the slider, it feels fine.

It only feels janky when I drag the slider and the screen brightness updates in very noticeable steps. But that is how I naturally interact with sliders, so it’s hard not to notice it for me.

It’s a very common feature for monitors, at least in my experience - both of my cheap AOC monitors support it, as well as all the other monitors I’ve ever connected my laptop to (a few HP and Samsung monitors iirc).

But it also feels kinda janky due to how long the display takes to change the brightness, so maybe that’s why Microsoft decided not to support it?

Not really - report your issue on their issue tracker if you can and feel like spending your time on it, then move on (and maybe check back in some time). Flatpak are meant to fix dependency issues, there’s not much you can do if they got it wrong for whatever reason.

If it’s a Flatpak, then installing anything with APT shouldn’t help you at all - it is possible to build a Flatpak that accesses host libraries, but it would defeat the point of using Flatpak in the first place. So your xapp issues are moot anyway.

As to the meaning of the output of apt policy: it says that the most up to date libxapp1 is from Linux Mint repos, and that there’s also an older version in Ubuntu repos. That means that Linux Mint doesn’t provide a xapp package at all, and the only one you could install is the old one from Ubuntu (which conflicts with the newer libxapp1 from LM)

The APT error is most likely a result of using PPAs - some PPA you use (probably the one with simple64) provides libxapp1 2.8, but doesn’t provide happy at all, so you end up falling back to the much older version from your distro’s repositories. But xapp needs an exact version of libxapp1, so you get this error.

That said, if the simple64 PPA doesn’t provide the xapp package, then it perhaps isn’t required and the module should be provided by libxapp1 (and the problem is something different). Or maybe it comes from a completely different PPA - I believe apt policy libxapp1 should tell you where it’s coming from.

Yes, but they are asking how to set up FDE in the same way it works on Windows, where automatic unlocking works using TPM. They just don’t know the technical details.

Yeah, but a lot of those things will trip the TPM module, so you will get a different decryption key if you for example try to use the single kernel parameter to boot into a root shell. And different decryption key means no access to the data.