Choice of choosing a linux distro for a Advanced Linux users is very limited

[jonah (Jonah Aragon)]

What you’re talking about is separate from the OP though.

[Revival873]

Let me clarify. I tried to explain a design philosophy that is both quite secure (and private of course) and highly practical for everyday users. Signal has immense potential to be the standard. It’s like comparing SMS to Signal. In this case SMS is Desktop Linux. Signal requires minimal setup sure but vastly improves every aspect.

[Libre_Software_Enjoyer]

@anon62834490

flatpak uses bwrap underhood which is nightmare for hardened system you need to Enable unprivileged user namespaces which is not secure you can use setuid as solution but still its bad idea. there has been many vulnerabilites in the past that escaped bwrap sandbox.

Do we have a better option, that doesn’t require writing policies yourself and/or entering long commands before starting applications?

[FranklyFlawless (Frank Lý)]

Define better.

[Libre_Software_Enjoyer]

• Reasonable secure
• Practical to use

[FranklyFlawless (Frank Lý)]

Qubes OS:

Qubes OS: A reasonably secure operating system

[Libre_Software_Enjoyer]

How much RAM does running Qubes OS takes?

[anonymous549]

6GB

System requirements

[Cyber-Typhoon (Always leveling up)]

@Revival873

you are downplaying the importance of secure implementation of kernel parts such as hardened_malloc.

I’m a bit more skeptical when it comes to things like hardened_malloc.

In my experience, allocator hardening often runs into a “usability wall.” I’ve seen it cause random crashes in games and significant performance hits in Firefox, mostly because it replaces jemalloc, which those workloads are specifically tuned for. When a security feature causes that kind of instability, it stops being a “default” and starts being a barrier.

It’s actually why Kicksecure moved away from it, the compatibility headaches and performance regressions just didn’t outweigh the benefits for most users. There’s a good write-up on their reasoning here: Hardened Malloc

@Revival873

This is how I look at it: let’s take Signal for example.

I think the comparison to Signal is interesting, but there’s a huge gap between a single, tightly-scoped app and a general-purpose OS. Signal can enforce strict defaults because they control the entire environment. A desktop OS has to play nice with an endless variety of hardware and software.

To me, the goal shouldn’t just be “maximum hardening,” but “practical security.” I leave the maximum hardening for activists, servers and whoever has the time to make it work. Says the person fighting with Arch the last 6 months trying to reach the perfect balance between privacy, security and convenience.

[sha123]

Realistically 16GB+

[Gopher]

I’m only a year long Linux user and tbh I’m not super hyped up about distro hopping. I was a life long Windows user so I just wanted something with out of the box support for KDE and had endorsement from smarter privacy/security people than me, so went with Fedora Atomic.

I share Linus’s view that the goal for a good distro is that is “just works” and not to get caught up in chasing the latest and greatest on a frequent basis.

[Libre_Software_Enjoyer]

@Cyber-Typhoon

I’m a bit more skeptical when it comes to things like hardened_malloc.

In my experience, allocator hardening often runs into a “usability wall.” I’ve seen it cause random crashes in games and significant performance hits in Firefox, mostly because it replaces jemalloc, which those workloads are specifically tuned for. When a security feature causes that kind of instability, it stops being a “default” and starts being a barrier.

GOS uses hardened malloc and I can’t remember any problems causes by it

[Cyber-Typhoon (Always leveling up)]

Yeah, I think both things can be true here.

GrapheneOS working great with hardened_malloc doesn’t really contradict anything. It actually proves the point. GrapheneOS is a tightly controlled environment. Same dev behind it, same allocator, same stack, everything built and tested together. Of course it’s going to be smooth there.

Desktop Linux is just a different world. You’re mixing:

• apps that expect different allocators (jemalloc, PartitionAlloc, etc.)
• different packaging systems (system, Flatpak, snap)
• tons of hardware and configs

That’s where things start falling apart.

Kicksecure, ended up dropping it as a default because of that reality. Not because it’s insecure, but because it breaks too much in a general-purpose setup. Browsers, Flatpaks ignoring it, Xorg issues, random segfaults… it becomes a maintenance burden fast.

So yeah, hardened_malloc is great tech. But outside something like GrapheneOS, it’s not just “flip it on and get free security.” It’s more like “be ready to babysit your system.”

Secureblue has it and I’m aware but I really don’t have the time to keep playing with it.

[Libre_Software_Enjoyer]

@Cyber-Typhoon

GrapheneOS working great with hardened_malloc doesn’t really contradict anything. It actually proves the point. GrapheneOS is a tightly controlled environment. Same dev behind it, same allocator, same stack, everything built and tested together. Of course it’s going to be smooth there.

Desktop Linux is just a different world. You’re mixing:

• apps that expect different allocators (jemalloc, PartitionAlloc, etc.)
• different packaging systems (system, Flatpak, snap)
• tons of hardware and configs

That’s where things start falling apart.

I think I get where you coming from, but I wouldn’t agree that “GrapheneOS is a tightly controlled environment. Same dev behind it, same allocator, same stack, everything built and tested together.”
Because the Android application platform is totally independent from GrapheneOS and still 99% of apps can run on it with hardened mallow and memory tagging.
The dev’s of GOS haven’t changed anything about how Android app’s run, and Android app dev’s don’t make any changes to their apps to run on GOS.