That was a possibility with this exploit, but realistically that doesn’t affect nearly as many people as “All GNU/Linux systems”.

Even there, if the stars align (network access, cups being used), you still need to convince the user of the device to switch printer.

As far as I’m aware, the exploit requires someone to try printing using a malicious networked printer. It is a vulnerability, yes, but it affects essentially nobody. Who tries manually printing something on a server exposed to the internet?

Although for local network access, like in a corporation using Linux on desktops, the vulnerability is an actual risk.

If this was the case, the phrashing around the issue would’ve likely been different. Yet bitwarden remained very vague, and even locked github comments on the issue.

Especially considering that a move like this alienates their core target demographic (people who use FOSS), they would’ve been much more open and much quicker if it wasn’t intentional.

I will personally be switching, likely to KeePassXC.

“clean driver install”, which heavily suggests you installed nvidia drivers, probably from the website. That issue is entirely on you.

mount -o remount,ro /

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.

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.

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.

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.

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.

The times I calculated were indeed going over every possible combination, it would take half as long to crack a password on average. Considering reducing the time to 1/1000000 still leaves you with an incomprehensibly large estimated timespan, dividing that by 2 doesn't do that much for making it brute-forceable.

I did note it was specifically for 8 emojis, not 8 characters or bytes.

And yes, it's very impractical and likely to break things. It's better and much easier to add extra letters, numbers, and symbols to your password rather than using emojis. Using a password manager is even better.

As you stated, a single unicode character would mean your password wouldn't be included with the potential options in almost all brute forcing tools. Whether you use 8 emojis or 1, your password likely won't get brute forced.

All of my "emoji password" numbers are if the attacker knows it's a password containing exactly 8 emojis, and nothing more. Adding a regular symbols+upper+lower+numbers 16 character password would make it even more impossible to brute force.

For somewhat more realistic numbers:

According to minerstat.com, an NVidia RTX 4090 has a hashrate of 118.07MH/s. This is 118.07 Megahashes per second, or 118.070.000 hashes per second. For a password with only 8 lowercase letters (208.827.064.576 combinations), it would take an RTX 4090 approximately 1769 seconds (or ~30 minutes) to go through all possible combinations. For an 8 character upper+lower+numbers password (218340105584896 combinations) it would take 1849243 seconds, or 21.4 days.

For an 8 emoji password (32482071647592311234920185856 combinations), it would take 275.108.593.610.504.896.512 seconds, or 8.723.636.276.335 years.

Lets say a magic prediction algorithm reduces the number of possible combinations in each password to 1 out of every 1 million previously possible combinations. 8 lowercase letters would be cracked instantly, while an 8 emoji password would still take 8.723.636 years.

NordPass is completely incorrect on the "it makes a password easier to "crack" thing.

I absolutely don't recommend using emojis in your password, as it is far too easy to get locked out. However, a password containing an emoji is significantly harder to crack.

Hashing is a process used to calculate a large number based on some input data. If the input is the same, the output is the same. If the input differs just slightly, the output is completely different. This process is mathematically irreversible. Since this (and other techniques) is often used for passwords, to "crack"/bruteforce a password, the attacker has to go through every possible combination of input data, calculate the hash, and check if the hash is the same as the password hash.

To make the process of bruteforcing a hash quicker, an attacker often makes assumptions about the input data. If they know a password contains 8 characters, and only lowercase letters, this massively narrows down the amount of passwords that need to be hashed and checked. If they know the password contains someones birth year, that too reduces the time to bruteforce a password.

The more possible characters you have per position in your password, the longer it will take to bruteforce. An 8 character password with just lowercase letters has 208.827.064.576 possible combinations. This sounds like a lot, but it's often bruteforced rather quickly. Adding uppercase letters and numbers to that, we're already at 218.340.105.584.896 possible combinations. That's ~1000x more combinations, and that's for 8 characters. It's the difference between bruteforcing taking a day, and taking 1000 days. (Do note an 8 characters lowercase password probably only takes like a few seconds to minutes, not a full day.)

According to https://emojipedia.org/stats there are 3664 different emojis. Lets say we create an 8 emoji password. (some emojis aren't one character internally, the same principle still applies.) Just 8 completely randomly chosen emojis. That password would have 32.482.071.647.592.311.234.920.185.856 different possible combinations. That is about 148.768.232.755.857 times more combinations than an 8 character uppercase+lowercase+numbers password. That is the difference between bruteforcing taking a day or taking 407584199331 years.

The same things as non-emoji passwords still apply, you can make assumptions about which emojis are used. People aren't entirely random, so chances are higher they used some of the more common emojis. However, that is similar to prioritizing the letter "e" because it is more common. Yes, it'll probably reduce the time taken to bruteforce a bunch of passwords, but it's not set in stone that every password will even contain the letter "e".

Again, due to the potential of breaking things, locking yourself out, etc. I DO NOT recommend using emojis. Use a password manager with longer passwords.

However, including an emoji in your password makes it significantly more difficult to bruteforce. As the assumption that the characters in your password are letters, numbers, and symbols no longer holds, which drastically increases the possible number of combinations.

Currently on Phosh on postamarketOS. Would’ve loved to use Plasma mobile but it is very unstable.

Depending on the application you used to alert you of the AirTag, it’s possible that your phone did not send location data back to Apple.

Apple can track AirTags, because iPhones are programmed to listen for them over Bluetooth Low Energy, and send the ID of the AirTag and location data of the device to Apple.

If your Android phone has an application to listen for BLE devices in the background, keeping track (locally) of which devices it saw in what locations, that application can tell you if you’re travelling with an AirTag (or similar device). It might even be able to interact with the AirTag, such as making it beep or reading its ID. If that application doesn’t send your location to Apple, the AirTag was not able to use your phone to make its location known to the owner.

Therefore, to the owner, AirTags are useless unless an iPhone (or other device that sends its location to Apple) is around.

I can personally vouch for how toxic the Discord server and its moderators/admins are. Went there for support (Hyprland was crashing on startup on AMD, sway worked fine), and was told something along the lines of “if you can’t figure this out you’re stupid and you should stop using Linux”. Figured out the issue on my own and stopped using and recommending Hyprland after that.

Not just the “lack of APKs”, but the lack of a FOSS build. As you noted, it is possible to instal an AAB by extracting the APK(s) inside, but that doesn’t magically remove non-foss libraries.