As someone who does a lot of infrastructure work on AWS, Azure, GCP etc, it’s just about the only operating system I’ll use at this point for that kind of work. The isolation I get per-client and per-environment is unmatched. There’s a little more upfront work to get everything the way you like (putting ZSH configs on /etc/skel of your templates for example) but once it’s set up it’s really solid. Having the windows named and color coded really helps me keep from crossing wires when stuff gets chaotic and I’m jumping around a lot.
It’s obviously MUCH worse at certain things such as CAD, but they’re still workable in it. HVMs can remedy this pretty easily but it’s not quite as seamless as the standard Qubes unfortunately but it’s progressed a LOT in a short amount of time so we’ll see what the future holds!
I switched off of BSD about a decade ago so I can’t weigh in on it’s current state at all. I generally avoid Flatpaks at least in Qubes. I do have a template that supports it but it’s only running on my Music VM currently which is offlined, the rest follow the traditional template+AppVM approach which I keep updated on a schedule.
I have never operated under the assumption that flatpaks are sandboxed or secure because they really aren’t. It’s a system to bundle packages with your software without contaminating the host environment. The big issue really is in the package maintainers shipping outdated packages, containers were never a security measure in my eyes due to the shared kernel and especially not with the default share of the homedir for flatpaks. If you need that kind of isolation you really need a VM. I treat them as a standard install personally without any expectations of isolation, and really with Silverblue I’m leaning more towards installing apps directly in Distrobox and exporting them to the host, it still has the shared homedir issue but you’re getting up to date packages in a desired environment that you fully control (this is both good and bad since maintenance is on you).
I think it’s a good idea if there were stricter requirements, maybe vulnerability scanning as a requirement to releasing and pulling stale flatpaks after a period of no releases to start. It’s difficult to appease everyone in this situation and breaking changes would be inevitable so it is difficult to fully solve now that it already exists as it does. I do think supply chain attacks will only get more common though so they definitely need work.
As someone who does a lot of infrastructure work on AWS, Azure, GCP etc, it’s just about the only operating system I’ll use at this point for that kind of work. The isolation I get per-client and per-environment is unmatched. There’s a little more upfront work to get everything the way you like (putting ZSH configs on /etc/skel of your templates for example) but once it’s set up it’s really solid. Having the windows named and color coded really helps me keep from crossing wires when stuff gets chaotic and I’m jumping around a lot.
It’s obviously MUCH worse at certain things such as CAD, but they’re still workable in it. HVMs can remedy this pretty easily but it’s not quite as seamless as the standard Qubes unfortunately but it’s progressed a LOT in a short amount of time so we’ll see what the future holds!
So what about FreeBSD? And did you read up on Flatpak having security issues because the containerization is supposedly not sufficient?
I switched off of BSD about a decade ago so I can’t weigh in on it’s current state at all. I generally avoid Flatpaks at least in Qubes. I do have a template that supports it but it’s only running on my Music VM currently which is offlined, the rest follow the traditional template+AppVM approach which I keep updated on a schedule.
I have never operated under the assumption that flatpaks are sandboxed or secure because they really aren’t. It’s a system to bundle packages with your software without contaminating the host environment. The big issue really is in the package maintainers shipping outdated packages, containers were never a security measure in my eyes due to the shared kernel and especially not with the default share of the homedir for flatpaks. If you need that kind of isolation you really need a VM. I treat them as a standard install personally without any expectations of isolation, and really with Silverblue I’m leaning more towards installing apps directly in Distrobox and exporting them to the host, it still has the shared homedir issue but you’re getting up to date packages in a desired environment that you fully control (this is both good and bad since maintenance is on you).
I think it’s a good idea if there were stricter requirements, maybe vulnerability scanning as a requirement to releasing and pulling stale flatpaks after a period of no releases to start. It’s difficult to appease everyone in this situation and breaking changes would be inevitable so it is difficult to fully solve now that it already exists as it does. I do think supply chain attacks will only get more common though so they definitely need work.