Search

@UnfortunateShort @archonet
That would essentially be a closed source fork of the kernel.

The GPL requires the end user be allowed and not prevented from making whatever change they wish to the kernel.

The people who want a closed source kernel can use the NT kernel.

I just install ProtonGE from AUR and then it is a magic option in Steam. Idk why we need whole programs for this

It’s not that easy for everyone, Debian users have to do it manually or through a third party application like ProtonUp-Qt.

For me both have their use cases. Heroic is my go to for GOG and Epic games and everything else not Steam (e. g. old Windows install files that I still have lying around). EA App only ran for me on Lutris until one day it didn't. Then I tried with Bottles and it worked ever since. Not trying to add more confusion, but for some people Bottles has a more intuitive interface than Lutris.

I've been exclusively gaming on my Steam Deck since launch and have a slightly different experience. For me, if the game is certified "Playable" or "Verified" on the Steam page, I just download and play it. I have never once tweaked any settings or tried a different version of Proton. I'm sure there are tweaks that can achieve better performance on certain games, but I have never personally felt the need to research that on any game.

For reference, below are my recently played games. All but Trials worked great for me. Trials is marked "Unplayable" on Steam, though I did get it to work for a few hours before it broke.

SteamOS definitely isn’t made for a traditional desktop computer. It has a desktop environment for when you need it, but that’s basically bolted onto the side of Steam’s Big Picture mode. It would likely work well if you have a dedicated PC for your living room TV. But for a traditional desktop setup, you’d likely want something else.

Maybe Bazzite? It’s basically built for gaming, but doesn’t default to Steam’s Big Picture mode like SteamOS does. It comes with Nvidia drivers pre-installed, which is a big sticking point for lots of people; many have found and/or lost religion while trying to install Nvidia drivers on Linux, so having them ready out-of-the-box is a big selling point. And you can choose which desktop environment you’d prefer when installing it; I’d suggest KDE if you’re familiar with Windows, or Gnome if you prefer MacOS. It’s immutable, which is, to put it simply, controversial. Some people love it, because it means you won’t accidentally destroy your OS. But others find it limiting, because they enjoy being able to go elbow-deep in their OS config.

I know its not the same and would be better to have it officially implemented by Steam, but meanwhile theres an extension you can use for seeing on the web browser (Chrome/Firefox)

@AwesomeLowlander @princessnorah

Secret World Legends
Catherine Classic

Just 2 examples which with default Proton have at least "issues"

 python

    
import sys
import random

inFilePath = sys.argv[1]
outFilePath = sys.argv[2]
damagePercentage = float(sys.argv[3])

with open(inFilePath, "rb") as f:
    d = f.read()

damageTotalCount = int(len(d) * damagePercentage / 100)

print("Damaging "+str(damageTotalCount)+" bytes.")

dList = [ x.to_bytes(1) for x in d ]

for i in range(damageTotalCount):
    pos = random.randint(2000,len(d)-2)
    dList[pos] = random.randint(0,255).to_bytes(1)
    if (i%1000 == 0):
        print(str(i)+"/"+str(damageTotalCount))

d = b"".join(dList)

with open(outFilePath, "wb") as f:
    f.write(d)

  

If you run it, the first argument is the input file, the second one is the output file and the third is the percentage of corrupted bytes to inject.

I did spare the first 2000 bytes in the file to get clear of the file header (corruption on a BMP file header can still cause the whole image to be illegible, and this demonstration was about uncompressed vs compressed data, not about resilience of file headers).

I also just noticed when pasting the script that I don't check for double-corrupting the same bytes. At lower damage rates that's not an issue, but for the 95% example, it's actually 61.3% actual corruption.

Sure, lossy compression is lossy, but that wasn't my point. My point was that data corruption in information-dense formats is more critical than in low-density formats.

To take your example of the vacation photos: If you have a 100 megapixel HDR photo and you lose 100 bytes of data, you will lose a few pixels and you won't even notice the change unless you zoom in quite far.

Compress these pictures down to fit on the floppy from your example (that would be ~73kb per photo), then losing 100 bytes of data will now be very noticeable in the picture, since you just lost ~0.1% of the whole data. Not taking the specifics of compression algorithms into account, you just lost 1 in every 1000 pixels, which is a lot.

High resolution low information density formats allow for quite a lot of damage before it becomes critical.

High information density formats on the other hand are quite vulnerable to critical data loss.

To show what I mean, take this image:

I saved it as BMP and then ran a script over it that replaces 1% of all bytes with a random byte. This is the result:

(I had to convert the result back to jpg to be able to upload it here.)

So even with a total of 99865 bytes replaced with random values, the image of an apple is clearly visible. There are a few small noise spots here and there, but the overall picture is still fine and if you print it as a photo, it's likely that these spots won't even be visible.

