The Steam Machines were also equally open, and the (otherwise streaming-focused) Steam Link supported sideloading.

btw to this day it still receives updates!

But, what were people sideloading on it? any alternative usage that might be interesting to explore?

The internet is filled with stories about locked accounts, lost libraries, games being pulled out of the library due to 'low quality of gameplay' while people are actively playing them on Steam, DLC and in-game currency sold that can never be redeemed or used in the game it's bought for (see: 'Wizardry Online' debacle, Steam/Valve continued selling in-game currency far beyond the point that it was being discussed to remove the game from the library all together.. then removed access from the game for Steam users after making a tidy profit. This was a current/active/new game with a bad launch, not an old title.)

So just to re-state: Valve never won my trust with their behavior with Steam and associated acts. There is just no one else; let's call this phenomenon 'Walmart Syndrome', perhaps?

Bypassing Steamworks basic DRM is easy. Other DRMs obviously require special workarounds.

GOG (and CDPR) on the other hand can't even be bothered to port their own client and games.

Also, GOG is not 100% DRM-free anymore, even if they want to advertise themselves that way. [0]

[0] https://www.gog.com/forum/general/drm_on_gog_list_of_singlep...

> GOG (and CDPR) on the other hand can't even be bothered to port their own client and games.

To be fair, I'm pretty sure GOG has a hell of a lot less money than Valve. They don't benefit from any of the gambling-mechanics or multiplayer game "bling" sales that bring in so much of Valve's money, aside from having a much smaller share of PC game sales than Valve does. Valve's got to be way more profitable plus have much higher income, so have the margin to play with stuff like this—which is in their interest, because the weaker alternative operating systems are, the more Valve operates only at the pleasure of Microsoft.

I'm not happy about these features requiring an internet connection, but they seem pretty minor. The alternative would probably have been that those features were left out of the GOG versions completely.

Luckily Lutris allows me to somehow compensate for GOG's lack of interest in Linux, but still, I feel they really do not care about the DRM thing.

https://sharkwouter.github.io/minigalaxy/

It deals with both downloading and installing as well as integrating Wine.

https://github.com/Sude-/lgogdownloader

I only have 12Mbps DSL and an offline game system that I use a FAT formatted microSD card to transfer to so I appreciate the split files, even though it does get annoying with the huge games.

