No, it will fast charge to 80%, then restart charming just in time to hit 100% when your alarm goes off (or when it thinks you're going to wake up). There's no automatic slow charging other than thermal throttling.

Wow, first time I feel strongly about a quick settings update. It looks awful, taking the worst parts of the Android 12+ redesign and combining them with the worst ideas from the older design, like unlabeled icons.

It looks like there are unlabeled icons in the expanded state? Wtf? If I'm expanding the quick settings, that means I'm fishing for the less used settings, so there's no way I'm going to remember that for example the weird circle with a small segment cut out means "Data saver". It will just be a mystery icon that does some mystery action - that has nothing to do in a modern OS.

It looks like this design is heavily sacrificing usability for people who don't spend hours every day mucking around with quick settings in order to please some hypothetical user who feels more slowed down by swiping over one or two screens than by having to find the one setting they currently need in a big matrix of poorly designed icons.

Edit: also it looks like the home screen is visible under the quick settings - I'm not a big fan of that, I really like the current design where the notifications are pretty much their own separate screen without distracting app content, but that's just my subjective taste. Unlabeled icons are objectively bad.

Then what's the meaning of this whole part?

On non-corpo linux syslog can be disabled if you want, though I'd prefer to just symlink/mount /var/log to a memory filesystem instead.

Is it just a random tidbit that could be replaced with a blueberry muffin recipe without any change of meaning of the whole comment? Because it sure won't help OP at all with their Arch-specific question, so it's either that, or it provides contrast to the "corpo Linux", which is how I interpreted it.

And here's the remaining part of your comment I left out, just to make sure people won't lose the context between two three sentence long comments (for those without any attention span, it comes before the previous quoted part):

If you're on arch you use redhat's garbage.

On non-corpo linux syslog can be disabled

systemctl disable --now systemd-journald

I'd prefer to just symlink/mount /var/log to a memory filesystem instead

Set Storage=volatile in /etc/systemd/journald.conf

Vista's problem was just the terrible third party drivers and the fact that it was preinstalled on machines it had no business running on. 7 didn't improve much on it (except fixing the UAC prompt so that it no longer made you feel like you're using Linux with misconfigured sudo timeout), but it had the benefit of already having working drivers from Vista and proper hardware capable of running Vista/7.

Apparently it's an EU thing due to the recent DMA changes

https://www.androidpolice.com/google-pixel-launcher-change-default-search-engine/

It should not be controlled by a company that is known to make you lose your games.

Are you referring to the fact that Valve promotes digital game distribution (which is a very fair view), or are you talking about some incident where Valve removed games from people's libraries? Because if it's the second one, then I would really like to hear about it.

You still need some privileged process to exploit. Glibc code doesn't get any higher privileges than the rest of the process. From kernel's point of view, it's just a part of the program like any other code.

So if triggering the bug in your own process was enough for privilege escalation, it would also be a critical security vulnerability in the kernel - it can't allow you to execute a magic sequence of instructions in your process and become a root, that completely destroys any semblance of process / user isolation.

Cool, so it's like two years ago

Oh...

Oh no

They seem too small and consistent in size to just be bundles of system apps that got security fixes

Correct, just one note here: system apps (both APK apps and APEX system modules) are updated through Google Play like all other apps, the monthly security patches are a layer below that - it updates the base OS files like firmware and kernel modules. More info about APEX

Are they like differential patches or something?

Yes, that's exactly what they are. Small differential patches (often called delta patches / delta updates) to the files.

Btw apps are also getting delta updates through Google Play for at least a few years now (5-ish?)

And what happens while the 'finishing system update' notification is shown?

Android Runtime (ART) works by compiling the Java bytecode in apps to native code before running them - it's called "ahead of time compilation". This compiled native code is specific to the device, OS and system modules, and some of the modules probably changed during an update - that means the OS has to recompile all the native code against the new updated modules, and that takes some time to do for all installed apps. There can also be updates to the ART module itself that improve the way ART compiles code, and that also requires recompilation to have effect.

as far as I can tell the phone remains unlocked while updating, so why do they need it to be booted to finish the update? Is it just to turn on the phone faster?

There's a mechanism called A/B partitioning where there are actually two copies of the OS installed. To update, you copy the current OS into the other slot, then apply all the updates to it and finally mark it as the active slot. When you boot your phone, the bootloader looks up the active slot and boots it (and switches the primary slot back if it fails to boot a few times in a row).

The OS can be updated during a reboot and that's how some vendors still do it, but the downside is that the phone cannot be used during updating. With A/B partitioning and background updates, you can use your phone like usual and then reboot as quickly as any other reboot to apply the updates.

Yes in the sense that the APIs were made because of flatpak, but not in the sense that devs would need to keep two separate code paths for flatpak vs non-flatpak - portals work everywhere.

No, face unlock on Pixels doesn't do anything to illuminate your face, it simply refuses to work if the lighting's too dim. It's actually worse than the face unlock in Google Smart Lock in dealing with low light environments.