There definitely are sites that block or restrict accounts using ProtonMail addresses. Obviously social media sites will be more likely to force an account to provide a phone number if one is using a proton mail address compared to for instance, a GMail address. There has been one site I have seen block/restrict ProtonMail outright, and that is Lenovo. It is not possible to actually make purchases from Lenovo directly if the account's email is a ProtonMail address. Too be fair though, that is the only site I have seen any explicit account blocks/restrictions.
jrgd
joined 1 year ago
Given my limited usage of system themes to one that has flatpak packages (Materia) and tendency to go through the permissions of new flatpaks and tighten them anyway, those are good points to mention. For theming, it is definitely a trouble point depending on the platform and theme used. Especially when combining Qt5/Qt6 apps, Fltk, GTK2,3+, and GTK4 applications together, things may get even more messy than consistent theming on native applications. Having comprehensive theme packages for the theme you use almost completely resolves this problem. Though I doubt predefined customization isn't something that will be popular with some users given that ricing your Linux desktop to the extreme is a huge selling point of the Linux desktop for many.
I did forget about how especially with Flatpak and Snap how there is no actual guarantee that the default sandboxing permissions will actually be any good or even usable on many applications, which is an issue that partially comes from when community maintainers end up publishing packages for developers rather than developers or dedicated platform testers publish a given package (a common practice for many applications on the Flathub repository).
It is disingenuous to simply state that people think new = bad. There are definitely both advantages and disadvantages to the current containerized packaging platforms / formats at the moment. Some of which, some people may see as greater positives, negatives than others.
There are a few obvious security implications with the rise of containerized packaging. One of the first is the move away from true centralized, least trust packaging. With traditional packages, you are trusting your distro maintainer (be it Debian, Canonical, RedHat, Arch, SUSE, etc.) To provide patched versions of software from their trusted repository mirrors to your computer. This does a few things like limiting the amount of places that you need to download software binaries from, as well as having other potential benefits like checksum validation on downloaded packages.
Most containerized package platforms including Docker, Snap, Flatpak tend to have a centralized set of repository mirrors, but anyone may compile and publish their own software to it. Flatpak is kind of the exception to this. Some distros (i.e. Fedora) publish their own sets of repos with flatpak packages. This is because Flatpak allows for more than one source repo for packages. I do believe Docker, Podman allow for the same as well. Snap infamously doesn't allow any repos other than Canonical's proprietary community repo.
Most of these containerized packages solutions also offer varying levels of sandboxing, which is a good set of security features that could benefit individual hosts from potentially vulnerable software. One could argue that flatpaking Firefox or other browsers and jailing them to limited capabilities and filesystem access is a good thing given the potential for malware propagation through such applications.
In particular though, most containerized solutions aren't generally hated by online user communities except Snap, which has both been among the most restrictive as well as furthest behind in features, performance parity, and general user experience. Snap was for the longest time significantly far behind Flatpak for user land applications and still wouldn't be my first choice for server applications compared to Podman or Docker due to just not being nearly as flexible as the other two.
The performance of the platforms can vary compared to native. For the desktop-oriented platforms (Snap, Flatpak) they generally perform insignificantly different from native packages, although Snap packages that are built compressed have had horrific IO performance for the loading of package files (leading to atrociously slow startup times of applications in the past). This is supposedly better now, though I have no intention of installing Snapd to find out.
As a note for culture, people particularly also dislike Snap because of how badly Ubuntu (Canonical's Linux distro) is depending on it, including having Snap automatically reinstall after removal and dropping many packages from apt only to throw redirects in to pull the snap package when requested from apt. This is why de-snapped derivatives of Ubuntu are also popular.
As for package sizes, they tend to be a bit bigger than native, as well as the added cost of a second set of libraries. Many users online don't get the 'why' when their first package from Flatpak is nearly a 3 GiB download, despite the following packages will hardly be any different in size from native packages. In a way, these packaging solutions do remove an advantage of the singular set of libraries. If you use netbooks, SBCs, IoT devices, or other similar minimal storage devices, you might feel this impact. However most systems will only have a marginal increase of storage utilization overall from a second set of libraries being installed.
Spreading FUD over a group of people's intent with their software that they personally use is an odd take, when kbin could very well have similar vulnerabilities in its codebase. Federation is good as part of limiting the attack vector one of many implementations and a subset of all servers hosting and routing media content. Kbin is just another set of federated content servers, with there being no guarantee of who develops the software being inherently more competent than those who develop Lemmy.
It seems I did not try making a Lenovo account with the pm.me alias address. I did use a protonmail.com address when tried before swapping to making an account using a Tutanota address and attempting to replay the purchase sequence. I don't remember the conversation I had with support when they deduced the error to protonmail addresses not being eligible for purchases for not "being verifiable" despite the fact that payment and billing information is also provided in a purchase. I don't remember if the support technician claimed that the pm.me alias would also be blocked, but for some reason I never tried it.