As a comparison, I now saved the original image as JPEG and also corrupted 1% of all bytes the same way. This here's the result. Gimp and many other file viewers can't open the file at all any more. Chrome can open it, and it looks like this:

The same happens with audio CDs. Audio CDs use uncompressed "direct" data, just like BMP. Data corruption only affects the data at the point of the corruption. That means, if one bit is unreadable, you probably won't be able to notice at all, and even if 1% of all data on the CD is corrupt, you will likely only notice a slightly elevated noise level, even though 1% data loss is an enormous amount.

If you instead use compressed formats (even FLAC) or if it's actual data and not media, a single illegible bit might destroy the whole file, because each bit of data depends on the information earlier in the file, so if one bit is corrupted, everything after that bit might become unreadable.

That's why your audio CD is still legible far beyond its expiry date, but a CD-R containing your backup data might not.

Again, these data retention time spans don't mean that after that time all data on the device disappears at once, but that until that time every single bit of data on your device is preserved. After that you might start to experience data loss, usually in the form of single bits or bytes failing.

Edit: Just for fun, this is what the BMP looks like with 95% corruption:

Even with this massive amount of damage, the image is still recognizable.

Edit 2: Due to a mistake in the script, this image is actually 61.3% corrupted, not 95%, but that's still a massive amount of corruption and the image is still clearly recognizable.

Have a look at the Linux VR Adventures Wiki for possible VR solutions.

EDIT: And this compatibility site akin to ProtonDB I just found out about.

hate articles like these, when lemmy has everything one needs to trailer the game.

Or for in game cut scene/Media sometimes it is a must: Additional media foundation patches for better video playback support.

Sometimes. It contains fixes for specific games and patches from wine-staging (the newest, testing branch) that are not included in Valve's Proton releases, many of which have a positive impact on performance. The project's overview is the best summary.

... I can't undervolt my card...

People usually use/recommend LACT for undervolting/overlocking on Linux

Not difficult to find, but whatever.

SteamOS, at this point, is not officially supported outside of select hardware (Basically, Steam Deck and other handelds), so while it is prominent and talked about - it may not be the best choice for home PC usage.

As @[email protected] said already: Bazzite is probably the closest equivalent, it also has gaming optimisation, but a more fully-fledged Desktop experience along with it. There are other gaming focused distros (e.g. Garuda, PikaOS) as well, but if you are prone to choice anxiety, just go with Bazzite - and check the others out if you get sucked down the "I want to tinker more with my system and try out more, different Linux flavours" pipeline later.

MacOS stopped supporting 32-bit with Catalina and, according to appleinsider.com, older games won't work on Catalina at all.

It seems like maybe it's a regional thing, as this is from Lenovo AU:

It was already shown that SteamOS is way better in terms of battery performance than Windows. So if Windows uses power saving mode by default, these results are even more damning:

There might be some tweaks to mitigate some of the short comings of Windows, but that doesn't changed that the script has flipped. Before it was Linux that required tweaking and Windows would have a decent out of the box experience. Now SteamOS works great out of the Box while Windows needs tweaks. And at that point there is no reason for sticking with Windows unless your software specifically demands it.

As of right now, both models of the Go S listed on Lenovo's website have 32 GB of RAM (screenshotted below, if the weird screenshot functionality here works). So no, you're wrong here. The version with 16 GB is the Go 1. If there is a 16 gig SKU of the Go S, which there may be, they currently don't have it listed.

Memory size requirements depend on what you're trying to run. Easier to run stuff will run on everything, but from hands-on experience I assure you a bunch of newer games struggle with the default allocation of 4 gigs of VRAM and can use the extra RAM. You can still give 8 gigs to the GPU with 16 but then you're a lot more likely to start struggling with system RAM. If these AMD APUs worked like an Apple chip and could dynamically allocate RAM that wouldn't be such a pain, but at the moment you need a reboot to change this even on current-gen hardware, so it's easier to have a larger pool and give the GPU a little too much.

The amount of CUs and the VRAM aren't necessarily related. Even with larger RAM allocations and weaker GPUs you can find yourself in the wrong setup, which is annoying. And it's not just amount of RAM, these shared architectures can struggle with bandwidth as well, so speed can matter (although it's more giving you more or smoother FPS and the less the fall-off-a-cliff unplayable mess you get if the game is entirely out of RAM budget). That's also why I suspect being lighter on memory and perhaps having a better default setup may be a part of why SteamOS performance is disproportionally better on heavier scenarios compared to what you see on desktop PCs. I can't be sure, though.

This comes from me messing around with a literal handful of PC handhelds on Windows, SteamOS and Bazzite. I'm not guessing, I'm telling you what happened during hands-on testing.