fa3556

Xiaomi phones also have it but you can block Wi-Fi only for user (non system) apps. However you can block mobile data access to all apps.

None of the Samsungs I have owned so far had this feature and neither did my last Pixel.

Tweaks are divided into essential and advanced. The essential ones shouldn't have any negative impact on the system. They also document the changes each tweak makes (so you can undo them): https://winutil.christitus.com/dev/.

Maybe. The appeal of distros like these is lost on those who know linux well. If you are new to linux, the difference between Aurora/Bazzite/Bluefin and base fedora (silverblue, kinoite) can be like day and night.

I feel like the ship has sailed for X11 or any fork of it, regardless of its technical merits (or the lack thereof). All the major DEs (KDE, Gnome, COSMIC) are either already wayland exclusive or soon will be. New DEs like niri, hyprland, sway, etc. are all wayland only from the start (some like niri dont even have xwayland support, instead pointing users to an external project, xwayland satellite, for running X11 apps).

And for almost all the somewhat famous traditional X11 DEs or tiling managers or wms, there is now a wayland compositor mimicking them. Cinnamon and XFCE both have advanced wayland sessions (a recent review of LMDE 7 by distrowatch praised Cinnamon's wayland session as even better than KDE's wayland). They might support X11 for now but it will be increasingly harder to maintain both especially if the majority of their users use the wayland session. This will lead to bit-rotting of the X11 code paths both here and upstream (GTK, mutter, etc).

There are obviously people unhappy with wayland because it has issues with accessibility or automation or other more niche use cases. As hard as it may be, I think the time would be better spent solving these issues in wayland instead. If it cant be solved upstream, downstream protocols like the wlr-protocols can be an option. In fact, even upstream, ext-namespace protocols only require 2 ACKs which shouldn't be too hard to get especially once more wayland compositors join upstream development.

This starts to impact the entire stack as toolkits, mesa drivers, etc. are increasingly developed with Wayland in mind and are simply better tested there. IMO wayback is probably a more fruitful investment than an x11 fork for those who want to run traditional X11 DEs.

You could use the about:config preference browser.profiles.enabled in the meantime I suppose.

No I don't use sync at all. I think it might just require `browser.profiles.enabled` to be set to true in about:config, at least until wider rollout.

You can (now?) create profiles from the account icon in the toolbar [1] and at least on my firefox install, you can also do it from the hamburger menu.

I use firefox via flatpak and had no issues so far accessing profile data (in one of the folders in ~/.var/app/org.mozilla.firefox/.mozilla/firefox/ - I keep a regular archive of the entire folder as backup).

[1] https://support.mozilla.org/en-US/kb/profile-management

I understood GP's point to be that because Obsidian leaves a lot of functionality to plugins, most people are going to use unverified third party plugins. On arch however most packages are in core or extra so for most people they wont need to go to AUR. They are more likely to install the flatpak or get the appimage for apps not in the repos as thats much easier.

yay or paru (or other aur helpers afaik) are not in the repos. To install them one needs to know about how to use AUR in the first place. If you are technically enough to do that, you should know about the security risks since almost all tutorials for AUR come with the security warnings. Its also inconvenient enough that most people wont bother.

In obsidian plugins can seem central to the experience so users might not think much of installing them, in Arch AUR is very much a non essential component. At least thats how I understand it.

I think this criticism is unfair because most common packages are covered by the core and extra repos which are maintained by Arch Linux. AUR is a collection of user build scripts and using it has a certain skill cliff such that I expect most users to have explicit knowledge of the security dangers. I understand your concern but it would be weird and out of scope for Arch to maintain or moderate AUR when what Arch is providing here amounts to little more than hosting. Instead Arch rightly gives the users tools to moderate it themselves through the votes and comments features. Also the most popular AUR packages are maintained by well known maintainers.

The derivatives are obviously completely separate from Arch and thus are not the responsibility of Arch maintainers.

I feel like the only other solution to kernel-level anticheat is some kind of measured and verified system image. The whole chain has to be signed and trusted from the TPM through the kernel to userspace. This way if anyone tampers with the system the game will refuse to launch. I think something like this is already possible with systemd or is at least the long term goal IIRC from Lennart's blog.