sudotstar

My hope, though I’m keeping my expectations low, is that since these supposed live-service games will be supposedly releasing alongside remakes of the original games the IP is based on, that if the remakes sell significantly better than the live service games it might hopefully inform better decision-making around them.

While they haven’t been controversy-free in terms of their monetization practices, Sega has released a slew of back-to-back AAA games: Persona 3 Reload, Like a Dragon: Infinite Wealth, and Sonic Frontiers, that have generally been complete, single-purchase packages (with a few questionable omissions from base game moved to DLC that I’d consider “regular bad”, but not anywhere near the level of egregious monetization seen in most live-service games).

I think that’s the rub, in my theoretical scenario, Apple is not blocking the distribution or sale of iOS applications through third-party means, they’d enforce their existing restrictions on and power over building iOS applications in the first place. Developers would absolutely still be able to distribute unsigned applications - end user iOS devices would just be unable to install them.

It sounds ridiculous to me, and as I wrote earlier, it would be a clear violation of the spirit of the DMA, but I don’t see any reason why this scenario would not be technically possible for Apple to pull off.

I’m not too sure that these actions violate the letter of the law here, even though I agree that they’re 100% in violation of the spirit of the law.

It’s been some years since I’ve put the mobile development world behind me, in no small part because of Apple’s shenanigans, but the way I understand how this might work - Apple may be required to allow “iOS software” to be installed from third party stores, but software that runs on iOS must either be signed using a certificate that only allows installation in a developer or enterprise context (which require explicit and obvious user consent to that specific use case, and come with other restrictions such as the installation only lasting for a limited period of time), or through an “appstore” certificate that allows installation on any device, but the actual application package will need to go through Apple’s pipeline (where I believe it gets re-signed before final distribution on the App Store). All certificates, not just the appstore ones, are centrally managed by Apple and they do have the power to revoke, or refuse to renew, any of those certificates at-will.

If my understanding is correct (I’d appreciate if any up-to-date iOS devs could fact-check me), then Apple could introduce or maintain any restrictions they please on handling this final signing step, even if at the end of the day the resulting software is being handed back to developers to self-distribute, they can just refuse to sign the package at all, preventing installation on most consumer iOS devices, and to refuse to re-issue certificates to specific Apple developer accounts they deem in violation of their expected behavior. I haven’t read the implementation of the DMA in detail, nor am I a lawyer, so I’m not sure if there are provisions in place that would block either of these actions from Apple, but I do expect that there will be a long game of cat and mouse here as Apple and the EU continue to try and one-up the other’s actions.

I can see the use case for someone who wants a single OS install on the Steam Deck that does gaming just about as well as SteamOS does, but has a more fleshed out desktop experience (or even just a different one). The linked article goes into detail on various desktop-focused developments within Bazzite that wouldn’t really make sense for Valve to prioritize in SteamOS itself.

I’m a big fan of the series and would consider it to be my favorite JRPG series, not just for the story but because I enjoy the gameplay it offers as well.

It’s a fairly “cheap” series to try out and see if you’re into it. The entire series is a singular, continuous story, so the recommended place to start is Trails in the Sky First Chapter, which can be picked up fairly cheaply on Steam, especially during Steam sales. It’s not as long as future games in the series, and is fairly representative of the pacing and storytelling format that later games will follow (though it is considered one of the slowest-paced games in the series). Basically if you’re not a fan of Sky FC, you’re not likely to be a fan of the future games in the series either (especially given that the substantial improvements to gameplay over the series’ 20 year history likely won’t have much appeal to you).

There are also demos available for some of the newer games in the series (e.g. Trails of Cold Steel III), and while I would not recommend actually playing through those games out-of-order, they may serve as a quick/cheap way to see if the format of the games is right for you.

I will say that while the combat of the games is rarely very difficult, and the game provides difficulty modifiers to make it even easier if you’d like, that the combat system is still fairly fleshed out and quite good casually IMO, but if you’re really not into doing it even at easy difficulties, one option (PC exclusive) may be to download completed game saves and play through the games on New Game+ and completely trivialize the combat.

In this case it’s referring to the fact that the OS is built upon the same containerization technology used on cloud platforms such as Kubernetes. As a marketing tool it’s a bit buzzwordy, but it’s not about running the core OS components outside of the physical machine here.

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.

If I’m not literally touching the content I’m trying to scroll, I’ll stick to the default orientation (scrolling down moves content down). Wayland touchscreen input handling seems to handle this just fine and not couple touchscreen scroll direction to trackpad/mousewheel scroll direction.

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 haven’t adopted this kind of setup, mainly because Proton just does such a good job I have almost zero need for Windows, but my plan for eventually doing something like this was to also maintain a passthrough Linux VM for any GPU-intensive work on that side.