I agree that GOG's Linux support is minimal; often they don't even provide Linux versions that are available on other stores :(.

Two of the isses on the list account42 links to are more serious, although most are fairly minor (there are also a few issues not on the list). Not to excuse those exceptions, however I don't know of any other store that is anywhere close. I have no inside info but my my suspicion is that many CD Projekt investors resent the DRM-free aspect of GOG and would like it to change, while the people running GOG realize it is the major unique aspect of GOG and trying to change it could sink the business. OTOH, I suspect the CD Projekt investors mostly see GOG as a way to get a better deal from Steam for CDPR games. Hard to say what will happen in the future.

This is also how we used to install and play games on Windows, before the Steam era.

Why do I need Galaxy?

Itch.io has a Linux client, by the way.

I disagree that they "should" have a Linux client, for the reasons I explained. I don't have a use for such a client, and as such, I'm happy to ignore it (and love that it isn't mandatory, unlike Steam).

I've never received support from Steam for any technical issue. I'm resourceful and if there's a way, I'll make it work; but almost every help I needed with Steam games was taken from user's forums, within and outside Steam.

Case in point: I learned browsing Steam's forums that the Linux version of The Eternal Castle is glitchy and in many cases the keyboard input doesn't work at all; one user helpfully suggested just using the Windows version using Wine or Proton; this suggestion worked.

> Itch.io has a Linux client, by the way

Good for them! I hope it's optional, since I've no use for it.

What I love about Humble Bundle and GOG is that their games (mostly) don't try to take over your games collection, unlike Steam. I do use Steam and support Valve, but I'd prefer Steam was optional.

I mean, all they had to do is let users disable automatic updates and keep running the old version of the client "without any guarantees" -- if the Steam APIs end up changing enough that I can't log in anymore, well, so be it. But to permanently lock users out simply because of a forced update… seriously uncool.

Now that the store had that facelift the only issue I am aware of is the honestly pretty lacklustre curation... Which is an extremely hard issue so pretty forgiveable

But hey, you can instead distribute with Epic, a storefront so advanced it doesn't even have a shopping cart.

[0] not to mention community forum, reviews, and art gallery.

I understand the sentiment though.

Which is kind of odd, since the Unreal Marketplace in the same launcher does have a shopping cart.

There is no good justification for this restriction and it makes that whole feature sound more like a PR move than something that was really released to help the consumer.

Good to know, then devs can sell their games somewhere else? Oh, I guess they don't. Nevermind.

Rather the opposite. I think it ended up as part of several compute clusters because the console was sold for less than it cost to produce, something normally offset by game sales. So suddenly Sony had a large market that only cost it money.

I'm sure internally it was pitched as a neat idea why don't we see what happens (god can you imagine the corporate politics in a decision like that?), but practically it allowed Sony get get special import status.

I'm sure eventually they realized they didn't care about that enough it outweigh allowing those filthy users to possibly do something interesting.

Sony throws a lot of stuff at the wall. There was a good chunk of hardware cut out of later PS3s, not to mention continued attempts and silent canceling of things like those move lightguns, etc.

The major use case for these was for number crunching (training neural nets, running physics simulations, etc). And these things were something crazy, like 100x faster than a similarly priced PC server. There were plenty of libraries out there for doing linear algebra.

A quick google search suggests that this was extraordinarily common in academia. I found materials from lots of different universities that were close to what I remember my peers talking about.

This was also a little bit before CUDA hit. So there really wasn't a mainstream offering for doing massively parallel, SIMD calculations.

Edit: I went to Wright State Uni and most of my CS professors did research associated with the Air Force, which as forgotpwd16 notes, had at the time a super computer made from PS3s. This might explain why the PS3 was so popular among our department.

Wasn't more an issue that games didn't specifically optimize for cell processors? They had to run on dozens of platforms and the Cell processor was the odd one out.

> to get useful compute out of it during the length of time that option was arounnd.

There were at least three largish cluster setups, the biggest being a super computer with almost 2000 PS3s. Of course you are right, that is barely a blip on their sales.

https://en.wikipedia.org/wiki/PlayStation_3_cluster

That’s what being exotic hardware means.

[0]: https://www.wpafb.af.mil/News/Article-Display/Article/399987...

I think it's an urban legend fueled by marketing, I've never seen any hard proof of that, except some BOM calculations from independant analyse, but I don't think mass production work that way.

https://www.theregister.com/2010/01/25/playstation_cracked_w...

https://tedium.co/2020/11/27/sony-linux-otheros-geohot-histo...

It's arguable giving hackers a platform to explore the innards of the PS3 was the biggest contribution Other OS made to the PS3, and I'm not surprised it scared Sony management. In the release notes for the PS3 firmware update that removes "Other OS", Sony also state it was for "security concerns":

https://blog.playstation.com/2010/03/28/ps3-firmware-v3-21-u...

"...will disable the “Install Other OS” feature that was available on the PS3 systems prior to the current slimmer models, launched in September 2009. This feature enabled users to install an operating system, but due to security concerns, Sony Computer Entertainment will remove the functionality through the 3.21 system software update."

The "security concerns" were of course geohot/others using it to crack the PS3 DRM.

[1] https://arstechnica.com/gaming/2006/11/8239/

You can’t run physics simulations on single precision. So the people who would have bought and tinkered and pushed it forwards were all turned off by it.

The military was allowed double precision; but there was no point making it a compute cluster otherwise.

I don’t know if it was a marketing or budget decision but basically all the early adopters who would have championed doing impressive things on there (I was so hyped at the time for the cell architecture) couldn’t do anything useful with it.

I recall I was very excited at the prospect of getting my hands on a ps3 for modelling, but all my work (1) at least required double precision and it left a long bad taste in my mouth when it wasn’t to be.

(1)chaotic plasmas

Hopefully this eventually results in more user friendly Arch Linux installers. The learning curve is an absolute wall when installing, even after several years on Linux, but after that it's pretty standard.

Based on this trajectory I expect they'll be migrating to NixOS (or maybe Nix on Arch) in about 5-10 years.

Canonical doesn't have any reason to be friendly towards the specific features Valve needs to make SteamOS a thing, and Valve probably doesn't want to maintain their own fork of the entire Ubuntu distro.

Not to mention, a default install of Arch is tiny and minimalist. It's the perfect base to apply your own packages on top of without having to worry too much about conflicts with system packages, or anything else that might break between Ubuntu LTS version updates.

It means Valve can mostly have their own custom distro without having to do most of the work required to maintain a custom distro.

It also means Valve can deploy the latest package of something that boosts gaming performance (like some new graphics driver or whatever), again, without jeopardizing the core os. Arch is well known for being "bleeding edge" and getting the latest packages out immediately which is something gamers (the target audience for SteamOS) want (every single extra FPS matters, etc).

SteamOS was based on Debian directly, not Ubuntu. Ubuntu is just what they officially support for the desktop Steam client.

I wonder if they considered alpine? Though arch is a fine choice and makes me want one all the more!

I'm not sure how ready Valve would be to require not only their own game distribution mechamisms but a whole package manager, but Nix + NixGL would be a very reliable and low-overhead way to get cross-platform support and to make it easy for games that might depend on extra libraries or specific versions of them.

Pretty sure it won't. I bet it's going to use a self-made system upgrade facility and not rely directly on pacman either.

pacman is great for its intended use-cases, but it's not a package manager you want to use with no supervision of an experienced user. It may even silently leave a package in broken state just because the rootfs went full during the upgrade.

And at the very least, pretty sure they're not going to use actual Arch system repos but roll their own.

You can nail down a new release on your local hardware using a bash script that calls pacman against specific packages and specific package versions. Once your local dev works, push that to the update tool. Hopefully you caught all the bugs. :)

For the system data, which could be immutable, they could either take an A/B approach with two different partitions, or perhaps use either btrfs or ZFS to allow the new version to be applied over the old version as a 'diff' of the system partition. On a failed update, or to rollback for any other reason the system partition would simply be rolled back to the last snapshot.

https://manjaro.org/download/

It's more than an installer. Manjaro and Arch don't even share repositories.

https://github.com/archlinux/archinstall

Manjaro Live OS can't be used to install vanilla Arch. Manjaro uses its own package repositories that differ significantly from the Arch repos, in terms of versions (which are held back for at least a couple of weeks) and in terms of which packages are available (quite a few AUR packages are present in the Manjaro's repositories).

Only recommend using them for subsequent installations. You have to get the basics right first, so you can troubleshoot anything in the arch forums

It is very, very promising. It spits a JSON that can be used for reproducible installs. It is also very flexible in which you can use the API with custom python install scripts. Very impressive and ergonomic.

I would call that stagnant rather than stable. If a version of software remains the same with the same bugs/issues not getting resolved, that seems unstable to me. Yes, not crashing could also be considered stable as well.

In Stable (what you call Stagnant) vulns get backported. Only the code fixing the vulnerability gets updated, the rest is left untouched. Its how Apple deals with older iOS versions, and it keeps their happy users of older devices happy.

If I run some old piece of hardware/software, there are a few things I want: I want it to keep functioning the way I bought it, and I want it to remain secure and reliable. So what I want is security and reliability fixes ie. what Debian Stable (and e.g. Ubuntu LTS) receives.

This isn’t always possible. And sometimes creates more problems than it solves or ends up not mitigating the issue completely.

In any case, backporting is a slower process. And back ports for non-stable are not done by the security team but volunteers.

....what. That is not how OS stability works.

Also, Arch is nearly impossible to use in production environments.

Let's say there is a vulnerability discovered in the version of lighttpd you're running in your production environment. On Debian, you pull that package, do some testing, and you're done.

