Flatpak - Flathub

Discuss how to promote using FLOSS to make music.

Moderators: MattKingUSA, khz

User avatar
khz
Established Member
Posts: 877
Joined: Thu Apr 17, 2008 6:29 am
Location: German

Flatpak - Flathub

Postby khz » Tue Aug 21, 2018 1:53 pm

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?
FZ - Does humor belongs in Music?
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.

User avatar
khz
Established Member
Posts: 877
Joined: Thu Apr 17, 2008 6:29 am
Location: German

Re: Flatpak - Flathub

Postby khz » Wed Aug 22, 2018 7:45 am

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.
FZ - Does humor belongs in Music?
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.

User avatar
CrocoDuck
Established Member
Posts: 962
Joined: Sat May 05, 2012 6:12 pm
Contact:

Re: Flatpak - Flathub

Postby CrocoDuck » Wed Aug 22, 2018 3:48 pm

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.
Check my Linux audio experiments on my SoundCloud.
Browse my AUR packages.
Fancying a swim in the pond?

fundamental
Established Member
Posts: 150
Joined: Thu Nov 07, 2013 1:19 pm

Re: Flatpak - Flathub

Postby fundamental » Wed Aug 22, 2018 5:49 pm

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

User avatar
AlexTheBassist
Established Member
Posts: 214
Joined: Mon May 19, 2014 3:44 am
Location: Russia, Moscow

Re: Flatpak - Flathub

Postby AlexTheBassist » Sun Nov 11, 2018 12:38 pm

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.
Kde Neon
Warwick RockBass Streamer Standard
Tons of other borrowed instruments
Presonus Eris E4.5
Some musical education
Ardour, EQ10Q, LSP Plugins…

User avatar
CrocoDuck
Established Member
Posts: 962
Joined: Sat May 05, 2012 6:12 pm
Contact:

Re: Flatpak - Flathub

Postby CrocoDuck » Mon Nov 12, 2018 11:32 am

AlexTheBassist wrote:Why would I want another (usually older) copy of, say, KDE libs in my system?


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.
Check my Linux audio experiments on my SoundCloud.
Browse my AUR packages.
Fancying a swim in the pond?

User avatar
AlexTheBassist
Established Member
Posts: 214
Joined: Mon May 19, 2014 3:44 am
Location: Russia, Moscow

Re: Flatpak - Flathub

Postby AlexTheBassist » Mon Nov 12, 2018 3:51 pm

CrocoDuck wrote:
AlexTheBassist wrote:Why would I want another (usually older) copy of, say, KDE libs in my system?


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.

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.
Kde Neon
Warwick RockBass Streamer Standard
Tons of other borrowed instruments
Presonus Eris E4.5
Some musical education
Ardour, EQ10Q, LSP Plugins…

User avatar
CrocoDuck
Established Member
Posts: 962
Joined: Sat May 05, 2012 6:12 pm
Contact:

Re: Flatpak - Flathub

Postby CrocoDuck » Mon Nov 12, 2018 6:52 pm

AlexTheBassist wrote:Flatpak, by the way, shares runtime libraries between the apps, so no “used by that program only” thing.


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:

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.
Check my Linux audio experiments on my SoundCloud.
Browse my AUR packages.
Fancying a swim in the pond?

User avatar
tramp
Established Member
Posts: 1246
Joined: Mon Jul 01, 2013 8:13 am

Re: Flatpak - Flathub

Postby tramp » Mon Nov 12, 2018 7:12 pm

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.


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".
If I want stuff like that, I could use windows or MAC :lol:

User avatar
AlexTheBassist
Established Member
Posts: 214
Joined: Mon May 19, 2014 3:44 am
Location: Russia, Moscow

Re: Flatpak - Flathub

Postby AlexTheBassist » Mon Nov 12, 2018 11:22 pm

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.

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.
Kde Neon
Warwick RockBass Streamer Standard
Tons of other borrowed instruments
Presonus Eris E4.5
Some musical education
Ardour, EQ10Q, LSP Plugins…

User avatar
GMaq
Established Member
Posts: 1287
Joined: Fri Sep 25, 2009 1:42 pm

Re: Flatpak - Flathub

Postby GMaq » Tue Nov 13, 2018 12:02 am

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.

User avatar
raboof
Established Member
Posts: 1531
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Contact:

Re: Flatpak - Flathub

Postby raboof » Tue Nov 13, 2018 8:26 am

I like the idea in theory, but I've not worked with Flatpak or any implementation that I liked in practice.

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


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.

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.


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?

User avatar
CrocoDuck
Established Member
Posts: 962
Joined: Sat May 05, 2012 6:12 pm
Contact:

Re: Flatpak - Flathub

Postby CrocoDuck » Tue Nov 13, 2018 9:13 am

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.


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.

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?


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: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.


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.
Check my Linux audio experiments on my SoundCloud.
Browse my AUR packages.
Fancying a swim in the pond?

User avatar
khz
Established Member
Posts: 877
Joined: Thu Apr 17, 2008 6:29 am
Location: German

Re: Flatpak - Flathub

Postby khz » Tue Nov 13, 2018 4:19 pm

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
    I don't care about the freedom of speech because I have nothing to say.

User avatar
AlexTheBassist
Established Member
Posts: 214
Joined: Mon May 19, 2014 3:44 am
Location: Russia, Moscow

Re: Flatpak - Flathub

Postby AlexTheBassist » Wed Nov 14, 2018 4:20 pm

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?

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:

Code: Select all

flatpak run program_name

because Flatpak apps run in containers, which take significant time to even get running. This may be uncritical for those who run apps for days, weeks or longer, but this forum is dedicated to audio production. We musicians rarely run anything for more than 6 hours in a row. For us, the better thing is Nix package manager. It effectively solves problem of conflicting dependencies without container overhead of Flatlak and similar stuff, and there will be no problems like snap- or Flatpak-packaged Musescore having small icons, ignoring systemwide Qt4 theme, and not having a synthesizer.
Kde Neon
Warwick RockBass Streamer Standard
Tons of other borrowed instruments
Presonus Eris E4.5
Some musical education
Ardour, EQ10Q, LSP Plugins…


Return to “Music & FOSS Advocacy”

Who is online

Users browsing this forum: No registered users and 1 guest