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.

Being incredibly car-centric is probably our biggest issue in my opinion. If you're expecting to be able to use public transit or even walk to basic necessities, and are looking to purchase a house, you'd likely be looking at areas outside of your price range, generally within highly urbanized city centers. Owning a car is very much the norm here, even within those urban environments.

If you're running uBlock Origin, go into the addon settings, go to Filter Lists, and turn on the Annoyances filters. They're not on by default, but should get rid of these kinds of "known" popups across popular sites.

I think their original intent back when Proton originally launched was to just show generic Linux compatibility on any titles if it worked with Proton and was approved by Valve. I'm not sure why they stopped doing that.

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'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.

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.

Windows's dedicated Saved Gamed folder is within the same user-specific directories that Documents and AppData are in, and would still allow for game saves to be user-specific.

It's unfortunate, but it's understandable if effort needs to be focused on a single good UI widget ecosystem fully under Mozilla's control, rather than living by the whims of the three major desktop UI toolkits they have to support, as well as the hundreds of thousands of web pages that are exclusively designed and tested against Chrome which already has been using non-native widgets across desktop platforms for a very long time. I'm not in the web dev space anymore, but I'd constantly see sites built that were incredibly dependent on the exact pixel sizes of widgets as they would render in Chrome, and would visually fall apart on Firefox, or with other zoom/text size settings.

UI design across Windows, macOS, and Linux GNOME/KDE have converged enough that it's probably good-enough if Firefox continues down the path of just theming their own widgets with the OS/user's color scheme where applicable, and calling it a day.

This is, IMO, the biggest yet least obvious advantage of immutable systems. A traditional Linux environment is "just as safe" as the immutable setups, if only the user/administrator is perfect, never makes a mistake, and always makes the right decisions for now and the future.

Given reality tends to differ from the above, having a system that, at a bare minimum, provides you the "oh shit go back" button to system-level changes, and at best provides a clear, reproducible, trail of actions, is a huge advantage for long-term stability for all users, experienced or not. I've been through the school of hard knocks far too many times maintaining everything from server setups to gaming desktops the traditional way, and have committed to "early adopting" immutable distros for pretty much everything except the gaming setup (given the whole suite of proprietary and out-of-date/out-of-touch applications that are basically necessary in that space and not-fully-compatible with the sandboxes and abstraction layers necessary).

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.

There is no Fairphone 5 released yet in any regions.

It's not like Nova Launcher, but I've been really enjoying Kvaesitso. It does support icon transformations (better than Nova does IMO) but provides a very different interface that's focused on search.

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.

Yup, while Denuvo DRM is still an issue for many other reasons, it has been generally very Linux and Wine-friendly, especially in comparison to other popular DRM/anticheat solutions in place that explicitly block LInux users by-design, or at best change their implementation so often that it's a cat-and-mouse game keeping Wine and other layers up to date to support it.

I was aesthetically a fan of the Fossil watches, and was using a Fossil Sport (1st gen) for quite a while. Unfortunately the layers of proprietary-Fossil required software/watchfaces on top of the layers of proprietary-Google WearOS hampered the software experience a tiny bit, and the frankly poor hardware quality marred the experience significantly. My charging band coil in the watch completely dislodged itself (it appeared to be held in with glue), rendering the watch unusable.

Fossil's customer support was excellent, replacing the device fully when this happened, though that was when that model was still on store shelves. I recently inquired about getting a replacement battery and was told I can just trade it in for 50% off a current-gen model, which while being far more generous an offer than I expected, still leaves me hesitant to upgrade to another device that suffers from the same problems and is in danger of being outright discontinued.

At this point I don't really need/want a WearOS device specifically, and would actually prefer something that's less tied to Google's whims, the hardware OEM's whims, and whatever the interplay is between those two companies. I've been eyeing more hobby-oriented projects like bangle.js or the PineTime smartwatch, but the fact that I'm even looking in that space shows that it's become a device I would get for tinkering, not one I strictly "need".

The reason this is known is because this supposed device is using the same AMD APU used in the Steam Deck. It's unlikely that a standalone controller would have a dedicated APU like that without becoming a full-on portable gaming device of its own.

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 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.

This change is interesting. The process of creating parameterized blueprints looks a little tedious, but I'm pretty sure that's just inherent to the idea in general and there isn't much room to make it better, and I imagine the ease of using such blueprints that are e.g. downloaded from the internet is perfectly fine.

I play a lot of Factorio in multiplayer, with a group where not everyone has the same desire to make blueprints, and we in-general resist just downloading designs off the internet and try to do everything in-house. This leads to a lot of asymmetric gameplay, where e.g. I may design a blueprint and others will use them. I think this kind of change will work well overall for that (complex train systems are now a reality) but might come with the cost of the blueprint producer spending more time faffing around with the blueprint UI.