On Arch? It's a rolling release distro. They're continuously updating everything, including system libraries. You can easily end up in a situation where getting a security bugfix means you have to update nearly the entire OS thanks to it being built against updated core system libraries.

Like Gentoo it's one of those OSs that is cool for linux nerds and a headache for people who actually need to practice proper systems engineering.

Its a falsehood pushed by old 80's thinking. It sounds nice, in theory.

In practice, what you often get are bugfix patches blindly applied to older codebases, oftentimes by people (distro maintainers) who are not very familiar with the codebase. As long as the patch applies, and it passes various tests.

Remember, most OSS projects - including some critical ones - do not have large teams of devs able to maintain multiple codelines in tandem. Usually, the dev(s) just work on the latest, and pay only cursory attention to applying security bugfixes to older versions.

After all, how is an OSS dev for proj X meant to know (or even give a damn for) which distro arbitrarily decided which older version is somehow the SECURE and BLESSED one.

The dev in question probably moved on from that version months (and in regard to Debian, probably YEARS) ago.

So in theory, what you said sounds right. In practice, no.

Seen it done and participated.

I've also known a couple shops that run Gentoo as their distribution. Usually a central binary package host / build machine which makes it very easy to have a set of staging hosts. Just test package releases like normal before migrating them to prod.

People have used Arch in prod. But personally I'll still use Debian to be on the safe side despite all of the issues that comes with.

[0] https://wiki.archlinux.org/title/System_maintenance#Partial_...

But sure, just yoloing a single package upgrade can break things, obviously.

Fear not. As GKE is running on Container-Optimized OS which is based on Chromium OS which itself is based on Gentoo, you can safely practice proper systems engineering within the container environment :)

I'm surprised, I found it very easy to get into Arch linux. But I came from distributions like Slackware & Gentoo where it was common to do the installation almost entirely from commands in the terminal.

IMO distributions that keep the installation primarily command-line focused are a good way for beginners to get started, it gives them a real grasp of how linux works, and how to change things to suit.

1/ You can search for stuff on the internet and get quick results (not a video) 2/ You can _paste_ a command and send it to someone to run it instead of a word document with instructions and screenshots. 3/ Once you learn to find and search for stuff in files, it is easy to discover where stuff is configured. 4/ Manual pages are great once you know how to read (I mean skim) them.

Thanks for playing games on NixOS!

https://nix.dev/tutorials/cross-compilation#cross-compilatio... for an approachable introduction.

Currently we just support Unix -> Windows via MinGW. That's not good enough for AAA games.

But in the works is:

- https://github.com/NixOS/nixpkgs/pull/72366 Windows cross via LLVM and auto-downloaded MSVC runtime (you do need to indicate you signed the license, but that's it). I've heard of running cl.exe in Wine, and we could do that too

- https://github.com/nix-windows/nix Windows port of Nix

We finish these things up, and then we have the flawless Unix <-> Windows I advertised.

However, https://github.com/NixOS/nix/pull/3160 to switch to Meson, has gotten new life breathed into it. Pamplemousse, who is interning where Edolstra works, is fuzzing Nix and needs Meson to make that less burdensome.

If that does get merged, than nix-windows can just be about Windows and not also be about Nix's build system, which will make it a lot easier to finish.

Still, I think Arch is an interesting choice for a console. I'd think you'd want stability (in the sense of very controlled changes / not requiring updates every day).

I have been using Archlinux for more than 10 years and from time to time some major upgrades can make things broken for a couple days until all the packages get updated and all the relevant compatibility fixes have been pushed upstream by the developers. But in most cases this happens with some 3rd party desktop related packages or closed source drivers. I bet that Valve won't have that many problems with AMD since their drivers are open source.

Or just use packages and make regular snapshots.

I bet that the underlying distribution doesn't matter much at all, and since this console is meant to also be a desktop (or living room) PC, might as well ship with a distribution that's good for that purpose. Arch makes more sense for desktops than Ubuntu, and has for a while tbh.

What are you precisely referring to with "packages drift from each other"? Stable distros like Ubuntu (and I suppose Debian) don't do release updates at all, only critical/security fixes only. Only some software has special treatment (browsers first of all) and get full updates.

Funny you say that! Arch images now ship with an official installer as of a couple of months ago - which is comparable to the Ubuntu or Fedora installers in ease-of-use.

https://github.com/archlinux/archinstall

- Able to connect to WiFi from within the installer.

- Full-disk encryption setup, ideally with a single checkbox like Ubuntu.

- Interactive partitioning.

- Auto-detects or allows choosing between BIOS/UEFI.

- Supports creating a NetworkManager-based network setup, so that I don't have to switch network managers after installation.

However I do welcome an installer, it's fun to install Arch a couple of times, but after that I'm not really learning anything new.

Thus your expression "an absolute wall" would mean that you immediately grasp everything there is to know.

But since the meaning since has unintentionally shifted and the original meaning is universally ignored, we all understand you.

I've tried both, Arch Linux will routinely hose your entire install if you don't carefully read the update notes every time (even if most of the time there is no call to action for you). Unless it has changed, this is still the expectation of users.

NixOS promises stability, you just walk back to a previous version! Alas, i've had NixOS hose _all_ of my previous versions because of X server issues. Not only that, but the community of NixOS is hostile to getting shit done, if its not the NixOS way please stay away,

I'm honestly not quite sure what you're talking about. I've been using Arch as my daily driver for maybe 5 or 6 years, and I don't recall ever having my installation messed up from an update. Arch is fair bit along the spectrum of being a "build your own system from the ground up" type of deal though (although not quite as far along as something like Gentoo), so I don't doubt your experience, given how much two Arch installations can differ.

But one of those was a big compatibility breaking one that I hadn't done the prep for (because I'd missed the whole lead up for various reasons and was months late on the update anyway) and I still can't really explain the other.

Compared to Debian which I managed to break many times in the same time frame...

How did you exactly break Debian multiple times?

