Linux public beta (4408)

[krans]

While I understand abique's frustration with old libs and so on, and won't be mad at you no matter what you choose to do, I'd like to comment on the whole "why not just change distro, then?" approach:

Sound and music is my profession, so I need a distro that:
1/ is stable, reliable every day, doesn't suddenly break because of an upgrade. This is where distros like Arch, AVLinux and Debian Testing have failed me (even though they're all good distros).
2/ can provide a really good realtime setup, as I also perform live and need everything to run smoothly. This is where Mint and the Ubuntus have failed me (even though and so on).

Mint is great! I used it for years, I still install it for anyone else who wants Linux. But it was in fact audio that made me move - I have yet to see an Ubuntu based distro with great realtime performance. I never managed to get it myself, at least. No matter what I tried, Ubuntu's low latency kernels or even Liquorix or other clever solutions could simply never compete with the performance I get from Debian's rt-kernels.

The point isn't mainly that I find it paradoxical if audio companies choose the (in my experience) not so very audio oriented Ubuntu as their standard, the point is more that people sometimes have a reason to choose their distro. Debian 9 with KXStudio repos, in my case.

So no, I would not be one of those who just changed (back) to an Ubuntu based distro, I'd definitely rather continue using the 6640 build instead.

[Jack Winter]

AFAIK, dynamic load libs are versioned on Linux, so one can perfectly have several versions installed in parallel.. It's also possible to ship libs with an app, you can even preload them. I don't see that there would be a great need for static linking to solve this issue. The gcc issue is possibly thornier and unfortunate, but not all apps are susceptible to it .

[mclstr]

As much as we care about the little nuances of different distros, you have to kind of settle on one.
Ubuntu has been the most popular with the general desktop community and Ubunto Studio the most common for music production.

If you want companies to make their products available for Linux, they are going to insist on sticking with one distro. It's too expensive to create multiple versions for every distro.

I would rather have it on Ubuntu Studio than no Linux version at all. And companies may chose not to bother if they can't develop for one standard.

If I had to spend the money to make a Linux version and had to keep it closed source, I would stick with Ubuntu Studio myself. It's the biggest market. And would be the most likely to be profitable.
And you can't exist as a business not being profitable.

I don't think I could trust that developing for other distros would be profitable.

[mclstr]

... It's also possible to ship libs with an app, you can even preload them. I don't see that there would be a great need for static linking to solve this issue.

I am not a developer, but I always guessed that was the way to solve all the problems with Linux compatibility, but I suspect that it isn't that simple.

[Jack Winter]

Since ubuntu is based on debian, it might be better to take debian as a baseline.. I'm no expert on linux plugin development, but as far as I can tell, the best way is to only depend on xlib as it has a stable API/ABI (just like the kernel).. Maybe a bit more work for the dev, but would make it portable. Thanks to the gcc 4 vs 5 issue you might run into problems with libstdc++, but the world has to move forwards too

If you need some other lib, maybe link it statically.

@abique, ask rgareus next time you see him, he knows all about this and has well founded opinions on the issue of linux plugins and libs..

[glokraw]

Last point is instead of thinking "software should all be compatible with my old distribution" why don't you think "my distribution should offer me maximum compatibility"? And then wonder why it is a problem to update a library which is stable since 3 years.

I'm sure Abique has it right for his position, and we as customers
can easily allow for it.
It's been a decade since I've had fewer than three different distros configured
to account for the diversity of linux audio issues, with 5 currently, and about
to add two more. We have available bootable external drives, docking stations,
live media, virtual machines, roll-your-own customizers,
and probably even cloud solutions that my inner (and outer ) Sergeant Schulz,
is still blissfully unaware of.

Just because windoze was a drive-wiper for most of it's existence,
doesn't mean we linux users shouldn't/can't use the capabilities and freedoms
easily at hand, to run and take advantage of multiple systems,
especially when the .deb package format can be used in two very similar
setups, one for cutting edge, and one for stability. People should have
multiple systems for security and/or backups, if they have any respect
for their music or data.

For that matter, the windows U-he herd gallops
fast and long in most any recent Reaper/wine environment, should ones finances
be in a really dire state for a season.
Cheers

[mevla]

