Nayr438

If Kisai is so wrong, let me know how Valorant, Sniper Elite 2, Civilization V (Native), or a multi disc game works. No third part patches from a clean Install with no knowledge of WINE or DXVK/VKD3D. I made sure to include most of the examples from Kisai post (AntiCheat, DRM, Native). Outside of most single player games on Steam, everything Kisai said is pretty accurate. Maybe these things don't affect you, if so then good for you, but Linux is not a overall better experience for gaming.

You pretty much need a secondary GPU to passthrough to it and a lot of AntiCheats have started actively checking to see if it's in a VM and consider it a bannable offense. It's mixed, if you play single player games from steam then your probably fine, venture outside of that and it's a mixed bag. For Proton/Wine Compatibility can always check https://areweanticheatyet.com/ and https://www.protondb.com/ but just because it works today doesn't mean it will tomorrow. For instance I got locked temporarily out of Anno1800 because the ubisoft launcher updated and broke compat for a couple months, had a similiar issue in the past with GTA V and the Rockstar Launcher. Another recent example. Roblox worked on wine, then broke compat with a new anticheat, added wine support, then blocked wine after they seen a rise in people moving to linux to cheat, because of the limitations of how AntiCheat works on Linux.

As far as I know there is no way to guarantee a mount with autofs, meanwhile systemd mount units can be used as a dependency for other systemd units / services. Outside of that I don't think there are any other major differences apart from how they are configured. fstab on its own is nothing more than a common file to provide a quick way to manage mounts, in the case of systemd it's managed by systemd-fstab-generator which generates mount / automount units. So for systemd automount the additional fstab option would be x-systemd.automount. using autofs does however remove the ability to manage automounts via fstab.

Be aware this is unmaintained, it hasn't seen a update in 3 years. Also the way it handles user accounts is kind of stupid, which is a randomly generated single long key that can't be recovered. Have yet to find a usable alternative to it however.

That kind of defeats the point/purpose of jellyfin/plex. It's a media library not a disk player. Even if Jellyfin/Plex could read from a disk the two problems your going to run into are Java Support for handling disc menus. DRM / Copy Protection on both DVD and BD. You could integrate with something like MakeMKV like Handbrake and VLC do, but it still often requires manual intervention.

The NVIDIA Runtime for Flatpak.

To my understanding some distros may handle this for you. Arch and Fedora on my laptop don't, I have not tested other distros or devices.

How is Quake Champions installed, if it's through steam then how is steam installed. If it's using Proton have all the wine deps been installed and are you using Steam(Ubuntu) Runtime or Steam Native (Arch Runtime) For Steam Native and all of the WINE Deps. Make sure NVIDIA is properly installed and configured If using flatpak ensure the nvidia runtime is installed

CyanogenMod died in 2016... It's long been replaced by LineageOS See Above. LineageOS dropped support for the Tab 2, probably due to the device specs as mentioned previously. The roms on XDA are community maintained and based on older versions of Android, ver. 8 (Oreo) is about as new as your going to get and the Roms available have various issues listed. The same security concerns apply here. You are free to do what you want, but I would consider the security risks heavily before handing it off to someone to potentially manage their bank accounts or any other personal data. If it was the Tab S2 as mentioned previously it would be a whole different story.

That thing is pretty much e-waste. It's 1G of ram won't satisfy the requirements of any newer builds of Android, and If you do find a newer third party build it will likely be a unpleasant experience. Running such an old version of Android is also a security risk, I wouldn't have it connected to the local network or access any banking or personal information with it.

It's complicated. The Affected package entered Arch repositories in 5.6.0 on February 24 and wasn't patched until Mar 28 in 5.6.1-2. The malware targets libsystemd's notification daemon, so anything that depends on it or even potentially just xz/liblzma itself could be compromised. The primary affected target however was OpenSSH, but relied on a patch to integrate with libsystemd's notification daemon, something Arch itself doesn't ship but most other distros do. The primary affected distros to my knowledge are Arch, Gentoo, OpenSUSE Tumbleweed, along with various in-development/unstable builds of distros. That isn't to say it couldn't have been shipped in containers or sneaked it's way in through third party repositories.

I buy a bunch of crap from BestBuy, if it has a red label its a open-box/return item, however usually it will say that rather than PRC. To my understanding however PRC items can't be resold in the store as they are considered to be unsellable in the store due to either being defective, hazardous, or they have a contract to send them back. What's left out is whether they were on the shelf like that or if they were tagged after.

That I can agree with. In this case however for it to land in Arch it would have had to land as a stable release rather than a development one, and yes I am aware Arch may have been unaffected. xz-5.6.1 was marked as stable on "2024-03-09". SSH is used for more than just remote access to a shell. For example git as mentioned previously or something like SFTP . As to whether they were affected, I don't believe so, but it was more of a you should consider that even if someone is using say debian in prod, they may be deploying newer packages in some form. And as we have been moving forward this has been becoming more common. And while this may have not affected any major production instances it was more a jab at the original comment of the expectation that Arch/Rolling Releases should not be run in production and SSH should not be exposed, when there are valid reasons for both.

I use Arch in production and expose ssh for git as do many others including Arch itself, so I would say that's a poor expectation. And even if we ignore Arch there are plenty of people who deploy exposed upstream services via containers in production. Technically I would fall into both of these.

Because it's user managed, it wont mount until you interact with it locally. It should dissapear from your mount list since it's no longer user managed. It should be available at whatever path you specified in fstab. The directory does need to exist before it can be mounted as well. https://wiki.archlinux.org/title/samba#As_mount_entry The "_netdev" option will tell it not to mount it until the network has started