"New firmware-based battery charge control, which offers fixed a 75%/80% threshold setting. To use this, you need to update your system firmware to at least version 13.0, which you can do by simply updating your macOS partition to at least that version or newer. This new charge control method also works in sleep mode."
This is interesting, am I correct in thinking this a feature implemented by Apple and now supported by the Asahi team? Does that mean that macOS supports this charge control feature?
I really hope Apple brings the same charge limiting to iPhone as well.
> This is interesting, am I correct in thinking this a feature implemented by Apple
Yes, battery charge control is a hardware(/firmware) feature supported on other modern laptops as well, such as the Lenovo ThinkPads, but it's not a standard so it requires explicit driver and OS support.
OpenBSD recently added support for this as well for both of these implementations (Apple silicon and ThinkPads).
In my experience for it to take effect you need either a predictable window of plugged in time (it will delay charging until it needs to to hit 100% by when you normally unplug) or just to use your compute almost exclusively plugged in (at which point it will start letting the battery drift down to 80%). If you regularly unplug to work on the couch or whatever you may not ever see the effect directly unless you wake up an hour early to check the charge state of your laptop.
I really want to try this out on my work ThinkPad since it stays plugged in effectively all the time. It requires a kernel module though, I'd need to get that approved first and I haven't got around to it.
Naïve me doesn't understand why it can't be done from userspace, but I'm sure there is a good reason...
If your laptop firmware doesn't support it, here is one trick if you have a removable battery:
Put a piece of paper over one of the batteries middle contacts. That will make the firmware think the battery is overheating. It will then refuse to charge, but will still happily discharge.
You can do that to keep your battery at 80% while still on AC power. Handy if you operate from AC power 99% of the time, yet don't want your battery to die from being stored at 100% charge and hot for many years.
> Put a piece of paper over one of the batteries middle contacts.
Bad, very bad idea if you don't know what you are doing - depending on where the "smarts" in the BMS are, you may damage your battery or make your BMS think the pack is broken or prevent your BMS from recognizing a charge state mismatch (and in the worst case, a cell going undervoltage or reverse polarity) as you have a good chance that you cut off one of the cell balancer contacts. This trick only works with removable phone batteries.
I'm a corporate firefighter assistant. If there's one thing people should not be messing around with, it's Li-Ion batteries. These things are dangerous enough even without people messing around with their control and management systems.
> I really hope Apple brings the same charge limiting to iPhone as well.
This was added to iPhones in 2019.
> If your iPhone stops charging at 80%, it's most likely due to a feature Apple introduced in iOS 13 called Optimized Battery Charging. It aims to prevent over-stressing the battery and hence extend the battery life of your iPhone by limiting the charge to 80%.
Your iPhone learns your usage patterns and delays 100% charging until moments before you wake up in the morning.
It's a bit different, though. I don't often need my iphone to last multiple days on end. Yet, if I keep it plugged in as often as I'm sitting at a desk, it'll never go below 80%. If I get it below 80%, sooner or later, it will figure "i want to use it" and will charge it all the way to 100%. The lowest my battery ever got on this phone was 40 something when I was away for a weekend without a charger. It's very rare I use it a lot, so the "intelligence" clearly doesn't care how long the battery needs to last.
The way it's implemented on my mom's android, it always shows 80 or 85% (can't recall which one it is), even if she leaves it plugged in for the whole weekend.
On my HP laptop, if I activate the "battery saver mode" (as opposed to "AI"), it reports the maximum capacity as somewhere around 80% of the design capacity. I don't know whether Linux cooperates with this, but probably not. HP only talks about OS compatibility for the "AI" mode, which not only requires Windows but a specific HP app.
Sure, but if I know I won't drain my battery more than 10% that day, I can't tell it not to top it up more than 80%. That's the case for me 99.9% of days.
This also seems to work only if you've drained the battery below 80%. If it says 90% and I plug it in? It'll charge it fully right away.
It doesn't charge the battery over 80% at all, unless it detects that you have a normal waking time, in which case it charges fully right before you normally wake up.
Unfortunately, other companies copied the 80% charge bit without copying the part about figuring out if you have a normal waking time and giving you a full charge right before that.
For instance, Samsung's S23:
>Once you turn off the battery protection function, you'll be able to charge your battery up to 100%
> It doesn't charge the battery over 80% at all, unless it detects that you have a normal waking time, in which case it charges fully right before you normally wake up.
My iPhone disagrees with you. I go to bed and wake up at just about the same time. If I somehow managed to drain the battery below 80%, when I plug it in, it'll charge to 80 and then tell me that by the time I wake up in the morning, it'll be fully charged. Which is the case.
But the most common use case, for me, is waking up, leaving the phone plugged in (WFH). Maybe go for a walk around noon, snap a picture or two. Forget to plug it back in and get back to work. Plug it in as I go to bed at 95%. It tops right up, doesn't wait until the morning.
> Unfortunately, other companies copied the 80% charge bit without copying the part about figuring out if you have a normal waking time and giving you a full charge right before that.
But that's actually what I want. With very, very rare exceptions, I never need a full charge on my phone. Hell, until a few weeks back, I was rocking an iphone 7 with a battery in a questionable state (started bulging). That thing never went below 60% with my use patterns. 60% meant night out, so a hefty dose of maps use. Normal days, it didn't go below 85-90%.
I think the issue is that Apple expects that when you wake up in the morning, you unplug your phone for the day and actually use it a significant amount. Which isn't my case at all. If I don't leave my house, it'll stay plugged in. I usually forget about my phone since everything I need to do, I do on my computer. For the occasional phone call, I can either keep it plugged in (the cord is long enough) or it's already connected to my headset, so don't even need to go fetch the phone. If I don't go to work, it can stay plugged in for days on end (I don't always grab it when I go out).
Because it's my understanding that charging and keeping it all the way full shortens significantly its battery life compared to 80-85%. I would rather not have to dick around plugging and unplugging the phone to not have it be full all the time. Plus, that also counts as consumed cycles.
I've used my old phone for a good six years. I've swapped its battery some three years ago, and it would've needed a new one now, had I continued using it.
If that phone is any indication, my current one should be in service for at least as long. If I can avoid having to swap its battery, it's a win in my book.
It can also sometimes happen that I foresee being away from an outlet or otherwise need as much charge as possible. In those situations, I'd just deactivate the battery saver feature and let it charge to 100%. So if the remaining capacity is closer to its original one, again, it's a win.
> If you don't charge fully until just before the user's normal wakeup time you aren't keeping it all the way full all the time.
You keep repeating this and seem to ignore my observation that if the battery isn't drained below 80% when I plug it in, it will recharge it fully immediately. It will not wait until the user's wake-up time.
And in my case, it's rare that the battery falls below 80%, so whenever I plug it in, it gets recharged fully right away.
So, in practice, it's all the way full all the time.
My Sony Xperia 10 IV lets you set it to never charge above 90 or 80 %, as an alternative to it learning your habits. I have it set to 80%, and I've been unable to use it up in under 2 days. I've heard that iPhones have similarly good battery life as the 10 IV, so it seems, to me, that get quite far on 80%.
I bought the same phone recently, and for my light usage pattern (some texting, the browser, Google Translate, Google Maps, a calculator app, and the camera), the battery lasts almost 5 days!
I had completely forgotten how it is to own a phone that doesn't need to charge everyday...
> This is interesting, am I correct in thinking this a feature implemented by Apple and now supported by the Asahi team? Does that mean that macOS supports this charge control feature?
It does, but in a weird way. You can turn on "adaptive charging" and it will randomly decide to charge to 80%.
If you want to properly control it, just install the wonderful AlDente utility ( https://apphousekitchen.com/ ). Then you can manually control the max charge percentage. Mine is permanently set to 80% because I never really use even 40% of the battery on my M2-based laptop.
Sorry to hear you lost access to the document, I hope you can regain access.
It might be be a good idea to use a tool like Rclone to create a local copy of the data going forward. It allows you to download Google sheets as .xlsx files.
At least as I understand it, in implementations like yubikey the FIDO2 secret is baked-in to the yubikey for security, which is good as it shouldn't be possible to remove the private key.
However the main issue I have is that the user cannot import their own secret into the yubikey, so you cannot choose to use your own secret vs the factory generated one, or choose to have multiple yubikeys using the same secret, which would be useful as you wouldnt need to enrol multiple secrets with each service.
> However the main issue I have is that the user cannot import their own secret into the yubikey
Where would you get this secret from in a secure way? How would you prevent a nefarious actor from exporting it and importing it into their own yubikey or similar?
Secrets are easy to securely generate and it would allow importing, not exporting. If you allow importing then the user can generate the secret, store it somewhere safe and import it into the device. Then if they lose that device they can just write the saved secret to a new key.
Various strategies that trade off security vs. convenience. Most secure is probably something simple like printing it out and putting that in a fire-proof safe. But there are lots of options. For the non-tech parents or some such, a nice pass-phrase would probably work well as the secret.
How do you get this pass-phrase from paper onto the yubikey without an adversary getting hold of it?
I'm not trying to be pedantic here, I'm just failing to see how this can be realistically implemented without significantly lowing the overall security. But this is also not my domain, so I'd like to learn.
Importing keys into an HSM/key storage device is not an uncommon exercise.
If you're asking about the structure of the bits you'd need to move into the device in a verifiable way, there are standard APIs like PKCS #11 for interacting with HSMs.
You would then need a computer and a PKCS #11 client application. If you don't have a computer you can trust to pass keyboard inputs to a USB port without being intercepted, you've got problems that a yubikey will not solve.
Synology SHR is btrfs (or ext4) on top of LVM and MD. MD is used for redundancy. LVM is used to aggregate multiple MD arrays into a volume group and to allow creating one or move volumes from that volume group.
It's not exactly part of the webauthn standard. Or at least not a described part, it falls under the 'roaming authenticator' and 'backup credentials' mentioned in the spec, effectively it's a function that generates a crypto key where the key matter is the 24 randomly chosen words. It's basically just _another_ key that a service can setup and store for your, but encrypted with the secret they share with you up front in the form of those words.
The Ledger hardware wallet can act as a FIDO U2F (probably other hardware wallets as well). And to back up a hardware wallet you write down the 24 words…
looked interesting, but is around double the price for around max 2 hours viewing per day, with no guaranty of supporting BBC streams. from experience I'll presume they know about this service and are actively blocking their subnet
I'm paying around half the price for unlimited viewing of direct streams (no faffing with client protocols) which come transcoded for home and mobile usage
It should be possible to enable Cloud Identity Free on your gsuite tenant. So you can use a free identity account for your admin account and only pay for gsuite on your main email account.
They are available on Amazon.