I've read about people doing crazy stuff, like replacing the default compiler entirely (rather than setting an alternative one) or forcing apt to install incompatible packages... and then complaining that the distribution is not stable.

Non-rolling distros are very very conservative with package upgrades, and they don't "just break", as little changes over a given version.

Alas, I can't remember exactly what happened but it was the late 1990s/early 2000s - no crazy stuff involved, just things getting confused / crashing whilst doing updates and leaving things half-arsed and broken.

I'd love to hear more detail about this, because `nixos-rebuild switch` is not capable of causing such a problem in a permanent way.

(It can arise temporarily, though, if you switch to a new configuration without rebooting, and that configuration requires a different kernel than you are currently running. Rebooting and choosing your old configuration at the bootloader menu fixes this.)

Yes, Arch requires you manage and maintain your system, it's not a "just works" thing, but that's a few minutes of work here and there, it mostly just chugs along.

As to hosing your install, I've never had even the threat of that. Yes, you should check the news before doing upgrades to make sure there isn't something that requires your attention, but it's not exactly a big deal to check an RSS feed before you run an update command.

I started using Arch back in 2011 and Manjaro (Arch-based) in 2018. Besides a day or two of initial setup, getting things how I like, I spend ZERO time tweaking or fixing my installation. Your warning simply does not match up with my experience.

I also have a Pi2 running Arch ARM at my mom's house, doing one or two updates per year when I visit her, also failed only once, and that's because of a corrupted SD card.

I'd admit I'm usually a bit nervous typing pacman -Syu on those two, but it's doing surprisingly great.

However, I stopped using arch mainly because I was working with ROS at the time, where every boost upgrade triggered half-a-day recompilation of ROS and it's various plugins.

NixOS is more sane because it has roll backs, and declarative configuration is like a gigantic black hole eating everything which was known before it.

I've had the same problem on Arch Linux on my desktop. To be fair, I was using AUR, but without that there's far less software (less than Ubuntu I suppose). So what I did was trying out Arch Linux on a separate NVMe during some free time, learning some specific tools (it also has NixOS installed on another partition for the same purpose). I come back after a while, want to update my OS first because that is the first thing I do when I use any computer. What ya know? Boom, dependency issues. I really do not want to deal with that before I can use a tool. And every time I bring this up I get these replies "I never have issues with Arch". Sure thing, I must be special.

Look, I ran Debian Testing and Unstable for a while before Arch was cool (1999 - 2003 era). That way I could run Linux with tools such as a decent package manager, while running recent software. But this was a different time, and not mission critical computers.

I would recommend following the wiki and installing Arch Linux (I know, no UI) over Manjaro to have a true Arch experience.

That said, AUR is the reason I use arch linux, because there are scripts to install pretty much anything in a frictionless way.

When installing esoteric stuff the dpkg / apt repositories dance gets old pretty quickly on debian derivates. Often I would just install things on the system instead of creating my own deb. On Arch Linux I can often find a package in AUR (or quickly write a PKGBUILD).

Upgrading the system every few months and breaking a lot of things all at once (making a reinstall the easiest option) is also not very appealing in my book. I prefer the rolling release model which gives me the latest update immediately and let me fix things once at a time.

That said, anyone has its own preferences, no need to bad mouth distros.

Not really, unless you did everything with a GUI in other distros before and refused to learn anything about the underlying guts of the OS.

Sounds like a scary arms-race, though. At some point the bots will probably be very hard to distinguish from "skilled human."

It will be sad if online play becomes only enjoyable with people you already know. I'm surprised how gleeful some people seem to be about this sort of "soon cheating will be undectable!" tech advancement.

Or you just go all-in on the surveillance path and there are models that look at your performance in the game over time, your performance in other games over time, etc. Mediocre player suddenly amazing? Probably a cheater! etc... Not great sounding privacy-wise, but Steam probably has access to the data to do this.

The YOLO stuff combined with softaim is going to be pretty hard to detect. The game can't tell if your video is going into the cheating device. Even if it can tell if there's a secondary input coming in for the trigger... people could just mod their mouse to take external input for the button. Someone pathetic enough to cheat absolutely would do this.

I honestly don't know how multiplayer will even work in a year's time or maybe even less!

It's easy, IMO: remove the incentives for cheating. If this is the only way forward, I might be more likely to actually participate in the industry, because it'll put the focus back on intrinsically-fun games, instead of treating games as merely a vehicle for chasing status/rankings/items/etc.

I stopped playing most modern games because they stopped being intrinsically fun. I'd like to enjoy them again.

The way to defeat cheating is giving users exaustive options to watch and monitor other players and report them effectively. Half the damn games dont even have this sorted out.

You have a report system that weights users honesty based on usefulness of previous reports - so people.who just report good players get downweighted and their reports count for less, then its just a statistics exercise. Combine this with easily identifiable data for things like headshot % to help highlight players for closer review.

You know, the Steam Deck might be good for that.

I bet at some point in the next 20 years we will all have much more important concerns than anything related to gaming.

Only in the "do these movement patterns appear human-like or not" sense. These aim bots can use assistive devices to input mouse movements and there's no way to tell whether or not there's a human hand moving the mouse.

As far as performance improvements, oh it's going to make the cheat programmers even more money as they implement a skill ramp up period and get to charge more.

The only way in which I'm "gleeful" is that it might finally put an end to the spyware when we realize that controlling someone else's computer is a losing proposition. Otherwise yeah it does suck.

Already long since passed that point for me quite a couple few years back.

Thankfully, it's not that hard to build up a little circle of gamer friends who are fun to play with these days. The messaging options alone currently available are many and featureful, making it dead easy to gather a little group and keep in contact with them to organize a game session any ol' time.

For me this has always been the case. I've felt the same since the days of Kali. There's enough jagoffs running around in games to spoil playing with the normal people. To the jagoffs, they're playing the metagame of cheats/trolling and the game itself is incidental.

Or a GAN

They are using deep learning to detect hackers, since 2018

Random drivers are just too stupid/reckless.

You're thinking of wallhacks or wallhacks+aimbot

