Markaos

Yep

Usually the problem isn't that the changes are big, but that the new way simply isn't compatible with the old way to do things, and you can't just make a change that will break existing applications in minor versions (well, there's nothing technically stopping you, and unintentional compatibility breaking bugs have definitely happened in the past, but people are gonna get real mad at you if you do that). Even if you break that change up into thousand tiny changes over many minor versions, the end result is that at some point, you break old apps.

The solution is to take note of all the things that are either badly designed or became obsolete and once in a while go "hey, let's make a new major version and fix all of this crap". With a new major version, you don't have to worry about old applications and are free to improve your library in any way you wish, and you also get the option to keep updating the old major version with some maintenance bugfixes so that the old apps keep working well enough.

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, kernel immediately stops execution of all normal processes once it gets into a kernel panic, and there's no way for processes to hook into this functionality. It is intended to be the emergency stop state when the kernel realizes it doesn't know what's going on and it would be dangerous to continue executing. So it does the bare minimum to report the issue and then stops even its own execution.

There's also a softer variant of the kernel panic called kernel oops that should let the user choose to continue if they think the risk of data corruption doesn't outweigh losing all data currently in memory. But just like the kernel panic, it is handled completely inside the kernel and userspace is frozen until the user chooses to continue.

This is intended for situations where systemd runs into an unrecoverable issue while booting (for example you have misconfigured fstab and a required disk is missing). Without this, you just get thrown into the terminal with some error messages that might not make much sense to you if you don't have a decent understanding of Linux. Now, you get a more newbie friendly message and a QR code that should bring you somewhere you can learn more about possible causes and troubleshooting steps.

Well, this goes the other way than ray tracing - it degrades graphical fidelity but improves performance. That should result in better FPS at the same power consumption or lower power consumption at the same FPS in games, and mobile gamers will probably welcome both effects.

Have you tried fully discharging it? It depends on the specific battery management system in your phone, but my Pixel 7a doesn't take being kept at 30-60% battery too well and loses track of the actual charge level. AccuBattery was reporting about 80% capacity on it after two months.

Then I decided to let it fully discharge and found out that the thing just refuses to die at 1% - that last percent took me about the same time to discharge as going from 20% to 1%. And now I'm back to 98% capacity reported by AccuBattery and the actual battery life has improved noticeably.

Yeah, 24 hours of SoT is impossible with Pixel 7 series. I mean, the idle drain alone will kill my 7a in 48 hours, and any amount of active use will just make it worse.

This is after two days of sporadically checking email and taking a few photos (about 40 total, no video) on stock Android 14:

Nowadays, even the cheapest phones are sufficient in terms of power for the most demanding regular user activities such as social media , watching videos, taking good enough pictures and light gaming.

Eh, try doing that with HMD's Nokia 5.3 - Instagram was a PITA with frequent long stutters and the official YouTube app was nearly unusable (NewPipe for the rescue). Oh and its camera app also kept randomly forgetting to actually save the photos I took after updating to Android 11 (which came with a year long delay behind upstream, so I was already out of warranty once it hit), and Android 12 update earlier this year did nothing to fix the issues but made it so that factory resetting would permanently brick the phone, so that troubleshooting option was also gone.

There were other issues with unreliable rear fingerprint sensor and touchscreen towards the tail end of me owning the phone, but I'm willing to consider those hardware issues with just my unit.

Yes, I'm a tiiiiny bit salty about that, mostly because Nokia is the last cheap way to get close to stock Android and now I just have zero trust in them and am forced to pay more for a Pixel.

Nokia 5.x wasn't even the lowest product range, they also made corresponding 3.x phones, but maybe those were better thanks to Android Go?

The thing is that they've clearly promised 7 years now, walking back on the promise would cause them massive issues with consumer protection agencies everywhere they sell - they might be toothless in the US, but Google also sells Pixels in Japan and the EU.

They were talking about old iOS getting a system update just to update WebKit/Safari which then generated quite a few news articles about how long Apple supports old phones. Their comment made perfect sense, they just didn't know how Android works internally.

System apps can be updated through Google Play (or any other channel) just fine. The version bundled with the system is just the baseline you can always revert to.

During a system update, the system apps only get updated if you don't already have a newer or same version installed (no automatic downgrades).

other than to outright disable dxvk

That's exactly what you want. DXVK is the "new" DirectX to Vulkan translation layer (that's where the name comes from), and if you disable it you will be using the DirectX translation layer from Wine which uses OpenGL