Re: A secure multimedia workstation

[Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>]

Dirk Scheuring writes:

> This is interesting. You seem to make packaging much easier than I
> thought it would be. I wonder why that is.

It really *is* rather simple.  I come from a background of packaging
RPMs by writing spec files and I find packaging for Guix much less
painful (to the point where it actually becomes fun).

> running it. For example, Ricardo Wurmus (1) recently added Ardour (2), a
> popular Digital Audio Workstation. Ardour depends on JACK Audio
> Connection Kit (3), as do many applications in the Linux Audio
> ecosystem. Multimedia distros like Ubuntu Studio and KXStudio include
> JACK, plus a kernel version compiled with the -lowlatency flag, to
> prevent dropouts/xruns when you're doing multichannel audio recording in
> Ardour, which might also have other samplers, synthesizers and drum
> machines feeding into it for playback, through JACK. So you want a
> kernel that prioritizes audio throughput above all else.
>
> I wouldn't know whether such a kernel was available for Guix currently,
> and if it wasn't, I wouldn't know how to compile one, and make it
> available. I would have to learn these things first, before I could
> start packaging something like Ardour. At least, so I thought.

A realtime kernel is not currently available, but there have been
discussions about simplifying the specification of custom kernel
packages by providing a wrapper function that takes a kernel
configuration file.

Ardour works without a realtime kernel (and I have been using it in the
past with stock kernels for many years).  You can prevent xruns by
increasing JACK buffers.  This increases latency, but for recording
where you don't need to listen to effects processing in realtime
(i.e. if you use direct monitoring on your equipment) this is not an
issue.  Dependent on your workflow your requirements may differ.  Still,
the Ardour package itself does not need a realtime kernel as an explicit
input, so from a packager's perspective this is a non-issue.

> Moreover, there are production workflows which depend on Ardour being
> connected to other programs (5) which in turn depend on JACK. So I
> thought that I would have to track down all those interdependencies
> between programs, and include knowledge about them, libraries, etc. in
> the package receipt. I have to learn how to do that before I can
> seriously contribute, don't I?

When I packaged Ardour I looked at the immediate dependencies.  If they
were not yet available (like JACK or LV2) I packaged those first.  Once
all build dependencies were satisfied I could build Ardour successfully.

Now, there are production workflows that require certain LV2 plugins,
for example.  But Ardour itself does not depend on them.  Ardour, using
LV2, looks up plugins in the LV2_PATH, a variable listing directories in
which LV2 plugin bundles are to be found.  At runtime you can modify
this variable and make available to Ardour whatever plugin you have
installed, long after Ardour was built.

So you don't have to learn about these interdependencies because they
don't really matter much to packaging.  In some cases programmes are not
as flexible as Ardour/LV2 and they look at hard-coded paths (e.g. CUPS
with its filters).  Only in these cases a little more effort is required.

> Also, not all audio applications support JACK. PulseAudio tends to fight
> with JACK, both trying to grab the audio hardware, but several other
> popular apps use PulseAudio, rather than JACK, as their audio
> server. The solution here is to configure PulseAudio to pipe its output
> into JACK, and as I'm trying to find out how to do that (6), I stumble
> across the remark
>
> "I performed the following changes to the files in /etc/pulse"
>
> when I realize that there is no /etc/pulse in Guix! Rather, the
> configuration files are represented - as is everything else - by their
> contribution to the hash values in /nix/store. Or that's how I currently
> understand it.

Guix (the package manager) and the Guix System Distribution (the GNU
system based on Guix and other GNU software, or GNU GSD for short) are
different things.  While Guix only stores stuff in /gnu/store/, the
system distribution may have "global" configuration files like any other
system.  I have not yet played with Pulseaudio on GNU GSD, but I'm
confident that Pulseaudio does not insist on /etc/pulse for its
configuration.  AFAIR, Pulseaudio also supports per-user configuration.

> So it seems like I have to learn how to map the relevant parts of the
> LSB to /nix/store, and I will also have to find out which parts are
> relevant for any program I have to include in my package, and I have to
> learn how to express this information in my receipt, so that the build
> process can use it successfully. And the deeper I crawl into this rabbit
> hole, the longer my list of known unknowns grows, while unknown unknowns
> remain unknown. I figured it might take me a while to work through all
> this, given that I have other jobs, and a family.
>
> Or am I overcomplicating things here? Thanks for any advice,

You probably are overcomplicating things :)

Packaging up software is relatively straight-forward; configuring the
system itself with good defaults out of the box less so.  As a packager
you don't have to worry much about system configuration.  Most user
software does not expect to run as a system-wide service and thus does
not need any special configuration at build time.

~~ Ricardo