A secure multimedia workstation

A secure multimedia workstation

[Dirk Scheuring]

Hello all,

my name is Dirk Scheuring, and I come out of the "conventional" world of
professional audio and video production and performance - a world which
is dominated by proprietary programs: Adobe Premiere, Logic Pro Audio,
Ableton Live, Traktor, Serato, to name a few "standards". Those are run
almost exclusively on Windows or Mac OS X. And a while ago, when Windows
8 and OS X Lion came out, I, after more than 20 years as a user of both
Microsoft and Apple products, decided that I've had it with that. That
if I went furter that-a-way, I'd no longer be buying a computer as much
as I'd be leasing a supervised node on some giant corporation's
network. All my production and communication data there are pre-pwned
and will be monetized by...everybody but me, mostly, and it's all out of
my control.

Furthermore, by now I've lost access to much of my production from the
past decades, because the data was recorded to SCSI hard disks, DAT
tapes, ZIP drives, Atari TOS floppies, and it exists in all kinds of
propretary file formats, like, for Akai, or Sequential Circuits
machines. If I still even have a copy at all. Which I don't, in many
cases.

This situation sucks for an artist like me. I figured that the problem
was that I had failed to take control of my data production,
communication, and storage, for the last 25 years. And I decided that I
would take control /now/, and that the next 25 years must de different.

So I looked for solutions to my problem, and I now think that a good
solution does not exist yet, but that it is possible for one to exist,
and that I could probably build it. But can I? Or would such a project
be too difficult for me to carry out? Please help me find an answer to
that question.

Here's what I want to be able to do in, say, three years time: I want to
boot and install GNU Guix from a USB Stick, just the way it's done today
(1). I want that future build to work flawlessly on libreboot-certified
hardware (currently, that would be X60 and T60 Thinkpads (2), so that's
my target machine, one with at least 4GB RAM and a 240GB SSD). And by
default, that Guix build would offer functionality similar to KXStudio
(3), which is a Ubuntu-Debian-based distribution aimed at multimedia
producers; it has a realtime-enabled kernel, sets the jack2 audio server
running at startup, and offers audio and video production tools like
Ardour and Cinelerra-CV. So that would be part of the work: Re-packaging
the KXStudio packages and the Xfce-based interface for the Guix package
manager. Xfce itself seems to be mostly done already, if I understood
the list correctly. I also noticed, to my surprise and delight, that
jack2 and Ardour have recently been added. (4)

Also, I want to gitify all the things (5), out of the box. The user
should be able to use git, git-annex, vcsh, and other useful programs in
that vein, to version-control, synchronize and back up everything, from
config files to all the media data formats they need. I aim for a
client-server-style system, which, by default, would install on a single
physical computer, but can easily be split for seperate server and
client hardware. The server architecture should make it easy to connect
hard discs/raids for backup, and to automate those as far as possible:
If I create a new MIDI file today, I want to be able to load and use it
in 25 years. Therefore, I want to be able to clone my whole system, data
and all, to a bootable disk, carry it over to the next generation of
libre hardware, and have it working there without a fuss.

And encrypt all the things (there will be trade-offs, because media
production machines need to read and write data from/to disk /fast/,
which is not so easy if you also want to encrypt, but...I'd like to know
what is possible...)

And lock down all the things: By default, the system should be able to
set itself up without a network connection. All communication to the
outside should be based on the decisions of the user. I would like to
discourage the use of the system for web mail, general surfing, and
socializing; I would like to encourage users to isolate their working
environment from the rest of their computer use, to enable only the
newslists, websites, and repositories necessary for media production,
patching/upgrading, and persistence, and to communicate via, e.g., Pond
(6). That is, there should be an awesome security meta-package for GNU
Guix, trying to minimize data leakage by default yet leaving the
ultimate responsibility and control to the user.

And though the default session should use Xfce, to make the transition
from proprietary systems as easy as possible for newbies, the user
should also be able to log in to an alternative interface, which would
be based on Guile Emacs and Guile-WM (7). What I hope for is described
in the Readme of the latter, in author Mark Witmer's "Even Crazier Wish
List":

"Implement enough of a widget toolkit to actually run Guile Emacs inside
of Guile-WM all on Guile XCB. You would basically be running a
Lisp-machine at that point and all of your friends will be jealous."