When I realized that the practical end-state of my system would mean I’d just be running things from within the Linux VM 98% of the time (games that can run on Linux) I kind of dropped the idea.

For me it’s always been after I tried to resize a partition.

I recommend using whatever is the “least hands-on” option for your boot drive, a.k.a your distro default (ext4 for Debian). In my admittedly incompetent experience, the most likely cause for filesystem corruption is trying to mess with things, like resizing partitions. If you use your distro installer to set up your boot drive and then don’t mess with it, I think you’ll be fine with whatever the default is. You should still take backups through whatever medium(s) and format(s) make sense for your use case, as random mishaps are still a thing no matter what filesystem you use.

Are you planning on dualbooting Windows for games? I use https://github.com/maharmstone/btrfs to mount a shared BTRFS drive that contains my Proton-based Steam library in case I need to run one of those games on Windows for whatever reason. I’ve personally experienced BTRFS corruption a few times due to the aforementioned incompetence, but I try to avoid keeping anything important on my games drive to limit the fallout when that does occur. Additionally if you’re looking to keep non-game content on the storage drive (likely if you’re doing 3D modeling work) this may not be as safe.

Sure, modding the device will always have a niche interest, and people doing it just because they can, but if the price point of such a device is comparable to a Switch (easily hackable) or even a Steam Deck (outright open for you to do whatever with no barriers in place), would this device have any practical benefit for that kind of stuff over the alternatives?

I think it will continue to have some niche benefit, especially if modding the device still retains its presumably “first party, easy” path to streaming games from a local PlayStation, and for people who would want to keep the presumably better-quality and 1080p display over what’s found in the Switch and Steam Deck, but I think someone looking to get something to primarily use with Steam Link or other such services have better (incl. first-party) options for that use case.

I was referring to the niche-but-growing segment of handheld game devices primarily designed for cloud/streaming services, like the Logitech G Cloud or more “traditional” handheld gaming devices like the Switch or Steam Deck, not necessarily all generic-tablet Android devices.

We still don’t know the price of the device. I think this device has to really target a low, potentially subsidized, price point in order to be worth it over existing handheld devices capable of streaming (or even running games locally), and if that’s the case, it may suffer from the Amazon Fire problem of being incredibly locked down and not seeing as large a development community as would be necessary to achieve a “no restrictions” Android setup. If Sony is subsidizing the device, they would really prefer it if consumers stay within their media ecosystem rather than having the ability to go out and use and/or pay for services that don’t allow Sony to recuperate their losses.

It is also possible that the device seen here is just running Android for testing purposes, and the final device will ship with something more locked-down. This seems unlikely due to being far more effort than just using common tablet hardware and shipping Android, but Sony may prefer to do that to achieve more control over the device.

This is why I’m intentionally staying away from high-refresh-rate displays until I can feasibly upgrade everything I use to that standard (phone, TV+consoles, desktop monitors, etc). I don’t know exactly what I’m missing out on and ignorance here is bliss.

Unless LOS or a different custom ROM can re-enable the “old” work profile behavior, having access to the latest version of Android might be a detriment compared to an older version that still at least receives security updates (as I assume the Pixel mentioned here does).

I run LineageOS myself, and while I don’t think this change is enough of a dealbreaker to prevent me from ever updating past LOS20 if this change isn’t addressed somehow in either AOSP or LOS, it will make me less enthusiastic about immediately jumping to LOS21 the moment it’s made available to my device.

I would really like to have a headphone jack but the other benefits the Fairphone brings (longevity, easily replaceable parts, more effort on ethically sourcing components than pretty much any other manufacturer) allow me to begrudgingly make that tradeoff and just have a dongle permanently occupying space in my pocket.

I’m also using a OnePlus 5T (with LineageOS from day 1), and plan to replace it with a Fairphone should it die and there’s a good model available with US bands. I’m fine with importing the newest Fairphone should it release by that time, but the Fairphone 4 is also available directly in the US as well.

I think what’s impressive here is the first party, OEM support for feature updates on Android lasting as long as it has for this phone. That’s really not something you tend to see even on Google’s flagships (though security updates are still regular and better than what the Fairphone sees officially).

IMO, smartphones have basically plateaued in the past at least five years - a flagship model from 2015 should be sufficient for basic usage today, assuming the battery and modem hardware was somehow kept up to date and software updates were provided as well, and flagship models from like 2018 onwards were a better deal than today’s flagships, providing comparable real-world functionality at a lower price even if the spec sheet pales by comparison. I don’t think most other OEMs have the incentives to provide that kind of long-term support on older but still usable hardware, but Fairphone absolutely is.