The &
is the html escape code for an ampersand (&) symbol, which is used to separate query params in a url -- it appears like this has been re-encoded so the single & in the URL becomes &
by something breaking the link. If you change all of the &
s to $ it works. it's not really an "amp" link in the "Google Amp" meaning.
Also after posting this comment, it appears to be Lenny's url encoding, I think I've fixed it but if not, remove the amp;
from the 3 sections of the url you see it and it'll work
Sure, they obviously are dropping the ball here, just trying to explain what they might mean by "thoroughly tested" and why it's not succeeding
This is all assumption from me, but I think a lot of testing would likely be diagnostic machines and specialized testing -- not actually playing games. I would assume it's something like plugging in, confirming the parts all meet spec after whatever the refurb is. That spec is probably more around frequencies, power use, temperatures.
Obviously that's not good enough if they're sending out these clearly broken refurbs.
Maybe, but unless we're in there, it's hard to say for sure. Battleye supports it but given the clusterfuck that is the Tiger engine, they might be using an old or heavily modified version. Especially given how easily cheaters are getting past it atm, I would not assume they're keeping up to date on it without some evidence.
Stadia limits the player's control of the system substantially and might not have even needed the anticheat, or the same anticheat, given it's closer to a console in terms of user's ability to run programs alongside the game to modify memory.
The Deck is designed for SteamOS and SteamOS is pretty much designed for the Deck. They're chocolate and peanut butter.
I feel Valve's Windows support is not great -- it's a custom APU for them so you're getting your drivers through Valve, not directly from AMD's Adrenalin. The APU drivers are from March, I'm not sure if we've seen any Linux improvements since then on the APU side but months without GPU driver updates to address game compat issues doesn't encourage me.
They don't officially support dual booting AFAICT, and given the size of modern games + Windows, I wouldn't want to dual boot on any of the offered SSDs tbh.
If you've got a deck and really want a Windows-only game, it works. But given the easy availability of the Ally, and the upcoming non-extreme Ally, I can't imagine recommending anyone who wants to primarily play a Windows-only game get a Deck.
I've done it so it's definitely possible, though I can't remember if I used Steam link or Moonlight to do it. It was also pre-Lightfall, so they definitely could've changed it.
estiny has some anti-overlay stuff enabled that limits what can pop up on top of it, which might also be affecting some form of streaming?
Unless something has changed very recently, Destiny 2 does not work under Proton because the Anti-cheat isn't compatible. Windows is an option, but I'd really recommend a dedicated Windows handheld for that instead of the Deck.
I haven't tried Windows on the Deck itself, but based on 6800u performance, you're looking at maybe getting a solid 30fps on lowest settings. Destiny 2 is not a very well optimized game atm, and even the Ally at 20w can have trouble holding good performance in Neomuna or the Tower.
As long as tools to unclip the shell aren't consider specialized, I think almost all existing handhelds are gonna meet the actual requirements here - they just have to be user replaceable, not use swappable, without the use of specialized tools or thermal energy. If you can unscrew it, disconnect the old battery and connect the new one, it complies. It's really only an issue in waterproof devices, where they have to glue everything to seal it.
Imagine you have a household with 2 adults and 2 kids, and you've setup some level of presence tracking. You want to use automations to turn off everything if nobody is home, turn on some things if only kids are home, turn on other things if only adults are home, and turn on everything if kids and adults are home. You could build this logic into every automation you have, but it's a lot of repeated logic to put in every time you wanna add something cool.
Blueprints mean you don't have to write it out in every automation. But I've never found them to be especially convenient for updating. And they still have the automation doing all of the heavy lifting.
You could have a home State sensor that you depend on automations to manually update. But this is only as up to date as you make it, either running every so often (stale data) or using automations based on a change in presence tracking to update a sensor (buggy maybe? have not tried it but sounds prone to race conditions and misfires to me). Closer, but unideal IMO.
Or you could pull this logic into a service that returns 1 of 4 possible states - full, empty, kids, adults. Your automation no longer has any logic to figure out what the state is or who's home, it just asks what set of rules are in effect and can apply them. This lets the automation focus on a smaller area, which means less shit that needs updating if you change something, less chance for bugs.
There's not a ton new you can do now that you couldn't accomplish before, but you can do it in smarter, more maintainable ways.
Sure. They could do that. That doesn't really address my point though. And it's really unlikely to happen on any meaningful scale, imo:
- The market for a dedicated phone OS from one of the larger consumer electronics makers is ORDERS of magnitude larger than any kind of handheld PC gaming console. Just because Samsung did it for phones does not mean anyone will do it for handheld PCs.
- Even if they do, there's a lot of negative sentiment about Samsung's version of Android, to the point multiple Android users I know will never buy a Samsung phone. It's not necessarily a goal to emulate.
- Leaving all of that aside, that is still not the same thing as the maker of the device also being the developer of the OS. You're at the whims of upstream to fix a lot of major things, or you're maintaining a massive patch process on top of their releases. It's a much larger task than just "hire staff to optimize steamOS".
We already have some makers offering "steamos support" in the form of... basically a single steamos image they release once and don't steam to maintain? GPD's "GPD OS" from Dec 2022 and Anbernic's Win600 Steam OS image from Jan 2022.
And still the best way to run SteamOS on either of these devices is ChimeraOS.
The closest to what you're describing is AYANEO's ayaos. I don't know if it's a steamos fork or not, but it's their take on linux gaming OS. It's been in development for a while and we've got nothing but a few clips of it to view. And considering it mostly seems to replicate the Ayaspace windows app interface, I'm not sure it even offers any benefits over Windows+ayaspace.
No. Steamos is only really great on deck because of the whole making the hardware and software thing. If other people use it it loses that and you end up with a computer with a less compatible OS.
Looks cool, and I'll definitely check it out once the initial user bug is fixed :)
PS: I know about the implications of potentially removing contributions to the internet.
Reddit does not get to continue to profit off of any contributions I've made to the internet, one way or another. Anyone convincing you not to delete comments on reddit is a scab more concerned with maintaining the status quo so they don't get inconvenienced.
Looks like the mount definitions require the :ro
(or maybe :rq
?) at the end unlike regular docker volumes, that was the issue.
What's required to map a folder into one of the containers (i.e. retroarch)? I've attempted to edit config.toml to include it, but the main wolf container immediately crashes on boot due to interrupt code 11. There's no other error messages, just a binary stack trace.
The folder exists. I've tried directly mounting the host path as well as mounting it into Wolf-Wolf-1 and using the local path, but nothing works. Even perfectly mirrored paths don't work. Wolf appears to be running as root so I don't think it's a permissions error? I can certainly access the folders. They are a locally mounted NFS, but I've used this with dozens of containers without issue.