For me it works fine, but I guess that might be because I use the flatpak version of Firefox.
For me it works fine, but I guess that might be because I use the flatpak version of Firefox.
deleted by creator
I don’t doubt the fact that they take some margin to extend the lifetime of the battery, but if we take iPhones as an example, they:
This makes me suspect that that the margin between what’s reported in software as 100% and the actual capacity of the battery is less than 20%. This also makes sense from the standpoint of the consumer expecting a long battery life on their expensive high-end device, putting pressure on the companies to make the margin smaller and the charging algorithms smarter. Just my observations, of course.
I’m pretty sure that Chrome’s alternative is designed by Google to track you in a way that’s harder to block and gives them more control over the advertising market by forcing advertisers to play along and use their method instead of collecting your data directly. Sure, it’s more private, but it’s still tracking you.
Firefox, on the other hand, is focusing on completely blocking cross-site tracking. They have no incentive to completely block 3rd party cookies as long as there is also a legitimate use case for them, but I guess they will eventually also block them if Chrome is successful in forcing websites to stop relying on them for core functionality.
For general usage, it doesn’t really matter. Distrobox is inspired on toolbox and provides some added functionality and configurability, like init scripts and the ability to run different distros, as well as creating desktop shortcuts on your host system. If you don’t need all of that, I’d stick with toolbox, as it’s preinstalled and works well.
The regulation actually enforces that PD is implemented if high speed charging is available and that it can’t be limited in speed compared to any other charging protocol that’s also available on the device, irrespective of the charging device used.
We don’t need to guess if we can just read the regulation: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32022L2380&qid=1691523718368.
Imagine a system where you are just an end user, one of hundreds or even thousands, and the admin removes an application. I would be furious if the admin would also delete my personal application data from my homedir. There could be important settings in there, that I might want to move to another system, or maybe I’ll install my own flatpak in my homedir and continue to use those settings. There could be stuff in there that’s important and for which no backup exists.
So how would you implement that: would you, while uninstalling a system flatpak, be given the option to only remove your personal files and leave the files in other homedirs intact? Or should it remove the files for all other users too, without their permission? In my opinion the best way is to just leave the files alone. I think it makes sense and I think using a 3rd party app to remove the remnants is fine. It works the same on Windows, MacOS and Linux. Maybe adding something to the OS to detect these files and ask each user independently would be a nice addition, but not as part of the uninstall process of the flatpak.
The user data in your homedir is usually left intact, which makes sense to me, especially in a multi user environment. That’s not unique to flatpak either. If you reinstall you retain your settings, session, etc. For flatpak you can find those in ~/.var/app
.
I’m using Kagi, which aggregates search results from several search engines (including their own), but without the ads, with less crap and with features like searching for literal strings and promoting/demoting certain websites. It’s a paid service, though, but I like it enough that I’m ok with that.
The kernel is written in C and a bit of assembly. When support for a new language is added, that’s big news and worthy of headlines. The other languages are just there for various tools and helper scripts and are not used for kernel code, so not newsworthy by any means.