Compatibility is unlikely to be very different. The key is immutability (easy to update, hard to brick your system) and some baked in nice to haves for gaming like some specific drivers/patches and controller support out of the box.

Cheaper than Spotify for the number of users it gives you (at least where I live) and the app itself has functioned significantly better than Spotify’s has in my experience so far while not depriving me of any of the artists and albums I listen to regularly. Early on in its life it was big time selling snake oil, but at this point it’s just a solid alternative to Spotify and YouTube music which have both, frankly, gotten “too big to fail” and have begun enshittification because of it. Man we need more competition…

If you’re gaming you might as well just jump on Bazzite if you’re already interested in Kinoite. Very similar base, but Bazzite has some extras Kinoite doesn’t and it makes a transition into an immutable distro easier.

To be more clear I was more focused on the not wanting a car that needs software updates part of the argument, less so the means of delivery. Obviously, having an always on connection absolutely sucks and I’d personally be super down with just pushing an update via a USB drive or whatever like you can a BIOS update. But a lot of manufacturers have it set up so that you have to either pay a dealership to plug in the USB for some arbitrary reason, or demand the always on connection to do it. In a utopia of software development where there are no critical bugs, we would all prefer a car that doesn’t need updates. I didn’t mean to imply that I was arguing in favor of remote connection by manufacturers, and it’s absolutely my bad in not wording it properly.

On the flip side: if a car stereo has a known firmware issue causing problems with say Bluetooth connection, I DO want the manufacturer to actually provide an easy means of fixing/updating the borked software. Better that the system was properly tested and feature complete to begin with- but I’m not delusional enough to believe we can truly have nice things.

Possibly dumb question: why not use an Authentik outpost with a reverse proxy to enforce SSO? It wouldn’t be “baked in” so to speak, but it would be fully OIDC and as long as you’re just running it through a web browser. Biggest downside is you’d need 2 logins (one for the outpost and one for the app). I’d assume the sso is specifically for the extra security though, so that shouldn’t be a problem outside of it being a little hassle.

I believe it’s more a “the PS3 CPU architecture was an absolute nightmare and emulating it is difficult/slow” more than it had anything to do with the graphics rendering portion- which is typically where phones would have made the most substantial advancements. There are specific instruction sets that need to be supported by any CPU emulating PS3 to run anywhere near native speed… And I don’t believe much work has been done for ARM cpu’s to support the needed instructions in mobile devices.

Isn’t AMD’s HEVC/265 still decent, specifically? I feel like I read that somewhere years back. 264 has always been a weak spot for them, however.

Software-wise, it seems that the relatively fast adoption of flatpaks and other containerized formats somewhat solves the typical dependency hell that was so common in Linux just a few years back (and to some extent still is an issue today depending on your distro and use case). The hardware support side is a little harder. That’s going to be up to vendors to play nice with the Kernel team and/or introduce reasonable userland software that doesn’t break the golden rule. Until Linux gets more market share the latter isn’t likely to happen. A nice side benefit of the emergence of immutable and/or atomic distros is that users can play around and try things with much lower risk of bricking their systems, so I’d also consider that a step closer in the “it just works” department.

Very true. But brute force checking through tons of different settings for each camera you need to configure is not fun. I couldn’t seem to find any kind of “known working configs” database or anything either. Every camera seems to be different in what it expects, outputs, authenticates, etc. Once it’s set up, I agree, maintaining the config is easier. Having all your cameras match in model and firmware version probably makes the whole endeavor MUCH easier.

AmCrest and Frigate together are SO good. Integrating Frigate with Home Assistant was also insanely easy for quick viewing and notifications. That initial Frigate config is a bit of a bear- but once you’re past that I cannot speak more highly of it.

hunter2

Alright, where’s my replacement once my current Fitbit dies? What company makes a watch that tracks steps, heart rate, sleep, spO2, notifications, is generally water resistant (light swimming) and has a battery that lasts ~5+ days? Bonus points for open firmware/hardware that doesn’t require me to design my own apps/systems for each of those items. I don’t even use most of what my Versa 3 can do, but I know it won’t last forever and I’d at least like an idea of where to go if/when it breaks down.

Proton experimental and (at least as of yesterday) I had to opt into bleeding edge beta as well or I’d just get black screen at launch.

No stuttering for me on Linux… Runs as good as it ever has but the visuals are even that much better due to the engine upgrades. Not a fan of the new UI, but the old UI was clunky too, so I can’t really say it’s even a step backwards.

On windows the article mentioned being a microcode patch via Windows update. Linux would be similar- but via a kernel update most likely. I’d assume that a general BIOS update would also do the trick, but then you’re relying on motherboard vendors and it’s unlikely many would provide such an update to older hardware, even if it’s still widely used.

Difficult to exploit, already in the process of being patched. Truly, the most breaking of news.

I think they meant it as “once infected may be impossible to disinfect.” But it sure doesn’t read that way at first glance.

Here’s my vote for Bazzite. If your use case is simple computing and games? I don’t know if you can do much better.

Even with nvme drives which supposedly “don’t need” to use BFQ, I STILL always swap it since it maintains responsiveness across the system during heavy IO loads. I used to have similar full system freezes when downloading steam games which notoriously overload your IO in Linux. BFQ was the solution every single time.

Edit Try following the instructions detailed in this post to add a systemd rule to set the scheduler: https://stackoverflow.com/questions/1009577/selecting-a-linux-i-o-scheduler

The second answer that shows an actual rules.d file example has always worked for me. If using nvme or old school spinning rust you’ll need to change it up a bit. Instead of “noop” set it to “BFQ”.