Aimbots only aim at things you can see, it's one of their main features. That way you won't snap into someone's head through a wall which would make everyone know you're hacking and get you banned.

Also yes these were invented a long time ago because people got caught snapping through the wall when CS servers started recording demos.

Thanks to latency & the realities of the internet, the server has to bias towards sending data the client can't strictly see/hear at that exact moment, but potentially _could_ see if they move. Which is enough to give a wallhacker a meaningful advantage still.

But what you can't do anymore is see where all the enemies are going at the start of the round and run to the weaker part of the map or whatever. So reduced effectiveness, but still a thing.

BRB I'm gonna ask for VC funding (just joking)

I dunno … Mebbe you should run do that right now, before someone else does … Get that price down by around half and most every gamer everywhere can afford your shiny new "modern game genie"; Once everyone can cheat, the original cheaters have nowhere left to hide. They're on even footing with everyone else.

Cheater problem solved! ;)

The bigger issue, and I believe the primary reason for the rise in popularity of these bots, is when your performance does 'earn' you something. As the OP was speaking of TF2, this comes in the form of hats and custom weapons. Today's counterstrike game has weapon skins and knifes that go for pretty extreme real world dollars.

Almost every modern shooter has some sort of rank up system tied to rewards. Some of the worst examples would be PUBG's real world money trading of loot box items or Diablo 3's real world money auction house.

In my mind, these kind of systems turn video games meant for enjoyment into some weird NFT mining system where normal players are manually mining them with pen and paper while the bots have built ASIC devices.

In cases where the items themselves cannot be sold, you have people selling the whole accounts. There are entire middlemen businesses set up around this stuff. It's crazy but there is your primary driver for incentive.

I don't know about TF2, but for CSGO weapon skins & knives (and all drops) never come from gameplay wins. So there's no motivation at all to cheat for any monetary-related reason. Botting was a thing to farm for drops, but those literally just joined a server and spun in place to avoid being AFK kicked - that's it.

So CSGO cheating is purely about the human interaction components (eg, feeling good about winning, taking pleasure in making people angry, the thrill of getting away with it, etc...)

On the other hand, PUBG does have Battle Point rewards linked to performance. And there it is very common. Almost guaranteed to see a cheater every 10 matches or so. And there was an easy means to sell those rewards. Contrast that against Sea of Thieves. A game specifically about PvP and stealing loot from other players. I don't know that I have ever encountered a cheater there. But there is very little incentive to do so. There just isn't many vectors to turn virtual work into real world profit.

Seems to me that the lower the barrier of entry together with the higher the real world value of the rewards\drops gives you a clear scale of the cheat potential\incentive\effort. I think there will always be a small percentage of those doing it for the LULZ. You can combat that by raising the barrier to entry. F2P games seem to have a higher rate of these types.

When the reward system cultivates an environment ripe for abuse, it moves from occasionally annoying to game killing epidemic.

They can buy players /cheat to farm, then sell the virtual goods over to those with USD; with healthy discount as profit for the other end. Thereby transfering their asset out of China.

Though the FAQ says the following, so it might not be quite as bad as I feared:

> We recommend using user-space anti-cheat components for best results, as they can typically run in the Wine environment and provide the same level of functionality. Kernel-space solutions are not currently supported and are not recommended.

https://github.com/ufrisk/pcileech/blob/master/readme.md#har...

> I find it really difficult to see the value proposition for anti-cheat companies in spending time developing that functionality.

Let's say 1% of the population cheats. Maybe that's high (or low, but I could easily see 1% of the real world population having less than stellar morals w.r.t. cheating). So you play an online game with 20 people in it. That means on average one out of every 5 games there is a cheater in it.

That ruins the experience for you (and everyone in it). Not to mention now because there are so many legit cheaters, people start mistaking really talented players of cheating. Accusing them, starting back and forth arguments online which worsens the experience even if they're not cheating. This adds to the frequency of assumed cheating. Then one of those 20 people decides the way they'll fix it is they'll download a cheat a next time someone on the other team cheats then they'll start cheating too. And so they do, but sometimes they do it when someone is actually just good an not cheating and so they worsen the game.

Overall if you're a company, trying to run an online game you need a positive environment where people will want to return to play. Cheaters very quickly ruin the trust in a game, and that leads to real financial impact.

Modern cheats essentially can give a player inhuman reflexes. "See, aim, shoot" all mechanized, or even "see, dodge, aim, shoot". Some of them even use sound to locate other players, so it's "hear, dodge, turn, see, aim, shoot".

The cost of of infrastructure to reliably detect that on the server across thousands of players is a lot more than running some cheap process on the user's machine to look for other strange things going on (why does the user have two mice and only uses one to shoot?).

Valve is already using machine learning to analyze player mouse movements across all games to look for "inhuman" patterns and send those directly to the community-staffed manual review process called overwatch.

Specfiically, at about 7:50 into this, he talks about the propensity of encountering cheaters in CS:GO. The tl;dr is that in a 5v5 multiplayer game the percentage of cheaters required to ruin 9 other players' games at once is not high. It only takes 7% of people to cheater to encounter 1 every 2nd game, and a 2% cheating rate gets you a 20% cheater-encounter rate.

I'd also touch on the point that cheating ruins an online-only game. Like, it is the #1 way a game falls apart.

Take a look at a game like Escape from Tarkov, where a cheater will ruin a good block of time for a lot of people just by existing in one game. It's especially bad in that game because the distinction between 'being caught by someone in a position you didn't check' and 'being killed by a cheater' is so unclear, and the consequences of losing are so high (and thus losing to a cheater is so much worse). It creates an environment where the players have to be absolutely 100% confident cheating doesn't exist, or it will very quickly sour people to the game.

If this wasn't the case, and the server wouldn't send player positions until they were actually visible, players would pop out of thin air when turning corners or crossing doorways.

This leads to a different kind of disadvantage called "peeker's advantage", where the peeking player shows up later at the peeked player's screen... but this is generally accepted as a tradeoff. Players like their object persistence apparently :)

