While it might seem interesting for your usecase, please be careful which specific distro you use, especially when it comes to “windows-like” distros. Wubuntu (previously LinuxFX) has terrible security for your payment info, and the developers have made a ton of questionable decisions.

This issue is also visible on my firmware setting (BIOS)

That means it’s hardware.

Not entirely. SteamVR on Linux is almost that bad, yes. With ALVR you can try to use standalones on SteamVR, but it’s not very stable. Most games will “run” under SteamVR and modern proton, I’ve only encountered a few situations where they don’t, once again caused by kernel level anticheat. SteamVR does have major issues with stability and reprojection, which makes the VR experience much worse overall.

However, Monado and WiVRN (+ OpenComposite) are great when using Envision. Not all games run, and some have input issues, but it’s significantly better than SteamVR. With a couple overlays, you can get most functions working as expected, like desktop view, camera passthrough, etc.

As for “power management” and “bluetooth”, the only thing the Valve Index uses bluetooth for is power management. That doesn’t work in the drivers on Linux, but there are scripts you can use if you have a separate bluetooth dongle. It’s not a full fix, but not as painful as using an Android app or unplugging the basestations.

As we both noted, it requires setup and troubleshooting, and as someone who uses Linux for VR gaming too, I can’t recommend it to the average person. That does not make Windows a “requirement”, just much easier and the better plug and play experience.

Not needed, many VR games work fine under Proton. Unlike desktop though, not “plug and play”. If you’re ready to spend time troubleshooting, give Linux VR a try with SteamVR or Monado through Envision. If you just want to play VR, stick to Windows for now.

“LineageOS stan”?? The same arguments go for any custom Android rom that doesn’t ship with Google Play Services or MicroG.

“It’s always LineageOS users”

FYI, Since I personally prefer absolutely zero connections I didn’t approve of, I’m using a privacy-focused rom. I’m not even on LineageOS.

I love the complaining about privacy, after which you immediately share a google translate link. Was it that hard to find an English source stating LineageOS connects to Google?

Anyway, this doesn’t dispute any of my arguments. LineageOS connecting to Google by default does not mean it sends the same amount of data as a stock rom with Google Play Services. A user shouldn’t be discouraged in taking steps to further their privacy because it’s “not good enough”.

not actually degoogled

Aside from vendor firmware, LineageOS is mostly deblobbed by default afaik. The remaining bits that connect to google (by default) like AGPS or captive portal are significantly less information than full google play services.

try to do it in ways that provide no privacy benefit

Replacing google play services with microg might have the same security downsides as regular google play services (privileged access), however, MicroG is open source. It still connects to Google, but sends significantly less data, and you can see exactly what it sends.

Break any semblance of security model

Rooting is one example, but access to it is often left up to the user. Keeping the bootloader unlocked has some major security downsides, but they’re entirely for when an attacker has physical access. The privacy downsides of an unlocked bootloader do exist, but they’re hard to exploit even with physical access.

ingnoring all of AOSP is Google

Yes, this is something you are forced to ignore with any custom Android ROM. Graphene, Divest, Calyx, etc all suffer from the same issue. Sending data to Google and privacy is not the same as being independant from Google developed software.

purely focussing on Google

On an AOSP or LineageOS based rom without preinstalled bloat, this is almost entirely up to user choice. You can choose to only install FOSS apps without trackers, or use Aurora store and install proprietary apps. You can choose to block network access for apps with trackers, or isolate them to a work profile and kill them in the background. It isn’t good to focus only on Google, but it’s a good starting point to use a rom without standard google play services.

While I agree that a hardened and privacy focused rom is better for privacy than regular LineageOS, privacy is not black and white. MicroG sending significantly less data is better than full access google play services sending all data. Not sending data is better than MicroG. That doesn’t mean every user is able to use an entirely degoogled rom. Each person should decide for themselves what they’re okay with and what they absolutely require on their own device. When someone is trying to get some privacy back, MicroG is a great option “in the middle” where as little functionality as possible is lost while sending as little data as possible. Discouraging that someone takes steps to improve their privacy just because it isn’t perfect is not good, as that often results in someone not taking any steps towards privacy.

On the compatibility, while MicroG has some issues with specific apps, it does generally work (from what I hear from others). Not having google play services (or MicroG) can work, but it requires missing out on some google services like notifications for proprietary apps. For me personally, that’s not a big issue, as I only use FOSS apps.

Simply not having google play services installed is a massive privacy win. Any custom rom (without google) will offer that. Divest and Graphene offer some extra security features.

The compatibility can be usable if you don’t rely much on closed source apps or their notifications. If you do, you’ll need either microg or full google play services.

Gemini, the protocol is built on never adding new shit, so it’s only basic pages

Sadly there would still be wars, as some see “the other side losing” as a win. Even if both sides are completely destroyed.

That was a possibility with this exploit, but realistically that doesn’t affect nearly as many people as “All GNU/Linux systems”.

“But it looks bad and could be bad for the battery!”

Every other wireless mouse has it in the front, Apple has no valid reason to leave it at the bottom.

Even there, if the stars align (network access, cups being used), you still need to convince the user of the device to switch printer.

As far as I’m aware, the exploit requires someone to try printing using a malicious networked printer. It is a vulnerability, yes, but it affects essentially nobody. Who tries manually printing something on a server exposed to the internet?

Although for local network access, like in a corporation using Linux on desktops, the vulnerability is an actual risk.

If this was the case, the phrashing around the issue would’ve likely been different. Yet bitwarden remained very vague, and even locked github comments on the issue.

Especially considering that a move like this alienates their core target demographic (people who use FOSS), they would’ve been much more open and much quicker if it wasn’t intentional.

I will personally be switching, likely to KeePassXC.

Was yes. They have introduced an “internal sdk” into all their clients with no available source code. That’s what everyone’s complaining about. They call it a “packaging bug”, but in reality Bitwarden clients are just no longer open source.

AI photo, check the coins on the left

VR “works”, but as someone who uses it, I can’t reccomend it for now.

Compatibility is wildly different between headsets. And no matter which route you take, you will need to tinker and troubleshoot. There is no plug and play solution right now.

If you want to plug in your VR headset, and just play some games, stick to Windows for now. If you’re fine tinkering around, there’s always SteamVR, but also check out Envision and Monado.

As for desktop games, you can find what works on ProtonDB. Most games work fine, with the exception of games with kernel level anti-cheat.

https://manjarno.pages.dev is a good read

SteamOS is not the same as its base Arch Linux. If you want something slightly easier but still Arch-based, try EndeavourOS (but please not Manjaro).

If you have the time, try switching on your own terms within the next year. It’s almost guaranteed you’ll run into issues, but trying to dual-boot now rather than later gives you all the time you need to figure it out before MS forces you on Windows 11.

According to Jim Starkey, the person who coined the term, “Blob don’t stand for nothin’.” However, it is often referred to as a “Binary Large OBject”, meaning a large file with content not easily readable by people.

With an open source project, you have source code which is turned into executables/“blobs” by the compiler. As long as you trust the compiler, you can (functionally) know the content of the blobs by looking at the source code they were made from.

In the case of Ventoy, several “blobs” are included from an unknown or vague origin. This is a great way to bundle malware, as seen with the XZ backdoor from earlier this year. As such, the original creator of the linked issue is requesting they are built/obtained at compile time, so either the content or origin of these files can easily be found.