No matter what I tried, Ubuntu's low latency kernels or even Liquorix or other clever solutions could simply never compete with the performance I get from Debian's rt-kernels.

I do experience from time to time some xruns in Bitwig in LM18. Never seen any in exported audio, though. I mix using Mixbus32C so the exported audio is always clean so far. I wonder if it would be more or less simple to have the Debian rt-kernel in LM18...

Cheers.

[x42]

True. Each company could ask for a specific distro.

In the case of Mixbus32C, it's using quite a few system libs:

No it doesn't. it includes all dependent libraries (tested and known to work version) and only uses the minimum of mandatory system libs (such as libX11, libjack, libc).

try something like (replace the version-number)

Code: Select all

LD_LIBRARY_PATH=/opt/Mixbus32C-4.3.0/lib/ ldd /opt/Mixbus32C-4.3.0/bin/mixbus32c-4.3.0  | grep -v /opt/

The gcc-4 version of Mixbus runs on pretty much any GNU/Linux distro since circa 2009 (glibc ≥ 2.2.5). gcc-5 versions need a newer (2016ish) distro that provides libstdc++ 5.0 (or later).


PS. The harrion XT-* plugins are all statically linked (also only depending on libX11, openGL -- libraries which are guaranteed to be API and ABI stable). This allows them to work on any system with the exact same stability, leaving nothing at chance. They also cannot interfere with other plugins or host-libs for that reason.

[x42]

Sorry don't get me wrong. Dynamically linking is far better.

citation needed

It depends on the context and for audio-plugins, or plugins in general, I cannot make a good case why dynamic linking would be better.

Say you write a plugin that needs ffmpeg's resampler and uses the newer libswresample2 interface and there's another plugin that uses the older libswresample1 API. Now what? Distros may even package both library versions, and you can compile and link, but if you load both at the same time, you usually get in trouble. QT4/QT5 gtk2/3 same thing: They can be installed at the same time, but cannot co-exist in a single application. You may also remember https://github.com/FFTW/fftw3/issues/16 which caused crashes when multiple plugins which don't know about each other used it as shared library (static builds were not affected).

Long story short, the only way to ensure reliable operation is to make plugins self-contained (or process-separate plugins, but then you get context switches which are very expensive, even on modern machines).

FWIW, this is not Linux specific, (most) plugins on other operating systems are also statically linked and only depend on mandatory, stable system-libs because of the same reason.

[Jack Winter]

Yes of course, good point x42.

We are talking about plugins here. What happens when several plugins try to try to link to incompatible versions in the same process? We already have (had) several examples of this on linux.

Surely portability is more important than saving a few MBs of RAM, especially in this day and age.

There are many advantages to dynamic linking, but in this case mostly disadvantages.

[hihu]

I hope this discussion will not get too emotional. This wasn't my intention.

I wrote that dynamically linked stuff can definitely an advantage. But you gave an example yourself. plugin developers would have to works together so that the use the same basis and same libraries. This has to do with the communication between the developers.

This can work in open source software sometimes better than in commercial software but not always. I gave the example of Steam before where all relevant libraries are packed into steam only some really basic stuff is from the system itself.

But also in open source environment you can run into trouble because often developers have different opinions to solve problems.
I had bad experiences also in open source environment when a software was not working. I had to ask the software developer, maintainer of the packages, driver developer and so on. At the end I wrote emails to 7 different people to always get replies like, my software is the best, it's the other people fault or we take a different approach.

So for the user just wanting to work with the software it's a nogo.

I installed Debian because it gave me the best results in audio related stuff and it never crashes, also those specialized distros are not the holy grail because they often lack in manpower to support everything, make all wishes true and react fast. I could install Mint too but then I would have 5 OS on my system.

Actually we don't know if this library causes the problem because on CentOS it also doesn't work.

To summarize:

Linux Mint works
CentOS and Debian don't work.


@mevla: when it works does also the preset browser work can you search for presets?

[Subarumannen]

True. Each company could ask for a specific distro.

In the case of Mixbus32C, it's using quite a few system libs:

Code: Select all

