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.

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.

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.

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

Try swapping to BFQ io scheduler and see if that makes a difference.

I’m going to assume it’s not Universal Blue… But parts of your description reminded me of it.

I have personal experience with BTRFS and Windows. And that experience is that it’s roughly as stable/complete as NTFS is for Linux. 6 of one and a half dozen the other. I can’t recommend either situation for guaranteed stability long term between systems if one really needs to swap between the OS’s frequently while accessing all the same files.

I can vouch for Bazzite. Been running it on my desktop and laptop (both amd gpu’s) with virtually no issues or hiccups. The desktop is even dual boot, despite that not being advised.

Maybe not too helpful, but could point you in the right direction: you used to be able to use “gksudo” to get the graphical popup requesting your password in lieu of sudo which would only ask for a password in terminal. I believe gksudo is deprecated/non-existent at this point but there’s got to be an alternative out there. Best of luck!