This person uses an 8GB mac, and tried to defend Apple in the debate, going as far as to say that Apple hardware is “not that expensive”, and within 2 months regrets buying the 8gb mac.

They think Open Source is “overrated”, insecure, and not important. They think Linux users are “normies” and fakers, Linux is not a desktop OS, and have explicitly stated “F*** LINUX”.

That’s a lot of terrible opinions in just 4 months, especially for someone who calls the internet “stupid”, and supposedly doesn’t have any education.

This is either a troll account, or someone with less than zero credibility considering their opinions and statements.

They tried that, it’s called UWP. A lot of programs don’t want to be distributed through the microsoft store though, forcing them to use “old” .exe’s

Steam Link doesn’t work on Linux. SteamVR, ALVR, WiVRN, and Monado work under Linux.There’s more headsets than the Quest.

Android is a dead end for FOSS in the future, but moving from one corporate owned semi-proprietary OS to another doesn’t solve anything.

The bootloader of your phone (if locked) is one of the most secure parts. It’s very hard to get into a modern phones bootloader. In contrast, finding an exploit in a running phone is a lot more feasible.

If a vulnerability was abused to get into your running phone, it will persist until the phone reboots, and the bootloader verifies the core parts of the operating system at startup. In order to persist past a reboot, malware like that would need a vulnerability in the bootloader, or a bypass for its integrity checks.

Alongside that, any background services (“daemons”) that got stuck or became slow over time are forced to restart. Operating system updates can be applied, and working memory is cleared.

In general, it’s just good advice to just reboot your phone once in a while. There’s no harm in doing so.

Do NOT click the link. Instead, go to google.com yourself, go to your account settings, and “check activity”. If there’s anything suspicious (like an attempted login from another country), reset password and ensure 2FA is enabled. Otherwise, you can safely ignore/delete the email. (But still enable 2FA for better protection)

Afaik the bug was never present in a release. The developer who quit had to jump through a bunch of hoops, and treat it as a security issue, when it only affected people running the latest git commit.

KDE Connect, and if needed, ntfy.sh.

I don’t have a direct source other than the source code of the software they use: https://github.com/mautrix/signal

When using one of their “cloud hosted” bridges, the bridge software (that connects between Matrix/Beeper and other protocols) has to read all message content. Otherwise, it’s impossible to bridge to another protocol. E2EE becomes end (other users) to bridge (beeper) encryption.

With “local hosted” bridges, E2EE stays intact, but messages can’t be sent/received if the device hosting the bridge is unavailable.

In the future, with MLS (a different E2EE protocol), it could be possible to keep E2EE even when bridging to Matrix on cloud hosted bridges.

iirc NPxSP was getting messy internally, the author went and rewrote a lot of things

per-site process isolation, as mentioned here: https://divestos.org/pages/browsers#processIsolation

My experience with several firefox-based browsers on Android was not usable, with constant freezes, crashes, and performance issues.

There are some security considerations to using a Firefox-based browser on Android. In my experience, performance and stability has not been as good on Firefox Android as Chromium Android.

https://divestos.org/pages/browsers

Please, don’t recommend Ubuntu. It actively gets in your way, even as a new user. Something like https://distrochooser.de/ could help OP figure out what distro works best for them.

Unless a proper secure boot + FDE setup is in place.

Since the EFI partition is unencrypted, physical access would do the trick here too, even with every firmware/software security measure.

Most malware is written for Windows, especially when it’s distributed as a Windows executable. (Almost) no Windows malware targets Wine specifically. However, Wine on its own is not a sandboxing tool, and Windows ransomware will ruin your day.

Bottles does two things for security:

1. Separate wineprefixes
2. Being a flatpak

By separating wineprefixes, as long as the host filesystem is not directly exposed (which iirc is default for bottles), any malware not written with Wine in mind will only affect its own “bottle”.

By being a flatpak, even if some Windows malware specifically targets Wine, it would still have to escape the flatpak sandbox for elevated permissions. If the bottles flatpak has no access to personal files, “Wine-aware” malware won’t either.

Although malware can still do damage, even in its own sandbox. For example, botnet type malware would still function. The host system is “safe”, but the damage can still be done externally. Usually application-defined “autostarting” of applications is broken under Wine (iirc), which means all non “Wine-aware” malware will only start when an infected windows application is started in bottles.

Any sandbox will eventually be escaped, and malware sophisticated enough will be able to get access to everything on the host system. The chances of running into malware like this in the wild are extremely small.

• Is it fully secure? No.
• Is your virtual Windows environment safe? No.
• Are other “bottles” safe? Likely, as long as the malware isn’t aware of Wine.
• Is your Linux host safe? Most likely, depending on your flatpak settings. (and the malware has to specifically target Wine under Flatpak).

Depends on how it’s implemented. Anyone using a “media proxy” will see their discord bridged media probably fail to load (outside of possible caches) after a day. Anyone who has their bridge configured to reupload discord media to their homeserver should see no change.

And the reason you mentioned Ubuntu is “finicky” was explained above. It is not a good “just works” distro, there’s much better options than Ubuntu.

It used to be (one of) the best “just works” distros, but is somehow one of the worst now. Outdated blogposts still recommend it, and Canonical still calls themselves the “most used” desktop distro. The alternatives are just better.

This isn’t about “making the game work”, or “adding Linux support”. This is about toggling a checkbox to stop explicitly preventing Linux from working.

The games that already did never faced a massive cheater problem because of it. The games that have stopped development long ago or “don’t care about Linux” (without preventing it with anti cheat) were still made playable by Wine and Proton.

If the developer wants, they can add system info to their ticket system and filter out any Linux tickets. It costs a game developer barely anything to decide to allow Linux users. Linux support costs a lot, but valve, wine, and the community has been putting a lot of effort in so game developers don’t have to change anything about their game.

Short answer: you don’t. It’s either privacy or a facebook app, not both.

Longer answer: Don’t use the facebook app https://github.com/mautrix/facebook (requires your own Matrix homeserver)

It is much more complicated to host a Matrix homeserver and Facebook Messenger bridge, however, it allows you to use a FOSS chat app on your Android phone. With notifications and if needed, fully outside google infrastructure, or even fully selfhosted, with ntfy.sh for example. Without running any proprietary Facebook code, and without directly connecting to Facebook servers on your Android device.

It is of course unavoidable to have complete privacy, as your messages will still be sent to Facebook, but you avoid almost all telemetry (and all on-device telemetry) by using a Matrix bridge rather than the official website/app.

Another option is Beeper, although privacy with them is questionable, since you’re fully trusting them with your account, and any incoming/outgoing messages. It does avoid Facebook telemetry on device, and is much easier than hosting a Matrix homeserver.