ldd mixbus32c-4.2.15
        linux-vdso.so.1 =>  (0x00007ffd769d8000)
        libardourcp.so => not found
        libwaveview.so.0 => not found
        libptformat.so.0 => not found
        libardour.so.3 => not found
        libmidipp.so.4 => not found
        libevoral.so.0 => not found
        libaudiographer.so.0 => not found
        libcanvas.so.0 => not found
        libwidgets.so.0 => not found
        libgtkmm2ext.so.0 => not found
        libpbd.so.4 => not found
        libtimecode.so => not found
        libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007f466a335000)
        libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f466a0f9000)
        libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f4669e56000)
        libglibmm-2.4.so.1 => /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1 (0x00007f4669be8000)
        libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f4669997000)
        libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f466968f000)
        libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x00007f466948a000)
        libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f4669288000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f4669080000)
        libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007f4668a43000)
        libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 (0x00007f4668790000)
        libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f4668583000)
        libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007f4668361000)
        libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x00007f4668056000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007f4667e35000)
        libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f4667ac2000)
        libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f46678ad000)
        libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f4667660000)
        libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f4667457000)
        libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f46671f0000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4666fec000)
        libgtkmm-2.4.so.1 => /usr/lib/x86_64-linux-gnu/libgtkmm-2.4.so.1 (0x00007f46669b2000)
        libatkmm-1.6.so.1 => /usr/lib/x86_64-linux-gnu/libatkmm-1.6.so.1 (0x00007f466676a000)
        libgdkmm-2.4.so.1 => /usr/lib/x86_64-linux-gnu/libgdkmm-2.4.so.1 (0x00007f466651f000)
        libgiomm-2.4.so.1 => /usr/lib/x86_64-linux-gnu/libgiomm-2.4.so.1 (0x00007f466619f000)
        libpangomm-1.4.so.1 => /usr/lib/x86_64-linux-gnu/libpangomm-1.4.so.1 (0x00007f4665f75000)
        libcairomm-1.0.so.1 => /usr/lib/x86_64-linux-gnu/libcairomm-1.0.so.1 (0x00007f4665d52000)
        libfftw3f.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3f.so.3 (0x00007f466594d000)
        libfftw3f_threads.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3f_threads.so.3 (0x00007f4665746000)
        liblo.so.7 => /usr/lib/i386-linux-gnu/liblo.so.7 (0x00007f4665535000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4665317000)
        libtag.so.1 => /usr/lib/x86_64-linux-gnu/libtag.so.1 (0x00007f4665040000)
        libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f4664cd9000)
        libsuil-0.so.0 => not found
        libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f46649a4000)
        libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f466473c000)
        libarchive.so.13 => /usr/lib/x86_64-linux-gnu/libarchive.so.13 (0x00007f466449b000)
        libaubio.so.2 => not found
        libsamplerate.so.0 => /usr/lib/x86_64-linux-gnu/libsamplerate.so.0 (0x00007f466412f000)
        liblrdf.so.2 => not found
        libvamp-sdk.so.2 => not found
        libvamp-hostsdk.so.3 => /usr/lib/x86_64-linux-gnu/libvamp-hostsdk.so.3 (0x00007f4663eec000)
        librubberband.so.2 => /usr/lib/x86_64-linux-gnu/librubberband.so.2 (0x00007f4663cba000)
        liblilv-0.so.0 => /usr/lib/liblilv-0.so.0 (0x00007f4663a9f000)
        libsratom-0.so.0 => /usr/lib/x86_64-linux-gnu/libsratom-0.so.0 (0x00007f4663896000)
        libsord-0.so.0 => /usr/lib/x86_64-linux-gnu/libsord-0.so.0 (0x00007f466368c000)
        libserd-0.so.0 => /usr/lib/x86_64-linux-gnu/libserd-0.so.0 (0x00007f466347a000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4663176000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4662e70000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4662c5a000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4662895000)
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f466266b000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4662452000)
        libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f466222c000)
        libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f4662028000)
        libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f4661e20000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f4661be2000)
        libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f46619dc000)
        libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f46617d2000)
        libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f46615cf000)
        libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f46613bf000)
        libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f46611b5000)
        libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f4660fab000)
        libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007f4660da8000)
        libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f4660ba5000)
        libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f4660993000)
        libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f46606ea000)
        libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f46604e7000)
        libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f46602de000)
        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f46600bf000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f465fe9c000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f465fc81000)
        libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f465fa2c000)
        libthai.so.0 => /usr/lib/x86_64-linux-gnu/libthai.so.0 (0x00007f465f823000)
        libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 (0x00007f465f5f0000)
        librtmp.so.0 => /usr/lib/x86_64-linux-gnu/librtmp.so.0 (0x00007f465f3d6000)
        libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f465f177000)
        libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f465ed9c000)
        libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f465eb55000)
        liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f465e946000)
        libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f465e6f5000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f466a566000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f465e4d3000)
        libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f465e004000)
        libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f465ddd7000)
        libnettle.so.4 => /usr/lib/x86_64-linux-gnu/libnettle.so.4 (0x00007f465dba8000)
        libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f465d9a3000)
        liblzo2.so.2 => /lib/x86_64-linux-gnu/liblzo2.so.2 (0x00007f465d782000)
        libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f465d572000)
        libfftw3.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3.so.3 (0x00007f465d17a000)
        libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f465cf76000)
        libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f465cd70000)
        libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f465cb54000)
        libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007f465c94d000)
        libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x00007f465c68f000)
        libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x00007f465c40f000)
        libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f465c144000)
        libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f465bf15000)
        libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f465bd11000)
        libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f465bb06000)
        libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f465b8eb000)
        libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007f465b6ad000)
        libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f465b499000)
        libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f465b257000)
        libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f465b052000)
        libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f465ae4e000)
        libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007f465ac45000)
        libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007f465a9bd000)
        libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x00007f465a71c000)
        libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007f465a4e9000)
        libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x00007f465a2d4000)
        libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x00007f465a0ab000)
        libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007f4659e9d000)
        libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x00007f4659c54000)
        libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f465999b000)
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f4659762000)

