OK, so the current dev implementation seems to make accessing notifications one-handed nearly impossible? You need to reach somewhere to the left half of the upper edge to pull them down - the top right corner is already far enough from my thumb most of the time to be a bit inconvenient to pull down on.

And I hope they bring back some quick toggles to the notification screen, it would be awful to have to go to the full quick settings menu just to turn on the flashlight, lol.

If you keep your Pixel plugged in for a few days, it will give you an option to limit charging to 80%. There’s no other way to activate it currently, but that should change soon (the Adaptive Charging option will have three options instead of just on/off).

I personally chose RADV after looking into this myself and the only drawback from my understanding is that they are proprietary drivers.

RADV is the open-source community developed Vulkan driver. It has the widest hardware support of the three Vulkan drivers and is generally the best for gaming.

AMD provides two more Vulkan drivers - AMDVLK is the open-source one available in AMDGPU, then there’s the unnamed proprietary Vulkan driver in AMDGPU-PRO. The biggest advantage of the proprietary one is that it is certified - doesn’t matter most of the time, but when it does, a missing certification is a deal breaker.

Pixels never had the SD card slot

Since the phones have water resistance, they are technically designed to work under water

Oh, so a device that offers no warranty in case of water damage (because you’re not supposed to expose it to water) can use an IP certification as a loophole to completely avoid this law? That’s not good

It’s likely the same sensor that is included in the rest of the Pixel 9 Pro Fold.

I see proofreading the first paragraph is too hard these days.

Don’t know about the rest, but…

Does reflashing a ROM fix it?

The phones appear to be simply dead with no response to anything. No way to connect ADB, no way to connect fastboot, nothing.

Also the bootloader allows flashing over the cable only when it’s unlocked (at least on Pixels; I couldn’t find anything relevant in the Android documentation). The vast majority of Pixels should have their bootloaders locked, and it is only possible to unlock it through the system settings, so it’s pretty safe to say that most Pixels cannot be recovered if Android fails to boot because you cannot unlock the bootloader if you can’t get into settings.

Licensing the source as GPL doesn’t really force the copyright holder (which is 100% BitWarden due to their Contributors Agreement^*, no matter who contributed the code) to do anything - they are absolutely free to release binaries built on the same codebase as proprietary software without any mention of the GPL.

For example if I write a hello world terminal program, release its source code under GPLv3 and then build it and give the built binary to you (and a permission to use it), you cannot force me to give you the source code for that build because I never gave you a GPL licensed binary.

If you were to take my GPLv3 source code and distribute a build of it however, you would have to license your binaries under GPLv3, because that’s the terms of the license I provided the source code to you under. Your users would then have the right to request the source code of those binaries from you. And if you released the build under an incompatible license, I (but not the users) could sue you for violating my license.

Their previous versions, still being under the GPL, would require them to release a change to make it usable on desktops.

License violations are usually not resolved by making the violator comply retroactively, just going forward. And it’s the copyright holder (so BitWarden themselves) who needs to force the violator to comply.

^* this is the relevant part of the CA:

By submitting a Contribution, you assign to Bitwarden all right, title, and interest in any copyright in the Contribution and you waive any rights, including any moral rights or database rights, that may affect our ownership of the copyright in the Contribution.

It is followed by a workaround license for parts of the world where copyright cannot be given up.

That depends a lot on how the license gets interpreted and how license violations are handled by the local law. The argument for why the end user cannot do anything about GPL violation is that the violated contract is between upstream and the “bad” developer - the upstream project gave the bad developer access to their source code under the condition that the license stays the same. You as the end user only get exposed to the bad developer’s license, so you can’t do anything.

However there was also a case recently where the FSF argued that this interpretation / handling of the situation is against the spirit of GPL and I think they won, so… Yeah, it’s just unclear. Which is normal for legal texts (IMHO intentionally, but I’m not here to rag on lawyers, so I’ll leave it at that).

