sudotstar

My Deck and Linux desktop regularly have shader cache updates every few days, but they’re generally tiny and finish near-instantly. I’ve never seen the behavior here of needing to download multiple gigabytes of shaders daily (and I’m thankful for it, with the frustrating data cap I have from my ISP).

I expect this is simply a case of “Valve Time” on that effort. Perhaps there’s a long-term path towards more “official” SteamOS on these devices, but if there’s any area where HoloISO diverges technically from SteamOS in a way that’s not reconcilable, that’ll be problematic for offering users a “seamless upgrade”.

Long-term, I think it would be slightly more harmful to Valve’s efforts if more manufacturers started standardizing around HoloISO, so I expect that this might be a motivating factor to speed up their efforts to bring official SteamOS to third-party devices.

I am very interested in the success of this device. I have, use, and love my Steam Deck, but my biggest hopes for this form factor in the future is it using generational CPU improvements to create a more diverse set of devices, rather than just chasing higher performance.

I don’t actually play many games on my Deck that toe the line on its performance limits, I prefer to play 2D and lighter 3D games on it, while leaving the “spectacle” games for a more powerful system outputting to a much larger display at a higher resolution. I would love long-term to have a more smaller, lightweight device for portable PC gaming, and I hope that increased diversity in the market, running Linux-based systems (even if it’s all just SteamOS) will help drive towards that. I think that the pipedreams of running x86 games on Linux on ARM on a really power-efficient device, even as unrealistic as they are, are far more likely to occur if there’s a healthy market of Linux based systems, than they would on Windows handhelds given the state of Windows on ARM, and on these devices in general.

If Valve is working with Ayaneo to get SteamOS shipped on these devices, then I imagine Valve would have some level of involvement on at least the software support side, even for things specific to the device. If Ayaneo is just like shipping by using one of the existing 3rd party SteamOS installers and not working with Valve at all, then yeah I expect things to be not as smooth sailing as the Deck.

I love the DualShock 4 and DualSense controllers’ support on Linux, but I’m not a huge fan of the controllers themselves despite exclusively using the DS4 as my PC controller. I’m perfectly okay with the layout since I grew up on the PlayStation, and in fact prefer it to the mainstream Xbox/Nintendo options due to being the only controller to have a touchpad, and both gyro and analog triggers, but the abysmal battery life on the controllers has been a frustration for my couch PC gaming setup, my fairly old DS4 controllers barely last for more than 30 minutes on battery now. The biggest thing holding me back from buying a new DualSense to replace those controllers is the fact that it, too, has terrible battery life.

I’m hopeful that Valve’s desire to make a Steam Controller 2 pans out, as I expect that such a device will also provide stellar Linux support (or perhaps already does if it ends up reusing as much of the Steam Deck’s input setup as it can), and would hopefully offer much better battery life than Sony’s attempts.

I’m curious to hear about yours and others’ experiences with containerizing Java applications in such environments. I used to work in a place that traditionally had such restrictions on JDK versions, but after the internal IT environment moved towards running applications within containers, either on Kubernetes or on public cloud platforms’ container runtimes, that restriction became unnecessary since the application would be shipped to production alongside its compatible JDK.

While there were still restrictions on exactly what JDK you could run for other reasons, such as security/stability, common developer experience, etc, it at least allowed teams to immediately adopt the newest LTS release (17 at the time I left) with little restriction.

I’d probably pick something esoteric and then just stop programming, tbh. I enjoy being a polyglot programmer, and learning many languages and learning from many ecosystems is incredibly interesting to me, far more than hyper-specializing in a single language would be.

IMO this isn’t a real “solution” to the problem here, but this article states Android 14 also allows Google to manage device CAs remotely and push updates via Google Play, and goes into detail about how that mechanism is poorly documented publicly and is basically only an option for Google themselves, not any third party device administrators.

Google can easily claim that all security concerns are handled by their own management while continuing to deny access to all third parties to actually handle that responsibility themselves if desired.