Yes. This is what I want, ultimately: A truly-free, user-friendly,
self-cloning, Guix-package-manager-using, turn-key software-based
Lisp Machine for media production, versioning, archiving, backup, and
comsec. For anybody who can start out by spending $ 200 - 300 on a used
Thinkpad plus upgrade parts on Ebay (add to that a used server and some
more disks for the full-blown client-server solution).

Does this sound like a feasible project to you all? And what would it
take to make it real?

All the best,

Dirk


(1) https://www.gnu.org/software/guix/manual/html_node/System-Installation.html#USB-Stick-Installation
(2) http://libreboot.org/docs/hardware/index.html
(3) http://kxstudio.sourceforge.net/
(4) http://comments.gmane.org/gmane.comp.gnu.guix.devel/5809
(5) http://penta.debconf.org/dc13_schedule/events/1025.en.html
(6) https://pond.imperialviolet.org/
(7) https://github.com/mwitmer/guile-wm

Re: A secure multimedia workstation

[宋文武]

Hi!

2015-02-02 18:11 GMT+08:00 Dirk Scheuring <scheuring@gmail.com>:
>
> Hello all,
>
> my name is Dirk Scheuring, and I come out of the "conventional" world of
> professional audio and video production and performance - a world which
> is dominated by proprietary programs: Adobe Premiere, Logic Pro Audio,
> Ableton Live, Traktor, Serato, to name a few "standards". Those are run
> almost exclusively on Windows or Mac OS X. And a while ago, when Windows
> 8 and OS X Lion came out, I, after more than 20 years as a user of both
> Microsoft and Apple products, decided that I've had it with that. That
> if I went furter that-a-way, I'd no longer be buying a computer as much
> as I'd be leasing a supervised node on some giant corporation's
> network. All my production and communication data there are pre-pwned
> and will be monetized by...everybody but me, mostly, and it's all out of
> my control.
>
> Furthermore, by now I've lost access to much of my production from the
> past decades, because the data was recorded to SCSI hard disks, DAT
> tapes, ZIP drives, Atari TOS floppies, and it exists in all kinds of
> propretary file formats, like, for Akai, or Sequential Circuits
> machines. If I still even have a copy at all. Which I don't, in many
> cases.
>
> This situation sucks for an artist like me. I figured that the problem
> was that I had failed to take control of my data production,
> communication, and storage, for the last 25 years. And I decided that I
> would take control /now/, and that the next 25 years must de different.
>
> So I looked for solutions to my problem, and I now think that a good
> solution does not exist yet, but that it is possible for one to exist,
> and that I could probably build it. But can I? Or would such a project
> be too difficult for me to carry out? Please help me find an answer to
> that question.
>
> Here's what I want to be able to do in, say, three years time: I want to
> boot and install GNU Guix from a USB Stick, just the way it's done today
> (1). I want that future build to work flawlessly on libreboot-certified
> hardware (currently, that would be X60 and T60 Thinkpads (2), so that's
> my target machine, one with at least 4GB RAM and a 240GB SSD). And by
> default, that Guix build would offer functionality similar to KXStudio
> (3), which is a Ubuntu-Debian-based distribution aimed at multimedia
> producers; it has a realtime-enabled kernel, sets the jack2 audio server
> running at startup, and offers audio and video production tools like
> Ardour and Cinelerra-CV. So that would be part of the work: Re-packaging
> the KXStudio packages and the Xfce-based interface for the Guix package
> manager. Xfce itself seems to be mostly done already, if I understood
> the list correctly. I also noticed, to my surprise and delight, that
> jack2 and Ardour have recently been added. (4)
Yes, Ricardo Wurmus did it. He's a musician too ;-)
>
> Also, I want to gitify all the things (5), out of the box. The user
> should be able to use git, git-annex, vcsh, and other useful programs in
git-annex seem require GHC and a lot of haskell libraries, I won't expect
to have it Guix soon, but we can use Nix to install it.
> that vein, to version-control, synchronize and back up everything, from
> config files to all the media data formats they need. I aim for a
> client-server-style system, which, by default, would install on a single
> physical computer, but can easily be split for seperate server and
> client hardware. The server architecture should make it easy to connect
> hard discs/raids for backup, and to automate those as far as possible:
> If I create a new MIDI file today, I want to be able to load and use it
> in 25 years. Therefore, I want to be able to clone my whole system, data
> and all, to a bootable disk, carry it over to the next generation of
> libre hardware, and have it working there without a fuss.
Sound like a deploy a cloud with something like NixOps to me.
>
> And encrypt all the things (there will be trade-offs, because media
> production machines need to read and write data from/to disk /fast/,
> which is not so easy if you also want to encrypt, but...I'd like to know
> what is possible...)
>
> And lock down all the things: By default, the system should be able to
> set itself up without a network connection. All communication to the
> outside should be based on the decisions of the user. I would like to
> discourage the use of the system for web mail, general surfing, and
> socializing; I would like to encourage users to isolate their working
> environment from the rest of their computer use, to enable only the
> newslists, websites, and repositories necessary for media production,
> patching/upgrading, and persistence, and to communicate via, e.g., Pond
> (6). That is, there should be an awesome security meta-package for GNU
> Guix, trying to minimize data leakage by default yet leaving the
> ultimate responsibility and control to the user.
A whitelist iptable rules? I have no idea.
>
> And though the default session should use Xfce, to make the transition
> from proprietary systems as easy as possible for newbies, the user
> should also be able to log in to an alternative interface, which would
> be based on Guile Emacs and Guile-WM (7). What I hope for is described
> in the Readme of the latter, in author Mark Witmer's "Even Crazier Wish
> List":
>
> "Implement enough of a widget toolkit to actually run Guile Emacs inside
> of Guile-WM all on Guile XCB. You would basically be running a
> Lisp-machine at that point and all of your friends will be jealous."
>
> Yes. This is what I want, ultimately: A truly-free, user-friendly,
> self-cloning, Guix-package-manager-using, turn-key software-based
> Lisp Machine for media production, versioning, archiving, backup, and
> comsec. For anybody who can start out by spending $ 200 - 300 on a used
> Thinkpad plus upgrade parts on Ebay (add to that a used server and some
> more disks for the full-blown client-server solution).
>
> Does this sound like a feasible project to you all? And what would it
> take to make it real?
I don't know how much work it need, but it does exciting and hit my heart.
>
> All the best,
>
> Dirk
>
>
> (1) https://www.gnu.org/software/guix/manual/html_node/System-Installation.html#USB-Stick-Installation
> (2) http://libreboot.org/docs/hardware/index.html
> (3) http://kxstudio.sourceforge.net/
> (4) http://comments.gmane.org/gmane.comp.gnu.guix.devel/5809
> (5) http://penta.debconf.org/dc13_schedule/events/1025.en.html
> (6) https://pond.imperialviolet.org/
> (7) https://github.com/mwitmer/guile-wm
>

