Little bit of good news to start Tuesday, as the excellent livestreaming and recording software OBS Studio got another good donation recently, this time from Red Hat.
Red Hat certainly aren't the first big company to help fund OBS development, software that has become essential for so many different uses. Nice to see a bigger Linux and open source company jump in though with the confirmation of the $10,000 donation on Twitter.
This actually puts Red Hat in the top 5 of companies who have donated to OBS via their OpenCollective campaign.
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. This is fantastic news, as it means all the proper service integration will be easily available to all Linux users. Although it’s nothing to do with the donation from Red Hat.
We still remember trying to livestream on Linux before OBS Studio came along, what a complete pain that was. OBS is another incredible project that really shows the power of open source. Super useful for other uses too because of all the easy to use plugins from podcasts to plain video content creation.
Quoting: feaneronOh. That's pretty cool.Quoting: Purple Library GuyThat's great.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.
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?
Quoting: feaneronIt 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!
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.
Quoting: feaneronOBS Studio is the first application in history to publish directly from GitHub to Flathub.Huh! That's really interesting.
Best software! Shoutout to the team!
Quoting: CyborgZetaGood. I want to see more Flatpak adoption.
Me not at all. https://ludocode.com/blog/flatpak-is-not-the-future
Quoting: sudoerQuoting: CyborgZetaGood. 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
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:
QuoteFlatpak 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
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.
Quoting: STiATI 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
See more from me