I'm afraid LSB does not seem to be the answer. Will LSB say that xcb-util have to be of a certain version ? Linux Mint 18, where Repro 1/5 works very well is not LSB. Debian 9 OTOH seemingly is. And has an older version of xcb-util.

A company is about making money. If Bitwig adopts Ubuntu, and I think they did, it is hard to imagine that another company making closed source commercial Linux software could be clueless enough to choose another distro out of the whim of one of its developers or managers, w/o assessement of that aspect of the business model. Of course, if a company makes it so that it runs everywhere so much the better, but a company cannot test on 5 distros in parallel.

Bitwig uses Ubuntu, I use Linux Mint. So I thought, hmmm, maybe it will not work. But it does, since LM is based on Ubuntu. I was aware that there could have been a risk.

There are not enough commercial Linux companies out there to make dialogue impossible after all. It's a pretty small gang.

slightly OT
You know Mixbus 32c 4.3 and Generic 4.3 is out ?

[mclstr]

Linux Mint works
CentOS and Debian don't work.

But of course Mint is Debian:-)

I don't know if things have changed that much, but I worked for years at a RedHat/CentOS shop.
I ran various flavors of Debian for music though. I found RedHat/CentOS too backward to run cutting edge software easily.

I tweaked Linux at work and don't want to spend my spare time doing it at home. Very little music gets made if thats all your doing is trying to run modern software on a backwards distro.

I can see CentOS in the data center where stability is important, but stability is not so important for multimedia, except maybe in a live performance situation.
I also have a bad taste in my mouth about the direction RedHat went with their business practices.
CentOS reeks of that RedHat odor.

Besides, CentOS by itself was a crap desktop distro and especially bad multimedia distro,
Of course you can spend the time to make it a multimedia distro, but but why?
t gives me a headache just thinking about it.

I haven't used CentOS in a few years. Maybe things have changed?

I have never had stability issues with any of the many Debian distros I've used and the Debians are almost always more friendly with music apps.

[abique]

I've managed to build a statically version. I'll test it tonight and I'll post it tonight if it works.

[Subarumannen]

I've managed to build a statically version. I'll test it tonight and I'll post it tonight if it works.

Nice!!