This is true. I agree that developers should use more inclusive language in their documentation. I mostly just thought people saw the other post already.

“Singular they” has been common in english since somewhere in the 1300s. Idk how it is confusing, and even if it is, do those individual’s opinion outweigh like grammar? If people are confused they can learn, lest they be confused forever. “They” in this instance would be replacing “he”, so I think the benefit is clear. Or avoid ambiguity by just saying “the developer” (cus I think it was Dev documentation iirc).

Edit:
Maybe it was referring to the browser itself? Therefore “it” would make things much less confusing.

I was only commenting that this post has been posted already twice, once in a closely related community. I have already had to argue with people supporting the Dev’s choice to be bigoted. I will just scroll past, just not excited to see more transphobes crawl out of the woodwork.

It think the discussion of this issue has been thoroughly explored in your other post on the “free and open source” community. People know about this now. Is there anything else to cover? All that will be talked about is either “wow, that was an overreaction from the Dev, they seem close-minded” or “you should separate the tech from the developer” or people (bigots) just saying they think he made the right choice.

The discussion is stale.

Sorry, misunderstood. Proxmox Free broke my containers on updating a while ago.

Now I use Docker-style application containerizing, but I think LXC (the base technology powering Incus/LXD) is useful in a number of situations and perfectly viable for use. I think Incus-containerized applications are easier to upgrade individually (like software updates of your apps, no need to recreate the container image) and gives a closer to native experience of managing. You do lose out on automated deployment of applications from widely available image sources like docker.io, but the convenience-loss is minimal.

If incus works for yoy, use it. Proxmox locks you out of the option to choose your base server distros.

I remember updating (maybe a year ago now) and it making all my containers unaccessable.

If they want proper anonymity, the user needs to protect against fingerprinting from the duckduckgo website (Tor or Mullvad). If by anonymity you are meaning from OpenAI, then duckduckgo needs to be running user’s text prompts through a paraphrasing LLM to normalize text and avoid deanonimization using writing-style Fingerprinting.

Unofficial MCPE launcher is the only way to run bedrock on Linux

Many mechanics, and bugs, and features. Redstone is very different because the bug/exploit parity doesn’t exist and even obvious features are different (Redstone attaches to pistons). When they add a new mechanic, the bugs are different and unique to each game. Like because cauldrons can hold potions in bedrock, you can (idk if its changed) use the newish block dripstone to increment the potion fullness, duplicating it.

How recently. I tested with Mullvad and it gave me a notice.

They block VPN users.

deleted by creator

Microsoft Activation Scripts (MAS)

Alternatively to upgrading edition check out these apps:

• KDE Connect
• Syncthing

I very much recommend Kicksecure hardened Debian as a daily driver. Eventually I will test gaming on Kicksecure making use of the steam flatpak, but I currently dont have the time.

IIRC, there is a way to force hardened_malloc for flatpaks, but this breaks many flatpak applications. For another hardened by default OS distromorph (the process of turning one distro into another closely related derivative OS) check out secureblue

Requiring webassembly will break the website for most privacy hardened browsers (arkenfox, Librewolf, cromite, Mullvad, etc). Webassembly is disabled for security and privacy reasons in these browsers. Not worth IMO. See a short snippet of Arkenfox’s reasoning here: https://arkenfox.github.io/gui/?s=javascript.options.wasm

Ok, understandable. I hate mobile devices because of their limited usable life and limited OS compatiblity. Verified boot is nice, libre-android is better. Not worth it for a person of interest to install /e/OS, but neither would stock Android or AOSP without significant hardening. DivestOS is my top pick for degoogled Android, but as I learn more (been reading kicksecure’s wiki on mobile device security) maybe Root isn’t as bad as I thought for security. I trust Kicksecure’s security research because of their significance as the base OS for Whonix and Whonix-qubes.

Related to relockable bootloaders and the security they provide, I was under the impression that if a malicious bit of software were to make use of some privilege escalating vulnerability and modify the kernel, the phone would fail to run in some way (ignore the rest of this if that isn’t the case). I dont think security should be dependent on the user behavior in basically any case.

For example, a FOSS developer in our communities could suddenly lose it and modify an existing app of theirs to inject malicious code making use of a vulnerability in android and we’d have know what of knowing until the damage is reported. Good user behavior is very important for security, but we can’t all be auditing our apps for each new release, even though its quite unlikely to happen.

It still has much of the google proprietary blobs still included and relies on google services, also without significant effort to harden Android. I have also heard that sometimes they fall behind on updates to their apps by weeks at a time (correct me if I’m wrong I am still looking for the source I found this info from). It may be moderately degoogled, but their security just ain’t there. In some cases (like OEM EOSL for older devices) having a 3rd party ROM may improve security with more up to date patches. Unless the bootloader is relockable and secure boot is possible, you will be compromising your device’s security (and privacy along with it) and destroying the Android security model in general.

There is no android ROM that is fully degoogled without losing out on much of base Android’s functionality. See the table I link under the other person’s comment. I have also heard that /e/ OS falls behind on package updates from its forks of other projects, many of its default apps.