Re: A secure multimedia workstation

[Ludovic Courtès]

Hi,

I don’t know about the specifics of audio applications.  However, in
general, it should hopefully be relatively simple to provide distro
configurations tailored to specific needs–like the “media production”
distro you have in mind, things like TAILS, etc.

Ideally, it would boil down to preparing a custom ‘operating-system’
declaration–with all the services and packages of interest ready to
use–that users would inherit from to further customize things.

At this point the Guix System Distribution is still very much for
hackers rather than newcomers, but I would love to see projects like
this one grow.

Thanks for your interest.

Ludo’.

Re: A secure multimedia workstation

[Dirk Scheuring]

Ludo wrote:

> Ideally, it would boil down to preparing a custom 'operating-system'
declaration-with all the services and packages of interest ready to
use-that users would inherit from to further customize things.

Yes, that would be the idea. You here and and your relatives (1) are way
further up the curve, of course, so I'm greatly encouraged by getting
what seems to be a "sounds reasonable" reply from you. This thing has
just migrated from the "crazy fantasy" to the "important side project"
stage for me.

> At this point the Guix System Distribution is still very much for
hackers rather than newcomers, but I would love to see projects like
this one grow.

I reckon that it will take me some years to learn how to build what I
can now only describe, but I also know why I want to spend the time: I
plan to use computers for decades more; I figured out that most of my
problems with them might be solvable by freedom, statelessness, and
homoiconicity; and Guix offers exactly these features. This makes it
seem worth the investment.

> Thanks for your interest.

Thanks for your work. Thanks to all of you here. I believe that Guix
matters, so carry on, please.

Dirk

