bsergay

Currently I got no time to go over this in more length. So apologies*. However, I still want to offer/provide a brief and concise answer. I will (hopefully tomorrow) return at this in more length.

Now i already setup my container & install some packages in it but the shortcut is missing from application launcher (a.k.a start menu), how i can link the shortcut from package inside toolbox to host application launcher ?

Short answer is that Toolbx for a long time (and perhaps still) didn't really support this feature. Sure, you could make it work, but it was a bit hacky. If this is a concern of yours, consider switching over to Distrobox. With distrobox, it's as easy as (while inside the container) distrobox-export --app <name app>. I will return at this tomorrow with the Toolbx way to do the same. I will also explore how Distrobox fares compared to Toolbx etc.

If i made a file (ex text file) from inside container will it show in Home directory ?

Yes if you've saved it in the Home directory to begin with.

If something crashed inside container will it also crashed my host system ?

Nope.

Why some packages doesn’t work inside container like Wine, Lutris, or Bottles ?

Interesting. I don't recall ever experiencing problems with either Wine or Lutris inside a Toolbx/Distrobox container. I'm also confident that Bottles should work.

Does it’s need special dependencies to make it work ?

This is definitely something that might be at play. Consider reporting the terminal output whenever you try to work with Wine, Lutris and Bottles.

Furthermore, expect some containerized solutions tomorrow for these 😉.

Can packages that modifying system (ex green tunnel, vmware, or QEMU, & hblock ) work fine ?

I'm not familiar with all of them. Though, you may expect troubles. I do recall I had to resort to rpm-ostree in order to make QEMU work. However, it's a fast moving space, so I wouldn't be surprised if Toolbx/Distrobox-based solutions exist for this. For example, since relatively recently, it has been possible to have a functioning Waydroid within Distrobox. I will also more exhaustively go over this matter tomorrow.

Aight, so you didn't like my methodology. That's fine; I've got no qualms with putting in the work. So, if you allow me, I would like to propose the following:

• Option 1. Somehow grant me access to the exact image you used. This could be done in multiple ways:
  • Either, just send me the link from which you downloaded it yourself.
  • Or, send it over to me through whichever file sharing/hosting solution you enjoy.
• Option 2. Getting VirtualBox to work on Bazzite is most likely a huge pain in the ass. Therefore, if it's fine with you, I could help you install virt-manager (if you even need any help with that). Furthermore, FWIW, it's worth noting that (GNOME) Boxes should work as well. It's relatively simple, though. Thankfully, at least installing it is as easy as flatpak install org.gnome.Boxes*.

Whonix is an OS exclusively meant to be used within a VM; at least, until Whonix-Host is released. Therefore, I didn't include it as it's not actually competing within the same space; as it can be run on any of the aforementioned systems within a VM. Finally, it's worth noting that by its own documentation, it's desirable to do so with Qubes OS.

Please allow me to link to an earlier comment of mine that goes over this in more length. You may also find it copied-and-pasted down below:

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'.

What are the main advantages of using this, that make it more secure?

More secure compared to your average distro? Or more secure compared to a specific set of distros? Unless, this is properly specified, this comment could become very unwieldy 😅.

Thanks in advance for specifying!

I daily drive secureblue; or, to be more precise, its bluefin-main-userns-hardened image.

"Why?", you ask. Because security is my number one priority.

I dismiss other often mentioned hardened systems for the following reasons:

• Qubes OS; my laptop doesn't satisfy its hardware requirements. Otherwise, this would have been my daily driver.
• Kicksecure; primary reason would be how it's dependent on backports for security updates.
• Tails; while excellent for protection against forensics, its security model is far from impressive otherwise. It's not really meant as a daily driver for general use anyways.
• Spectrum OS; heavily inspired by Qubes OS and NixOS, which is a big W. Unfortunately, it's not ready yet.

Maybe they’ve fixed it by now but at the time of my comment the page led to the mentioned empty standard folder path you’d expect on a regular installation.

Alright, so through the flathub remote-info --log flathub org.mozilla.firefox command, we can view which commit was active at that moment.

Command yields:

Firefox - Fast, Private & Safe Web Browser