While I agree with your view (at least when it comes to firmware, especially given that hardware that doesn’t require a firmware upload on boot generally just has the very same proprietary firmware on a built-in memory, so the only difference is that you don’t get to even touch the software running on it), the point of this project is to remove non-libre components from coreboot/libreboot.

It doesn’t differentiate itself from upstream in any other way, so if it fails to do the one thing it was made to do, then that’s in fact a newsworthy fact.

I don’t think it supports displaying HDR at all? The GitHub issue regarding HDR is still open and it definitely doesn’t switch to HDR mode when I open HDR photos with it.

The hardware supported it ever since adaptive charging was introduced, so that’s not surprising.

I do not know of any such dongle, but I’d like to ask you a question if you don’t mind: are you looking for a dongle with open-source firmware, or would a dongle that has its (proprietary) firmware stored in some onboard memory be acceptable?

The second option wouldn’t require you to install any proprietary firmware on your computer, but you’d still rely on the proprietary firmware for the device to run. And it might also exist, unlike a dongle with FOSS firmware.

Maybe developers will finally start implementing predictive back now that it’s not hidden behind developer options. It’s kinda nice when you can just peek at where the app wants to take you when you go back, and it currently ironically tends to be implemented only by apps that already have decently made navigation.

Also private space seems nice, finally a way to use the work profile sandbox natively without having to install third party apps that pretend to be work profile managers.

I know this isn’t Reddit, but r/peopleliveincities… When 90% of desktop users use Windows, it’s going to both be the most targeted by malware developers and have the highest chance of being operated by someone who doesn’t understand enough about computers to recognize that the shiny calculator app that just popped up after visiting a very legit Nigerian prince’s crowdfunding page probably shouldn’t need admin access.

And speaking of user error, I’m willing to bet that basic security practices like using full disk encryption, SecureBoot, some MAC layer (provided by antivirus on Windows, AppArmor/SELinux on Linux) and regularly applying security updates are way more common over in the Windows land - if I was in a situation where there was one completely randomly selected Windows PC and one also completely randomly selected Linux PC, and my life depended on being able to gain access to either of them (some kind of really messed up Saw trap? idk), I would definitely bet my life on the Linux one being misconfigured.

Don’t get me wrong, Linux can make for a very secure and private OS, but most installs most definitely cannot be described as such - just look at the popularity of random unverified PPAs on Ubuntu derivatives or AUR packages on Arch.

A reasonable build of the kernel optimized for virtualization won’t take more than a few tens of megabytes of RAM (and it will have support for memory ballooning, so the virtualized kernel will give the memory it doesn’t need back to the host), and the userspace will need to be separate anyway due to how different Android is to normal Linux distros.

Containers are nice when you want to run dozens of separate services on the same server or want to get the benefits of infrastructure as code, but in this case they would provide minimal benefits at the cost of having no way of loading any kernel modules not built into whatever ancient kernel version your SoC manufacturer decided you have to use on your phone. Also, container escape vulnerabilities are still a bit more common than full VM escape, so this is also good for security on top of being more useful.

box86/box64, and there’s also FEX-emu which is used by the Asahi Linux project (Linux on Apple Silicon macbooks).

Yeah, this seems properly configured. No clue why it isn’t working for you.

The only app that doesn’t auto-update for me is Fdroid itself (ironically), because it targets an old Android version. Running Android 14 on a Pixel, so with the strongest Google fuckery.

Are you sure your Fdroid client is up to date? The new API was implemented in 1.19, and apparently I even misremembered and all you have to do to enable Fdroid to auto update its apps is to manually update them for one last time (so no fresh installation required).

Another long shot: there’s an option to force the old installation method hidden in expert settings - maybe you could check if that isn’t enabled?

On a normal unmodified phone you have to manually confirm each app you want to install. so no auto-updates in the background etc.

Background app updates are possible since Android 12, Fdroid just took two years to implement the new API (and you have to do a fresh install of the apps - apps already installed using the old API still require confirmation on each update). There is still friction on the initial install though.