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

Good. I want to see more Flatpak adoption.

Oh too bad, flatpaks rarely work on my system and if they do they are buggy and slow.

i like flatpaks they have their uses.

In other OBS related news, it seems they're going to be moving their official Linux packages over to Flatpak rather than just having an official PPA for Ubuntu.

Awesome news. A special thanks to Georges Stavracas for his contributions to Flatpak and OBS.

i like flatpaks they have their uses.

Spoiler, click me

To protect your privacy, external media requires approval to load. Source: i.postimg.cc
View cookie preferences.
Accept & Show Accept All & Don't show this again   Direct Link

It looks like network access is required to open multiple instances of Audacity.

I would test, but I can't even get the flatpak version of audacity to launch past the splash window. Other flatpaks work fine (flatseal, authenticator). Audacity from the repos works fine.


Last edited by lectrode on 21 December 2021 at 7:10 pm UTC

It looks like network access is required to open multiple instances of Audacity.

Nope, i have it open. network disconnected. Just click 'new' within audacity and it creates a new separate window instance.

I would test, but I can't even get the flatpak version of audacity to launch past the splash window. Other flatpaks work fine (flatseal, authenticator). Audacity from the repos works fine.

works fine for me on Linux mint Una 20.3. My system is as standard as you can get.

Flatpak version 1.11.2

you can type flatpak --version in the terminal to find out what version you have. also Mint is not updating installed flatpaks from the software center automatically for me. I use the: 'flatpak update' command from the terminal to update them (also turned it into a script)

thx

In addition to Rodney, allow me to clarify another point: there is no connection between Red Hat's donation, and the Flatpak work. Publishing OBS Studio to Flathub was an effort lead entirely by the community, and contributors have been working on it for many months now.

In addition to Rodney, allow me to clarify another point: there is no connection between Red Hat's donation, and the Flatpak work. Publishing OBS Studio to Flathub was an effort lead entirely by the community, and contributors have been working on it for many months now.

That's great.
Makes me wonder about one thing, though--I thought one of the deals with Flatpak was supposed to be it wouldn't take whole communities months to make decent packages? Just saying, doesn't seem like ease of use, you know?


Last edited by Purple Library Guy on 21 December 2021 at 10:17 pm UTC

That's great.
Makes me wonder about one thing, though--I thought one of the deals with Flatpak was supposed to be it wouldn't take whole communities months to make decent packages? Just saying, doesn't seem like ease of use, you know?

It did not take months to package it, only a few hours. What took months was improving the whole stack, from adapting OBS Studio to use portals, to adding new features to existing portals, to adding new features to the Flatpak tooling itself, to figuring out a deploy pipeline from GitHub to Flathub - OBS Studio is the first application in history to publish directly from GitHub to Flathub. In the end, these months were well spent; the platform was improved, and the entire community - users and developers alike - will reap the benefits of the work we've done.

That's great.
Makes me wonder about one thing, though--I thought one of the deals with Flatpak was supposed to be it wouldn't take whole communities months to make decent packages? Just saying, doesn't seem like ease of use, you know?

It did not take months to package it, only a few hours. What took months was improving the whole stack, from adapting OBS Studio to use portals, to adding new features to existing portals, to adding new features to the Flatpak tooling itself, to figuring out a deploy pipeline from GitHub to Flathub - OBS Studio is the first application in history to publish directly from GitHub to Flathub. In the end, these months were well spent; the platform was improved, and the entire community - users and developers alike - will reap the benefits of the work we've done.

Oh. That's pretty cool.

It did not take months to package it, only a few hours. What took months was improving the whole stack, from adapting OBS Studio to use portals, to adding new features to existing portals, to adding new features to the Flatpak tooling itself, to figuring out a deploy pipeline from GitHub to Flathub - OBS Studio is the first application in history to publish directly from GitHub to Flathub. In the end, these months were well spent; the platform was improved, and the entire community - users and developers alike - will reap the benefits of the work we've done.

That's some really great insight there, thanks for sharing!

I really love Flatpak. There are some issues, it's true, but they are arguably being ironed out as we speak. In the end, installing applications and getting the latest upgrades have never been so easy.

On top of that, as developers and their tools get more knowledge of Flatpak features, security will become better and better (e.g. with sandboxing*).

* I know the current state is not perfect, but if Flatpak was too strict on security right from the beginning, it wouldn't have been popular and we wouldn't be having this discussion about OBS officially supporting Flatpak. The community would probably have turned to Snap or, worse, AppImage.

OBS Studio is the first application in history to publish directly from GitHub to Flathub.

Huh! That's really interesting.

I do use OBS at work to capture video when I need to showcase or troubleshoot stuff to associates haha
Best software! Shoutout to the team!

Good. I want to see more Flatpak adoption.

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

Good. I want to see more Flatpak adoption.

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

This is on side of the story, I suggest you read this response to the blog post you sent: https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/

Edit: there is also https://flatkill.org/ (on the against side). These are highly opinionated blog posts, they tend to show only the numbers they want to show and hide the other because it goes against their beliefs. I tend to take these kind of blog posts with a HUGE grain of salt.


Last edited by Creak on 24 December 2021 at 1:56 pm UTC

Ok, to really put the emphasis on the dishonesty of the case against Flatpak (which apparently tends to trigger me more than it should ):



So lets see what a user can see when he wants to install Steam for instance:



"Potentially unsafe".. doesn't seem like it claims to be sandboxed and the safest. It simply says that it's not perfect.

But Steam is a proprietary app.. maybe on an open source app, they are less strict? Let's see GIMP:



Well, look at that! "Unsafe", it's even stricter even if it's an open source app.

I really do wonder how a regular user would think Flatpak is safer than any other solution. For them, it's only a simpler way to install open source and proprietary applications.

Oh and one last thing: I agree that it is not the most secure package manager in the world, but it is more secured than the distribution-specific package managers (e.g. dnf, apt, pacman, ...).

An application installed through these managers have literally access to anything all the time. It's like a flatpak application but with all the permissions possible. At least with Flatpak, you can limit these accesses.

The most modern applications uses the portal APIs, so they only get access to the files (or other resources) that the user accepted, and we're not talking about access to /home, we're talking about access to one specific file only, because thanks to portals, it's dynamic. You can even select a file and force it to be read-only for the applications your using. But there are portals for networks, webcams, screencasting, bluetooth, etc.

And when applications didn't implement portals, they can set default permissions in the application manifest. Like, for instance, access to network and access to the user's directory. But the user's directory is still better than having access to the entire filesystem (which is what happens for applications installed through the distribution package managers)! Not using the portals is still what compose most of the Flatpak applications, but it's because portals are fairly new, and it takes time for applications to upgrade to new standards, but it's getting there.

And finally, we might find to ultimate bad Flatpak applications that give access to the whole system. Well, guess what? it's just like an application installed through the distribution package managers.

Edit: I've continued to read and found this gem in the "Local root exploit? Minor issue!" section:

Flatpak developers consider this a minor security issue.

If you look at the link, it is a link to a minor release, as defined by semantic versioning. If it does not add, change or break a feature, it's a minor release. My god, this person has absolutely no idea how software development works and he's made this page? (I am a software developer btw)


Last edited by Creak on 24 December 2021 at 2:38 pm UTC

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.

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.

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.


Last edited by 14 on 26 December 2021 at 5:39 pm UTC