ID: org.mozilla.firefox
Ref: app/org.mozilla.firefox/x86_64/stable
Arch: x86_64
Branch: stable
Version: 129.0
License: MPL-2.0
Collection: org.flathub.Stable
Download: 98.6 MB
Installed: 259.6 MB
Runtime: org.freedesktop.Platform/x86_64/23.08
Sdk: org.freedesktop.Sdk/x86_64/23.08

Commit: 57fc35d29f0ee4915ebd903e2b9ce5497972c175cf0a6950153ec91d6f1b3e33
Parent: 6a16f6a509340ad3bb833c9d9aa794ed78910aa43803a7420438b880aa0a6ce0
Subject: Export org.mozilla.firefox
Date: 2024-08-06 12:45:05 +0000
History: 

Commit: 6a16f6a509340ad3bb833c9d9aa794ed78910aa43803a7420438b880aa0a6ce0
Subject: Export org.mozilla.firefox
Date: 2024-07-26 13:29:41 +0000

Commit: 5b92a5aa533a8f68fe1d73f3910392018c4d4bb9f4370ee0577384e101999ce8
Subject: Export org.mozilla.firefox
Date: 2024-07-23 14:34:25 +0000

So, at the time of your comment, commit 6a16f6a509340ad3bb833c9d9aa794ed78910aa43803a7420438b880aa0a6ce0 was active and deployed on your system. Let's find out what downgrading to this commit yields.

Downgrading through sudo flatpak update --commit=6a16f6a509340ad3bb833c9d9aa794ed78910aa43803a7420438b880aa0a6ce0 org.mozilla.firefox, after which the about:profiles page is opened on this downgraded Firefox yields:

The beautiful part is that, as Flatpak is containerized anyways, anyone can downgrade to the earlier commit and it yields the exact same result. So, please feel free to verify this for yourself.

So, as a result, if the logic and the appliance is sound, then this showcases that your claim is either still true and portrays an anomaly -which I would deem as highly unlikely- or it's simply false and you were just mistaken.

Finally, if I've messed up at any of the steps, then please feel free to correct me.

lol, the full answer I had written somehow was ripped to pieces. I'll therefore keep it brief.

• Thank you for the reply!
• Apologies for making you wait so long for an answer! Thank you for your patience!
• Thank you for correcting me when I had wrongfully suggested that it's found in about:support while it's found (as seen below) in about:profiles instead. I know it's found in Firefox, I (just) messed up the exact spot. Therefore, thank you for countering misinformation!

• You've mentioned stuff that require to be addressed and corrected, but I'll leave it at this. You should read documentation and don't take people's words anyways.

Nix, the package manager, is distro-agnostic. Add Home Manager on top of it and you're good to go; both packages and dotfiles are dealt with.

If security is a serious concern of yours, perhaps consider NovaCustom's offerings instead. Intel BootGuard is coming to their new models (i.e. the 14 inch V54 the 16 inch V56). Add Dasharo's coreboot, the possibility to disable Intel Management Engine, (soon hardware-based) kill switches, open source EC, ongoing work to get it Qubes OS certified (like how they managed on their NV41) and perhaps even Heads (also like how they did on NV41). We haven't even talked about how they'll soon achieve HSI-3 and their plans to tackle Trenchboot next year.

It's a lot of good stuff. And simply unheard of for vendors that are Linux-first. Heck, if their ongoing work on lvfs delivers and they manage to put out updates like industry leader (at least in this regard) Dell does^[1]^, they might even be a contender for most secure laptop for general use.

While it may seem as if I've been gushing a lot already, I have not even mentioned how they fare in other important aspects:

• Communication and support is excellent and a lot better than any other Linux-first vendor; including both Star Labs and TUXEDO.
• They're committed to repairability and sustainability. While they definitely can't compete with Framework in this regard, they do offer spare parts (including motherboard, CPU, fans, cmos battery and a lot more) for up to 7 years.

It's a pity that they're underappreciated and underrated for not putting as much money into advertising as they do on delivering an excellent product.

1. Dell is very competent in this regard. So, I honestly don't expect NovaCustom to seriously compete with them. However, I'm already content if they can compete with Lenovo at this.

but photoshop/Adobe Creative suite is a must have… how is that on Linux these days?

We got you covered, fam.

This.