(1)
https://www.domenkozar.com/2014/03/11/why-puppet-chef-ansible-arent-good-enough-and-we-can-do-better/

Re: A secure multimedia workstation

[David Thompson]

Dirk Scheuring <scheuring@gmail.com> writes:

> https://www.domenkozar.com/2014/03/11/why-puppet-chef-ansible-arent-good-enough-and-we-can-do-better/

I really like this article.  It does a good job of classifying the
various configuration management tools in mainstream use (imperative,
stateful declarative) and showing how the stateless declarative
configuration offered by Nix and Guix is both simpler and technically
superior.

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: A secure multimedia workstation

[Andreas Enge]

On Mon, Feb 09, 2015 at 06:33:02PM +0100, Dirk Scheuring wrote:
> I reckon that it will take me some years to learn how to build what I
> can now only describe

Years, I do not know. Hopefully less! Definitely you could start helping 
the Guix project (and your own project) by packaging software that you are
interested in and that we do not provide yet. Some guile/scheme knowledge
is helpful, but not strictly required, see
   https://www.gnu.org/software/guix/guix-ghm-andreas-20130823.pdf
Some experience in installing software by hand is needed, though.
The irc channel is usually a good place to ask for advice.

Andreas

Re: A secure multimedia workstation

[Dirk Scheuring]

Andreas Enge wrote:

> ... Definitely you could start helping the Guix project (and your own
project) by packaging software that you are interested in and that we do
not provide yet. Some guile/scheme knowledge is helpful, but not
strictly required, see
https://www.gnu.org/software/guix/guix-ghm-andreas-20130823.pdf Some
experience in installing software by hand is needed, though.  The irc
channel is usually a good place to ask for advice.

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

I know next to nothing about Guix yet, but I know some things about
audio production software, and the problems you can experience while
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.

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?

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.

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,

Dirk

(1) http://lists.gnu.org/archive/html/guix-devel/2015-01/msg00477.html
(2) http://en.wikipedia.org/wiki/Ardour_%28software%29
(3) https://en.wikipedia.org/wiki/JACK_Audio_Connection_Kit
(4) https://en.wikipedia.org/wiki/JACK_Audio_Connection_Kit#Low_latency_scheduling
(5) http://kxstudio.sourceforge.net/Applications:Cadence
(6) http://askubuntu.com/questions/100862/running-jackd-on-startup-replacing-pulseaudio

Re: A secure multimedia workstation

[Ricardo Wurmus]

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

Re: A secure multimedia workstation

[Ludovic Courtès]

Dirk Scheuring <scheuring@gmail.com> skribis:

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

Right.  The “Defining Services” shows how to create service definitions
that potentially populate the store with the relevant configuration
files.

So it’s a different approach from what you may be used to: users do not
/modify/ config files; instead, they formally declare the /system state/
that they want, and /instantiate/ that configuration.

Thanks,
Ludo’.

Re: A secure multimedia workstation

[Andreas Enge]

On Tue, Feb 10, 2015 at 04:21:27PM +0100, Dirk Scheuring wrote:
> This is interesting. You seem to make packaging much easier than I
> thought it would be. I wonder why that is.

Most packages are easy, because they just require a few declarations.
One should start from easy ones, learn and move on to more complex ones.

> 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?

I am not sure what you mean exactly. As Ricardo said, sometimes it is
only necessary to recursively track down the dependencies ("inputs")
of a package and then package first the ones with no inputs themselves.
And then the ones which have only inputs that you have already packaged.
And so on.

> Or am I overcomplicating things here? Thanks for any advice,

Maybe. I would suggest to start working with the Guix package manager
on top of your current system, check whether the packages we already have
satisfy your needs and start packaging the others, or file bug reports
and patches for packages that do not work as expected. It requires practice,
but not necessarily to understand everything from the start!

Andreas

Re: A secure multimedia workstation

[Dirk Scheuring]

Hi Ricardo, Ludo, and Andreas,

thank you for your feedback. Things really looked scarier to me before
we had this conversation. I'm still insecure about some things - what
about D-Bus, which some programs also expect to be in a certain
place? - but since both the Jack and Xfce packages use it already, I
guess I can just look at how it's done in there. Maybe I really just
need some practice, without fearing that I don't know enough yet to do
anything. So again, thanks.

Dirk