For some reason I can’t get behind, this feature requires some virtualization mode with lowered security features.
The usual virtualized devices like network cards (that are already supported by Linux distributions like Debian) work by the hypervisor intercepting memory access to certain memory regions. Perhaps it’s not viable to support these with the secure approach where the VM is protected from Android.
OK, what exactly does an average person need a computer for that cannot be adequately done on a phone? Because I do have a few relatives with computers that just gather dust permanently returned off, and they don’t seem to mind.
“Oh, you didn’t spend at least a few hundred dollars on a device that you aren’t going to use for anything except flashing a custom ROM once? What a moron!”
Right, but the commenter above me seems to suggest that GrapheneOS removed the battery management in order to bring the charging limit back, which is why I asked.
Wait, did Android 16 QPR 1 remove the charging limit for newer Pixels? My 7a has both the Battery health assistance option and the original optimization modes (off, adaptive charging and 80%).
Also, Google is no longer releasing the Pixel-specific source code, meaning you can no longer just build AOSP for new Pixels and have all the hardware just work - this makes it harder for custom ROM developers and might eventually lead to some hardware being simply unsupported unless you use the stock ROM.
Your screenshot is misleading - apps installed from alternative marketplaces on iOS also need to be signed by a certificate linked to a known developer by Apple, exactly like Google wants to do it on Android.
Just to be clear, the applets were stuck while the laptop was plugged in? If so, then it might just be the threshold - connected, not charging, not discharging (because the laptop is running off the AC adapter).
For example on my IdeaPad laptop, when I enable the charge limiting feature it will get “stuck” at 59 or 60% while plugged in. It doesn’t have a configurable threshold. Although your laptop might provide a more fine-grained control given that you were able to fully discharge it while plugged in.
I agree, the fact that Meta considers 13 year olds being able to have romantic chats with chatbots to be perfectly fine is disturbing and IMHO the main newsworthy thing here.
However there is no mention of “200 pages of romantic interactions with minors” in the article - that is the whole chatbot guidelines document. Still, it including such things shows how shitty Meta is as a company.
OK, so the whole LLM chatbot arranging dates with people thing is obviously problematic, but this person simply tripped and fell, and the headline vaguely implies that the chatbot is responsible for his death. That seems a bit clickbaity - if it was a real person and they were actually waiting to meet at the agreed upon address, the outcome would be the same.
I don’t understand how having a notification is what’s keeping an app alive.
Do you remember notifications that couldn’t be swiped away in older Android versions? Their point was to keep their app alive. They still exist and still work the same way, keeping their app alive until it cancels the notification, except they can now be dismissed like any other notification (which doesn’t really have any effect other than hiding it from you - it will still keep the app alive even when hidden).
It’s possible that it’s broken in AOSP for some reason, but developer documentation says it should work like this and it does indeed work like this on stock Google ROMs on Pixels.
why would swiping away an app not kill it? why would you do that? leave it be until it’s done wtf
Because if an app has a permanent notification, it cannot get killed. Before Android 15 or 14, you couldn’t even swipe such notifications away - the idea was that the app was forced to tell the user it’s running.
Then Android added a list of apps running in the background and allowed users to dismiss the permanent notifications, but the behavior is still the same - an app can keep itself alive until it removes the notification on its own or gets force killed either by doze or from the settings.
So swiping away a browser after you initiate a download is a perfectly valid use case that is intended to work without any problems. If it doesn’t, then it’s a bug either in LineageOS or in the browser.
Also, I can confirm this works perfectly fine on stock Android 16 ROM on a Pixel with Vivaldi browser - the download finished, and then Vivaldi got killed, because nothing was keeping it alive after it cancelled its download notification.
Idk, it surprises me it took so long for TP-Link to get into trouble with how they tend to support every HW revision of their routers for about a year and then stop releasing any security updates for them. That’s awful for a device intended to sit at the edge of your network, possibly having a public IP address.
Like sure, you can look for any reasons you want, but not giving a fuck about security in a device that’s always connected to the internet and also routes all user traffic is bound to get companies in trouble when someone with the power to do something about it notices.
Apparently not according to the other comments here, but I absolutely love Material You now that a lot of apps support it. Not having every app have its own color scheme just feels comfortable and IMHO makes a lot of sense together with the system-wide dark mode.
Also, the app drawer always has unthemed icons, the themed ones are only for the home screen where I like to keep the few apps that I use often, so not having a colorful mess for a home screen is a bigger plus for me than losing the ability to recognize them at a glance, because I know exactly where on the home screen they are anyway.
I mean, first there was the 4a with its software update that rendered affected batteries nearly useless, then the battery recall for 7a, and now there are apparently some restrictions for the 6a in the new update
TL;DR: the minimum went from 16 to 32 GB
xfwm is XFCE’s window manager, and it’s eating almost 30% of the total system memory, so that’s the prime suspect (I’m not exactly sure how much it interacts with other apps, so it’s possible something else is forcing xfwm to use all that memory, but that is IMHO unlikely).
An ugly “fix” is to log out and log back in (yes, not much better than just rebooting), or you could try to somehow restart xfwm - running xfvm --replace in terminal might work.
Edit: there’s an issue on the Manjaro forums that might be related: https://forum.manjaro.org/t/xfwm4-memory-leak-since-4-20/173910/7
That was my deleted comment, but then I realized the article specifies they are Rome CPUs (Zen 2), while the 4000 series of EPYCs is based on Zen 4
This is seriously cool. Although the current specs are a bit funny - if you take the largest possible disc size (360 TB), then it would take a million hours to fully write it at 10 MB/s (more if the storage unit is actually TiB). That’s over a hundred years.
Also if the goal is datacenter archival, then I wonder what the plan for practical use is - many individual discs with separate write “heads” (basically a RAID 0) to bring the speed up? And then maybe the maximum size per disc is a theoretical limit for the technology once we get faster access rather than something practical they intend to build anytime soon.