LinuxMusicians

AlexTheBassist wrote:

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.

Hmm, at https://flatpak.org/faq/#Is_Flatpak_a_c ... technology_ they claim they don't necessarily run in containers though? And even with containers, I'm not sure there's necessarily a fundamental reason those should be terribly slow. What kind of 'significant time' are you talking about? When I for example run "time docker run alpine ls" that takes under 2 seconds in total - which seems slower than reasonable to me, but still not super relevant for an application that would run for 6 hours.

AlexTheBassist wrote:For us, the better thing is Nix package manager.

I think the NixOS concept is very interesting, but have never used it in practice. Have you?

I've never used Flatpak so I can't opine on it. But the current way of doing things in Linux is definitely not good. Especially for us. Look at this:

I registered with this forum in 2015. I was using Debian 7 (Wheezy) then. I remember packages that we used to have in the KXStudio repository and are no longer there. And you can't just download old versions, because they won't work with the newer support libraries. The only choice left is for oneself to build those from source, which almost never worked for me. There's always something missing or breaking or whatever. Sometimes a large amount of additional software has to be installed just so I can build and run that one goddamn package. That is very, very annoying and we know that the build-from-source nightmare is dreaded by lots of people.

Meanwhile, will you watch the tremendous irony: ALL, absolutely ALL of the Windows plugins that I have installed in these last three years still work fine, dandy, smooth, unfettered, reliably, copacetic, still strong, tall and glorious through the weathers of time. Can I count on them five years from now? I really don't see why not. Can I count on native Linux music software five years from now? Who knows? I know I can pray that someone will keep building new versions of the ones I like.

I find this situation nothing short of embarrassing for the Linux camp.

raboof wrote:And even with containers, I'm not sure there's necessarily a fundamental reason those should be terribly slow. What kind of 'significant time' are you talking about? When I for example run "time docker run alpine ls" that takes under 2 seconds in total - which seems slower than reasonable to me, but still not super relevant for an application that would run for 6 hours.

I'm talking about delays up to a minute, maybe even more. Yes, you probably won't believe that, but starting “flatpaked” Handbrake on two machines I have used recently does really take that much. This happens because Flatpak is not a useful thing, but rather “we put a wrapper around your wrappers, so you can wrap while you wrap”. Barebone Docker is of course times faster, especially with Alpine Linux. Try starting a full blown KDE runtime with Docker and see for yourself.

raboof wrote:I think the NixOS concept is very interesting, but have never used it in practice. Have you?

Not really, as I only have it in a virtual machine, and operate it as a user. I don't know yet if it's convenient for packagers, but surely I'll try to package a couple of plugin sets and tell if it's any more complicated than packaging them for Debian/*buntu.

khz wrote:What about the (automatic) update of the programs and security updates of the (all dependencies included) Flatpak packages?

You can always create a cron script or a simple daemon which will do that by itself, but Flatpak, as I know, doesn't offer any autoupdate capabilities, mainly because its daemon only launches when requested. Abovementioned Nix OS does offer that, though. This is enabled in a simple text config with one switch. I hope this Nix thing will be the future of Linux audio app distribution (including KXStudio moving to Nix from Ubuntu/KDE Neon), as the main advantage of such packaging systems is easy downgrades if something went wrong. This is extremely useful both for DAW PCs and headless stuff like synths or signal processors (MOD Duo etc). Another interesting concept is offered by Endless OS, but I don't know much about it, as I never even used it for once.

I find NixOS intriguing too.

There is realtime audio stuff going on: https://github.com/musnix/musnix

The biggest problem for me is that the runtimes can't read global configuration and I have no idea how to configure them. I have HiPPI monitor and Flakpak apps think I have 96 PPI and the text is too small. I can barely read it.

I am bumping this thread after two years to ask, how is the state of things?

raboof wrote: ↑Wed Nov 14, 2018 6:13 pm

AlexTheBassist wrote:For us, the better thing is Nix package manager.

I think the NixOS concept is very interesting, but have never used it in practice. Have you?

I switched to NixOS full-time about a year ago (https://quey.org/@raboof/102933366121683459) and am very happy with it.

AlexTheBassist wrote: I don't know yet if it's convenient for packagers, but surely I'll try to package a couple of plugin sets and tell if it's any more complicated than packaging them for Debian/*buntu.

I have packaged, updated and contributed a bunch of packages (https://github.com/NixOS/nixpkgs/pulls? ... s%3Aclosed), and found it infinitely more easy and pleasant compared to packaging for Debian.

I haven't done much audio stuff lately, though, so can't really comment on that yet.

There is some learning curve: I would only recommend it if you're comfortable with the command line and are prepared to learn the nix 'language' used to describe configurations and build procedures. I found it fairly easy to get into (for simple things), though, and it provides a smooth path into also contributing improvements upstream.

raboof wrote: ↑Thu Oct 01, 2020 7:17 am There is some learning curve: I would only recommend it if you're comfortable with the command line and are prepared to learn the nix 'language' used to describe configurations and build procedures. I found it fairly easy to get into (for simple things), though, and it provides a smooth path into also contributing improvements upstream.

What about Guix? Based on similar principles as Nix but uses standard Scheme (Guile) instead.

Basslint wrote: ↑Thu Oct 01, 2020 8:47 am

raboof wrote: ↑Thu Oct 01, 2020 7:17 am There is some learning curve: I would only recommend it if you're comfortable with the command line and are prepared to learn the nix 'language' used to describe configurations and build procedures. I found it fairly easy to get into (for simple things), though, and it provides a smooth path into also contributing improvements upstream.

What about Guix? Based on similar principles as Nix but uses standard Scheme (Guile) instead.

I haven't tried it. Fundamentally I like what they're doing (for example also in terms of bootstrapping, https://guix.gnu.org/manual/en/html_nod ... strap.html). I'm not sure I'm convinced using Scheme is a better fit than the Nix language: the Nix language isn't so bad, and the additional power of Scheme could turn into a disadvantage rather than an advantage.

I also get the impression Guix is a bit more hard-core in shunning non-free packages. I think Nix strikes a nice balance here: they do include non-free packages, but you must 'whitelist' them to install them on your system. That way I can conveniently install and manage the (few) non-free packages I'm still relying on while I try to reduce my reliance on them .

But all in all Guix sounds great as well, I just haven't tried it and am really enjoying Nix .

The one time I tried to use Flatpak (to use MusE on my old Gentoo system), I found that its sandbox tended to ignore outside plugins. Since I make pretty heavy use of the LSP plugins, as well as Yoshimi and LinuxSampler, I really don't want to use a sandboxed system like Flatpak.