bsergay

And yet they did so using the package manager.

So, Davinci Resolve's .run file used for installation definitely somehow interacted with the package manager. Otherwise, the system wouldn't break the way it did. While, technically the package manager was in use (at least at some point), the user -i.e. OP- did not intentionally invoke its use consciously. So, I wouldn't refer to this as "using the package manager".

They just installed a apt.source

What is an apt.source? Search engines and LLMs failed at resolving this. They did explain what apt source is or could refer to, though*. Regardless, what leads you to understand that they've installed an apt.source? Please be elaborate as I'm not a Debian/Ubuntu user; consider shedding light on it through the RPM world.

THAT I would say one should not do unless one really knows what they are doing.

How does one know which apt.source they should and should not install? Doesn't this imply "expert skills" (using my understanding of your logic)? On Windows, you can install software with almost no fear; as long as the source is trusted.

If they had just installed some .appimage

Assuming they've installed libfuse2. Which actually is not present in modern Ubuntu installations.

or compiled something from source they would have been fine.

So, in this case, you believe that compiling a gargantuan program like Davinci Resolve would not have caused a ton of issues related to dependencies even if it was supported on Ubuntu?

So... I'm not going to nuance your stance if it shouldn't be nuanced.

I thought that my writing was sufficiently easy to comprehend and would not lead to any misunderstandings. Therefore, within that context, nuance was not needed. However, your engagement in the conversation implies that some actually did misunderstand it. Thus, nuance was (seemingly) needed and I only became aware of it afterwards.

It's a bit up to you to be clear about your nuance. And in this case you're being very ambiguous about it.

My stance is pretty simple:

• Use whatever is provided, intended and supported by the 'distro'.
• For that which goes beyond this, you're on your own and should be prepared to face the consequences.

So, if one can't deal with the consequences, like how OP had to come here for help, then one should stick to the first point.

It just had its first Stable release (as Vanilla OS 2). Therefore, consider to wait it out a bit until it has been well-tested at large. Until then, please feel free to choose something else that is to your liking. Like, what is it that attracted you to this one in the first place?

Thank you for the quick reply!

Thank you.

It has been my pleasure 😊!

I haven’t been following them lately so I do not know their reasons for deprecating hardened malloc, I assume there’s an explanation for it.

Pragmatism 😅; at least, that's how I interpret their justifications.

Thanks for the note

Again. it has been my pleasure 😊!

Very curious. I didn't know this. I tried verifying this, but didn't manage to do so.

So, I got to ask; Was this just a joke? Or is there (some) truth to this claim?

I infact did not 100% know what I was doing obviously lol despite having complete confidence that I did

I know that feeling very well 🤣. I'm glad to hear that you were able to recover your system; at least this mistake only came at the cost of your time and not your system.

Have a good one 😉!

Interesting. Thank you for sharing your experiences! Would you be so kind to elaborate on that experience? Did you like it? Are you still using it? Why or why not? Pros and Cons? Thank you in advance!

Unfortunately, neither do I. I hope this will be the last time you'll have to face this issue.

First of all, apologies for delaying this answer.

Disclaimer:

• I'm not an expert. While I try to verify information and only accept it accordingly, I'm still human. Thus, some falsehoods may have slipped through, my memory may have failed me, and/or what's found below could be based on outdated data.
• Additionally, I should note that I'm a huge nerd when it comes to 'immutable' distros. As a result, I'm very much biased towards secureblue, even if Kicksecure were to address all of their 'issues'.
• Furthermore, for the sake of brevity, I've chosen to stick closely to the OOTB experience. At times, I may have diverged with Qubes OS, but Qubes OS is so far ahead of the others that it's in a league of its own.
• Finally, it's important to mention that -ultimately- these three systems are Linux' finest when it comes to security. In a sense, they're all winners, each with its use cases based on hardware specifications, threat models, and priorities. However, if forced to rank them, I would order them as:

Qubes OS >> secureblue >~ Kicksecure

Context: Answering this question puts me in a genuinely conflicted position 😅. I have immense respect for the Kicksecure project, its maintainers and/or developers. Their contributions have been invaluable, inspiring many others to pursue similar goals. Unsurprisingly, some of their work is also found in secureblue. So, to me, it feels unappreciative and/or ungrateful to criticize them beyond what I've already done. However, I will honor your request for the sake of providing a comprehensive and balanced perspective on the project's current state and potential areas for improvement.

