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.
I think this game definitely has the hardest shinespark “puzzles”, but the actual execution of shinespark is much easier than in previous games which balances it out. Super Metroid had items where figuring out what shinespark maneuver to do was easy, but actually executing it was difficult, while Zero Mission and Fusion had easier-to-pull-off shinesparks with harder puzzles.
With Dread, the challenge is almost entirely in figuring out what to do, once you know exactly where/when to shinespark the actual execution is very intuitive and feels amazing when you land a complex sequence of shinesparks/speed booster runs/wall jumps.
I have played the original, and will be playing the remaster, though not on Switch, I already own the Japanese version on Steam which will be patched with the localization upon release in the West.
It’s quite a fun, fast-paced game, as Falcom action RPGs tend to be. Being a PSP title originally, I think the game format works well for shorter, pick-up-and-play sessions, making it ideal on devices like the Switch and Steam Deck. No context or experience with the wider Trails series necessary, all connections to the mainline series are just simple references and the game has a standalone story (unless you’re deep in the rabbit hole of lore crack theories).
The thing with R&D for a company like Nintendo is that they’re never finished. If they’ve really finalized the Switch 2 as you’ve said then R&D will have immediately started working on the next console, or at worst post-launch accessories.
Not to be too dismissive, but I agree that it should be taken with a grain of salt. I also would expect that somebody who’s supposedly a part of Nintendo R&D specifically will be more likely to be walking around with many attempts at proof-of-concept hardware ideas that aren’t (yet) intended to ship in a final product, and only an incredibly tiny portion of such ideas will ever make it far enough to even be in consideration for a new device.
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.