needed for some low level stuff like system packages
Contra apt:
a ton of stuff comes from outside the main Ubuntu repo. Debian doesnt have that difference afaik but still many packages may be more abandoned
3rd party packaging 99% of the time, i.e. "unverified". I had a lot of strange bugs especially with Ubuntu packages
the apps ars not isolated at all
Pro Flatpak
a ton of verified apps, nearly unavailable on other repos (that still doesnt make unverified apps insecure!)
all apps have a sandbox that can be graphically hardened to be more secure, if the defaults are too broad
by defaults the sandbox is pretty good
many many apps that run everywhere
Contra Flatpak
not suited for some apps like terminal apps or system stuff
some apps are less maintained and use EOL runtimes etc
some more storage space needed
need user namespaces, nearly all distros have them enabled
a bit slower startup time but okay
a bit more RAM usage
In general I agree, though had something to add regarding these points:
by defaults the sandbox is pretty good
This is a rather major problem with Flatpak; the maintainer decides what permissions they need by default, not the user. The user needs to retroactively roll them back or specify global options and manually override them per-app, but that's not user-friendly at all. Though many Flatpaks do have good permissions because Flathub maintainers step in and offer suggestions before approving the Flatpak for publication, there are a number of Flatpaks that punch big holes in the sandbox; so much so that they might as well be unsandboxed.
But Bottles has a great sandbox, for instance, which is just what you'd want when running lots of proprietary Windows applications you maybe don't trust as much as your Linux-y software.
It's better than what we have with traditional packages but it can sometimes get in the way and not all beginners can easily figure out how to fix permissions issues with Flatseal. This will probably improve as we get more portals built.
some apps are less maintained and use EOL runtimes etc
not suited for some apps like terminal apps or system stuff
This isn't really true. It's only true when terminal applications need privileged access to something. Flathub ships Mesa userpace drivers and NVIDIA's proprietary userspace drivers just fine. You can package something like yt-dlp in Flatpak just fine with --filesystem=host. Hell, they've even got Neovim on Flathub. Sure, it's a little more cumbersome to type, but you can always create an alias.
You can easily rollback Flatpaks to a previous version (even from a long time ago) with flatpak update --commit. Much harder with traditional package systems, and you'll probably need to downgrade shared libraries too.
You get a consistent build environment with Flatpak manifests. If you want to build a newer version of a stable package you're using straight from master or with a few patches, all you really need to do is clone it from flathub/whatever, change a few lines, and it has a very high chance of building properly. No need to figure out dependencies, toolchains, or sane build options. And it's all controlled from an easy-to-read and modify file.
defaults
The default is completely sandboxed. Developers need to allowlist exactly what they want. So it is transparent.
Compare that to a random app where you need to monitor its syscalls to see what it does.
KDE Plasma now includes a GUI settings page that allows to change these.
I think GNOME needs to integrate that into their settings, I mean just include damn Flatseal as a settings page...
specify global options
This is supercool and I started doing that. All apps get the env vars to force Wayland now even though they may not use it. I have my overrides and uploaded them to my dotfiles.
But Bottles has a great sandbox
Echo that
over 1200 unmaintained packages in the Debian repositories, and even over 400 in Arch's much smaller repositories
This is crazy, same on Fedora. Distros really need to start using separate repos, and automatically filter out everything that didnt get a "I maintain this" for a while.
There are packagers maintaining a shitload of apps at once.
Flathub applications are usually maintained by upstream
Not always but having this at all, and having most big names in there, is incredible. This is like a first time this happens.
easily rollback Flatpaks
Ostree is great
consistent build environment
And having it declared centrally can help add all the security benefits of the individual ones too. Really nice
The default is completely sandboxed. Developers need to allowlist exactly what they want. So it is transparent.
The default before the developer touches it doesn't matter; compare this to Android, iOS, or macOS's permission system. An app needs to ask for permission to use the microphone or access your files. With Flatpak, all a developer needs to do is specify --filesystem=home or --socket=pulseaudio and if the user hasn't specified global options like --nofilesystem=home, then the developer gets access to it. Having a sandbox that is optional for the developer rather goes against the point of a sandbox, don't you think?
I'm not unsympathetic to Flatpak developers, though. The status quo on Linux for decades has been, "you get access to everything." If Flatpak enforced that sandbox, more than half of the apps on Flathub right now just wouldn't work because they don't support the filesystem portal.
I think GNOME and KDE need to do the work of manually restricting Flatpak apps' access to sensitive permissions like home by default, maybe in a few years when the idea of the filesystem portal has had time to gestate among developers. Kind of like how Firefox's HTTPS-only mode (which I think should be the default) prevents you from accessing the website unless you give permission.
That's something we can work on, I think. At least we have a way to get there.
KDE Plasma now includes a GUI settings page that allows to change these.
I think GNOME needs to integrate that into their settings, I mean just include damn Flatseal as a settings page…
I recall saying the exact same thing. They have a built-in area for it in the Apps section. They'll probably get around to it eventually...
There are packagers maintaining a shitload of apps at once.
Felix Yan is awesome to be maintaining thousands of packages for Arch. But man, that's a lot of work. If we could reduce the workload of our package maintainers who rarely receive any gratitude (usually only demands) and let them focus on the really important packages, I think that would also be awesome.
Yay my answer was deleted...
before the developer touches it doesn't matter
It matters as the security rating is based on that, apps like KDE Systemsettings or Flatseal show that etc.
I agree that asking for permissions is better.
Placing an override in ~/.local/share/flatpak/overrides/global would be an easy workaround.
Desktops could implement dialogs that use the currently preset permissions.
Having a sandbox that is optional for the developer rather goes against the point of a sandbox, don't you think?
No, these are defined, enumerated holes in a sandbox. Without a sandbox you need to monitor the behaviour yourself or other things.
This is the only good working GUI sandbox I know.
half of the apps on Flathub right now just wouldn't work because they don't support the filesystem portal.
Important point here:
the portal should allow static permissions too
apps that dont support portals would also not support asking for permissions, natively. A workaround could be done, using dbus, and asking for everything when the app is launched first time, BUT
Linux has a tiny marketshare
flatpaks are not the only ones
people dont care about security that much (look at my survey, I will post an evaluation soon)
permissions on Linux are more complex than on the actively restricted Android. External media, devices, filesystems etc
HTTPS-only mode (which I think should be the default)
I should open a bug about this. It cant be that this is not default, it works well and I agree on the style of implementation.
But this would also need apps to have that mechanism. A Libreoffice will just say "file doesnt exist" currently.
let them focus on the really important packages
Thats why I like Fedora Atomic. The core is as small as possible, the apps are just base stuff or upstream stuff like the Desktop. Everything else is a Flatpak.
It is so much more secure.
RHEL / CentOS has different repos for core and extras. More distros will do that
It matters as the security rating is based on that, apps like KDE Systemsettings or Flatseal show that etc.
That's a good point.
Linux has a tiny marketshare
people dont care about security that much
permissions on Linux are more complex than on the actively restricted Android. External media, devices, filesystems etc
That's true.
I think my issue with the Flatpak sandbox is I understand how it works and what its limitations are (and I'm mostly fine with them), but the average user doesn't. I was reluctant to try Flatpak before understanding how it worked, but now that I know how it works, I think it's fantastic! But it's also a work-in-progress. What we have now is good, but I think it could be better. Not entirely sure how it gets better though.
Thats why I like Fedora Atomic. The core is as small as possible, the apps are just base stuff or upstream stuff like the Desktop. Everything else is a Flatpak.
I'm still not really sure where I stand on Fedora Atomic. Lack of H.264 decoding by default is a damaging choice. They should just include openH264 in the base image, reproducibility be damned. Give it 5 more years and maybe this will be revisited...
Nova + Zink + NVK will solve some of the problem with NVIDIA (maybe even very soon), but not hardware decoding currently, which is a big one.
Gamescope doesn't work great in a Toolbox. It works fine in Flatpak, but Bottles doesn't let me use Gamescope options. I think Lutris does, but I haven't tried it out yet.
And how am I supposed to install fonts without layering them on?? I've been copying them to ~/.local/share/fonts manually.
I think the idea is cool. But I think a few more parts of the ecosystem need to be in place first. I'll keep using it for now.
What we have now is good, but I think it could be better.
I had a damn Librewolf crash some time ago, the RPM is broken, switched back to Firefox... so I lost about 3 hours of overhaul of that list as it is currently very messy.
But if it is fixed, feel free to submit apps to be included, to have a "goodness enumerating" list of apps, rather than a huge mess of random apps.
Lack of H.264 decoding by default
They dont include that? I thought they would...
I use Fedora kinoite-main from uBlue which is very close to upstream but fixes many issues for me.
UBlue focussing on their very opinionated variants is a bit annoying, because it is now pretty hard to find a guide how to install kinoite-main. I just have a bookmark of their archived website.
Give it 5 more years
If this is actually an issue I would like to tackle that. I am currently doing a Change Proposal to make the default rpm-ostree permissions reasonably secure.
So this is an issue with reproducability? I dont think so? Cisco builds the binaries for Fedora and it gets installed. The packages are not from their repos, but the typical sync issues would not occur on Atomic.
but not hardware decoding currently, which is a big one
Yeah for sure, I think for Intel and AMD too, hardware h264 for example. AV1 in OBS will be awesome though.
But thats why I use uBlues base images, it is Fedora and I say I use Fedora and participate in their community, but their base images have a ton of stuff I dont agree with (toolbox, missing random packages, too simplistic installer...)
I maintain a list of recommended Flatpak apps.
I'm very familiar with you, haha. You keep popping up wherever I go these days. You're everywhere. Maybe not quite as omnipresent as Neal Gompa.
I can think of a few Flatpaks that could fit on that list.
They dont include that? I thought they would…
It's the same old story with codecs. Fedora would love to support as many codecs as possible, but H.264 is patent-encumbered so they can't. They had hardware decoding support through Mesa a few years ago but then they...changed it.
Fedora Atomic wants to include the OpenH264 enablement package for Firefox inside the Fedora Flatpak eventually which will solve most of the problem as that is where people are playing H.264 most often.
So this is an issue with reproducability? I dont think so? Cisco builds the binaries for Fedora and it gets installed. The packages are not from their repos, but the typical sync issues would not occur on Atomic.
My understanding is OpenH264 is provided in binary-only format to Fedora because otherwise the royalty-free license cannot apply (i.e. Fedora can't build it from source). Fedora only ships free software. OpenH264 is free software. But it's binary-only. So they need to trust Cisco has built the binary correctly. I assume the reason they don't include it by default is because the only way to trust it's built from the same sources is to reproduce the build. Otherwise, I really don't see the issue.
OpenH264 is not a part of the base system so you need to layer it on. OpenH264 doesn't have support for High 10 Profile video which is fairly common off the web and is generally inferior to x264, I've found, but at least it's something.
And the reason I mention "5 years" is because by then, most of the patents on H.264 will have expired. With the exception of the new ones from just a few years ago that no one really uses. Maybe Fedora can enable x264 in their ffmpeg build then and we can stop talking about it. I am so sick of talking about H.264.
I use Fedora kinoite-main from uBlue which is very close to upstream but fixes many issues for me.
Call it a personal challenge or whatever but I'm sticking to Fedora Silverblue for the foreseeable future. uBlue is almost certainly a better experience for most people.
Yeah for sure, I think for Intel and AMD too, hardware h264 for example.
That's not true if you're using Flathub packages. Flathub ships userspace Mesa drivers which enable hardware decoding for Intel and AMD GPUs even with H.264 and H.265.
but their base images have a ton of stuff I dont agree with (toolbox, missing random packages, too simplistic installer…)
uBlue does solve the two big issues with Fedora, which is codecs and proprietary NVIDIA drivers. Any other issues are tiny in comparison. I will say I prefer Toolbox to Distrobox, despite using Distrobox first. I certainly understand that's an unpopular opinion and not one a lot of people share. It's probably the same reason you use KDE and I use GNOME (most of the time).
I've always hated the Fedora installer. Does uBlue do something different?
You keep popping up wherever I go these days.
Funny, I use that name not so long. Currently hyperfocused on Fedora Discuss, Lemmy and Github.
Although I should really change my stuff to some Forgejo instance and just mirror to Github.
I thought a lot about tech resiliance in the last days, I am from germany and the people here are stupid. They literally elect people that will make a neofascist surveillance hell reality.
I wonder how Tor, Tails and others handle their code stuff. Apart from selfhosting their services of course. Like resiliance, I think decentralized code repos are crucial.
I really like how uBlue just used the official Fedora OCI images (that they produce but dont even use) and used all the container tooling to create this awesome project.
But relying on Github is insane, it is owned by Microsoft and they dont give a damn about freedom. It is pretty scary, 90% of my Android apps are also on Github.
I want to build my own variant, KDE and minimal only, maybe GNOME if contributors join. But no more, all the freedom is great but it is huge maintenance.
H.264 is patent-encumbered so they can't
I thought Ciscos trick could fix that? They are a huge company, pay the max amount of money already and can just share the software with their license to anyone.
inside the Fedora Flatpak
Not sure if that is the best way. Flatpak has runtime extensions, and rpmfusion could build one for the entire ffmpeg and more. This could just be added from an external repo and installed along.
Or they include openh264 in their runtime.
Fedora Flatpaks got quite a boost recently and even have some KDE apps not on Flathub.
the only way to trust it's built from the same sources is to reproduce the build.
Well... rpmfusion could do that? And act like a "3rd party auditor" ?
doesn't have support for High 10 Profile video which is fairly common off the web
Interestesting, never heard that. I use Celluloid Flatpak which is pretty great (I wish Haruna would get their basics together like customizable UI, working subtitles, working queue etc).
So the only reason to have ffmpeg is nice terminal stuff, Dolphin extensions or just video previews in Dolphin. Nautilus supports that via a Flatpak right? Thats cool.
we can stop talking about it. I am so sick of talking about H.264.
Fuck patents. I am happy that we now have AV1 and dont really know why VP9 is not more used? It is a pain!
Call it a personal challenge or whatever
I have a command text file with the exact command I need to reproduce my install. One for Fedora Kinoite, one for Kinoite-main.
It is just a few packages and I really only need the things I mentioned.
I also dont like Aurora or others that much, they have too much stuff added.
That's not true if you're using Flathub packages.
True, Flatpak is cool. Dolphin is also available as one, I need to test if it works with Flatpak ark and all that, udisks2, mounting stuff, MTP, maybe SMB.
prefer Toolbox to Distrobox
Interesting, why? I need to try it again.
Do you know btw how to upgrade a F39 distrobox to F40? Distrobox has some "assemble" function to rebuild it with a config file. But traditional dnf system-upgrade doesnt work.
It's probably the same reason you use KDE and I use GNOME (most of the time).
Why? Curious.
No uBlue uses Anaconda too, which is a whole set of stuff. They are testing the new UI (a component of Anaconda) for workstation exclusively.
uBlue pioneered in making Anaconda work for installing OCI rpm-ostree btw
Looks like we frequent the same circles, then.
I thought a lot about tech resiliance in the last days, I am from germany and the people here are stupid. They literally elect people that will make a neofascist surveillance hell reality.
But hey, Germany was responsible for the Sovereign Tech Fund, which has made a big difference for GNOME and accessibility with the Newton stack. So it's not all bad. Not that I live there.
But relying on Github is insane, it is owned by Microsoft and they dont give a damn about freedom. It is pretty scary, 90% of my Android apps are also on Github.
That's the main reason I don't use uBlue. The idea of booting my entire operating system from a container created on Github's infrastructure is just...it scares me. Even though much of the free software I rely on is hosted on Github. And yes, most of my Android apps are also from Github.
I want to build my own variant, KDE and minimal only, maybe GNOME if contributors join. But no more, all the freedom is great but it is huge maintenance.
That's a nice idea. I wonder if Sourcehut does container registries...I know people praise their CI.
I wonder how Tor, Tails and others handle their code stuff.
I thought Ciscos trick could fix that? They are a huge company, pay the max amount of money already and can just share the software with their license to anyone.
Yes, however it only covers their implementation (which is lacking) and it only covers binaries they create.
Well… rpmfusion could do that? And act like a “3rd party auditor” ?
I'm thinking about Fedora including the build in their own repositories. It would be really nice if H.264 decoding was just default and you didn't need to do anything.
doesn’t have support for High 10 Profile video which is fairly common off the web
So do I. But keep in mind there are two Celluloid Flatpaks you can install; one is from Fedora Flatpaks which disables H.264/H.265/VC-1 decoding and the other is from Flathub with all features enabled.
Nautilus supports that via a Flatpak right? Thats cool.
File previews are supported via the Sushi extension, which is available as a Flatpak. Obviously, it doesn't work on H.264/H.265/VC-1 media because it's a Fedora Flatpak.
I really need ffmpeg because it's a crucial part of my workflow because I convert so much media. But that's fine; I just use it in a Toolbox.
But Nautilus works really well as a Flatpak. It even seems faster than non-Flatpak Nautilus and I have no idea why.
True, Flatpak is cool. Dolphin is also available as one, I need to test if it works with Flatpak ark and all that, udisks2, mounting stuff, MTP, maybe SMB.
KDE made a big push to make all of their programs available as Flatpaks. And Snaps. Which I think is great. But you end up in a weird situation where the Krita Flatpak is not officially supported by Krita because no one at Krita works on maintaining the Flatpak. Rather, they support only AppImage officially, probably because it's easier to maintain their insane patchset than with Flatpak. Not having any experience with distribution systems aside from Flatpak, I really don't know what niceties Snap or AppImage provides.
Interesting, why? I need to try it again.
Nothing much has changed since last you commented on that Toolbox thread I was reading :)
I think Toolbox is the right way to solve the problem. It's using a real programming language (Go) instead of bash, it supports a small set of important container images, and those container images are only provided from quay.io, Red Hat's own infrastructure, instead of Docker Hub.
But it lacks some features intentionally (and some just because they haven't gotten around to it). Like distrobox export. Annoying to manually patch in but not hard. I use Toolbox for Signal and Steam because I don't want to use Unverified Flatpaks.
Do you know btw how to upgrade a F39 distrobox to F40? Distrobox has some “assemble” function to rebuild it with a config file. But traditional dnf system-upgrade doesnt work.
I don't think upgrading Distroboxes or Toolboxes is supported. They're meant to be destroyed and re-created. Really inconvenient, but I guess the proper way of maintaining toolboxes/distroboxes is through Containerfiles.
So I don't use Fedora containers. Or Ubuntu containers. Or Debian containers.
I use Arch because it's a rolling release and you just keep updating it. No upgrade problems so far...aside from all the errors I ignore (everything seems to work fine). Also, I really like the Arch userland and it has Signal Desktop in the official repositories.
It really makes me feel at home on Fedora.
It’s probably the same reason you use KDE and I use GNOME (most of the time).
Why? Curious.
I think GNOME provides a more coherent and consistent experience for users. I'm okay with not having features like a system tray, desktop icons, or window buttons I never use. I really love GNOME. It's changed the way I use computers and has made everything aside from KDE feel like a completely inferior experience in comparison.
But I use KDE for my multi-monitor system because frankly, GNOME is an awful experience if you have more than one monitor with different resolutions. KDE kind of sucks too, but it's not completely broken. KDE is practical by solving problems we have now, like letting XWayland applications scale themselves. Because even if it's a total hack that works inconsistently, it works very well for most of the software I use. I find parts of KDE overwhelming (especially the System Settings) but hey, it works.
I like both KDE and GNOME and think each has their own strengths. It's nice to see KDE adopt one of GNOME's killer features (partially), the Overview. It'd be nice to see GNOME adopt a KDE feature like CTRL+META+ESC so I can kill windows graphically even on Wayland.
But god GNOME is annoying when it comes to protocol standardization. At least they're finally implementing DRM Leasing for VR users (not me).
Huh. I thought I was supposed to be sticking up for GNOME. Alright, I use GNOME everywhere else and it's still my favorite desktop by far. They focus on a great experience with what works great now. There are very few hacks in GNOME land. I just think they need to catch up to KDE with Wayland and other areas like the multi-monitor stuff.
Newton stack
Never heard of that, I hope accessibility on Wayland improves.
Neal Gompa mentioned that Flatpaks dont have the permission holes to allow screen readers? Thats crazy and may be possible to fix with a global override.
The idea of booting my entire operating system from a container created on Github's infrastructure is just...it scares me.
Same here. I think it would be nice to create 2 or so base images on an individual host like Codeberg, but I am completely new to all that container stuff.
I wonder if Sourcehut does container registries...I know people praise their CI.
There are so many alternatives. I even have access to a selfhosted Gitea instance which may also be fine.
I know Tor uses Gitlab.
At the surface, yes. But I wonder about the stuff in the background, like decentralized encrypted backups, maybe not traceable or something.
Interesting, will add that blog to my Feeds :D
I'm thinking about Fedora including the build in their own repositories.
For sure it needs to, to be a usable product.
I only see it as a platform which needs to be tweaked to be usable. Currently doing a bit of work, upstreaming some secureblue things (btw the admin blocked be because they... dont like annoying questions?).
Matrix is also horrible for Dev work. People dont use threads so they just spam stuff in a single chat and it just bad...
Also, these change processes are damn slow, but hey, thats fine I guess?
it's a crucial part of my workflow because I convert so much media.
I want to start doing some videos, no idea why OBS just has h264 hardware? I mean it doesnt matter but why no VP9? AV1 will come in 30.1 you know when that is stable?
I would just invoke the ffmpeg from some Flatpak, freedesktop.org runtime may have it. Maybe with some flatpak-spawn it could even have access everywhere?
Do you know what flatpaks (that are not VLC) have ffmpeg as a binary included?
But Nautilus works really well as a Flatpak. It even seems faster than non-Flatpak Nautilus
Interesting, I need to try full-Flatpak Kinoite in a VM. I think Flatpak Firefox is also faster, but I need to benchmark that again.
I did quite a big benchmark including Brave, Firefox Tarball (firefox and firefox-bin), Fedora Firefox, Librewolf, Torbrowser, MullvadBrowser.
Need to do that again. I also compiled FF myself for some time to use it on secureblue with hardened malloc. Funny enough, Fedora FF allows to replace the memory allocator now that I opened an issue, but it is very questionable if hardened_malloc is more secure, and if LD_PRELOAD is a secure way to do that.
Toolbox is the right way to solve the problem. It's using a real programming language (Go) instead of bash, it supports a small set of important container images, and those container images are only provided from quay.io, Red Hat's own infrastructure, instead of Docker Hub.
I agree on these points. Is it considerably faster? Because bash is slow as hell, I need to start learning some real language as my bash scripts start getting a pain. (Especially the Arkenfox (FF and TB) scripts need to get a big overhaul and I am still bery unhappy with them).
I use Toolbox for Signal and Steam because I don't want to use Unverified Flatpaks.
Well I hope you use an Ubuntu container because I bet these packages are also not "verified" on Arch ;)
I use 90% verified and just have the verified subset repo around to check if an app is. If it is, I get 2 installation repos.
But these both apps are also Electron apps and supposedly containers dont restrict user namespace creation, so they are the best way to run these apps. According to uBlue devs, Firefox too.
Or Debian containers.
You could use Debian Testing which is rolling afaik.
Fedora rawhide is too unstable, OpenSUSE has some strange package issues (I use QGis and RStudio).
RStudio uses the system package manager to add dependencies, nice concept but annoying on atomic. There is this guy that just builds the entire R libraries as RPMs on COPR, he had to reduce the repos priorities because it prevented all the other projects from building their stuff.
Does Arch have Rstudio stuff? I really think they should just abandon that concept and build the libraries themselves, and install them to the app directory...
Same for QGis but that needs pip.
It really makes me feel at home on Fedora.
Ironic. But I really wonder what to use. Basically its
Debian Testing
OpenSUSE Tumbleweed
Arch
... ?
These damn package names. Or maybe dnf5 could solve this? I really like Fedora packages, they are often very good.
Also when it comes to deduplicating libraries, I dont need a separate distro in a container, I need a clone of my current system and just a few packages and their specific dependencies on top. Not sure how this could work, especially in RAM, there is a thread somewhere on Discuss.
Never heard of that, I hope accessibility on Wayland improves.
Neal Gompa mentioned that Flatpaks dont have the permission holes to allow screen readers? Thats crazy and may be possible to fix with a global override.
I think GNOME is working on a portal for that. After the Newton stack is in a good state.
Same here. I think it would be nice to create 2 or so base images on an individual host like Codeberg, but I am completely new to all that container stuff.
Codeberg is probably a good host for that.
Currently doing a bit of work, upstreaming some secureblue things (btw the admin blocked be because they… dont like annoying questions?).
Lol. How strange.
Matrix is also horrible for Dev work. People dont use threads so they just spam stuff in a single chat and it just bad…
I don't much like Discord either. Issue tracker is the right place for this sort of discussion in my opinion. Or Sourcehut's mailing lists are fine too.
Also, these change processes are damn slow, but hey, thats fine I guess?
I guess that's kind of the point :)
I want to start doing some videos, no idea why OBS just has h264 hardware? I mean it doesnt matter but why no VP9? AV1 will come in 30.1 you know when that is stable?
I'm usually converting other people's media, so I don't have much experience with OBS. But as for VP9, the industry was gun-shy about it because MPEG-LA threatened to sue Google over patent infringement for it. Essentially the same sort of deal with Sisvel and AV1, except MPEG-LA never followed through on it. Hardware encoding for VP9 has apparently never taken off, but hardware decoding is all around.
Do you know what flatpaks (that are not VLC) have ffmpeg as a binary included?
I like flatpak as it helps me keep bloat down. I always find that native packages eventually pollute the system. Flatpaks do somewhat as well but I can manually delete the app storage if necessary
True, especially the dotfiles. Having them separated in individual per-app directories is awesome
Things installed by apt almost always work as expected and are easily run from the cli.
Flatpaks are sometimes more up to date.
One thing that hasn't been mentioned yet is interopability, that is, flatpak interacting with the rest of your system.
I'm not that familair with flatpak, but in my brief experience with the steam flatpak, I had trouble getting it to recognize my controllers. Steam installed through pacman (Arch's package manager) had no such issues, on the other hand. My hunch is that this has to with flatpaks being more isolated from the rest of your system.
Im pretty sure that's just some kind of permission issue, but it can be nice to not have to troubleshoot acces rights and the like. But this is obviously a double edged sword: more isolation may also mean more security, just at the cost of ease of interaction with other components.
The good news is that flatpak and XDG portals are progressing
Yeah, both have pros and cons. I have Steam installed through pacman and flatpak also. For me I have the Flatpak version because it contains its own version of glibc. This mostly doesn't matter, except I play Squad and it's doing something with it's anti-cheat that isn't supported in the most recent versions of glibc, so I use the Flatpak version for Squad only.
Flatpak is essentially a more controlled environment. It will contain everything it needs to work, which is good for ensuring it works but bad because you'll have duplicates. It mostly doesn't matter which you use, but occasionally it does.
This issue with glibc should have been sorted out. But yeah, if you use arch you may have some issues from time to time cause some projects broke their ABIs sometimes, but I prefer to use the one with pacman cause I only have to update my entire system with one command, also theming is an issue with flatpak that I know there is solutions out there but AFAIK are always adhoc solutions for each app.
Also, IIRC steam folder is always in a weird place using flatpak.
flatpaks are designed for gui apps, and due to packaging dependencies, they are extra heavy in disk space. flatpaks are also most often installed on the user, not systemwide, so no root permissions needed to install.
apt installs systemwide exclusively, but can have a much smaller download size if the dependencies are already installed. Apps sharing dependencies means much less disk space. cli is supported.
they are extra heavy in disk space
While they use more disk space than most native packages, this point is often exaggerated. Flatpak uses deduplication and shared runtimes if multiple apps use the same runtime.
What's up with all the negativity around flatpaks?
I use Arch (btw) and I try to install as much as I can using flatpak. I think they are great. They are compatible, usually up to date, easy to install, easy to remove and it won't break your system. The sandbox can be edited to include more paths etc.
If I developed a Linux app I would absolutely package it as a flatpak. If a package is in pacman, however, I see no reason to use the flatpak version instead.
In addition to other people's comments, flatpaks are usually more up to date than their apt counterpart (expecially those from the debian stable repositories).
I run debian and I deliberately installed some software from flatpak (eg. Ardour and Guitarix) because the deb package is a whole version behind.
Lots, LOTS, TL;DR - flatpaks are sandboxed and work on every* distro out there, while apt packages are not and only work on debian and it's derivatives. I'd say on mint or debian, prefer using flatpaks over apt packages as you're usually gonna get newer versions of software.
Flatpaks won't get their libs updated all at once by just updating a library. This can be very bad in cases like bugs in openssl. Instead of just updating one library and all other software benefiting from the fix, with flatpaks, you need to deal with updating everything manually and waiting for the vendor to actually create an update package.
I'm not 100% sure about this. Flatpak has some mechanisms that would allow to manage dependencies in a common fashion.
Most Flatpaks depend on the Freedesktop Platform runtime, or GNOME/KDE runtimes, which are derived from it. This contains several hundred common dependencies and librarires programs need, like gcc and python. When you update the runtime (change it from 22.08 to 23.08 in the manifest), all the dependencies are updated too. Many simple applications don't depend on many more dependencies than are available in the runtime. Some...have more complicated dependency trees.
But counterpoint: the developer will update the dependencies when they are known to work properly with the application. Upgrading GTK3 to GTK4 in the GIMP flatpak will just break the application. Same thing with Krita and the dozens of patches to libraries it depends on. If you upgrade the application in the name of security before it's compatible, all you end up with is a broken application. Which I guess is more secure, but that's not helpful to anyone.
Which means that if you have a flatpak with an uncommon library and the dev stops issuing updated flatpaks because they get hit by a bus, you could be SOL with respect to that library. Distro libs are less likely to have this happen because very few distros have a bus factor of 1—there's usually someone who can take over.
TIL about bus factor
if you have a flatpak with an uncommon library
In this case, you're responsible for packaging it yourself. This usually means specifying the git URL and build options in the manifest. You can see Krita doing this in their manifest because they don't depend on the KDE Platform, as they need much older dependencies. So they're responsible for over 1000 lines worth of dependencies.
The Freedesktop Platform is essentially a distribution unto itself, and I don't think there's ever been a case of dependencies in that distribution not being kept up-to-date.
Distro libs are less likely to have this happen because very few distros have a bus factor of 1—there’s usually someone who can take over.
Well...debatable. There were over 1200 orphaned packages in Debian last year, many of which had not been maintained in over 3 years.
Thanks for the interesting point! I learned something today. I guess it all depends on your use-case, whether flatpaks make sense or not.
I wonder how much work would be needed to make a "FreeDesktop Linux" complete OS, with the runtime + whatever it needs beyond that. Then when you install a flatpak, it's just like installing, uh, I didn't think this through tbh.
Well, if you think about it, the Freedesktop Platform is essentially a distribution. And Flatpak used to be called "xdg-app". If you've got all your graphical applications installed via Flatpak, with GNOME, Systemd, glibc, GRUB and all the core dependencies only packaged for the base system (essentially Arch's core repository), that's pretty much a Freedesktop OS.
Hey, maybe we could use Snaps for the base system and Flatpaks for the userland? Or are these the kinds of ideas that get people stoned?
Common libraries like OpenSSL are usually bundled in runtimes. So if my application uses e.g. org.gnome.Platform, I don't have to update my application if there is a fix in a library of that runtime, I just need to update the runtime.
The runtime is also shared by all applications that use this runtime.
Flatpak's benefits mostly exist for the developer. Apt is more tightly integrated with the distro, which is generally advantageous, but also means more work for packaging. Flatpak's benefit is that it's a compatibility layer for lots of different distros. In a perfect world, every distro would have a large library of packages in the official repo, but that's a lot of work for devs, and flatpak lets them avoid that sprawling support.
Flatpaks require more storage space as all dependencies are combined in a flatpak. For me rather 2nd choice.
FYI: Flatpaks can share some dependencies and duplicate files.
It isn't bad if you have a bunch of flatapaks as they share dependencies. For install the first install might be huge but the second app that also uses the same framework will be much smaller
Flatpak is good for applications where you want the people who write the software to be creating the releases and for closed source apps that you want to isolate a bit from your system.
For example, on a new system you might install everything using apt except for Zoom. Zoom isn't in the Debian repos, it's closed source and proprietary. But you can get the official Zoom application using flathub. Zoom will also be fairly isolated from the rest of your system so it has less access to your files and can be removed more cleanly later on if needed.
I'm using MX, debian based, apt package, I have 0 flatpak/snap. They are up to date on about everything, like the latest Firefox I got this morning in a simple .deb that nala (apt frontend) installed without problems.
I never ever installed a snap/flat in my Linux years.
Honestly you should (flatpak that is)
Flatpaks are nice and provide isolation so installed apps do not add bloat to the core system.
I thought id give flatpak firefox a shot and the profiles are broken. I might be able to fix it by making some symlinks but it left a bad taste in my mouth. I was unable to get it to recognize my userChrome.css
I'm not very knowledgeable about this sorta thing. I'm just gonna say that modding games with the Flatpak version of Steam is way easier.
Security. Use apt
apt runs as root
Yep, and that's not a problem
bwrap wants to have a word with you
Sorry I tried to download bwrap but I got a virus because flatpak doesn't verify anything that it downloads with cryptography
This is kind of a bad comparison. Theoretically, malicious authors could sign their Flatpak packages and Flatpak could verify it with cryptography. It doesn't matter if you're downloading a "crypto-wallet" that's really just a phishing exercise.
That's why they put their public key fingerprint on many distinct domains, and users can import them and pin them. Flatpak doesn't support this. Apt does.
Pro apt:
Contra apt:
Pro Flatpak
Contra Flatpak
In general I agree, though had something to add regarding these points:
This is a rather major problem with Flatpak; the maintainer decides what permissions they need by default, not the user. The user needs to retroactively roll them back or specify global options and manually override them per-app, but that's not user-friendly at all. Though many Flatpaks do have good permissions because Flathub maintainers step in and offer suggestions before approving the Flatpak for publication, there are a number of Flatpaks that punch big holes in the sandbox; so much so that they might as well be unsandboxed.
But Bottles has a great sandbox, for instance, which is just what you'd want when running lots of proprietary Windows applications you maybe don't trust as much as your Linux-y software.
It's better than what we have with traditional packages but it can sometimes get in the way and not all beginners can easily figure out how to fix permissions issues with Flatseal. This will probably improve as we get more portals built.
Not much is different for distribution-maintained packages, either. See TheEvilSkeleton's post about how there are over 1200 unmaintained packages in the Debian repositories, and even over 400 in Arch's much smaller repositories that are outdated (!). At least Flathub applications are usually maintained by upstream, and so are usually as up to date as they can be.
This isn't really true. It's only true when terminal applications need privileged access to something. Flathub ships Mesa userpace drivers and NVIDIA's proprietary userspace drivers just fine. You can package something like
yt-dlpin Flatpak just fine with--filesystem=host. Hell, they've even got Neovim on Flathub. Sure, it's a little more cumbersome to type, but you can always create an alias.Flatpak is not suitable for all graphical applications, either. Wireshark's full feature-set cannot be supported, for example.
I would add that:
flatpak update --commit. Much harder with traditional package systems, and you'll probably need to downgrade shared libraries too.masteror with a few patches, all you really need to do is clone it fromflathub/whatever, change a few lines, and it has a very high chance of building properly. No need to figure out dependencies, toolchains, or sane build options. And it's all controlled from an easy-to-read and modify file.The default is completely sandboxed. Developers need to allowlist exactly what they want. So it is transparent.
Compare that to a random app where you need to monitor its syscalls to see what it does.
KDE Plasma now includes a GUI settings page that allows to change these.
I think GNOME needs to integrate that into their settings, I mean just include damn Flatseal as a settings page...
This is supercool and I started doing that. All apps get the env vars to force Wayland now even though they may not use it. I have my overrides and uploaded them to my dotfiles.
Echo that
This is crazy, same on Fedora. Distros really need to start using separate repos, and automatically filter out everything that didnt get a "I maintain this" for a while.
There are packagers maintaining a shitload of apps at once.
Not always but having this at all, and having most big names in there, is incredible. This is like a first time this happens.
Ostree is great
And having it declared centrally can help add all the security benefits of the individual ones too. Really nice
The default before the developer touches it doesn't matter; compare this to Android, iOS, or macOS's permission system. An app needs to ask for permission to use the microphone or access your files. With Flatpak, all a developer needs to do is specify
--filesystem=homeor--socket=pulseaudioand if the user hasn't specified global options like--nofilesystem=home, then the developer gets access to it. Having a sandbox that is optional for the developer rather goes against the point of a sandbox, don't you think?I'm not unsympathetic to Flatpak developers, though. The status quo on Linux for decades has been, "you get access to everything." If Flatpak enforced that sandbox, more than half of the apps on Flathub right now just wouldn't work because they don't support the filesystem portal.
I think GNOME and KDE need to do the work of manually restricting Flatpak apps' access to sensitive permissions like
homeby default, maybe in a few years when the idea of the filesystem portal has had time to gestate among developers. Kind of like how Firefox's HTTPS-only mode (which I think should be the default) prevents you from accessing the website unless you give permission.That's something we can work on, I think. At least we have a way to get there.
I recall saying the exact same thing. They have a built-in area for it in the Apps section. They'll probably get around to it eventually...
It's pretty crazy. I think this is probably the craziest example: https://old.reddit.com/r/archlinux/comments/f3wrez/much_love_to_felix_yan_an_arch_maintainer_from/
Felix Yan is awesome to be maintaining thousands of packages for Arch. But man, that's a lot of work. If we could reduce the workload of our package maintainers who rarely receive any gratitude (usually only demands) and let them focus on the really important packages, I think that would also be awesome.
Yay my answer was deleted...
It matters as the security rating is based on that, apps like KDE Systemsettings or Flatseal show that etc.
I agree that asking for permissions is better.
Placing an override in
~/.local/share/flatpak/overrides/globalwould be an easy workaround.Desktops could implement dialogs that use the currently preset permissions.
No, these are defined, enumerated holes in a sandbox. Without a sandbox you need to monitor the behaviour yourself or other things.
This is the only good working GUI sandbox I know.
Important point here:
I should open a bug about this. It cant be that this is not default, it works well and I agree on the style of implementation.
But this would also need apps to have that mechanism. A Libreoffice will just say "file doesnt exist" currently.
Thats why I like Fedora Atomic. The core is as small as possible, the apps are just base stuff or upstream stuff like the Desktop. Everything else is a Flatpak.
It is so much more secure.
RHEL / CentOS has different repos for core and extras. More distros will do that
That's a good point.
That's true.
I think my issue with the Flatpak sandbox is I understand how it works and what its limitations are (and I'm mostly fine with them), but the average user doesn't. I was reluctant to try Flatpak before understanding how it worked, but now that I know how it works, I think it's fantastic! But it's also a work-in-progress. What we have now is good, but I think it could be better. Not entirely sure how it gets better though.
I'm still not really sure where I stand on Fedora Atomic. Lack of H.264 decoding by default is a damaging choice. They should just include openH264 in the base image, reproducibility be damned. Give it 5 more years and maybe this will be revisited...
Nova + Zink + NVK will solve some of the problem with NVIDIA (maybe even very soon), but not hardware decoding currently, which is a big one.
Gamescope doesn't work great in a Toolbox. It works fine in Flatpak, but Bottles doesn't let me use Gamescope options. I think Lutris does, but I haven't tried it out yet.
And how am I supposed to install fonts without layering them on?? I've been copying them to
~/.local/share/fontsmanually.I think the idea is cool. But I think a few more parts of the ecosystem need to be in place first. I'll keep using it for now.
I maintain a list of recommended Flatpak apps.
I had a damn Librewolf crash some time ago, the RPM is broken, switched back to Firefox... so I lost about 3 hours of overhaul of that list as it is currently very messy.
But if it is fixed, feel free to submit apps to be included, to have a "goodness enumerating" list of apps, rather than a huge mess of random apps.
They dont include that? I thought they would...
I use Fedora kinoite-main from uBlue which is very close to upstream but fixes many issues for me.
UBlue focussing on their very opinionated variants is a bit annoying, because it is now pretty hard to find a guide how to install kinoite-main. I just have a bookmark of their archived website.
If this is actually an issue I would like to tackle that. I am currently doing a Change Proposal to make the default rpm-ostree permissions reasonably secure.
So this is an issue with reproducability? I dont think so? Cisco builds the binaries for Fedora and it gets installed. The packages are not from their repos, but the typical sync issues would not occur on Atomic.
Yeah for sure, I think for Intel and AMD too, hardware h264 for example. AV1 in OBS will be awesome though.
But thats why I use uBlues base images, it is Fedora and I say I use Fedora and participate in their community, but their base images have a ton of stuff I dont agree with (toolbox, missing random packages, too simplistic installer...)
I'm very familiar with you, haha. You keep popping up wherever I go these days. You're everywhere. Maybe not quite as omnipresent as Neal Gompa.
I can think of a few Flatpaks that could fit on that list.
It's the same old story with codecs. Fedora would love to support as many codecs as possible, but H.264 is patent-encumbered so they can't. They had hardware decoding support through Mesa a few years ago but then they...changed it.
Fedora Atomic wants to include the OpenH264 enablement package for Firefox inside the Fedora Flatpak eventually which will solve most of the problem as that is where people are playing H.264 most often.
My understanding is OpenH264 is provided in binary-only format to Fedora because otherwise the royalty-free license cannot apply (i.e. Fedora can't build it from source). Fedora only ships free software. OpenH264 is free software. But it's binary-only. So they need to trust Cisco has built the binary correctly. I assume the reason they don't include it by default is because the only way to trust it's built from the same sources is to reproduce the build. Otherwise, I really don't see the issue.
OpenH264 is not a part of the base system so you need to layer it on. OpenH264 doesn't have support for High 10 Profile video which is fairly common off the web and is generally inferior to x264, I've found, but at least it's something.
And the reason I mention "5 years" is because by then, most of the patents on H.264 will have expired. With the exception of the new ones from just a few years ago that no one really uses. Maybe Fedora can enable x264 in their ffmpeg build then and we can stop talking about it. I am so sick of talking about H.264.
Call it a personal challenge or whatever but I'm sticking to Fedora Silverblue for the foreseeable future. uBlue is almost certainly a better experience for most people.
That's not true if you're using Flathub packages. Flathub ships userspace Mesa drivers which enable hardware decoding for Intel and AMD GPUs even with H.264 and H.265.
uBlue does solve the two big issues with Fedora, which is codecs and proprietary NVIDIA drivers. Any other issues are tiny in comparison. I will say I prefer Toolbox to Distrobox, despite using Distrobox first. I certainly understand that's an unpopular opinion and not one a lot of people share. It's probably the same reason you use KDE and I use GNOME (most of the time).
I've always hated the Fedora installer. Does uBlue do something different?
Funny, I use that name not so long. Currently hyperfocused on Fedora Discuss, Lemmy and Github.
Although I should really change my stuff to some Forgejo instance and just mirror to Github.
I thought a lot about tech resiliance in the last days, I am from germany and the people here are stupid. They literally elect people that will make a neofascist surveillance hell reality.
I wonder how Tor, Tails and others handle their code stuff. Apart from selfhosting their services of course. Like resiliance, I think decentralized code repos are crucial.
I really like how uBlue just used the official Fedora OCI images (that they produce but dont even use) and used all the container tooling to create this awesome project.
But relying on Github is insane, it is owned by Microsoft and they dont give a damn about freedom. It is pretty scary, 90% of my Android apps are also on Github.
I want to build my own variant, KDE and minimal only, maybe GNOME if contributors join. But no more, all the freedom is great but it is huge maintenance.
I thought Ciscos trick could fix that? They are a huge company, pay the max amount of money already and can just share the software with their license to anyone.
Not sure if that is the best way. Flatpak has runtime extensions, and rpmfusion could build one for the entire ffmpeg and more. This could just be added from an external repo and installed along.
Or they include openh264 in their runtime.
Fedora Flatpaks got quite a boost recently and even have some KDE apps not on Flathub.
Well... rpmfusion could do that? And act like a "3rd party auditor" ?
Interestesting, never heard that. I use Celluloid Flatpak which is pretty great (I wish Haruna would get their basics together like customizable UI, working subtitles, working queue etc).
So the only reason to have ffmpeg is nice terminal stuff, Dolphin extensions or just video previews in Dolphin. Nautilus supports that via a Flatpak right? Thats cool.
Fuck patents. I am happy that we now have AV1 and dont really know why VP9 is not more used? It is a pain!
I have a command text file with the exact command I need to reproduce my install. One for Fedora Kinoite, one for Kinoite-main.
It is just a few packages and I really only need the things I mentioned.
I also dont like Aurora or others that much, they have too much stuff added.
True, Flatpak is cool. Dolphin is also available as one, I need to test if it works with Flatpak ark and all that, udisks2, mounting stuff, MTP, maybe SMB.
Interesting, why? I need to try it again.
Do you know btw how to upgrade a F39 distrobox to F40? Distrobox has some "assemble" function to rebuild it with a config file. But traditional dnf system-upgrade doesnt work.
Why? Curious.
No uBlue uses Anaconda too, which is a whole set of stuff. They are testing the new UI (a component of Anaconda) for workstation exclusively.
uBlue pioneered in making Anaconda work for installing OCI rpm-ostree btw
Looks like we frequent the same circles, then.
But hey, Germany was responsible for the Sovereign Tech Fund, which has made a big difference for GNOME and accessibility with the Newton stack. So it's not all bad. Not that I live there.
That's the main reason I don't use uBlue. The idea of booting my entire operating system from a container created on Github's infrastructure is just...it scares me. Even though much of the free software I rely on is hosted on Github. And yes, most of my Android apps are also from Github.
That's a nice idea. I wonder if Sourcehut does container registries...I know people praise their CI.
I know Tor uses Gitlab. Seirdy has an article series on "Resilient Git".
Yes, however it only covers their implementation (which is lacking) and it only covers binaries they create.
I'm thinking about Fedora including the build in their own repositories. It would be really nice if H.264 decoding was just default and you didn't need to do anything.
See the following thread for all of the research I did: https://discussion.fedoraproject.org/t/h-264-support-in-fedora-workstation-by-default/114521
Michael Cantazaro had a really helpful and enlightening response: https://discussion.fedoraproject.org/t/h-264-support-in-fedora-workstation-by-default/114521/5
So do I. But keep in mind there are two Celluloid Flatpaks you can install; one is from Fedora Flatpaks which disables H.264/H.265/VC-1 decoding and the other is from Flathub with all features enabled.
GNOME Software tends to select Fedora Flatpaks first. So users can end up really confused; see: https://github.com/flathub/io.github.celluloid_player.Celluloid/issues/140
File previews are supported via the Sushi extension, which is available as a Flatpak. Obviously, it doesn't work on H.264/H.265/VC-1 media because it's a Fedora Flatpak.
I really need ffmpeg because it's a crucial part of my workflow because I convert so much media. But that's fine; I just use it in a Toolbox.
But Nautilus works really well as a Flatpak. It even seems faster than non-Flatpak Nautilus and I have no idea why.
KDE made a big push to make all of their programs available as Flatpaks. And Snaps. Which I think is great. But you end up in a weird situation where the Krita Flatpak is not officially supported by Krita because no one at Krita works on maintaining the Flatpak. Rather, they support only AppImage officially, probably because it's easier to maintain their insane patchset than with Flatpak. Not having any experience with distribution systems aside from Flatpak, I really don't know what niceties Snap or AppImage provides.
Nothing much has changed since last you commented on that Toolbox thread I was reading :)
I think Toolbox is the right way to solve the problem. It's using a real programming language (Go) instead of bash, it supports a small set of important container images, and those container images are only provided from quay.io, Red Hat's own infrastructure, instead of Docker Hub.
But it lacks some features intentionally (and some just because they haven't gotten around to it). Like
distrobox export. Annoying to manually patch in but not hard. I use Toolbox for Signal and Steam because I don't want to use Unverified Flatpaks.I don't think upgrading Distroboxes or Toolboxes is supported. They're meant to be destroyed and re-created. Really inconvenient, but I guess the proper way of maintaining toolboxes/distroboxes is through Containerfiles.
So I don't use Fedora containers. Or Ubuntu containers. Or Debian containers.
I use Arch because it's a rolling release and you just keep updating it. No upgrade problems so far...aside from all the errors I ignore (everything seems to work fine). Also, I really like the Arch userland and it has Signal Desktop in the official repositories.
It really makes me feel at home on Fedora.
I think GNOME provides a more coherent and consistent experience for users. I'm okay with not having features like a system tray, desktop icons, or window buttons I never use. I really love GNOME. It's changed the way I use computers and has made everything aside from KDE feel like a completely inferior experience in comparison.
But I use KDE for my multi-monitor system because frankly, GNOME is an awful experience if you have more than one monitor with different resolutions. KDE kind of sucks too, but it's not completely broken. KDE is practical by solving problems we have now, like letting XWayland applications scale themselves. Because even if it's a total hack that works inconsistently, it works very well for most of the software I use. I find parts of KDE overwhelming (especially the System Settings) but hey, it works.
I like both KDE and GNOME and think each has their own strengths. It's nice to see KDE adopt one of GNOME's killer features (partially), the Overview. It'd be nice to see GNOME adopt a KDE feature like
CTRL+META+ESCso I can kill windows graphically even on Wayland.But god GNOME is annoying when it comes to protocol standardization. At least they're finally implementing DRM Leasing for VR users (not me).
Huh. I thought I was supposed to be sticking up for GNOME. Alright, I use GNOME everywhere else and it's still my favorite desktop by far. They focus on a great experience with what works great now. There are very few hacks in GNOME land. I just think they need to catch up to KDE with Wayland and other areas like the multi-monitor stuff.
Never heard of that, I hope accessibility on Wayland improves.
Neal Gompa mentioned that Flatpaks dont have the permission holes to allow screen readers? Thats crazy and may be possible to fix with a global override.
Same here. I think it would be nice to create 2 or so base images on an individual host like Codeberg, but I am completely new to all that container stuff.
There are so many alternatives. I even have access to a selfhosted Gitea instance which may also be fine.
At the surface, yes. But I wonder about the stuff in the background, like decentralized encrypted backups, maybe not traceable or something.
Interesting, will add that blog to my Feeds :D
For sure it needs to, to be a usable product.
I only see it as a platform which needs to be tweaked to be usable. Currently doing a bit of work, upstreaming some secureblue things (btw the admin blocked be because they... dont like annoying questions?).
Matrix is also horrible for Dev work. People dont use threads so they just spam stuff in a single chat and it just bad...
Also, these change processes are damn slow, but hey, thats fine I guess?
I want to start doing some videos, no idea why OBS just has h264 hardware? I mean it doesnt matter but why no VP9? AV1 will come in 30.1 you know when that is stable?
I would just invoke the ffmpeg from some Flatpak, freedesktop.org runtime may have it. Maybe with some flatpak-spawn it could even have access everywhere?
Do you know what flatpaks (that are not VLC) have ffmpeg as a binary included?
I need to add a better app to this guide since I dont use VLC anymore.
Interesting, I need to try full-Flatpak Kinoite in a VM. I think Flatpak Firefox is also faster, but I need to benchmark that again.
I did quite a big benchmark including Brave, Firefox Tarball (
firefoxandfirefox-bin), Fedora Firefox, Librewolf, Torbrowser, MullvadBrowser.Need to do that again. I also compiled FF myself for some time to use it on secureblue with hardened malloc. Funny enough, Fedora FF allows to replace the memory allocator now that I opened an issue, but it is very questionable if hardened_malloc is more secure, and if LD_PRELOAD is a secure way to do that.
I agree on these points. Is it considerably faster? Because bash is slow as hell, I need to start learning some real language as my bash scripts start getting a pain. (Especially the Arkenfox (FF and TB) scripts need to get a big overhaul and I am still bery unhappy with them).
Well I hope you use an Ubuntu container because I bet these packages are also not "verified" on Arch ;)
I use 90% verified and just have the verified subset repo around to check if an app is. If it is, I get 2 installation repos.
But these both apps are also Electron apps and supposedly containers dont restrict user namespace creation, so they are the best way to run these apps. According to uBlue devs, Firefox too.
You could use Debian Testing which is rolling afaik.
Fedora rawhide is too unstable, OpenSUSE has some strange package issues (I use QGis and RStudio).
RStudio uses the system package manager to add dependencies, nice concept but annoying on atomic. There is this guy that just builds the entire R libraries as RPMs on COPR, he had to reduce the repos priorities because it prevented all the other projects from building their stuff.
Does Arch have Rstudio stuff? I really think they should just abandon that concept and build the libraries themselves, and install them to the app directory...
Same for QGis but that needs pip.
Ironic. But I really wonder what to use. Basically its
These damn package names. Or maybe dnf5 could solve this? I really like Fedora packages, they are often very good.
Also when it comes to deduplicating libraries, I dont need a separate distro in a container, I need a clone of my current system and just a few packages and their specific dependencies on top. Not sure how this could work, especially in RAM, there is a thread somewhere on Discuss.
Here's a recent article: https://blogs.gnome.org/a11y/2024/06/18/update-on-newton-the-wayland-native-accessibility-project/
So do I.
I think GNOME is working on a portal for that. After the Newton stack is in a good state.
Codeberg is probably a good host for that.
Lol. How strange.
I don't much like Discord either. Issue tracker is the right place for this sort of discussion in my opinion. Or Sourcehut's mailing lists are fine too.
I guess that's kind of the point :)
I'm usually converting other people's media, so I don't have much experience with OBS. But as for VP9, the industry was gun-shy about it because MPEG-LA threatened to sue Google over patent infringement for it. Essentially the same sort of deal with Sisvel and AV1, except MPEG-LA never followed through on it. Hardware encoding for VP9 has apparently never taken off, but hardware decoding is all around.
There's: https://flathub.org/apps/org.gnome.gitlab.YaLTeR.VideoTrimmer
Honestly, as long as I don't notice it, it doesn't bother me. I only noticed Flatpak Nautilus' launch time because it was instant.
I think so. It at least seems more reliable. I got a bunch of weird bugs with Distrobox in the beginning but I guess I was pushing it pretty far.
I kind of hate Python but it's at least more pleasant than Bash. I've no experience with Go, but it's probably nice to write.
Ah, well, I use Arch for all my other computers so I feel like I'm already trusting Arch's devs for all my packages. What's one more?
I make an exception for Anki and MakeMKV.
I kind of hate Debian and Ubuntu's userpsace :) It's okay on servers.
It has it in the AUR, but not as an official package. In most cases the AUR is just as good anyway.
DNF5 will definitely shake things up. Because
rpm-ostreeis going away to be replaced bydnfagain.I like flatpak as it helps me keep bloat down. I always find that native packages eventually pollute the system. Flatpaks do somewhat as well but I can manually delete the app storage if necessary
True, especially the dotfiles. Having them separated in individual per-app directories is awesome
Things installed by apt almost always work as expected and are easily run from the cli.
Flatpaks are sometimes more up to date.
One thing that hasn't been mentioned yet is interopability, that is, flatpak interacting with the rest of your system.
I'm not that familair with flatpak, but in my brief experience with the steam flatpak, I had trouble getting it to recognize my controllers. Steam installed through pacman (Arch's package manager) had no such issues, on the other hand. My hunch is that this has to with flatpaks being more isolated from the rest of your system.
Im pretty sure that's just some kind of permission issue, but it can be nice to not have to troubleshoot acces rights and the like. But this is obviously a double edged sword: more isolation may also mean more security, just at the cost of ease of interaction with other components.
The steam flatpak can't install udev rules. It works if you install a packacke such as
steam-deviceson your host system. See https://github.com/flathub/com.valvesoftware.Steam/wiki#my-controller-isnt-being-detectedThe good news is that flatpak and XDG portals are progressing
Yeah, both have pros and cons. I have Steam installed through pacman and flatpak also. For me I have the Flatpak version because it contains its own version of glibc. This mostly doesn't matter, except I play Squad and it's doing something with it's anti-cheat that isn't supported in the most recent versions of glibc, so I use the Flatpak version for Squad only.
Flatpak is essentially a more controlled environment. It will contain everything it needs to work, which is good for ensuring it works but bad because you'll have duplicates. It mostly doesn't matter which you use, but occasionally it does.
This issue with glibc should have been sorted out. But yeah, if you use arch you may have some issues from time to time cause some projects broke their ABIs sometimes, but I prefer to use the one with pacman cause I only have to update my entire system with one command, also theming is an issue with flatpak that I know there is solutions out there but AFAIK are always adhoc solutions for each app.
Also, IIRC steam folder is always in a weird place using flatpak.
flatpaks are designed for gui apps, and due to packaging dependencies, they are extra heavy in disk space. flatpaks are also most often installed on the user, not systemwide, so no root permissions needed to install.
apt installs systemwide exclusively, but can have a much smaller download size if the dependencies are already installed. Apps sharing dependencies means much less disk space. cli is supported.
While they use more disk space than most native packages, this point is often exaggerated. Flatpak uses deduplication and shared runtimes if multiple apps use the same runtime.
What's up with all the negativity around flatpaks? I use Arch (btw) and I try to install as much as I can using flatpak. I think they are great. They are compatible, usually up to date, easy to install, easy to remove and it won't break your system. The sandbox can be edited to include more paths etc.
If I developed a Linux app I would absolutely package it as a flatpak. If a package is in pacman, however, I see no reason to use the flatpak version instead.
In addition to other people's comments, flatpaks are usually more up to date than their apt counterpart (expecially those from the debian stable repositories).
I run debian and I deliberately installed some software from flatpak (eg. Ardour and Guitarix) because the deb package is a whole version behind.
Lots, LOTS, TL;DR - flatpaks are sandboxed and work on every* distro out there, while apt packages are not and only work on debian and it's derivatives. I'd say on mint or debian, prefer using flatpaks over apt packages as you're usually gonna get newer versions of software.
Flatpaks won't get their libs updated all at once by just updating a library. This can be very bad in cases like bugs in openssl. Instead of just updating one library and all other software benefiting from the fix, with flatpaks, you need to deal with updating everything manually and waiting for the vendor to actually create an update package.
I'm not 100% sure about this. Flatpak has some mechanisms that would allow to manage dependencies in a common fashion.
Most Flatpaks depend on the Freedesktop Platform runtime, or GNOME/KDE runtimes, which are derived from it. This contains several hundred common dependencies and librarires programs need, like
gccandpython. When you update the runtime (change it from22.08to23.08in the manifest), all the dependencies are updated too. Many simple applications don't depend on many more dependencies than are available in the runtime. Some...have more complicated dependency trees.But counterpoint: the developer will update the dependencies when they are known to work properly with the application. Upgrading GTK3 to GTK4 in the GIMP flatpak will just break the application. Same thing with Krita and the dozens of patches to libraries it depends on. If you upgrade the application in the name of security before it's compatible, all you end up with is a broken application. Which I guess is more secure, but that's not helpful to anyone.
Which means that if you have a flatpak with an uncommon library and the dev stops issuing updated flatpaks because they get hit by a bus, you could be SOL with respect to that library. Distro libs are less likely to have this happen because very few distros have a bus factor of 1—there's usually someone who can take over.
TIL about bus factor
In this case, you're responsible for packaging it yourself. This usually means specifying the git URL and build options in the manifest. You can see Krita doing this in their manifest because they don't depend on the KDE Platform, as they need much older dependencies. So they're responsible for over 1000 lines worth of dependencies.
The Freedesktop Platform is essentially a distribution unto itself, and I don't think there's ever been a case of dependencies in that distribution not being kept up-to-date.
Well...debatable. There were over 1200 orphaned packages in Debian last year, many of which had not been maintained in over 3 years.
Thanks for the interesting point! I learned something today. I guess it all depends on your use-case, whether flatpaks make sense or not.
I wonder how much work would be needed to make a "FreeDesktop Linux" complete OS, with the runtime + whatever it needs beyond that. Then when you install a flatpak, it's just like installing, uh, I didn't think this through tbh.
Well, if you think about it, the Freedesktop Platform is essentially a distribution. And Flatpak used to be called "xdg-app". If you've got all your graphical applications installed via Flatpak, with GNOME, Systemd, glibc, GRUB and all the core dependencies only packaged for the base system (essentially Arch's
corerepository), that's pretty much a Freedesktop OS.Hey, maybe we could use Snaps for the base system and Flatpaks for the userland? Or are these the kinds of ideas that get people stoned?
Common libraries like OpenSSL are usually bundled in runtimes. So if my application uses e.g.
org.gnome.Platform, I don't have to update my application if there is a fix in a library of that runtime, I just need to update the runtime.The runtime is also shared by all applications that use this runtime.
Flatpak's benefits mostly exist for the developer. Apt is more tightly integrated with the distro, which is generally advantageous, but also means more work for packaging. Flatpak's benefit is that it's a compatibility layer for lots of different distros. In a perfect world, every distro would have a large library of packages in the official repo, but that's a lot of work for devs, and flatpak lets them avoid that sprawling support.
Flatpaks require more storage space as all dependencies are combined in a flatpak. For me rather 2nd choice.
FYI: Flatpaks can share some dependencies and duplicate files.
It isn't bad if you have a bunch of flatapaks as they share dependencies. For install the first install might be huge but the second app that also uses the same framework will be much smaller
apt is good for most things.
Flatpak is good for applications where you want the people who write the software to be creating the releases and for closed source apps that you want to isolate a bit from your system.
For example, on a new system you might install everything using apt except for Zoom. Zoom isn't in the Debian repos, it's closed source and proprietary. But you can get the official Zoom application using flathub. Zoom will also be fairly isolated from the rest of your system so it has less access to your files and can be removed more cleanly later on if needed.
I'm using MX, debian based, apt package, I have 0 flatpak/snap. They are up to date on about everything, like the latest Firefox I got this morning in a simple .deb that nala (apt frontend) installed without problems.
I never ever installed a snap/flat in my Linux years.
Honestly you should (flatpak that is)
Flatpaks are nice and provide isolation so installed apps do not add bloat to the core system.
I thought id give flatpak firefox a shot and the profiles are broken. I might be able to fix it by making some symlinks but it left a bad taste in my mouth. I was unable to get it to recognize my userChrome.css
I'm not very knowledgeable about this sorta thing. I'm just gonna say that modding games with the Flatpak version of Steam is way easier.
Security. Use apt
apt runs as root
Yep, and that's not a problem
bwrapwants to have a word with youSorry I tried to download bwrap but I got a virus because flatpak doesn't verify anything that it downloads with cryptography
This is kind of a bad comparison. Theoretically, malicious authors could sign their Flatpak packages and Flatpak could verify it with cryptography. It doesn't matter if you're downloading a "crypto-wallet" that's really just a phishing exercise.
That's why they put their public key fingerprint on many distinct domains, and users can import them and pin them. Flatpak doesn't support this. Apt does.