Red Hat donates $10,000 to OBS Studio, their Flatpak to be official for Linux

I actually never saw snap or flatpak as security layer but as a means to distribute a packaged versions regardless of the linux distribution and library versions available on a distribution.

The thing is that especially on dependencies they multiply memory usage by different versions of libraries, which I like to avoid where possible.

I will still use the obs-studio provides by my distro though, but it does make sense for me in example for Spotify or other stuff which may not find their way into my distro.

!meme

You will spend more on disk and memory in both desktop and server scenarios.

I have a good amount of professional experiencing administering containerized applications. I do not love or hate them. They have their use-cases. In a desktop experience, I think the primary benefit for an end-user is convenience. For maintainers, support should be more routine because the problems people bring to you are the same thing over and over. You can write a troubleshooting guide for them. In contrast, the errors traditional packaging generates can be more unique to the user's setup and harder to diagnose.

In a server experience, the benefits are scaling the instance count of the application. That extra resource spending allows you to be lazier about planning your resource purchases because you don't need to custom build a server to fit an application's usage at peak times; you can add servers of varying capacities to your farm to host the same application and spread the load. You can also recover an unhealthy application by restarting it instead of the server.

What choice do I make on my personal computers? Well, I have avoided containerized applications. I also do not like the idea of redundancy. I make exceptions, for example the Unity Hub, and I will test out the OBS Flatpak to see if any features work better, but in general I don't like these application capsules on my desktop. I do use them on some of my servers but not the ones where I want more administrative control over all the components.

I actually have my issues with dockerized applications and kubernetes, I do not see a real benefit there but to be able to scale up and down for single applications fast.

To realize our shared web environment containerized has 10 times the RAM usage than before. On that size overhead, scaling for workloads would hardly be an issue on a more traditonal approach.

The good part is that you really can seperate them, which is the only real benefit there.

I actually have my issues with dockerized applications and kubernetes, I do not see a real benefit there but to be able to scale up and down for single applications fast.

I think the best way to summarize the benefits is the "pets vs cattle" paradigm: https://www.hava.io/blog/cattle-vs-pets-devops-explained

Good. I want to see more Flatpak adoption.

Me not at all. https://ludocode.com/blog/flatpak-is-not-the-future

You are certainly entitled to your opinion.

For me, Flatpaks are extremely convenient. They're kept separate from the core OS, and they're distro-agnostic. On a more "stable" distribution, like Xubuntu on my ThinkPad, Flatpaks are a handy way of having up-to-date programs. And on an Arch-based system, like I'm using on my desktop, they allow me to maintain my policy of avoiding the AUR, in addition to allowing me to reliably use Steam.

Getting Steam to work reliably, coming from Ubuntu and Debian, has been a pain in the butt on EndeavourOS. For starters, I had to add udev rules to root that Ubuntu+Debian installed automatically as the package "steam-devices". But more importantly, the Steam Flatpak has been the only way I've been able to consistently play my Steam games. The only game I can't explicitly run in the Steam Flatpak is Vampire the Masquerade: Bloodlines; any other game I've had issues with have had issues in the Steam Flatpak and the Steam Runtime.


Last edited by CyborgZeta on 27 December 2021 at 12:14 pm UTC