Latency isn't getting any better soon, and there will always be an impassable limit on link latency due to distance.

>Cheaters use wallhacks to see opponents through walls. In a tactical shooter like VALORANT, this gives them huge advantages when it comes to individual combat encounters as well as strategic decisions for the round as a whole. Wallhacks are especially insidious because they give an advantage that isn’t always obvious - your enemies could be using wallhacks... or maybe they’ve just figured out that you rush B every round. We really wanted to prevent that sense of doubt which lingers with players, poisoning their experiences long after the match.

>At the beginning of development, when we were talking about security goals for the project, the two things that came up over and over again were wallhacks and aimbots.

>League’s Fog of War system works because the game server withholds information about the positions of enemies until a client needs to display it. I knew if I could implement something like this for VALORANT we could solve the problem of wallhacks because there would be nothing for the wallhack to see. If an opponent was behind a wall, we wouldn’t send their location to enemy players, keeping them hidden until they decided to peek the angle. If we could pull it off, this seemed like the ideal solution - but we had no idea whether this would be feasible in Unreal Engine.

E.g. rocket league or online chess. No need to hide anything. Can't have wallhacks if there are no walls.

Also some types of cheats such as wall hacks can only be detected client side.

https://www.youtube.com/watch?v=o8apCPN56PU

https://www.youtube.com/watch?v=B35XhcmBDDI

https://www.youtube.com/c/Collabora/videos

They should design their games such that the client is not trusted, and then the only possible cheats would be UI/AI assistants to the human players, which is not really cheating.

Gamestreaming (Stadia etc) shows that this absolutely is possible. It might not be feasible due to players on bad connections and hardware cost (in fact, the reason that games do so few checks serverside is hardware cost), but it's not something impossible anymore.

> I can't even think of a way that things like aimbots could be prevented server-side; it's hard enough just to detect them.

Pattern detection can, things like following enemy movements through walls or extreme precision. I agree that it's easier to check for running software on the client, but this is error prone as well and can also be defeated by a sophisticated enough hacker.

That's a fair point, and maybe we're closer than I think, but I don't think that fully-streamed games demonstrate that we're there yet. At the risk of sounding too elitist, those games aren't "hardcore". The things that streamed game players expect and will put up with are a far cry from the things that hardcore gamers expect.

A serious Counter-Strike player wants things to operate as close to the limits of human reaction time as possible. People can typically react (as in press a button) in response to visual stimuli in something like 150ms, and to audio stimuli in something like 50ms (I don't have good links for these, so don't hold me to the numbers; there are studies out there).

