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.
But Wayland isn't a thing on its own, there's no "Wayland server" or anything else equivalent to the X server. The compositors like Kwin or GNOME's Mutter are Wayland implementations fully responsible for handling the display output.
You can blame Wayland for the lack of universally supported global hotkeys or for issues with apps that need to know exactly where on the screen they are - these are issues with the protocol - but not for bugs in one compositor's implementation of display management.
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.
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
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.
See? Hidden in an image, clearly that's steganography! /s
Yeah, but a lot of those things will trip the TPM module, so you will get a different decryption key if you for example try to use the single kernel parameter to boot into a root shell. And different decryption key means no access to the data.
If you boot the computer into the currently installed OS, you will be presented with a login screen and will have to enter the correct password to log in (kernel parameters are part of the checksums, so booting into single-user mode won't help you, that counts as a modified OS). If you boot a different OS, you won't get the key off the TPM.
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.
Markaos
joined 1 year ago
Ah, the joys of requiring non-standard library calls for apps to function.
The problem is that this approach breaks the C standard library API, which is one of the few things that are actually pretty universal and expected to work on any platform. You don't want to force app developers to support your snowflake OS that doesn't support C.
The current way forward accepted by every other distro is to just recompile everything against the new 64-bit libraries. Unless the compiled software makes weird hardcoded assumptions about sizes of structs (hand-coded assembly might be one somewhat legitimate reason for that, but other distros have been migrating to 64-bit time_t for long enough that this should have been caught already), this fixes the problem entirely for software that can be recompiled.
That leaves just the proprietary software, for which you can either have a separate library path with 32-bit time_t dependencies, or use containers to effectively do the same.
Sneaky edit: why not add new 64-bit APIs to C? Because the C standard never said anything about how to represent time_t. If the chosen implementation is insufficient, it's purely on the platform to fix it. The C17 standard: