6:01 p.m.
Hi Steve,
On 11/2/20 3:01 PM, Steve Batte wrote:
Hi Erich,
I know this chain is getting long, but I have a big decision to make
and need advice. In terms of best functionality, most users, best
support, would you recommend:
1. Ubuntu Studio 20.4 LTS
2. Ubuntu Studio 20.10
3. Fedora Jam (32 or 33)
I'm partial to Fedora, maybe because I've been using it with
Stanford's CCRMA repo for 20 years or so. But I get the impression
everyone else is settling on Ubuntu as the standard. I also prefer KDE
and stability, so last week I installed Kubuntu 20.4 and U-studio on
one hard drive, and Fedora 32 Jam on another. I didn't find much
difference, so settled on Fedora and spent a few days correcting Carla
plug-in paths, compiling WhySynth 2017 and OxeFMSynth etc. But it's
not too late to change.
My day job is stressful but pays well. Music is keeping me sane. I
would love to contribute to one or both of these projects.
Thanks
Steve
When it comes to changing the subject, you really need to start a new
thread. So, I hate to say it, but this is a little off-topic.
That said, this is one of the oldest questions ("Which is best?") as
it's very subjective. As for me, I dual-boot both, but that's mostly
because I'm in charge of both projects (Ubuntu Studio and Fedora Jam).
However, if you had to choose just one, I can't answer that question.
What works best for one person won't necessarily work best for everyone.
But, I do have a few things for you to consider.
Planet CCRMA At Home was discontinued after Fedora 30, which is EOL. One
thing I've been considering doing was emailing the person in charge of
that to see if he wanted to get it going again. That said, many of the
tools that were in Planet CCRMA At Home are now in Fedora (except the RT
kernel, more on that later).
My visions for Ubuntu Studio and Fedora Jam are quite different, yet
intertwined.
Ubuntu Studio is an all-in-one content creation studio. It targets
streamers, musicians, audio engineers (like myself), video producers
(like myself), graphic designers, photographers (like myself), and
publishers.
Fedora Jam targets musicians and audio engineers who are okay with
experimenting with the latest audio technologies in Linux, such as
pipewire. With Fedora 34, we're hoping to get Pipewire mainstream, and
I'm one of the people doing the testing and, quite possible, will be
authoring a system-wide change proposal for all of Fedora to switch to
Pipewire as the default audio server, if I can get a few ducks in a row
in those regards. My rationale is that Pipewire will be a drop-in
replacement for both PulseAudio and JACK and will make applications that
target both completely interoperable without bridges. This, quite
literally, is the dream for audio on Linux that we've been waiting for
since ALSA.
Another thing to consider: Ubuntu Studio was neglected for 2 years
(2016-2018) before I came along. Fedora Jam was neglected for much
longer: 7 years (2013-2020). The longer a distro, or in these cases
spins, is neglected, the harder it is to pick-up the pieces and get it
moving again. Ubuntu Studio is *finally* where it needs to be, but Jam,
partially because the KDE spin went a couple years with a lack of
leadership, and partially because Jam itself went 7 years until this
past January, is still suffering. I've slowly been introducing new
packages with plugins and other software to Fedora. For instance, JACK
Mixer had been a thing in Ubuntu (and Debian) for a very long time, but
was never a part of Fedora until just recently.
While I have been introducing items formerly in Planet CCRMA and
rolling-in other items, we cannot bring-in an RT kernel, nor would I
want to. I made a huge write-up on the Ubuntu wiki
(https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel) as to
why RT kernels this day and age are a BAD idea. TL;DR: They're full of
security holes, and most modern hardware, with a current Linux kernel,
doesn't need them anyhow. The Ubuntu Lowlatency Kernel and the Fedora
kernel are already lowlatency-enabled. In Jam and Ubuntu Studio, we add
an additional kernel boot parameter, "threadirqs", which activates the
already-configured "CONFIG_IRQ_FORCED_THREADING=y" kernel flag (the code
for that flag doesn't work without the "threadirqs" boot parameter).
This allows for more IRQ threading and lower latency, albiet at the
expense of power usage, all while keeping your system secure.
So, I hope that helps you in your decision. Either way, I'd welcome
contributions to either or both of these projects. :)
--
Erich Eickmeyer
Maintainer Fedora Jam
Project Leader Ubuntu Studio
Council Member Ubuntu Community Council