Flatpak - Flathub
Moderators: MattKingUSA, khz
- khz
- Established Member
- Posts: 1648
- Joined: Thu Apr 17, 2008 6:29 am
- Location: German
- Has thanked: 42 times
- Been thanked: 92 times
Flatpak - Flathub
Flathub is now in version 1.0.
What do you think of the new package service which allows you to install current software promptly -
but is fundamentally different from the previous concept of the package manager?
What do you think of the new package service which allows you to install current software promptly -
but is fundamentally different from the previous concept of the package manager?
. . . FZ - Does humor belongs in Music?
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
- I don't care about the freedom of speech because I have nothing to say.
- khz
- Established Member
- Posts: 1648
- Joined: Thu Apr 17, 2008 6:29 am
- Location: German
- Has thanked: 42 times
- Been thanked: 92 times
Re: Flatpak - Flathub
Correction:
https://flatpak.org/ is version 1.0, of these and numerous other programs can be found on https://flathub.org, which the Flatpak makers have created as the first point of contact for the distribution and procurement of Flatpaks.
https://flatpak.org/ is version 1.0, of these and numerous other programs can be found on https://flathub.org, which the Flatpak makers have created as the first point of contact for the distribution and procurement of Flatpaks.
. . . FZ - Does humor belongs in Music?
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
- I don't care about the freedom of speech because I have nothing to say.
Re: Flatpak - Flathub
In essence, looks like it is a "mac-ification" of Linux. In fact, on Mac OS you can install containerized applications (like flatpak), which I think make up most of the applications today, or install "Linux package style" packages (it happens with many packages) or build from source in Port-like fashion (with homebrew).
So, in essence the project adds containerized applications to Linux too.
I am not exactly a fan of how it works on Mac, the reason being that applications end up creating a lot of cache folders somewhere in your OS, and next thing you know your disk is full of useless stuff so complicated to track down that you need specialized applications for that. This is one of the things I hate most of Mac OS. That said, I don't think this sort of stuff is second nature with containerized applications really, it is probably just the way Mac OS is set up to work.
I don't think audio applications, especially plugins, can be easily distributed, if at all, with these containerized methods - as of now. Today I learned about pipewire, and one of its design goals is to support flatpak: https://pipewire.org/, which makes me think that as of now audio apps are not easy to distribute with flatpak.
So, my current view, as a dude that never tried those methods for Linux, is:
Do they create a bunch of cache directories? If so, I am a bit on the "ugh" side.
Do they allow distribution of audio applications? At this stage, seems not. But I would welcome if flatpak (or similar projects) diffusion could help advancing the audio stack technology in Linux.
Can I update all of my flatpak programs with one command? The last thing I want to do is to browse the internet to manually download the latest version every time it is out. That is exactly the reason why I like package managers better than "download and install" stuff.
So, in essence the project adds containerized applications to Linux too.
I am not exactly a fan of how it works on Mac, the reason being that applications end up creating a lot of cache folders somewhere in your OS, and next thing you know your disk is full of useless stuff so complicated to track down that you need specialized applications for that. This is one of the things I hate most of Mac OS. That said, I don't think this sort of stuff is second nature with containerized applications really, it is probably just the way Mac OS is set up to work.
I don't think audio applications, especially plugins, can be easily distributed, if at all, with these containerized methods - as of now. Today I learned about pipewire, and one of its design goals is to support flatpak: https://pipewire.org/, which makes me think that as of now audio apps are not easy to distribute with flatpak.
So, my current view, as a dude that never tried those methods for Linux, is:
Do they create a bunch of cache directories? If so, I am a bit on the "ugh" side.
Do they allow distribution of audio applications? At this stage, seems not. But I would welcome if flatpak (or similar projects) diffusion could help advancing the audio stack technology in Linux.
Can I update all of my flatpak programs with one command? The last thing I want to do is to browse the internet to manually download the latest version every time it is out. That is exactly the reason why I like package managers better than "download and install" stuff.
-
- Established Member
- Posts: 165
- Joined: Thu Nov 07, 2013 1:19 pm
- Been thanked: 1 time
Re: Flatpak - Flathub
The recent news around all of these options flatpack/snap/etc sound like attempts to push packaging efforts for projects further upstream to the open source projects themselves rather than the distros. This is great for proprietary apps which more or less need this sort of control, but it's just shifting around the job of the packager for open source projects and IMO moves it to a position where it shouldn't be.
ZynAddSubFX maintainer
- AlexTheBassist
- Established Member
- Posts: 353
- Joined: Mon May 19, 2014 3:44 am
- Location: Russia, Moscow
- Been thanked: 1 time
Re: Flatpak - Flathub
This is a fail in general. Why would I want another (usually older) copy of, say, KDE libs in my system? Why would I want to wait for apps to start? I used Flatpak, it's one of the worst things that happened to Linux software packaging. A “natively” (i.e. with a package manager) installed application on my system starts in a flash, while Flatpak installed apps have a startup delay, like, of 6 to 10 seconds. Back in the days, when I've got an IBM XT, this was normal if an HDD is heavily fragmented or in case of running apps from a 5.25" floppy, but today, when an average smartphone is gazillion times more powerful than that poor old XT… Seriously? F**k that.
Being creative does not imply being lazy, stupid, or illiterate.
Working in Harrison Mixbus and Ardour on KDE Neon + KXStudio.
Working in Harrison Mixbus and Ardour on KDE Neon + KXStudio.
Re: Flatpak - Flathub
You might want it if one program is developed and tested against them. It should make it more stable, and they will be used by that program only. This is what Ardour sort of does with their own binary distribution: they distribute a binary built against the libraries version they tested most.AlexTheBassist wrote:Why would I want another (usually older) copy of, say, KDE libs in my system?
- AlexTheBassist
- Established Member
- Posts: 353
- Joined: Mon May 19, 2014 3:44 am
- Location: Russia, Moscow
- Been thanked: 1 time
Re: Flatpak - Flathub
Ardour does it the right way. Flatpak, by the way, shares runtime libraries between the apps, so no “used by that program only” thing. That's why there are only full runtime packages, not sets of libraries a certain app needs.CrocoDuck wrote:You might want it if one program is developed and tested against them. It should make it more stable, and they will be used by that program only. This is what Ardour sort of does with their own binary distribution: they distribute a binary built against the libraries version they tested most.AlexTheBassist wrote:Why would I want another (usually older) copy of, say, KDE libs in my system?
Being creative does not imply being lazy, stupid, or illiterate.
Working in Harrison Mixbus and Ardour on KDE Neon + KXStudio.
Working in Harrison Mixbus and Ardour on KDE Neon + KXStudio.
Re: Flatpak - Flathub
Yes, thanks for pointing that out: http://docs.flatpak.org/en/latest/basic-concepts.html. The libraries your application needs are all bundled within the package, and are not shared anywhere else. Then there is a runtime, which incorporates basic dependencies, and against which the package is built. This is shared among all packages with the same runtime. If I got this straight, in theory, it should still be an improvement on stability with respect the most common scenarios, in which we either:AlexTheBassist wrote:Flatpak, by the way, shares runtime libraries between the apps, so no “used by that program only” thing.
a) Install a version from our distro repo which is built against distro libs, and patched (not always successfully) for that.
b) Build from source against whatever we have in the system.
Not that I ever had many problems with a) and b) in my life, but others that run mission critical applications maybe will disagree.
-
- Established Member
- Posts: 2348
- Joined: Mon Jul 01, 2013 8:13 am
- Has thanked: 9 times
- Been thanked: 468 times
Re: Flatpak - Flathub
I running linux debian/sid now longer then 15 years, and must admit, that I only get problems with applications that I ain't build myself or install from my distribution. I (try to) avoid any third party binary's like plage. And I count packages like Flatpak into the category "avoid it if possible".CrocoDuck wrote:Not that I ever had many problems with a) and b) in my life, but others that run mission critical applications maybe will disagree.
If I want stuff like that, I could use windows or MAC
On the road again.
- AlexTheBassist
- Established Member
- Posts: 353
- Joined: Mon May 19, 2014 3:44 am
- Location: Russia, Moscow
- Been thanked: 1 time
Re: Flatpak - Flathub
I do have problems with Flatpak. It slows down application start significantly. It takes much more time to start an app even on my modern system with an SSD. It's not mission critical, but we live in 21st century, and I don't want to wait for app to launch for so long. That's not what I built a new PC for. Better packaging for certain apps can solve the problem better. For instance, Ardour is installed in /opt directory with all of its libraries and starts right after I click on launcher.CrocoDuck wrote:Not that I ever had many problems with a) and b) in my life, but others that run mission critical applications maybe will disagree.
Being creative does not imply being lazy, stupid, or illiterate.
Working in Harrison Mixbus and Ardour on KDE Neon + KXStudio.
Working in Harrison Mixbus and Ardour on KDE Neon + KXStudio.
- GMaq
- Established Member
- Posts: 2827
- Joined: Fri Sep 25, 2009 1:42 pm
- Has thanked: 530 times
- Been thanked: 573 times
Re: Flatpak - Flathub
Hi,
I always use Debian Stable and for most years have distributed AV Linux on it, I have been testing Flatpak and I'm enjoying the opportunity to work with some newer versions of programs that will never come to Debian Stable and I certainly don't want to start compiling and packaging them (I did that for many years and it's a thankless endless task). I've always liked self-contained binary stuff like Ardour, Mixbus, Blender etc that will run well tested new versions reliably on Stable and LTS distros and I like Flatpak's "One Stop Shopping" for these useful apps. I don't like it's GTK plugin package frontend very much though, very buggy and slow to update and often hangs when checking for update..
Flatpak as a concept is cool with me but the frontend UI needs a lot of refining, polishing and improving IMHO.
I always use Debian Stable and for most years have distributed AV Linux on it, I have been testing Flatpak and I'm enjoying the opportunity to work with some newer versions of programs that will never come to Debian Stable and I certainly don't want to start compiling and packaging them (I did that for many years and it's a thankless endless task). I've always liked self-contained binary stuff like Ardour, Mixbus, Blender etc that will run well tested new versions reliably on Stable and LTS distros and I like Flatpak's "One Stop Shopping" for these useful apps. I don't like it's GTK plugin package frontend very much though, very buggy and slow to update and often hangs when checking for update..
Flatpak as a concept is cool with me but the frontend UI needs a lot of refining, polishing and improving IMHO.
- raboof
- Established Member
- Posts: 1855
- Joined: Tue Apr 08, 2008 11:58 am
- Location: Deventer, NL
- Has thanked: 50 times
- Been thanked: 74 times
- Contact:
Re: Flatpak - Flathub
I like the idea in theory, but I've not worked with Flatpak or any implementation that I liked in practice.
That's funny: I have always felt the 'packagers' are doing far too much (indeed, as GMaq mentions, thankless endless) work, often duplicated across distro's. To me it makes much more sense to push this responsibility (more) towards upstream: after all, that's the part of the community who actually cares. Of course there will always be a bit of distro-specific 'integration work', but moving more of this upstream IMO moves things to where they should be.fundamental wrote:all of these options flatpack/snap/etc sound like attempts to push packaging efforts for projects further upstream to the open source projects themselves rather than the distros. This is great for proprietary apps which more or less need this sort of control, but it's just shifting around the job of the packager for open source projects and IMO moves it to a position where it shouldn't be
This is interesting. Do you have any idea why? Is this caused by a fundamental design flaw, or simply an implementation problem that can be fixed?AlexTheBassist wrote:I do have problems with Flatpak. It slows down application start significantly. It takes much more time to start an app even on my modern system with an SSD.
Re: Flatpak - Flathub
This is bad for normal users, but less so for those who need to run a program for days or more without shutdown or crashes. Those users will never care about startup time, as well as they don't care if their system boots in 30s instead of 10s. Still, we are not that kind of user, on average, I would say. I think we want our apps to be fast and responsive.AlexTheBassist wrote:I do have problems with Flatpak. It slows down application start significantly. It takes much more time to start an app even on my modern system with an SSD. It's not mission critical, but we live in 21st century, and I don't want to wait for app to launch for so long.
That would be indeed interesting to understand. Containerized applications must have their share of downsides. As I said above, I am not too fond about how it works on macs: too much rubbish generated on the system. But the startup time in macs never seemed higher than that of applications installed in the traditional unix way to me, but I never measured anything. It must be a very different technology with respect flatpak, but this makes me think that startup time might be contained within the human threshold of annoyance for containerized applications in general, even if being slower than than those installed in the traditional way. Probably on certain systems it will be felt more? Like, if tomorrow everything was flatpak, how fast and responsive my Raspberry Pi would be? For these mini-systems optimization is still very important, and I don't like wasting performances in general. I am sort of worried that behind flatpak and similar stuff there might be the mentality "don't worry about efficiency, in 2020 computers will be powerful enough to make it fast anyway" of which I am not a big fun, but I really don't know if this is the case.raboof wrote:This is interesting. Do you have any idea why? Is this caused by a fundamental design flaw, or simply an implementation problem that can be fixed?
I started thinking a bit through this lines as well. If we get with some kind of "universal" distribution vector, independently from that being flatpak, snappy or some kind of more traditional package system, I reckon it could be some sustainable overhead, as it would be one thing only to take care of.raboof wrote:That's funny: I have always felt the 'packagers' are doing far too much (indeed, as GMaq mentions, thankless endless) work, often duplicated across distro's. To me it makes much more sense to push this responsibility (more) towards upstream: after all, that's the part of the community who actually cares. Of course there will always be a bit of distro-specific 'integration work', but moving more of this upstream IMO moves things to where they should be.
- khz
- Established Member
- Posts: 1648
- Joined: Thu Apr 17, 2008 6:29 am
- Location: German
- Has thanked: 42 times
- Been thanked: 92 times
Re: Flatpak - Flathub
What about the (automatic) update of the programs and security updates of the (all dependencies included) Flatpak packages? Can this be done promptly and automatically?
. . . FZ - Does humor belongs in Music?
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
- I don't care about the freedom of speech because I have nothing to say.
- AlexTheBassist
- Established Member
- Posts: 353
- Joined: Mon May 19, 2014 3:44 am
- Location: Russia, Moscow
- Been thanked: 1 time
Re: Flatpak - Flathub
Yes, this is the very nature of Flatpak. There's that daemon which starts up too slow, and one can't run Flatpak programs bypassing it. They are started this way:raboof wrote:This is interesting. Do you have any idea why? Is this caused by a fundamental design flaw, or simply an implementation problem that can be fixed?
Code: Select all
flatpak run program_name
Being creative does not imply being lazy, stupid, or illiterate.
Working in Harrison Mixbus and Ardour on KDE Neon + KXStudio.
Working in Harrison Mixbus and Ardour on KDE Neon + KXStudio.