honestly I don’t know whether you can still do that after they started making non-x86 stuff
Asahi Linux isn't far off and I'm guessing it will be ready for prime time before anything Apple Silicon loses support.
conciselyverbose
joined 2 years ago
Giving organizational policy administrators control over execution doesn't preclude using the cloud as your primary or strongest security model.
It's sincerely not difficult to allow the organization to literally sign the executable of the interpreter they want to use, to explicitly enable or disable specific modules from base Python, to enable specific external libraries by ID through Conda or by signing them with their own keys, or to pass the scripts to their own signed server for execution with any mitigations they want. They wouldn't be assuming any liability or even bad will if a company's IT fucked it up and left an attack vector exposed.
There is not a good faith explanation for forcing execution to the cloud. It only protects against bad configuration, at the cost of a hell of a lot of capability to a competent organization. Defaults are way more than enough to mitigate any exposure for Microsoft. Not providing the right way to do it as an option is all about control.
I just don't see it. They control the whole stack and permissions structure from top to bottom. If they wanted IT to authorize every module you import (to limit low level access), they could do it. If they wanted to allow IT to host their own cloud with whatever constraints they want, they could do it.
This is to increase reliance on their cloud. I don't see any other explanation.
Even perfectly implemented DRM steals cycles that can't possibly benefit any gamer ever in any way.
See, I kind of see all this, but they control the OS, all the enterprise policy tools, and the software. They could very easily facilitate IT locking execution to the cloud (or custom environments) for their domains without ridiculously limiting people who know what they're doing and want tools that aren't dogshit.
Possession of a plant is a felony.
They're only not CPU intensive because the hardware was fucking pathetic and they had no choice. AMD held the entire gaming space back for a decade.
If you're OK with a dumpster fire CPU the cost of chips goes way down.
What kind of poor are you that your power outlets don't have built in phone shelves?
How daunting is it? It's an extra field in your database for Steam app ID with the ability to use a file picker for non-steam games.
The steam deck is significantly more capable than the PS4. Jaguar's CPUs were absolute dogshit when they launched, let along compared to anything Ryzen.
The problem with a switch 2 is nvidia can't make competent CPUs.
A handheld digital only PS4 could move some units at $200 pretty easily IMO.
Ideally, any change to any codebase would be a strict upgrade that's always better for everything.
But in practice, it just doesn't work that way. There's a lot of software out there that needs specific versions of specific libraries in order to not break, because even a straight bug fix can break software that was built and tested while that bug existed, if it was touched by that bugged behavior and the developers didn't know it was a bug. There are a lot of code bases that just rely on way too many dependencies to be able to actually read and comprehend the specification for every dependency they have. In theory that's not ideal, and leaning on a lot of external dependencies can break stuff in a lot of ways as they change, but it's how it is.
It's worse in some ways for games, because they take more shortcuts in the name of optimization, and in a lot of times are helped by graphics drivers to avoid breaking. Nvidia game ready drivers are a good example. There are games that have serious issues if you use a driver earlier than that, because nvidia will do hacky shit to fix the hacky shit the devs did and make it work.