she/her

  • 0 Posts
  • 29 Comments
Joined 3 years ago
cake
Cake day: January 11th, 2022

help-circle
  • (who btw farms montages in low rated btb games)

    Typical, so many of the people who complain about the existence of SBMM in games are people who want to be able to constantly stomp players who are worse than them (when people complain about “not wanting to sweat all the time”, this is pretty much guaranteed to be the actual reason)

    While I don’t doubt that Halo and CoD have flawed matchmaking, people usually use those to say that SBMM as a whole is a bad thing, or even that it’s “ruining gaming”, when it exists for good reasons and benefits a lot of games

    You rarely see people complain about it in fighting games for example, usually when people do it’s because the developers of a given game have designed an original system that does a bad job at actually matching skill, when a typical Elo-style system would’ve worked far better






  • That’s not mentioned in this specific blog post, but that’s always been one of Vanilla OS’s defining features, it’s “apx” package manager to install those various types of packages

    It’s even using Distrobox actually, but the point is to make it simpler to install packages for those contrainers, with the user not worrying as much about managing the individual containers, and not having to memorize the specific commands for each individual distro’s package manager

    Basically, like the rest of Vanilla OS, the point isn’t that you can’t do this stuff elsewhere, it’s that it’s trying to make it easier to do it



  • I have a Steam Deck and I’m happy with it too, but my point is that the game compatibility would just get even worse if you add on having to emulate x86, because it’s not like x86 emulation would be perfect right away, and the amount of native ports will become even smaller than they already are

    Even if the architecture is an improvement, in practice it wouldn’t make any sense right now, and I can’t see an ARM-based Steam Deck or whatever selling nearly as well as the existing x86 ones given the downsides it would present


    1. Seems kinda hand-wavy to me, so I’ll boil this down to lower bloat (i.e. lower disk and mem usage by the OS)

    They pretty clearly say what they mean by that though, unless you only read the headers and not the actual text

    1. This is very much YMMV, and for Steam Deck specifically, it’s comparing a tuned the system to an OOTB experience; surely other handhelds tune their systems too

    They absolutely don’t, is the thing, and the Windows ones largely can’t in the same way that the Deck can, because they can’t change how Windows works beyond the surface, meanwhile Valve is able to write software for Linux like Gamescope, an entire lightweight compositor that lets them have full control over how games are displayed and means they don’t need to have a full desktop environment running, and they directly contribute to and fund development for open source system components (like the KDE Plasma desktop environment that’s used in Desktop Mode) in a way that would be impossible for similar things on Windows

    Valve even has their own custom patched version of the Linux kernel in SteamOS, you can’t do anything remotely like that on Windows

    1. I’m pretty sure this is true for other handhelds, but I haven’t used them personally so I don’t know

    You can’t avoid having using the desktop eventually on Windows on a handheld, and it’s always running the background, even if you boot into Big Picture

    Even if you’re always running games from Big Picture or whatever, you still need to use the desktop for updates, as well as any settings and functionality that can’t be accessed from Big Picture on Windows (like dealing with Bluetooth devices), as opposed to SteamOS where all of it can be handled directly in gaming mode without a desktop even running

    1. This seems very solvable, and not an inherent Windows issue; large enterprises manage drivers and whatnot centrally, surely a handheld can too

    ASUS already has a solution, like the article mentions, but it can’t be nearly as seamless as SteamOS where they can just push a single system update image that includes everything, and it’s applied all in one go directly from gaming mode

    There’s also additional benefits SteamOS can have with its update system that Windows can’t have, like how it has an A/B partition system similar to Android so that a broken update only breaks one partition and it can switch to the other one when that happens, which especially helps if something like a power interruption happens during an update and it doesn’t complete properly (meanwhile on Windows it can be pretty hard to recover from something like that)

    1. Surely this is true for Windows devices, no? I’m guessing more people are comfortable customizing Windows handheld PCs vs the Steam Deck simply because more people are familiar with customizing Windows than Linux

    You absolutely cannot modify Windows nearly as deeply as you can with Linux, and attempting to make any serious changes requires hacky solutions that Microsoft can just break in the next update anyway

    Like, you can change almost every single component of a Linux distro, you can rewrite components directly since they’re open source, and there are usually multiple options to pick from for any given piece of system software, such as the entire desktop environment, or the audio system, or even the kernel itself


  • The idea would be that new games would be compiled natively.

    They won’t even compile games for Linux as it is, and a lot of the ports we do get are awful ones that run significantly worse than the Windows versions do through Proton, so expecting publishers to start putting all their PC games on a different architecture entirely, just for the sake of handhelds like this, is completely unrealistic

    Stuff like Proton (which isn’t emulation in the sense that this would be) has already struggled so much with compatibility over the years to get to where it is now, adding an entire x86 emulation layer on top of that would set things back so far and it would even more of an uphill battle to recover from

    If the goal is to run enough current games well enough, then AMD chips are still doing fine at that, and upcoming generations will likely go a long way to improving that







  • because the package build script isn’t available?

    What are you talking about? Every Flatpak on Flathub has their build manifest available on GitHub, you can fork or download it for yourself and change it how you’d like, just like you can with an Arch PKGBUILD

    And the problem still isn’t solved because now the people who can set bad defaults still exist, they’re just different people.

    For one, unlike with distro packages, lots of Flatpaks are made by the developers of their apps, so bad defaults aren’t really going to be a thing for those since the developer would want to choose what’s best for their own app

    And for packages maintained by a third party, bad defaults are less common because maintainers don’t need to account for each individual distro’s unique package situation or specific dependency versions, and only have to package it once for every distro