Considerations: It's important to approach this critique with nuance. Kicksecure has been around for over a decade, and their initial decisions likely made the most sense when they started. However, the Linux ecosystem has changed dramatically over the last few years, causing some of their choices to age less gracefully. Unfortunately, like most similar projects, there's insufficient manpower to retroactively redo some of their earlier work. Consequently, many current decisions might be made for pragmatic rather than idealistic reasons. Note that the criticisms raised below lean more towards the idealistic side. If resources allowed, I wouldn't be surprised if the team would love to address these issues. Finally, it's worth noting that the project has sound justifications for their decisions. It's simply not all black and white.

With that out of the way, here's my additional criticism along with comparisons to Qubes OS and secureblue:

• Late adoption of beneficial security technologies: Being tied to Debian, while sensible in 2012, now presents a major handicap. Kicksecure is often late to adopt new technologies beneficial for security, such as PipeWire and Wayland. While well-tested products are preferred for security-sensitive systems, PulseAudio and X11 have significant exploits that are absent from PipeWire and Wayland by design. In this case, preferring the known threat over the unproven one is questionable.
  • Qubes OS: Its superior security model makes direct comparisons difficult. However, FWIW, Qubes OS defaults for its VMs to Debian and Fedora. The latter of which is known to push new technologies and adopt them first.
  • secureblue: Based on Fedora Atomic, therefore it also receives these new technologies first.
• Lack of progress towards a stateless^[1]^ system: Stateless systems improve security by reducing the attack surface and making the system more predictable and easier to verify. They minimize persistent changes, impeding malware's ability to maintain a foothold and simplifying system recovery after potential compromises. While this is still relatively unexplored territory, NixOS's impermanence module is a prominent example.
  • Qubes OS: There's a community-driven step-by-step guide for achieving this.
  • secureblue: Based on Fedora Atomic, which has prioritized combating state since its inception^[2]^. Its immutable design inherently constrains state compared to traditional distros, with ongoing development promising further improvements.
• Deprecation of hardened_malloc: This security feature, found in GrapheneOS, was long championed by Kicksecure for Linux on desktop. However, they've recently chosen to deprecate it.
  • Qubes OS: Supports VMs with hardened_malloc enabled OOTB, for which Kicksecure used to be a great candidate.
  • secureblue: Continues to support hardened_malloc and has innovatively extended its use to flatpaks.

1. This paper provides a comprehensive (albeit slightly outdated) exposition on the matter. Note that it covers more than just this topic, so focus on the relevant parts.
2. Colin Walters, a key figure behind Fedora CoreOS and Fedora Atomic, has written an excellent blog post discussing 'state'.

Thanks for sharing the solution! Though, I wonder... What caused this issue in the first place?

Lacking features

It's important to mention that the specific way by which 'immutability' and all of its associations are implemented, is key to determine what possible limitations are. Perhaps to gain a better grasp on this, consider reading this blog post. Note that due to the (very) active development 'immutable' distros enjoy, not everything found within that article is accurate.

and having to take weird extra steps to get what I want and tweak the system the way I want.

~~Does uninstalling snapd on Kubuntu fall under this?~~ Jokes aside, the way that 'immutable' distros want you to do stuff is simply unconventional compared to traditional distros. Heck, even the need to (soft-)reboot to apply changes to the base system is almost unheard of on traditional distros. However, unconventional does not necessarily imply weird. Care to elaborate when something goes from unconventional to weird?

I’m a bit of a power user and I’m wondering if a immutable distro could work for me over a regular one.

It depends on your priorities. There's a 'cost' that comes with going 'immutable'; mostly related to how it's still relatively immature and/or unpopular. However, even in this state, there are problems it solves and tackles that traditional distros don't.

Regarding 'being a power user', like what's even the wildest thing you'd want to do?

Thanks for the reply and thanks for sharing your experiences!

Something super basic for example is OpenRazer in order to control the settings of my mouse and keyboard - the backend of OpenRazer exists as a DKMS module, and kernel modules seem to be a bit more difficult to install on an atomic distro than a “mutable” distro.

IIRC, the DKMS modules are included in uBlue images. Have you tried any of their images?