Avoid Fedora Flatpaks (their repo, not Flathub) because of broken apps. OBS got pissed at them a while back for user reporting bugs that were only present in the downstream repackaging by Fedora. Broken af.

That second link gave me cancer just reading some of that shit.

Nocturne

Gapless

Pretty sure Asahi fixed that problem already.

deleted by creator

Maybe a MacBook M3 or 4 with the hopes that asahi gets support in the future? More RAM means much more money. I suggested a MacBook because OP like Mac.

For Mac, go with a Mac Book Neo.

https://www.zerofs.net/docs/zerofs-vs-juicefs

No, but Sway is basically a drop in replacement.

TRUEEEEE

I need me some gay desktop environments!

Plain and simple, with a supply chain attack.

It doesn’t use systemd, nor do they seem to have plans to add age attestation.

What is Animist?

Cool

Why Fedora 35? That is pretty ancient.

0% battery? power daemon broken?

On the first laptop the missing folders are likely to do with the fact that the Flatpaks are installed as system Flatpaks, therefore installed under /var/lib/flatpak (iirc). Flatpak is configured to let you install them as system wide Flatpak apps, meaning other users on your computer will also see them. It would normally require authentication to do that, but many distros configure it to be easy by default.

The second laptop is installing them as user Flatpaks, meaning the folders (mostly shared libraries, desktop entries, and apps) are stored in the user’s home folder.

What does it mean to “make Linux secure”? What does secure mean to you (genuine question). I see people say they can make Linux secure but from what kinds of attacks. I think madaidan’s blog explains why you can’t as an individual fix an issue with the entire ecosystem, or fix the kernel of its inherent security flaws https://madaidans-insecurities.github.io/linux.html

I think “good security” in my personal opinion means that even if you try to run a malicious app, it either crashes out right or can’t do anything because it doesn’t have the permission to.

One thing that I think is very misunderstood is that messy or extremely large/dense code can be very hard to understand, even if you have the source code. Like systemd, it is several million lines of code and is very tangled together. Is it that much better than a blackbox if no one can audit the whole thing (unless you are a massive team)? I do think it is better to have source code and documentation, but vulnerabilities arise from unintended interactions in the code. The more code there is, the higher the chance of this happening.

Just because AOSP uses many of the Linux kernels security features doesn’t magically make other distros more secure. Same with servers vs desktop, which have far different usage requirements and patterns, and vastly different threat models.

Linux desktop is a decade or more behind the curve on exploit mitigations and harm reduction. Social engineering is still a security failure, and it almost as much the fault of OS developers that people are falling for these attacks.

Only recently has sandboxing become more popular for distributing applications, but it still isn’t even close to as secure to AOSP or IOS/MacOS sandboxes. Flatpak and Snap are inherently insecure and that isn’t even their fault because they aren’t really meant to be secure sandboxes; they exist for easy system agnostic app distribution.

Many users still use X11 (or xwayland) which is consistently the source of vulns and regardless is massively insecure. X11 is a nasty rats nest of code and hacks which is massive, complex, and often runs privileged. Ever X11 app has complete access to the X server, and can: record the screen, read all window events and positions, record all keystrokes, send keyboard and mouse events, and much more. Wayland is a good step in the right direction. But Wayland compositors can also suffer from easy attacks, like using LD_PRELOAD to record keystrokes.

Speaking of LD_PRELOAD, most users have .bashrc writeable in there home. Any app that has write access to their home directory can preload a malicious binary which can modify and exploit the running app.

With .bashrc writeable, a hacker can just change tbe user’s $PATH and create a fake sudo binary which records the user’s password, and escalates to root without them knowing. Even specifying the full path isn’t safe, because a hacker can just set an alias which takes priority of the actual path of the binary (eg. /usr/bin/sudo could be an alias of /tmp/sudo).

Now I hear you saying, why didn’t the user just NOT run the malicious script or app? With supply chain attacks being at all time highs, you can’t just rely on trusting your application developer. An app could get compromised and you wouldn’t know. Even if you verify signatures, OpenPGP and GNUPG are inherently broken (see: gpg.fail, Latacora blog, Mathew Green blog)

Most distros use extremely weak memory allocators which allow for easy exploitation of memory corruption vulnerabilities. Hardened_malloc by GrapheneOS works on desktop Linux, with most apps just working fine out of the box. It helps to eliminate (or severely increase the complexity of) memory corruption vulnerabilities.

Many distros don’t use mandatory access control policies like AppArmor or SELinux (eg. Arch Linux and its derivatives), and even if they do it isn’t compare able to AOSP, like Fedora which use SELinux but doesnt by default isolate all applications with strong policies.

Then there are LTS distros, which because of their release schedule and also the way that CVEs are assigned, often miss important patches which go unnoticed (or not triaged for their security impact). See the recent copy.fail vuln which because of its disclosure timeline wasn’t given ahead of time to distros. The only ones affected were slower moving distros, where as rolling release distros were fine (eg Arch Linux).

Of course let’s not forget SETUID and SETGID which are the source of many many privilege escalation attacks, like in the case of that AppArmor vuln about a month ago. Daemon based privilege elevation tools (such as s6-sudo) avoid this problem, but they are not widespread. Systemd’s run0 is a more popular example, but just like everything with systemd it is a massive attack surface and extremely complex under-the-hood.

Linux has many security modules (LSMs) such as MAC (eg. SELinux), Seccomp (for filtering syscalls), Landlock (for filesystem and network isolation), unprivileged user namespaces, etc. The only popular apps which make use of some of these features are browsers.

Of course drivers are another source of vulnerabilities because the are implemented in kernelspace instead of using a standardized ABI.

Linux is not a secure desktop OS. Neither is it very secure for a server OS (without extensive development of tools which properly use the kernels security features).

I could apply most of what I have said to the *BSDs within the context of Desktop OSes.