While this may seem like it's slow enough that processing and network delays don't matter too much, when you add those in, you're well into the territory of perceptable delays. Advanced/pro gamers (especially younger ones) are even faster. I don't know that it's possible for fully server-side systems to compensate for this. Anecdotally, I can't tell the difference between 20ms and 70ms latency while gaming (at least not now that I'm old), but I can tell the difference between 20ms and 120ms. If everything had to happen server side, I think it'd be noticeable.

I fully agree with you that game streaming platforms, as of now, are not usable for pro FPS players (or any players where tens of ms of latency are important). You're not elitist, that is the truth of it :-) But, if a developer would really want to, there would be options:

1. You could go for datacenters in all major cities. With this, you could probably get <10ms roundtrips for a lot of people. It would still be bad compared to local, but if you control the stack, you could easily get those ms back on other fronts. Bad keyboards and mice, for example, might add a lot of latency. Same for USB hubs and non-gaming monitors. If you supply your own optimized hardware you can easily save quite a few ms compared to a "normal" setup to counter out the network latency.

2. Stadia is the concept driven to its maximum - the client is just a video player, everything is done server-side. For cheat safety, this is actually not necessary - by just sending render instructions (i.e. which object is where), you can let the client do the actual rendering, with only culling being done server side. This would not only reduce the server hardware requirements, but also drastically reduce the required bandwidth (especially at 4K) and latency (since you can skip video en-/decoding and a bit of compression). If cheat safety is the only goal (instead of not requiring hardware, which game streaming optimizes for) this would probably be a superior solution.

Stadia (and NVidia Now and the other ones) prove that the technology is close enough that this would be doable, even though they themself optimize towards other things. However, the reality of it is that this would cost an insane amount of money and still not catch everyone [0]. Cheaters do cost games something, but as long as there are reasonably few (and they're kept out of tournaments), it's fine with developers. This is far cheaper to do with client side anti-cheat right now. So you are probably even right with the prediction that we won't see this for a long time - it's just not for a technological reason.

[0] You could do [Game Console of Choice] -> HDCP Stripper -> Cheat-PC w/ HDMI capture card -> Faked gaming mouse/keyboard via USB host -> [Game Console]. This setup works with everything available on the market right now and is virtually undetectable on the client and the server, at least without analyzing user behavior.

Aimhacking is still fully possible on Stadia. You have the problem here of even if the client only has visibility into what they strictly should, machine reaction time & precision is vastly superior to humans. So aimhacks will always be viable, regardless of how little the client is trusted.

That's why I specifically quoted the part about the server being able to specify what is rendered client-side - this part is possible via game streaming.

> So aimhacks will always be viable, regardless of how little the client is trusted.

Fully agreed. In the end, the platform can only do pattern detection, but this is really, really hard to do. LAN tournaments where the hardware is fully controlled is really the only option where one can be reasonably sure that no cheating is going on, but it has happened even in these circumstances.

You can't make the client untrusted to the point of "I don't trust that the human really pushed the button" or you don't have a useful multiplayer mode anymore. Cheaters are truly ruining everything, here.

Like so many seemingly intractable moderation problems maybe this is why we shouldn't scale to infinity. YouTube is literally too big to moderate. Maybe this is a feature of humanity. What's wrong with more, smaller communities that have a dang to keep everyone in line? Other than the unfortunate lack of dangs in the world.

Back in my day CS servers were mostly privately run. If you were caught cheating you got banned. If you appeared to be cheating (you were too good) you also got banned. From the perspective of the players on the server those are the same thing. Communities formed on servers with similar skill levels and recognized players. Cheating in that kind of environment becomes extremely risky from a social perspective. You could piss off your actual friends.

There wasn't a need for rank-based matchmaking or anti-cheat or anything like that, you just eventually found a place you fit in and could have fun. Valve tried to replace that with algorithms but maybe they should "crowd source" so to speak, like we did 20 years ago.

This is all a lot of words to say that there is a "right size" for a community to form and enable everyone to have a good time. When you get to the point that "technology can't help us" I think that's an indicator that your community is too big.

They're doing that too.

https://blog.counter-strike.net/index.php/overwatch/

Fortunately, most cheaters don't know how or are not trying that hard to hide, and are identified by pattern recognition. It's not that big a problem in practice. It's still universally considered cheating.

A Linux distribution like Ubuntu, Arch or Gentoo provides a platform for users to configure their system. The distro is a toolkit for finishing up a generic OS into the specific workstation needed by the user to do their work.

Steam Deck on the other hand has one job to do: launch /opt/steam and run things linked against libsteam. The end user won’t be doing anything with the OS itself.

Accordingly, the underlying distro just doesn’t seem that interesting. What about the distro could possibly be surfaced to the end user/gamer that they would care about?

It’s not like Steam will apt dist-upgrade their device: upgrades will be a complete reimage.

What makes you think so? The desktop environment will be powered by KDE Plasma.

>Accordingly, the underlying distro just doesn’t seem that interesting.

Valve is pretty clear that in addition to having a gaming mode they want the device to be a full-fledged (linux-based) PC.. hopefully with everything that entails.

>What about the distro could possibly be surfaced to the end user/gamer that they would care about?

Maybe nothing in "gaming mode," but in "desktop mode", it's Arch running KDE Plasma. It's essentially a Linux-based PC with a gaming option. (Or vice-versa, depending on your primary use case and point-of-view.)

Given the fact that the desktop mode exists and is leaned on as an important feature, I'd assume a lot of underlying functionality will be exposed.

>It’s not like Steam will apt dist-upgrade their device: upgrades will be a complete reimage.

I too am interested to see how they will handle this, but based on their website copy I would not be surprised if you could at least apt-get upgrade the desktop portion, with the gaming mode running either on top or separate from it.

Ubuntu is good as a stable platform, but it's probably too slow moving.

If you upgrade often and you break stuff people will scream at you, so you need extensive testing of 3rd party games before you release an update of your os, which will naturally limit you anyway.

As far as why Arch, I think it’s a great “build your Linux OS” distribution that gives you a solid foundation to expand into the bespoke system of your dreams. On my desktop, I have a personalized computing experience using Wayland + Sway, PipeWire and only the software I use. That same DIY principle makes Arch a compelling option for anyone looking to build their own distro; Manjaro is one such example and it’s the distro I used before making the full dive into Arch.

You should be able to accomplish the same thing by using your own pacman repos with compiled binaries that have the right USE flags. They all have the same hardware after all.

Anyway, from my own experience, the video decoding performance of gentoo-on-rpi-64bit was somehow nowhere close to LibreELEC, on the same hardware. Perhaps there is a lesson to be learnt there...

With PC games, at least in my humble experience, you pretty much always need the latest drivers to run things well (especially so on Linux). With AAA games you will likely need to download several different driver updates within the first month to make it play reasonably well.

My understanding of Arch, is that it's more focused on providing systems which are more up-to-date/current than strictly "stable." [1] This is a pretty big advantage for Valve/Steam/Gamers since its less likely they'll be stuck having to back-port a sea of changes to a dying, but stable, LTS version. Instead they'll be on a platform with a community that prioritizes it. In all honesty, it'll probably make for a more reliable/stable gaming experience since patches will be easier/quicker to ship.

[1] Just to note, I'm not saying Arch is unstable in case someone reads it as that. I honestly was thinking of giving it a go this weekend (currently on a Debian based system), and this is probably the kick I needed to do it.

Steam (via Proton, mostly) already does a lot of development work, and it doesn't care which distro it's on. "Oh no, I updated my kernel and now my graphics drivers don't load at all!" is incredibly common, even with DKMS. Sometimes (mostly) bugs get fixed in Mesa or whatever. Often, new subtle bugs are introduced when a new Wayland/Pipewire/whatever feature goes GA. Having as few moving pieces as possible (by using an LTS distro, or at least something which isn't rolling with upstream and has a modicum of QA) lets you optimize the pieces you need to without worrying that this or that API is going to change underneath you.

Intel and AMD drivers do not have this issue, and Valve was smart enough to not go with NVIDIA, but "I want to be up to date" is a terrible experience.

Additionally, it generally makes for a much less reliable/stable experience (gaming or otherwise) because `pacman -Syu` may at any point break something because you didn't read the release notes, or "mostly" stable features were committed upstream then released so the userbase can put them through their paces and report bugs the developers didn't encounter.

Users of Arch/Fedora Rawhide/whatever accept this, but someone who buys an OEM gaming machine does not need or want this.

Just to note, I AM saying that Arch is unstable. I've been using Linux for 20 years, and I've had my time with Gentoo and Arch. 99% of the tinkering users do is reproducing the work of professional developers at distro vendors who spend a lot of time and effort making sure you never encounter the problems Arch users revel in fixing at all. Sure, you can tell yourself that means you "know" more about the system. But that is time invested that you could have spent doing REAL THINGS, and solving REAL PROBLEMS which are not un-breaking your distro.

Historically, sure, but with the leaps and bounds Intel and AMD graphics drivers have made (in no small part thanks to Valve!), we can leave Nvidia in the dust. With said FOSS drivers, "I want to be up to date" is a perfectly reasonable desire and does indeed get the best results as far as gaming goes.

That said, I agree that Arch wouldn't be my first choice for something I'd expect non-technical users to maintain. If Valve really wants a rolling release and close-to-cutting-edge kernel/driver versions, distros like openSUSE Tumbleweed could readily do that (with, at worst, an extra repo for bleeding-edge kernels, though I've yet to find that necessary on my openSUSE-running gaming laptop) without anything even vaguely resembling Arch's maintainability nightmare.

> Sure, you can tell yourself that means you "know" more about the system. But that is time invested that you could have spent doing REAL THINGS, and solving REAL PROBLEMS which are not un-breaking your distro.

You can start a sysadmin career with that kind of experience.

Not necessarily on Arch specifically, mind you, but a ton of the experience I had that led to me getting my first tech job was breaking stuff and then figuring out how I broke it. It's a great learning experience.

For the uninitiated; In programming, "stable" often refers to the programming interface or features a software developer can count on being available for a particular version of a given piece of code (library, server, etc). To the end user, "stable" often is taken to mean "How often does it crash? Rarely or never? It's stable."

Since it's based on arch, I assume they will pull the latest software from arch, test it, and push out updates as they are verified.

First, it's worth keeping in mind that this Steam Deck is for all purposes and intents a fixed-spec system. Valve will control all of the most major components that make various end-user support problems appear (fixed CPU, GPU, RAM, motherboard, controllers, storage, etc.)

Now, with that in mind, if you use a system that has a release cadence like Ubuntu, if you want to fix issues, you must report them upstream and backport them into your current system. This is workable, but it is implicitly predicated on the assumption that the backport is the only way to deliver the fix to users in a reasonable timeframe. Otherwise you would have to wait 6 months for Ubuntu to release anything.

If you use a rolling system like Arch that is much closer to the very latest versions, the same process above occurs. But the window for those changes to appear downstream (from reporting the issue to the person receiving the fix) is much smaller. If this window becomes small enough, say "I report an issue and a patch is issued and released in 48 hours", it often means you don't have to backport or maintain the backport for long. If you're maintaining less backports concurrently, or even none at all, that means you have less workload and can focus on diagnosing real issues with up to date code.

Finally, and this is the important part: it doesn't matter for who they want to buy this. I don't think Valve intends this to be seen as a console, but as a portable PC, and I don't think PC gamers who use Steam (and thus are the target market) are unexperienced with the fact games might not work and bugs need to be reported. It's part of PC gaming culture at this point to complain about bugs in PC games. They actually will probably want one anyway because it will make their massive investment in their Steam library all the more available. And if you're some die-hard guy who likes this thing because it's Linux, well, Proton is basically as good as it's ever going to get at this rate, and it's objectively made Linux gaming massively more available, so, you just gotta deal. (Proton's very existence gives developers less of a reason to deal with native Linux ports when they can just target Windows and let the magical translation layer fix it instead. So actually the focus will be going into making Proton better instead to fix these issues, and that is actually probably the best way forward to ensure older games can be available, too.)

There are a thousand confounding variables in this equation and I'm sure you can line up to list them or whatnot. But the important thing here is that in all cases there are social expectations about how the maintainers of each upstream project and distro fix issues, and on what timescale, and how users respond to them. That's why they think this will work.

As for the games themselves, Valve's been workin' hard on their Steam Linux Runtime containerized game thingy, and Proton sorta "containerizes" (WINE prefixes) things, so that allows for a reasonably stable environment for any given game which already runs well in those scenarios.

TL;DR: I doubt Valve will have too many problems keepin' this thing fairly stable from an end-user point of view unless you start hackin' around on it changing too much, then it's all on you what happens next. ;)

So yeah, not exactly an exciting story, more like a practical solution.

So, what is SteamOS?

SteamOS is a public release of our Linux-based operating system. The base system draws from Debian 8, code named Debian Jessie. Our work builds on top of the solid Debian core and optimizes it for a living room experience. Most of all, it is an open Linux platform that leaves you in full control. You can take charge of your system and install new software or content as you want.

this is probably this most exciting thing about this release. How many days until this thing is running k3s and/or serving up a prometheus dashboard on the same device that is touch capable?

1280 x 800 at up to 30 fps.

The only place where I've seen 30 fps being mentioned was when they said that you can switch Portal 2 into 30 fps mode to get longer battery life (which is a Portal 2 feature available on PCs from the very beginning).

[×] Use settings and textures specially optimized for this device?

Sales = f(game quality)

game quality = g(sales)

That's why if I were valve I would set about throwing money at some medium-appropriate game dev up front in addition to discounting the hardware.

OTOH I just learned the switch's battery life was not as good as I thought; it's no M1 idling. So that helps.

There's no way for valve to discount the deck, which uses a cutting edge SoC cut from the same cloth as the PS5, at anywhere near that price point.

Flagship hardware has flagship prices. If valve would have built a cheap but underpowered device to reach the price point of the switch nobody would have been interested. Gamers are into the deck because of its cutting edge specs.

The traditional business view is the casual gamers are growing, and the elite PC gamers are stagnant. Valve is trying to wreck that dichotomy with hardware like this, but I think that goes with making sure there are games that fit the form factor. You can't just sell this to people who rather play on their main gaming rig but are sometimes stuck without this.

Making games for this form factor != a retreat from the principle of general purpose computing.

IGN clarified 2 tflops "in the ballpark of xbox one or ps4".

I hardly ever even play video games these days, but I'm absolutely buying one of these just to have a nice little portable PC.

Thats what I always think when considering a new Switch game as well. They're so incredibly expensive, Breath of the wild is still 50€ although it was released 4 years ago.

Having a handheld device with all my Steam titles playable is huge!

Speaking of: I wonder if it'll work with a Switch dock? Probably would require some physical modification of the dock itself, but it'd still be neat if they're interchangeable and I can stick either one into any dock.

> Desktop: KDE Plasma

[0]: https://www.steamdeck.com/en/tech

Does this mean all steam users will get this now that they have hardware to get support of? IMO this would be huge

> Arch Linux

> KDE Plasma

> Will be able to install whatever they like

Is that you smartphone? The one I've been waiting for?

I'm sure there will be keyboard cases for the steam deck, We still might have to carry round a GSM radio module if we want that LTE/call/SMS.