Kernel 7.3 has a device driver (the intel iGPU driver) which was assisted by AI. This was done by Linus himself, not someone random.
So anyone refusing to run AI assisted code is stuck on Kernel 7.2, or needs to disable this driver.
Unless there's a USB standard for RGB lights connecting it via USB doesn't magically mean "no driver needed".
USB keyboards with RGB require a specific driver for the RGB to work. The keyboard part works without a "driver" (which really isn't true, there still is a driver).
There is a windows API for it.
I'm not whomever you're replying to, but you replied "apple does" to "there are many many different pieces of hardware which would have to be supported and nobody is bothering".
Lots of apple people would love RGB LEDs. I would love if my steering wheel worked on OSX.
What third party peripherals is apple writing drivers for?
kWh battery. Knew I'd miss that at some point.
Okay, that's amazing.
Here (Australia, all AUD) I pay 28 cents per kWh and get paid 5 cents per kWh. I have 12kW solar which was great when they paid 12cents, but now it's not so I got a 30kW battery and it's paying for itself pretty quickly. Battery was $6k AUD installed.
For at least a year (maybe more) I thought that it was go-dot, kind of a play on dotnet. Especially with the work on adding c# support.
I so dumb!
I can't find any reference to this. Not saying it hasn't happened, I just don't see it on the internet. A link would be useful.
I've had Linux kill a motherboard (would boot, but fans and sensors didn't work so it would overheat and crash pretty quickly) setting up lm_sensors.
Wait, no electric windows? That's not a luxury feature since the late 90s.
I like the idea of this (here in Australia there's no inexpensive EV utes), but that's a step too far.
A bit like the ship of thesus
75% is pretty close to a monopoly
I hate snap, but for an average computer user (not Linux enthusiast) there is nothing wrong with it. Steam was an issue for a while but that's been resolved.
I found the setting for this: chrome://password-manager/settings has a "Use Windows Hello when filling passwords". It was off for me - I can only assume that is the default, as I have several Chrome profiles over several PCs and it's off in all of them.
Also noticed there's this:
Set up on-device encryption
For added safety, you can encrypt passwords on your device before they're saved to your Google Account
which, if I click on, takes me to a page that just says "On-device encryption canâ(TM)t be used for this account. Sign in to another Google Account and try again."
Ah interesting, never seen that before! I've just turned it on to see how annoying it is.
Chrome does require authentication for every password retrieval. It uses Windows Hello as well so in theory you don't even have a password to intercept since something like facial recognition authentication via a FIDO2 handshake is what ultimately allows Chrome to fill a single password on a single site.
Maybe I'm misunderstanding what you mean by 'auth' here, but on my PCs (Windows 10):
It does require auth for passkeys, I think every time, but not for regular saved passwords in the browser. I have Windows Hello set up for a couple passkeys and I have to auth via Hello when I use them.
But I have regular saved passwords for almost every other website I use routinely and am not prompted to auth via Hello for that. My understanding is that for these, the auth/unlock is done once at user login and then the session has access to the unencrypted passwords.
(I posted elsewhere in this thread about Chrome using DPAPI as of 2024 - this was news to me so it's possible I'm just way out of date).
Remember Darwin; building a better mousetrap merely results in smarter mice.
