Search Results for: jack

Remote access to your VNC server via modern browsers

Posted on by

I think I am not the only one who runs a graphical Linux desktop environment somewhere on a server 24/7.
I hear you ask: why would anyone want that?

For me the answer is simple: I work for a company that runs Linux in its datacenters but offers only Windows 10 on its user desktops and workstations. Sometimes you need to test work related stuff on an Internet-connected Linux box. But even more importantly: when I travel, I may need access to my tools – for instance to fix issues with my repositories, my blog, my build server, or build a new package for you guys.

This article documents how I created and run such a 24/7 graphical desktop session and how I made it easily accessible from any location, without being restricted by firewalls or operating systems not under my control. For instance, my company’s firewall/proxy only allows access to HTTP(S) Internet locations; for me a browser-based access to my remote desktop is a must-have.

How to run & access a graphical Linux desktop 24/7 ?

Here’s how: we will use Apache, VNC and noVNC.

VNC or Virtual Network Computing is a way to remotely access another computer using the RFB (Remote Frame Buffer) protocol. The original VNC implementation is open source. In due time, lots of cross-platform clients and servers have been developed for most if not all operating systems. Slackware ships with an optimized implementation which makes it possible to work in a remote desktop even over low-bandwidth connections.

There’s  one thing you should know about VNC. It is a full-blown display server. Many people configure a VNC server to share their primary, physical desktop (your Linux Xserver based desktop or a MS Windows desktop) with remote VNC clients.
VNC is also how IT Help Desks sometimes offer remote assistance by taking control over your mouse, keyboard and screen.
But I want to run a VNC server ‘headless‘. This means, that my VNC server will not connect to a physical keyboard, mouse and monitor. Instead, it will offer virtual access to these peripherals. Quite similar to X.Org, which also provides what is essentially a network protocol for transmitting key-presses, mouse movements and graphics updates. VNC builds on top of X.Org and thus inherits these network protocol qualities.

Start your engines

Get a computer (or two)

First, you will have to have a spare desktop computer which does not consume too much power and which you can keep running all day without bothering the other members of your family (the cooling fans of a desktop computer in your bedroom will keep people awake).

Next, install Slackware Linux on it (any Linux distro will do; but I am biased of course). You can omit all of the KDE packages if you want. We will be running XFCE. Also install ‘tigervnc’ and ‘fltk’ packages from Slackware’s ‘extra’ directory. The tigervnc package installs both a VNC client and a VNC server.

You can store this server somewhere in a cupboard or in the attic, or in the basement: you will not have a need to access the machine locally. It does not even have to have a keyboard/mouse/monitor attached after you have finished implementing all the instructions in this article.

You may of course want to use a second computer – this one would then act as the client computer from which you will access the server.

In my LAN, the server will be configured with the hostname “darkstar.example.net”. This hostname will be used a lot in the examples and instructions below. You can of course pick and choose any hostname you like when creating your own server.
I also use the Internet domain “lalalalala.org” in the example at the end where I show how to connect to your XFCE desktop from anywhere on the Internet. I do not own that domain, it’s used for demonstrative purposes only, so be gentle with it.

Run the XFCE desktop

Let’s start a VNC server and prepare to run a XFCE graphical desktop inside.

alien@darkstar:~$ vncserver -noxstartup

You will require a password to access your desktops.

Password:
Verify:
Would you like to enter a view-only password (y/n)? n

New 'darkstar.example.net:1 (alien)' desktop is darkstar.example.net:1

Creating default config /home/alien/.vnc/config
Log file is /home/alien/.vnc/darkstar.example.net:1.log

What we did here was to allow the VNC server to create the necessary directories and files but I prevented its default behavior to start a “Twm” graphical desktop. I do not want that pre-historic desktop, I want to run XFCE.

You can check that there’s a VNC server running now on “darkstar.example.net:1”, but still without a graphical desktop environment inside. Start a VNC client and connect it to the VNC server address (highlighted in red above):

alien@darkstar:~$ vncviewer darkstar.example.net:1 

TigerVNC Viewer 64-bit v1.10.1 
Built on: 2019-12-20 22:09 
Copyright (C) 1999-2019 TigerVNC Team and many others (see README.rst) 
See https://www.tigervnc.org for information on TigerVNC.
...

The connection of the VNC client to the server was successful, but all you will see is a black screen – nothing is running inside as expected. You can exit the VNC viewer application and then kill the VNC server like this:

alien@darkstar:~$ vncserver -kill :1

The value I passed to the parameter “-kill” is “:1”. This “:1” is a pointer to your active VNC session. It’s that same “:1” which you saw in the red highlighted “darkstar.example.net:1” above. It also corresponds to a socket file in ” /tmp/.X11-unix/”. For my VNC server instance with designation “:1” the corresponding socket file is “X1”. The “kill” command above will communicate with the VNC server through that socket file.

Some more background on VNC networking follows, because it will help you understand how to configure noVNC and Apache later on.
The “:1” number does not only correspond to a socket; it translates directly to a TCP port: just add 5900 to the value behind the colon and you get the TCP port number where your VNC server is listening for client connections.
In our case, “5900 + 1” means TCP port 5901. We will use this port number later on.

If you had configured VNC server to share your physical X.Org based desktop (using the ‘x11vnc’ extension), then a VNC server would be running on “:0” meaning TCP port 5900.
And if multiple users want to run a VNC server on your computer, that is entirely possible! Every new VNC server session will get a new TCP port assigned (by default the first un-assigned TCP port above 5900).
It’s also good to know that the VNC server binds to all network interfaces, including the loop-back address. So the commands “vncviewer darkstar.example.net:1” and “vncviewer localhost:1” give identical result when you start a VNC client on the machine which is also running the VNC server.

Enough with the theory, we need that XFCE session to run! When a VNC server starts, it looks for a script file called “~/.vnc/xstartup” and executes that. This script should start your graphical desktop.

So let’s create a ‘xstartup’ script for VNC, based on Slackware’s default XFCE init script:

alien@darkstar:~$ cp /etc/X11/xinit/xinitrc.xfce ~/.vnc/xstartup
alien@darkstar:~$ vi ~/.vnc/xstartup

Edit that ‘xstartup’ script and add the following lines. They should be the first lines to be executed, so add them directly before the section “Merge in defaults and keymaps“:

vncconfig -iconic &
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS

Add the following lines immediately before the section “Start xfce Desktop Environment” to ensure that your desktop is locked from the start and no-one can hi-jack your unprotected VNC session before you have a chance to connect to it:

# Ensure that we start with a locked session:
xscreensaver -no-splash &
xscreensaver-command -lock &

In order for these commands to actually work, you may have to run “xscreensaver-demo” once, the first time you login to your desktop in VNC, and configure the screensaver properly.

Into the future

This ends the preparations. From now on, you will start your VNC server (hopefully once per reboot) with the following simple command without any parameters:

alien@darkstar:~$ vncserver

That’s it. You have a XFCE desktop running 24/7 or until you kill the VNC server. You can connect to that VNC server with a VNC client (on Slackware that’s the vncviewer program) just like I showed before, and configure your XFCE desktop to your heart’s content. You can close your VNC client at any time and reconnect to the VNC server at a later time – and in the meantime your XFCE desktop will happily keep on running undisturbed.
You can  connect to your VNC server from any computer as long as that computer has a VNC client installed and there’s a network connection between server and client.

How to make that graphical desktop available remotely ?

So now we have a VNC server running with a XFCE desktop environment inside it. You can connect to it from within the LAN using your distro’s VNC viewer application. And now we will take it to the next level: make this Linux XFCE desktop available remotely using a browser based VNC client.

We will require NoVNC software and a correctly configured Apache httpd server. Apache is part of Slackware, all we need to do is give it the proper config, but NoVNC is something we need to download and configure first.

noVNC

The noVNC software is a JavaScript based VNC client application which uses HTML5 WebSockets and Canvas elements. It requires a fairly modern browser like Chromium, Firefox, and also mobile browsers (Android and i/OS based) will work just fine.
With your browser, you connect to the noVNC client URL. Apache’s reverse proxy connects the noVNC client to a WebSocket and that WebSocket in turn connects to your VNC server port.

Some VNC servers like x11vnc and libvncserver contain the WebSockets support that noVNC needs, but our TigerVNC based server does not have WebSocket support. Therefore we will have to add a WebSockets-to-TCP proxy to our noVNC installation. Luckily, the noVNC site offers such an add-on.

Installing

Get the most recent noVNC ‘tar.gz’ archive (at the moment that is version 1.1.0) from here: https://github.com/novnc/noVNC/releases .
As root, extract the archive somewhere to your server’s hard disk, I suggest /usr/local/ :

# tar -C /usr/local -xvf noVNC-1.1.0.tar.gz
# ln -s noVNC-1.1.0 /usr/local/novnc

The symlink “/usr/local/novnc” allows you to create an Apache configuration which does not contain a version number, so that you can upgrade noVNC in future without having to reconfigure your Apache. See below for that Apache configuration.
We also need to download the WebSockets proxy implementation for noVNC:

# cd /usr/local/novnc/utils/
# git clone https://github.com/novnc/websockify websockify

Running

You will have to start the WebSockets software for noVNC as a non-root local account. That account can be your own user or a local account which you specifically use for noVNC. My suggestion is to start noVNC as your own user. That way, multiple users of your server would be able to start their own VNC session and noVNC acccess port.
I start the noVNC script in a ‘screen‘ session (the ‘screen’ application is a console analog of VNC) so that noVNC keeps running after I logoff.
Whether or not you use ‘screen‘, or ‘tmux‘, the actual commands to start noVNC are as follows (I added the output of these commands as well):

$ cd /usr/local/novnc/
$  ./utils/launch.sh --vnc localhost:5901

Warning: could not find self.pem
Using local websockify at /usr/local/novnc/utils/websockify/run
Starting webserver and WebSockets proxy on port 6080
websockify/websocket.py:30: UserWarning: no 'numpy' module, HyBi protocol will be slower
 warnings.warn("no 'numpy' module, HyBi protocol will be slower")
WebSocket server settings:
 - Listen on :6080
 - Web server. Web root: /usr/local/novnc
 - No SSL/TLS support (no cert file)
 - proxying from :6080 to localhost:5901

Navigate to this URL: 
   http://baxter.dyn.barrier.lan:6080/vnc.html?host=baxter.dyn.barrier.lan&port=6080
Press Ctrl-C to exit

I highlighted some of the output in red. It shows that I instruct noVNC (via the commandline argument “–vnc”) to connect to your VNC server which is running on localhost’s TCP port 5901 (remember that port number from earlier in the article when we started vncserver?) and the noVNC WebSockets proxy starts listening on port 6080 for client connection requests. We will use that port 6080 later on, in the Apache configuration.

From this moment on, you can already access your VNC session in a browser, using the URL provided in the command output. But this only works inside your LAN, and the connection is un-encrypted (using HTTP instead of HTTPS) and not secured (no way to control or limit access to the URL).
The next step is to configure Apache and provide the missing pieces.

Apache

Making your Apache work securely using HTTPS protocol (port 443) means you will have to get a SSL certificate for your server and configure ‘httpd’ to use that certificate. I wrote an article on this blog recently which explains how to obtain and configure a free SSL certificate for your Apache webserver. Go check that out first!

Once you have a local webserver running securely over HTTPS, let’s add a block to create a reverse proxy in Apache. If you are already running Apache and have VirtualHosts configured, then you should add the below block to any of your VirtualHost definitions. Otherwise, just add it to /etc/httpd/httpd.conf .

Alias /aliensdesktop /usr/local/novnc

# Route all HTTP traffic at /aliensdesktop to port 6080
ProxyRequests Off
ProxyVia on
ProxyAddHeaders On
ProxyPreserveHost On

<Proxy *>
    Require all granted
</Proxy>

# This will not work when you use encrypted web connections (https):
#<Location /websockify>
#     Require all granted
#     ProxyPass ws://localhost:6080/websockify
#     ProxyPassReverse ws://localhost:6080/websockify
#</Location>
# But this will:

# Enable the rewrite engine
# Requires modules: proxy rewrite proxy_http proxy_wstunnel
# In the rules/conditions, we use the following flags:
# [NC] == case-insensitve, [P] == proxy, [L] == stop rewriting
RewriteEngine On

# When websocket wants to initiate a WebSocket connection, it sends an
# "upgrade: websocket" request that should be transferred to ws://
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} =websocket [NC]
RewriteRule /(.*) ws://127.0.0.1:6080/$1 [P,L]

<Location /aliensdesktop/>
    Require all granted
    # Delivery of the web files
    ProxyPass http://localhost:6080/
    ProxyPassReverse http://localhost:6080/
</Location>

Again, I highlighted the bits in red which you can change to fit your local needs.

The “Alias” statement in the first line is needed to make our noVNC directory visible to web clients, since it is not inside the Apache DocumentRoot (which is “/srv/httpd/htdocs/” by default). I do not like having actual content inside the DocumentRoot directory tree (you never know when you accidentally create a hole and allow the bad guys access to your data) so using an Alias is a nice alternative approach.

You will probably already have noticed that Apache’s reverse proxy will connect to “localhost”. This means you can run a local firewall on the server which only exposes ports 80 and 443 for http(s) access. There is no need for direct remote access to port 6080 (novnc’s websocket) or 5901 (your vncserver).

Check your Apache configuration for syntax errors and restart the httpd if all is well:

# apachectl configtest
# /etc/rc.d/rc.httpd restart

Now if you connect a browser to https://darkstar.example.net/aliensdesktop/vnc.html and enter the following data into the connection box:

  • Host: darkstar.example.net
  • Port: 443
  • Password: the password string you defined for the VNC server
  • Token: leave empty

Then press “Connect”. You will get forwarded to your XFCE session running inside the VNC server. Probably the XFCE screen lock will be greeting you and if you enter your local account credentials, the desktop will unlock.

You can expand this Apache configuration with additional protection mechanisms. That is the power of hiding a simple application behind an Apache reverse proxy: the simple application does what it does best, and Apache takes care of all the rest, including data encryption and access control.
You could think of limiting access to the noVNC URL to certain IP addresses or domain names. or you can add a login dialog in front of the noVNC web page. Be creative.

Configure your ISP’s router

My assumption is that your LAN server is behind a DSL, fiber or other connection provided by a local Internet Service Provider (ISP). The ISP will have installed a modem/router in your home which connects your home’s internal network to the Internet.

So the final step is to ensure that the HTPS port (443) of your LAN server is accessible from the internet. For this, you will have to enable ‘port-forwarding’ on your Internet modem/router. The exact configuration will depend on your brand of router, but essentially you will have to forward port 443 on the router to port 443 on your LAN server’s IP address.

If you have been reading this far, I expect that you are serious about implementing noVNC. You should have control over an Internet domain and the Internet-facing interface of your ISP’s modem/router should be associated with a hostname in your domain. Let’s say, you own the domain “lalalalala.org” and the hostname “alien.lalalalala.org” points to the public IP address of your ISP’s modem. Then anyone outside of your home (and you too inside your home if the router is modern enough) can connect to: https://alien.lalalalala.org/aliensdesktop/vnc.html and enter the following data into the connection box in order to connect to your VNC session:

  • Host: alien.lalalalala.org
  • Port: 443
  • Password: the password string you defined for the VNC server
  • Token: leave empty

That’s it! I hope it was all clear. I love to hear your feedback. Also, if certain parts need clarification or are just not working for you, let me know in the comments section below.

Cheers, happy holidays, Eric

Explorations into the world of electronic music production

Posted on by

Apart from playing the recorder flute in primary school and keyboard with my father-in-law, I pretty much never had the chance to make music or even, to create new music. That did not bother me in the past, but when I married into a very musical and creative family I realized I was the only one without musical education or skill in playing an instrument. The family has (ir)regular jam sessions and sometimes arranges (mostly private but) quite high-quality classical music performances.

But, I had other hobbies, Slackware being one of them of course, and reading books while listening to my own music collection (which almost has no overlap with my wife’s by the way). And I was glad when I saw that my son has inherited my wife’s genes and has a knack for languages and music. He is exploring digital music making, has a keyboard or two and installed Ableton Live on his computer. I could never convince him that Slackware was the better alternative to Windows, all his friends are on Windows and what the group does is important for a teen. And furthermore, there’s a slew on tutorial and instruction video’s out there, all expecting you to use Ableton.

I looked at Ableton for its possibilities, and I had several discussions with one of my colleague/friends who is also a DJ/producer and uses Ableton a his primary driver. Seems to be a real nice program… but it costs hundreds of euros. So purchasing a license for Windows 10 and another one for Ableton, just to be able to converse with my son was not an option. I’ll introduce him to my friend and we’ll visit his studio to get inspiration. Then he can implement what he learnt, using tools he is familiar with.

During the past two years, I made some purchases just to have fun with creating sounds and rhythms, buying a couple of Pocket Operators from Teenage Engineering. I had one of these PO’s in my car, plugged into the car stereo and let my son create loops and sounds while on trips. Lots of fun and not too expensive. I also have an external USB soundcard,a FocusRite Scarlett 2i4. and a MIDI keyboard and bass guitar in the attic. But life’s too short and lots of stuff asks for attention – I never spent much productive time with my gear.

But these recent discussions about how to create digital music from scratch, and my wish toe be able to record the live performances of my in-laws, triggered a desire to have a better look at electronic music production and music recording, but then on Slackware Linux of course.

What would be needed for that? I would need software to create sounds (i.e. synthesizers), manipulate audio, create drum tracks, sequence the music, record and mix it. Also my USB sound card needs to be supported and I want my use midi keyboard to enter the notes that I play into the system. I obviously need low-latency real-time performance of my Digital Audio Workstation (DAW).

I guess that for many Linux musicians, the Debian-based AVLinux is a first choice when looking for pre-packaged, pre-configured Digital Audio Workstation (DAW) solutions and supporting software. But we Slackers already have Studioware – a Slackware expansion set which gives you a great toolkit with audio- and video manipulation software. My liveslak project even supports Studioware directly, and is able to create a Studioware Live ISO. You should try that out – it has a ton of software, not just for audio but also for video recording, manipulation and recording.

But… again… and that’s just me… I think that there’s no fun in using other people’s ready-made stuff. Here I am thinking again as the software packaging geek who wants to create possibilities for other people while not necessarily using those myself.

Anyway, I decided not to look too closely at what others had already done, and research a decent set of software products that I want to try out, and on Slackware-current too. Studioware is running on Slackware 14.2 and I tend to develop new stuff on our development platform.

And after a couple of weeks spent on reading, compiling, testing and scratching my head at my lack of knowledge, I came up with this list of software that I think is a nice start for venturing into DAW country. All of this is free and open source:

  • Music recording/mixing/manipulating:
    • ardour: the professional-grade Digital Audio Workstation (DAW).
  • Sound editing:
    • audacity: a graphical sound editor with a GTK3 based UI.
  • Synthesizers:
    • amsynth: an analog modelling synthesizer.
    • helm: a polyphonic synth with lots of modulation also works as a LV2 plugin.
    • zynaddsubfx: a software synthesizer and also a LV2 plugin.
  • Drum machine:
    • hydrogen: an advanced drum machine with Qt5 based GUI.
  • MIDI input:
    • vmpk: Virtual MIDI Piano Keyboard is a MIDI events generator and receiver which can be used to drive a MIDI synthesizer.
  • Audio manipulation plugins (not counting the standalone applications mentioned above that will also run as an Ardour plugin):
    • avldrums.lv2: a LV2 plugin wrapping the AVLinux Drumkits.
    • calf: Calf Studio Gear is a LV2/DSSI plugin collection but it also works as a standalone JACK-host.
    • eq10q: equalizer (and more) as LV2-plugins.
    • vamp-aubio-plugins: a small collection of audio feature extraction plugins.
  • System tools:
    • jack-audio-connection-kit (jack2): to provide low-latency real-time audio routing.
    • alsa-plugins-jack: part of alsa-plugins but not included in Slackware, allows audio to be routed to and from ALSA applications that are not JACK-aware.
    • qjackctl: a Qt5 application to control the JACK sound server.
  • Support libraries for implementing a DAW:
    • aubio: a system to extract annotations from audio signals.
    • ladspa_sdk:  SDK for sound plugins adhering to the Linux Audio Developer’s Simple Plugin API (LADSPA).
    • liblo: implementation of the Open Sound Control (OSC), a protocol for communication among multimedia devices.
    • lv2: the LV2 open standard for audio plugins.
    • rubberband: a library for audio time-stretching and pitch-shifting.
    • vamp-plugin-sdk: an audio processing plugin system (you still need to install actual plugins).
    • wxGTK3: GTK+3 implementation of the cross-platform wxWidgets API
  • Further dependencies for the above (not part of Slackware) that I had to create as packages to get it all working:
    • drumstick: MIDI libraries for Qt5. This is also part of my ‘ktown‘ Plasma5 desktop package set.
    • liblrdf: library to access LADSPA plugin metadata.
    • lilv: a library for using LV2 plugins in applications.
    • mxml: library to read and write XML and XML-like data files.
    • serd: RDF syntax library.
    • sord: library for storing RDF data in memory.
    • sratom: library for serialising LV2 atoms to and from RDF.
    • suil: library for loading and wrapping LV2 plugin UIs.
  • System libraries that I already had in my repositories and which you may already have installed and which are now all available in Slackware’s core distro:
    • qt5: the toolkit for creating graphical interfaces
    • libxkbcommon: support library for Qt5, handling keyboard descriptions.
    • OpenAL: support library for Qt5, implementing a 3D audio API.
    • SDL_sound: support library for Qt5 handling the decoding of various sound file formats.
Update 15-march-2019

Additions to the above set resulting from the discussion in the comments area below the main article:

  • Music notation:
  • Live Coding:
    • supercollider: a platform for audio synthesis and algorithmic composition
  • Plugins:
    • lsp-plugins: Linux Studio Plugins supporting LV2, LADSPA and Jack.
  • Support libraries:
    • portaudio: a cross platform audio I/O library.
    • portmidi: a platform independent library for MIDI I/O.
  • Front-ends:
    • qsynth: a Qt5 GUI Interface for FluidSynth.
Update 20-january-2020
  • System tools:
  • Support libraries:
    • dssi: an API for audio processing plugins.
    • libgig: a library for loading, modifying and creating gigasampler files.
    • liblscp: the LinuxSampler Control Protocol library.
  • Synthesizers:
  • Front-ends:
    • qsampler: a LinuxSampler Qt5-based user interface.
Update 27-january-2020
  • Support libraries:
  • Audio file analysis:
  • Synthesizers:
    • zyn-fusion: this is the zynaddsubfx realtime synthesizer (see above), but now with a new GUI based on ruby-zest.
      Install either the zynaddsubfx package (with the ntk GUI) or the zyn-fusion package (with the zest GUI) but not both.
Update 2-february-2020
  • Support libraries:
    • OpenBLAS: an optimized BLAS library. The package contains BLAS, CBLAS, LAPACK and LAPACKE support.
    • python-numpy: a python module for scientific computing.
    • python-pathlib2: a backport of pathlib to fully support stdlib Python API.
    • python-pyo: a Python module for digital signal processing.
    • wxpython: a cross-platform GUI toolkit.
  • Synthesizers:
    • cecilia5: an audio signal processing tool for sound designers.
Update 10-june-2020
  • Support libraries:
    • libsass: the C/C++ implementation of a Sass compiler.
    • sassc: the C implementation of Sass CSS preprocessor.
  • Music recording/mixing/manipulating:
    • non-daw: ‘Non’ DAW studio, with low hardware needs and responsive enough to be used live.
    • guitarix: a virtual guitar amplifier and effects rack.
Update 28-june-2020
  • Support libraries:
  • System tools:
    • cadence tools: JACK toolbox for audio production, an alternative to qjackctl.
    • jack_capture: a program for recording sound files with JACK.
    • meterbridge: meters for the JACK audio server.
    • zita-ajbridge: a JACK client to use additional ALSA devices.
Update 29-june-2020
  • Support libraries:
    • chromaprint: an audio fingerprint library.
    • faad2: ISO AAC decoder library.
    • hidapi: a library to communicate with USB & Bluetooth HID devices.
    • libmodplug: a MOD playing library.
    • libmp4v2: a library to read, create, and modify mp4 files.
    • protobuf: Google’s data interchange format.
    • qtkeychain: Qt API to store passwords and other secret data securely.
  • DJ Software:
    • mixxx: powerful DJ and performance software.
Update 30-june-2020
  • Support libraries:
  • System tools:
    • carla: a fully-featured audio plugin host.
Update 23-july-2020
  • Live Coding:
    • sonic-pi: a popular live-coding music performance tool.
Update 04-august-2020
  • Audio manipulation plugins:
    • gxplugins.lv2: a set of additional LV2 plugins for Guitarix.
    • x42-plugins: a set of LV2 plugins with standalone JACK applications.
  • Support libraries:
    • libltc: a Linear/Longitudinal Time Code (LTC) library.
    • zita-convolver: a real-time convolution matrix for up to 64 audio inputs and outputs.
Update 01-september-2020
  • Music recording/mixing/manipulating:
    • jamulus: internet jam session software (client & server).
Update 06-september-2020
  • Music recording/mixing/manipulating:
    • muse: a midi and audio sequencer.
  • Support libraries:
    • rtaudio: provides a common API for realtime
      audio I/O.
    • rtmidi: provides a common API for realtime
      MIDI I/O.
Update 20-september-2020
  • Music recording/mixing/manipulating:
    • qmidiarp: a MIDI arpeggiator, sequencer and LFO.
    • qtractor: an audio/MIDI multitrack sequencer.
Update 11-october-2020
  • Music recording/mixing/manipulating:
    • giada: a minimalist and hardcore music production tool.
Update 16-december-2020
  • Music recording/mixing/manipulating:
    • zrythm: a highly automated and intuitive digital audio workstation.
Update 20-december-2020
  • Support libraries:
    • libmicrohttpd: a small C library to make it easy to run a HTTP server as part of another application.
  • System tools:
    • faust: a functional programming language for real-time sound synthesis and audio processing.
Update 25-december-2020
Update 16-june-2021
  • Support libraries:
    • dblatex: DocBook to LaTeX/ConTeXt Publishing.
    • guile1.8: an interpreter for Scheme language.
  • Audio manipulation plugins:
  • Music notation:
  • Music recording/mixing/manipulating:
    • rosegarden: MIDI/audio sequencer and notation editor.
Update 26-june-2021
Update 10-july-2021
  • Support libraries:
    • libsmf: a standard MIDI fileformat library.
  • Drum kit:
    • dgedit: the drumgizmo drumkit editor.
    • drumgizmo: multichannel, multilayered drum plugin and stand-alone application.
Update 03-september-2021
  • Synthesizers:
    • VCV Rack modules: countmodula, mental, mindmeldmodular, modularfungi, packone, studiosixplusone, squinkyvcv, valley.
Update 03-september-2022
Update 15-june-2023
  • Synthesizer:
    • surge-xt: a powerful subtractive hybrid synthesizer.

Looking back, that is a big list! Actually when I started with my shortlist as mentioned above I did not anticipate that my ideas would require this many tools to support it. However I think that in order to do some serious audio production work on your computer, this is actually the minimum of applications that you require. There may be more, and I am very curious to hear from you if there is Open Source Software not on the above list, which you think is invaluable to your work as a musician or music producer and should be added here.

The ‘big boy’ in this collection, and the center of any DAW activities on Linux, is Ardour.

Ardour DAW

This is a complex program, but luckily the developers have an extensive manual online. And if you search on Youtube you will find a lot of videos on how to work in Ardour (most of them for older versions and most of them too obscure or too rambling to be educational). However, an Ardour channel on Youtube has just been created with the intention of releasing a new series of quality instruction videos, produced by Unfa who himself has a lot of nice videos on his own channel. Like I said, I have been scratching my head a lot lately, but my hair is still there and I will make progress and understand how to use this tool efficiently… eventually.
And I am glad to finally have Audacity in my repository, something I wanted/needed for quite a while.

All these packages are available in my regular repository, with one caveat (at least for now): I have built all of them for Slackware-current (both 32bit and 64bit). If you are running Slackware 14.2 then for now you need to have a good look at Studioware instead, or you can of course download the sources for my packages and compile them yourself.
The build order is roughly like this:

  • jack2
  • alsa-plugins-jack (depends on jack2)
  • pulseaudio-jack (Depends on jack2)
  • lv2
  • vamp-plugin-sdk
  • aubio (depends on jack2, and additionally on ffmpeg on Slackware 14.2)
  • liblo
  • ladspa_sdk
  • liblrdf (depends on ladspa_sdk)
  • rubberband (depends on ladspa_sdk and vamp-plugin-sdk)
  • serd
  • sord (depends on serd)
  • sratom (depends on lv2 and sord)
  • lilv (depends on sratom)
  • suil (depends on lv2 and qt5)
  • soundtouch
  • ardour (depends on jack2 aubio lv2 vamp-plugin-sdk liblo liblrdf lilv rubberband and suil)
  • mxml
  • ntk
  • portmidi (depends on openjre)
  • portaudio (depends on jack2)
  • zynaddsubfx (depends on jack2 liblo mxml ntk and portaudio)
  • hydrogen (depends on jack2 ladspa_sdk liblo liblrdf rubberband and qt5)
  • wxGTK3
  • soxr
  • audacity (depends on jack2 ladspa_sdk lilv soxr suil vamp-plugin-sdk and wxGTK3)
  • qjackctl (depends on jack2 portaudio and qt5)
  • calf (depends on jack2 and lv2, and for Slackware 14.2 additionally on fluidsynth)
  • avldrums.lv2 (depends on lv2)
  • helm (depends on jack2 and lv2)
  • amsynth (depends on jack2 ladspa_sdk and liblo)
  • eq10q (depends on lv2)
  • vamp-aubio-plugins (depends on aubio and vamp-plugin-sdk)
  • drumstick (depends on qt5)
  • vmpk (depends on drumstick)
  • musescore (depends on jack2 portaudio portmidi and qt5)
  • qsynth (depends on qt5)
  • lsp-plugins (depends on jack2 ladspa and lv2)
  • supercollider (depends on jack2 and qt5)
  • dssi (depends on jack2 liblo and ladspa_sdk)
  • libgig
  • liblscp
  • linuxsampler (depends on dssi libgig jack2 ladspa_sdk and lv2)
  • qsampler (depends on libgig liblscp linuxsampler and qt5)
  • libfishsound
  • capnproto
  • sonic-visualiser (depends on capnproto libfishsound liblo liblrdf portaudio rubberband serd sord and qt5)
  • zyn-fusion (depends on dssi jack2 liblo mxml and portaudio)
  • OpenBLAS
  • python-numpy (depends on OpenBLAS)
  • python-pathlib2
  • python-pyo (depends on portaudio portmidi liblo and jack2)
  • wxpython (depends on python-pathlib2 and wxGTK3)
  • cecilia5 (depends on python-numpy python-pyo and wxpython)
  • libsass
  • sassc (depends on libsass)
  • guitarix (depends on faust jack2 ladspa_sdk liblrdf lilv lv2 and sassc)
  • non-daw (depends on jack2 ladspa_sdk liblo liblrdf and ntk)
  • meterbridge
  • jack_capture (depends on jack2, liblo and meterbridge)
  • zita-alsa-pcmi
  • zita-alsa-pcmi
  • zita-ajbridge (depends on jack2 zita-alsa-pcmi and zita-resampler)
  • cadence (depends on a2jmidid jack2 jack_connect pulseaudio-jack and zita-ajbridge)
  • chromaprint
  • libmodplug
  • libmp4v2
  • faad2
  • hidapi
  • protobuf
  • qtkeychain
  • mixxx (depends on chromaprint faad2 hidapi libmodplug libmp4v2 lilv lv2 portmidi portaudio protobuf qtkeychain rubberband and vamp-plugin-sdk)
  • python-pyliblo (depends on liblo)
  • carla (depends on jack2 liblo and python-pyliblo)
  • sonic-pi (build-time dependency on erlang-otp)
  • libltc
  • zita-convolver
  • gxplugins.lv2 (depends on jack2 and lv2)
  • x42-plugins (depends on jack2 liblo libltc lv2 and zita-convolver)
  • jamulus (depends on jack2)
  • rtaudio (depends on jack2)
  • rtmidi (depends on jack2)
  • muse (depends on dssi jack2 ladspa_sdk liblo liblrdf lilv lv2 rtaudio rubberband and sord)
  • qtractor (depends on aubio dssi jack2 ladspa_sdk liblo lilv lv2 rubberband suil and vamp-plugin-sdk)
  • qmidiarp (depends on jack2 liblo and lv2)
  • giada (depends on fltk jack2 and rtmidi)
  • libmicrohttpd
  • faust (depends on libmicrohttpd portaudio rtaudio and supercollider)
  • libsass
  • sassc (depends on libsass)
  • guitarix (depends on faust jack2 ladspa_sdk liblrdf lilv lv2 and sassc)
  • glfw
  • jq
  • vcvrack (depends on glfw jack2 jq rtaudio and rtmidi)
  • noise-repellent (depends on lv2)
  • dblatex
  • guile1.8
  • lilypond (depends on dblatex guile1.8 (and build-time also on fontforge))
  • rosegarden (depends on dssi jack2 ldaspa_sdk liblo liblrdf lilypond)
  • python-ly
  • python-poppler-qt5
  • python-pygame (depends on portmidi)
  • qpageview
  • frescobaldi (depends on lilypond  python-ly  python-poppler-qt5  python-pygame qpageview)
  • libsmf
  • drumgizmo (depends on jack2, libsmf, lv2, zita-resampler)
  • dgedit
  • jack-example-tools (depends on jack2 zita-alsa-pcmi zita-resampler)
  • surge-xt (depends on jack2 and lv2)

I hope to get some interesting feedback from you. I am also considering how all of this could be added to a function-focused liveslak variant, as small as possible so it may load completely into memory. Actually I would prefer to attempt such a Live ISO using a bare Plasma5, rather than XFCE or other light-weight desktop environments (everybody else is probably already using XFCE). The Plasma5 desktop framework is very powerful and fast, and it could benefit the user of a DAW if everything she plugs in just works.
Update 29-jun-2020:
I wrote an article on configuring your Slackware system for using it as a DAW, and also in that article I am presenting a new liveslak variant “DAW” which will generate an ISO of 2.7 GB in size which runs out of the box as a fully configured Slackware Plasma5 based DAW: https://alien.slackbook.org/blog/configuring-slackware-for-use-as-a-daw/

Easy installation

If you use the slackpkg+ extension for slackpkg to manage packages from 3rd-party repositories, then installing all these packages (or refreshing the collection after I add packages) becomes very easy. Slackpkg has a powerful feature called templates, and with slackpkg+ added, it is possible to create a template containing multiple packages from one or more repositories.
For my DAW package set I created a template and host it here:  http://www.slackware.com/~alien/tools/templates/ with the name “daw.template”. Download this daw.template file and copy it into your local /etc/slackpkg/templates/ directory. Then, run:

# slackpkg install-template daw

…and slackpkg will prompt you with a list of all the packages from this template that you have not yet installed. For better readability in the example below I use the parameter “-dialog=off” so that the program outputs to the standard output instead of showing a ncurses dialog window:

# slackpkg -dialog=off install-template daw

NOTICE: pkglist is older than 24h; you are encouraged to re-run 'slackpkg update'
Looking for packages in "daw" template to install. Please wait...DONE
[ Repository ]              [ Package ]
  alienbob                    cecilia5-5.4.0-x86_64-1alien.tgz

Total package(s): 1
Do you wish to install-template selected packages (Y/n)?

In that sense, the “slackpkg install-template <templatename>” works similarly to the “slackpkg install <repositoryname>” command: it will install any package that is not already present on your computer.
After a “slackpkg install-template” action, you can fall back to your regular “slackpkg update && slackpkg install-new && slackpkg upgrade-all” routine of daily package management. You would have to run “slackpkg install-template daw” only after you read in my blog that I added a package, or if you had not yet installed the complete set and need (some of) the remaining packages.

Ideas? Enjoy! Eric

 

Slackware Live Edition, updated

Posted on by

blueSW-64pxDuring the past weeks I have been working on my “liveslak” scripts for the Slackware Live Edition. Check out my previous articles about Beta1 Beta2 and Beta3 releases for these scripts, they contain a lot of background about the reasons for creating yet another Slackware Live, as well as instructions on the use of the Live ISO images and their boot parameters.

I will be numbering the releases with ‘normal’ version numbers from now on, so the 4th beta release translates to “0.4.0”. The 1.0 release will contain everything I consider essential for my Slackware Live Edition. I think I am rapidly working toward that final milestone..

Update 06-jan-2016: please continue reading and commenting in my follow-up article on “Beta 5“.

 

What’s new in 0.4.0?

As with these previous public releases, this Beta4 marks a new milestone in the functionality of the Live OS. So what’s new? A feature I consider crucial for a persistent Live OS on a USB stick that you carry around with you in your jacket pocket… data protection! Persistence of the Live OS means, the things you change or add (or delete) are stored on the USB medium and will survive a reboot. As opposed to the raw ISO image (burnt to a DVD or ‘dd’-ed to a USB stick) which is a pure Live OS where all your modifications are written to RAM and gone when you reboot.

Data protection. How do you protect the stuff you are accumulating in your live user’s homedirectory, such as passwords, confidential documents, GPG and SSH keys etc? You lose the USB stick, someone else may steal it – your sensitive files will be compromised. Therefore the Slackware Live Edition offers you the option to create a LUKS-encrypted container file in the Linux filesystem of the USB stick. The filesystem inside that encrypted container will then be mounted on the /home directory of the Live OS when it boots. The LUKS passphrase you entered when creating the container, will be prompted for during the boot-up of the Live OS. On shutdown, the container will be locked again and a potential thief of your USB stick will be unable to get to the files in the LUKS container.

But there’s more of course. Here are some other highlights:

  • Better looking Grub boot menu (UEFI computers) by letting the “make_slackware_live.sh” script generate the used fonts.
  • The X session now supports the Compose Key. Use the Right-Alt (aka Alt-Gr) key to generate composed characters (like ë, ï, é etcetera).
  • When selecting a non-US keyboard, you can toggle between that and the US keyboard layout in your X session by pressing the Shift-Alt key repeatedly.
  • On request of Pat, the SLACKWARE ISO no longer contains the Nvidia binary drivers. You’ll get a pure Slackware experience without any 3rd party software getting in the way.
  • The ALSA softvol pre-amp is no longer applied when the pulseaudio package is installed.
  • The “isohybrid” commandline in the “make_slackware_live.sh” script has been tuned so that the resulting hybrid ISO file should boot on a larger variety of computers.

Download the ISO images

I have created ISO images for the SLACKWARE, XFCE, PLASMA5 and MATE flavours using the latest Slackware64-current packages available today. That means, you  can check out the recently added PulseAudio comfortably. For the PLASMA5 variant, I used the very latest KDE-5_16.01 packages available in my ‘ktown‘ repository. Willy Sudiarto Raharjo built a fresh set of Mate packages specifically for this Live release.

You can find the ISO images plus their MD5 checksum and GPG signature at any of the following locations – look in the “0.4.0” subdirectory for ISOs based on the liveslak-0.4.0 scripts:

Please allow some time to synchronize these mirror servers.

The ISOs have two user accounts: root (with password ‘root’) and live (with password ‘live’). My advice: login as user live and use “su” or “sudo” to get root access (note: “su” and “sudo” will want the live password!).

The ISOs are able to boot both on BIOS-based computers (where syslinux takes care of the boot menu) and UEFI systems (where grub builds the boot menu, which looks quite similar to the syslinux menu):

slackwarelive-0.4.0_syslinux

 

How to create a persistent USB stick from the ISO?

The ISO can be burnt to a DVD or copied to USB stick using ‘dd’ or just plain ‘cp’, but that will give you a read-only medium because all changes to the Live OS are in fact written to your computer’s RAM.

Use the ‘iso2usb.sh‘ script to create a Live OS on the USB device with persistence. Changes you make while running Slackware Live will then be preserved across reboots because the OS will write all these changes to the directory “persistence” in the root of the USB device. The script requires an input and an output parameter at a minimum:

# ./iso2usb.sh -i ~/Download/slackware64-live-current.iso -o /dev/sdX

… where /dev/sdX is the device name of your USB stick which will get formatted – erasing all data currently stored on it. The iso2usb.sh script will pause to show you the characteristics of the target device and ask you once more if you really want to continue erasing it. You will not easily destroy your harddrive unless you are really not paying attention!

How to create the LUKS encrypted homedirectory container?

THe iso2usb.sh script has been extended with a new parameter “-c” which takes a size argument. If you want to create a 400 MB container file to hide your homedirectory in, then you need to specify “-c 400M”. If you want 2.5 GB for your homedirectory, use “-c 2.5G”. If you are not concerned so much with the exact size but want to allocate a percentage of the free space on the stick, then use “-c 40%” to create a LUKS container that uses 40% of the available free space.

Now to put that into an actual example commandline which will create a file (its name will be “slhome01.img” by default) using up 50% of the free space on the stick:

# ./iso2usb.sh -i slackware64-live-xfce-current.iso -o /dev/sdX -c 50%

When the script gets to the point where it creates the LUKS container file, it will prompt you for a passphrase which will be used for encrypting and decrypting the container’s data. Right after that, the script will prompt you to enter that passphrase again when the LUKS container is unlocked and the ISO’s /home content is copied into the container.

Booting the Live OS

When you boot Slackware Live on a BIOS computer, Syslinux will handle the boot and show the following menu:

  • Start (SLACKWARE | PLASMA5 | XFCE | MATE) Live (depending on which of the ISOs you boot)
  • Non-US Keyboard selection
  • Non-US Language selection
  • Memory test with memtest86+

You can select a keyboard mapping that matches your computer’s. And/or boot Slackware in another language than US English. You will probably want to change the timezone; syslinux allows you to edit the boot commandline by pressing <TAB> because the syslinux bootmenu does not offer you a selection of timezones.

On UEFI computers, GRUB2 handles the boot and it will show a menu similar (and similarly themed) as the Syslinux menu:

  • Start (SLACKWARE | PLASMA5 | XFCE | MATE) Live (depending on which of the ISOs you boot)
  • Non-US Keyboard selection
  • Non-US Language selection
  • Non-US Timezone selection
  • Memory test with memtest86+

Editing a Grub menu is possible by pressing the ‘e’ key. After making your changes to the boot commandline, press <F10> to boot.

Another difference between Syslinux and Grub menus: in Grub you select keyboard, language and/or timezone and you’ll return to the main menu every time. You still have to select “Start Slackware Live” to boot. In the Syslinux menu, only the keyboard selection menu will return you to (apparently bot not actually) the same main menu. The non-US language selection will boot you into Slackware Live immediately without returning to the main menu. A limitation of syslinux.

Caveats and tips

Remember that this is still a Beta! There are still some rough edges that I am aware of, and if you find others please let me know.

  • Using the Nvidia binary drivers on a persistent USB stick – once you pass the argument “load=nvidia” and your USB stick is persistent, you have to keep loading the nvidia module or else your X serssion will no longer start. If you are always going to use the USB stick on computers with supported Nvidia cards, the simplest solution is to move the file “0060-nvidia-352.63_4.4.0-current-x86_64.sxz” from “liveslak/optional/” to the “liveslak/addons/” directory so that it is loaded by default, saving you from typing “load=nvidia” every time. The ugly solution is to remove the content of the “/persistence/” directory on the Linux partition.
  • Booting a persistent USB stick with LUKS home to the “virgin condition” – suppose you screwed up somehow and the USB stick won’t work anymore. You can boot the original Live OS without all your accumulated persistent changes by adding the boot command parameter “nop” which stands for “no persistence”. That will still mount the LUKS container on the /home directory. If you want to ignore the LUKS container, and use the /home directory of the original Live OS, an additional parameter “luksvol=” must be added to the boot commandline. After logging in you can remount the Linux partition of your stick to make it writable:

    # mount -o remount,rw /mnt/livemedia

    and proceed with pruning the persistence directory “/mnt/livemedia/persistence” and/or fixing the LUKS container file “/mnt/livemedia/slhome01.img“.

Happy hacking! Eric

PulseAudio comes to Slackware-current Beta

Posted on by

pulseaudio_medHah! Got you there! Oh wait – it’s true.

Yup folks, thanks to the new bluetooth stack in slackware-current (brought to you by BlueZ 5.x) we have introduced a dependency on PulseAudio. Bluetooth audio no longer accepts ALSA as the output driver.

So, Pat has added a pulseaudio package and with it, a lot of dependency packages: ap/pamixer l/alsa-plugins l/atkmm l/cairomm l/glibmm l/gtkmm3 l/json-c l/libasyncns l/libsigc++ l/pangomm l/speexdsp xap/pavucontrol and finally xfce/xfce4-pulseaudio-plugin…

Also, we have a Beta!

Wed Jan 13 00:01:23 UTC 2016
Also, enjoy a shiny new LTS 4.4.0 kernel and consider this 14.2 beta 1.

Coming back to PulseAudio: the alsa-plugins package ensures that ALSA applications can remain unaware that PulseAudio is now handling audio in- and output. A file “/etc/asound.conf” will be installed by a recompiled “alsa-libs” package. This configures Pulse as the default audio device. Please take care in case you created a “/etc/asound.conf” yourself that you have to merge yours with the freshly installed “/etc/asound.conf.new” !

Several other Slackware core packages needed a recompile against PulseAudio, but note that you may not have to. As said before, ALSA output still works transparently, it’s just that ALSA’s output is now an input for PulseAudio which in turn controls your audio hardware.

Yes, some people will be opiniated. We invited the Devil into our house and stuff. Well, PulseAudio is not maintained by Lennart anymore, and saner people took the helm. We expect no big mess as a result, just a learning curve to understand the new sound configuration. And truthfully, we were left no choice. The alternative would have been to say bye-bye to bluetooth in Slackware because already, major pieces of software are dropping or preparing to drop support the old and incompatible BlueZ 4.x API.

Note: Slackware is NOT going to add systemd. It’s too controversial and there is no need. Your sleep will be sound now.

People who installed the Jack audio connection kit should probably carefully evaluate the possible changes to their configuration. I stopped using “jackd” here  so I can not tell you at the moment.

Happy hacking! Eric

Slackware Live Edition

Posted on by

I thought it would be a cool idea to celebrate the “farewell to udev”. With the abandoned ConsoleKit replaced by ConsoleKit2 which is actively maintained by the Slackware-friendly XFCE crew, and Gentoo’s eudev taking the place of udev, we are well equipped to keep systemd out of our distro for a while. Basically eudev contains the udev code as found in the systemd sources, but then stripped from all standards-violating systemd crap and with a sane build system. Hooray, we’re back in business and eudev gained some more traction. Win-win.

How to celebrate the occasion? Easy! By releasing the Slackware Live Edition.

liveslak-1.0.0

Please also check out the original announcement text (moved to a different page) and the follow-up articles on “liveslak” which explain how this project grew from its humble beginnings.

First teasing screenshots of my (then still called) “Project X” were revealed in a blog post in November 2015. I wrote the original annoucement a week later, also in November, on this exact blog page. However, the original text talked about being beta, incomplete and in need of testing. In the meantime, this page’s URL is being linked to from everywhere and I get many questions about “when will it be ready” so I decided to re-write this text into a proper reference page and moved the original text to a different location for posterity.

Note for clueless newbies

The Slackware Live Edition comes with two user accounts: user ‘root’ (with password ‘root’) and user ‘live’ (with password ‘live’). My advice is to login as user live and use “su” or “sudo” to get root access.

Note: the “su” and “sudo” commands will ask for the ‘live’ user’s password!

What is Slackware Live Edition, and what is liveslak?

Slackware Live Edition:
It is a version of Slackware (14.2 and newer)  that can be booted and run directly from a DVD or a USB stick. It is distributed as an ISO image and meant to be a showcase of what Slackware is about. You get the default install, no customizations, but with all the power. You do not have to install Slackware to your harddisk first to experience it first-hand.

Liveslak:
The combination of scripts, bitmaps and configurations to generate the ISO images are called project “liveslak“.

Let me state the reasons I had for starting this “liveslak” project (apart from sheer curiosity):

  1. Provide a Live version of Slackware proper – i.e. show Slackware as it is, but without having to install it. No hiding of kernel messages scrolling across the screen at boot – no custom wallpapers, etcetera. Meant for education and demonstration purposes.
  2. The target should be slackware-current – the bleeding edge. Many people want to know what that looks like but are hesitant to install slackware-current for fear that it breaks stuff and causes productivity loss.
  3. Provide a way to generate a Live ISO with just Slackware packages as the source – fully scripted and deterministic.
  4. Still be able to customize its content – for instance provide stripped-down or minimalist versions of Slackware but also allow for the inclusion of 3rd party packages.
  5. Option to create a bootable USB stick running Slackware Live (which is different from ‘dd’-ing the hybrid ISO to a USB stick!)
  6. Keep It Simple Stupid!

… but I had not anticipated the expansion of scope that can be attributed to the people who have been testing all my Beta versions. They came up with real-life use-cases, worthwhile additions and fixes. My thanks go out to all of you! The “liveslak” is so much more now then I initially conceived. Instead of being just a simple demo-toy it is now usable as a full-blown Live work environment in its own right. I carry a USB stick with a secured Slackware Live on my key chain all the time.

Highlights of Slackware Live Edition

Properly documented

The Slackware Documentation Project contains extensive documentation about “liveslak“, both for users of the Live OS and for people who want to know “how it works”  and want to develop a custom Live OS.
Check it out please, in particular all the boot options for the Live OS.

Good hardware support

The Live OS boots on “good old” BIOS computers but also on modern UEFI hardware (disable secure boot first). The kernel and userland software in the OS is fully up to date and supports modern and older hardware. If your computer does not support a 64bit Operating System then you can just download the 32bit version of Slackware Live Edition.

Persistence

Slackware Live Edition is persistent if you install its ISO to a USB stick using the “iso2usb.sh” script. Persistence of a Live OS means, the things you change or add (or delete) are stored on the USB medium and will survive a reboot. As opposed to the raw ISO image (burnt to a DVD or ‘dd’-ed to a USB stick) which is a pure Live OS where all your modifications are written to a RAM disk and gone when you reboot.

A feature I consider crucial for a persistent Live OS on a USB stick that you carry around with you in your jacket pocket is… data protection!

Data encryption

How do you protect the stuff you are accumulating in your live user’s homedirectory, such as passwords, confidential documents, GPG and SSH keys etc? You lose the USB stick, someone else may steal it – your sensitive files will be compromised. Therefore the Slackware Live Edition allows you to apply strong, unbreakable encryption to your precious data. You have the option to create a LUKS-encrypted container file in the Linux filesystem of the USB stick. The filesystem inside that encrypted container will then be mounted on the /home directory of the Live OS when it boots.
When creating the LUKS container you must enter a passphrase which will be used to encrypt all your data. During the boot-up of the Live OS, you will be prompted to enter this exact passphrase again which will then unlock the container and make your data available. On shutdown, the container will be locked again and a potential thief of your USB stick will be unable to get to the files  (i.e. your homedirectory) which reside in the encrypted LUKS container.

Multiple OS variants or flavors

The “liveslak” scripts are able to generate a variety of Slackware Live ISO flavors: SLACKWARE, XFCE, PLASMA5, MATE, CINNAMON, CUSTOM. The locations where you can download these ISO files are shown in the next paragraph.

  1. By default, “liveslak” creates a 3 GB large ISO from scratch that will give you a complete 64bit Slackware-current Live Edition.
  2. The scripts can also create a 700 MB slimmed-down XFCE version with XDM as the graphical login manager which fits on a CDROM medium or a 1 GB USB stick.
  3. A 4 GB ISO image of Slackware64-current containing Plasma 5 instead of KDE 4 is also an option. The PLASMA5 variant is spiced up with several other packages I maintain: vlc, libreoffice, calibre, qbittorrent, ffmpeg, chromium, openjdk, veracrypt.
  4. The option to generate a 2 GB ISO containing either the Mate or the Cinnamon desktop instead of Slackware’s own KDE 4 could be added courtesy of Willy Sudiarto Raharjo’s repositories.
  5. The “liveslak” scripts allow a large degree of customization so that you can create “your own” variant of a Slackware based Live OS. One example of what’s possible is the Live Edition of Cinelerra CV.

 No custom kernel or 3rd party tools needed

The main script “make_slackware_live.sh” creates an ISO from scratch. The script installs Slackware packages or package sets into compressed “squashfs” modules, configures and optimizes the target filesystem to be run as a Live environment, and then generates an initial ramdisk that will assemble the Live environment when you boot. All that is put into a bootable ISO image file. Thanks to Linux kernel 4.x and the squashfs-tools package added to Slackware 14.2, the process requires no compilation nor does it need non-standard packages to create a Slackware Live Edition (of course, the Plasma, Mate and Cinnamon flavours do require 3rd party packages). The downside is that the ISO has to be created on Slackware 14.2 (older versions of Slackware do not have the proper tools or kernels). It follows that the only Slackware release which is supported as a Live Edition is 14.2 and the “-current” development tree. All future releases will be supported too of course.

Install the Live OS to your hard drive easily

The included program “setup2hd” (all ISOs except the small XFCE variant) is a modified Slackware installer which will guide you through the familiar setup menus and install the content of the Slackware Live Edition to your hard disk. The “setup2hd” program can be run from your X session so that you can keep interacting with the Internet while Slackware installs itself.

setup2hd

Start the builtin PXE server and let the whole LAN run Slackware Live

Load the Live OS into RAM using the “toram” boot parameter and then start “pxeserver” from an X terminal. All computers in your LAN will be able to boot Slackware Live Edition from the network now. Ideal for a hackfest.

pxeserver

Download the ISO images

As stated above, you can choose between several variants of Slackware Live Edition. ISO images for the SLACKWARE, XFCE, PLASMA5 and MATE flavours using the latest Slackware-current packages are available.

The ISO images (with MD5 checksum and GPG signature) are available on the master (bear) and its mirror servers. A symlink called “latest” will always point to the latest set of ISO images.

And if you love the bleeding edge, an ISO file for slackware64-current is automatically (re-)generated every time there is an update to the ChangeLog.txt of Slackware-current. You can find this ISO image here:

Download the source

Git repository for the scripts can be found here:

A checkout of the repository can be found here:

Transfer the ISO content to a medium

  • You can burn the ISO file to a CDROM medium (only the XFCE Edition fits on a CD) or to a DVD,using your favorite burning program like k3b (KDE), xfburn (XFCE), xcdroast (plain X-Window) or brasero (GNOME)… or a Windows burning program if you want.
    Make sure you inform the application that this is a bootable ISO, i.e. do not simply burn the contents of the ISO to a disk.
  • Or, you use the program ‘dd’ or else ‘cp’ to transfer the ISO to a USB stick (aka flash drive). Any of the following two commandlines will do the job, provided your USB stick is known by your Linux computer as “/dev/sdX“. Note that sdX means the whole disk, not a partition on the disk!

    $ dd if=slackware-live-14.2.iso of=/dev/sdX
    $ cp slackware-live-14.2.iso /dev/sdX

    This creates a read-only bootable USB medium containing Slackware Live. Readonly means that you will not get persistence this way. This method is similar to using a DVD medium. If you want a writable USB stick instead, read the next option.

  • You can use the ‘iso2usb.sh’ script to transfer the content of the ISO to a USB stick, thereby adding persistence to the Live OS on the stick. The stick will remain writable and you can add new modules later on if you want.
    You can find extensive documentation on the usage of that script on the Slackware Documentation Wiki.

Booting the Live OS

When you boot Slackware Live on a BIOS computer, Syslinux will handle the boot and show the following menu:

  • Start (SLACKWARE | PLASMA5 | XFCE | MATE) Live (depending on which of the ISOs you boot)
  • Non-US Keyboard selection
  • Non-US Language selection
  • Memory test with memtest86+

You can select a keyboard mapping that matches your computer’s. And/or boot Slackware in another language than US English. You will probably want to change the timezone; syslinux allows you to edit the boot commandline by pressing <TAB> because the syslinux bootmenu does not offer you a selection of timezones.

On UEFI computers, GRUB2 handles the boot and it will show a menu similar (and similarly themed) as the Syslinux menu:

  • Start (SLACKWARE | PLASMA5 | XFCE | MATE) Live (depending on which of the ISOs you boot)
  • Non-US Keyboard selection
  • Non-US Language selection
  • Non-US Timezone selection
  • Memory test with memtest86+

Editing a Grub menu is possible by pressing the ‘e’ key. After making your changes to the boot commandline, press <F10> to boot.

Another difference between Syslinux and Grub menus: in Grub you select keyboard, language and/or timezone and you’ll return to the main menu every time. You still have to select “Start Slackware Live” to boot. In the Syslinux menu, only the keyboard selection menu will return you to (apparently bot not actually) the same main menu. The non-US language selection will boot you into Slackware Live immediately without returning to the main menu. A limitation of syslinux.

liveslak-0.9.0-xfce

 

Things to remember when you boot the ISO

Slackware Live does not log you on automatically! This is a demonstration environment, with the purpose of getting you acquainted with Slackware, remember? Therefore you will first see all these intimidating kernel messages scrolling across the screen while booting the OS. Then you need to login manually.

Consult the documentation for assistance with the various boot parameters you can use to tailor the Live OS to your needs. The syslinux boot has help screens behind the F2, F3, F4 and F5 function keys and the grub boot screen has a “help on boot parameters” menu entry.

How to create a persistent USB stick from the ISO?

The ISO can be burnt to a DVD or copied to USB stick using ‘dd’ or just plain ‘cp’, but that will give you a read-only medium because all changes to the Live OS are in fact written to your computer’s RAM and lost when you reboot.

Use the ‘iso2usb.sh‘ script to create a Live OS on the USB device with persistence.

Note: The “iso2usb.sh” script can also be found in “/usr/local/sbin” when you boot Slackware Live Edition.

By default, the changes you make while running Slackware Live will then be preserved across reboots because the OS will write all these changes to the directory “persistence” in the root of the USB device. The script requires an input and an output parameter at a minimum:

# ./iso2usb.sh -i ~/Download/slackware64-live-14.2.iso -o /dev/sdX

… where /dev/sdX is the device name of your USB stick (the actual device, not a partition on the device).

Alternatively you can use a file “persistence.img” in the root of the USB device which will be loop-mounted by the Live OS and changes to the system will be written to the filesystem inside this container file. A feature which should be appreciated by people who want to use a USB stick with a VFAT partition instead of a Linux ext4 partition. The script requires an additional parameter “-P” in this case:

# ./iso2usb.sh -P -i ~/Download/slackware64-live-current.iso -o /dev/sdX

Note that your USB stick will get formatted by the script – erasing all data currently stored on it. The iso2usb.sh script will pause to show you the characteristics of the target device and ask you once more if you really want to continue erasing it. You will not easily destroy your hard drive unless you are really not paying attention!

How to create a LUKS encrypted homedirectory container?

The iso2usb.sh script has a parameter “-c” which takes a size argument. If you want to create a 400 MB encrypted container file to hide your homedirectory in, then you need to specify “-c 400M”. If you want 2.5 GB for your homedirectory, use “-c 2.5G”. If you are not concerned so much with the exact size but want to allocate a percentage of the free space on the stick, then use “-c 40%” to create a LUKS container that uses 40% of the available free space.

Now to put that into an actual example command line which will create a file (its name will be “slhome.img”) using up 50% of the free space on the stick:

# ./iso2usb.sh -i slackware64-live-xfce-current.iso -o /dev/sdX -c 50%

When the script gets to the point where it creates the LUKS container file, it will prompt you for a passphrase which will be used for encrypting and decrypting the container’s data. Right after that, the script will prompt you to enter that passphrase again when the LUKS container is unlocked and the ISO’s /home content is copied into the container.

Help, I messed up my persistent USB stick!

You can still boot a USB stick containing persistence and/or encrypted LUKS homedirectory to a “pristine condition”.

Suppose you screwed up somehow and the USB stick won’t work properly anymore or won’t even boot to the desktop. If this happens, you can still boot the original unmodified Live OS, discarding all your accumulated persistent changes. The unmodified OS should always boot unless your USB stick is physically damaged.

You have two options to solve the levels of brokenness:

  1. Start by adding the boot command parameter “nop” which stands for “no persistence”. The “nop” boot parameter will  cause Slackware Live to ignore your persistent data, as most probably the persistent data store will contain the cause of your issue. Even when passing “nop” to grub or syslinux, Slackware Live will still mount your encrypted LUKS container on the /home directory if you are using that. It is possible that your issue is somewhere in your homedirectory (for instance you might have an issue with configuration files in ~/.local ~/.config or ~/.kde).
  2. If you want to ignore any LUKS container as well as ignoring the persistent storage, and use the /home directory of the original Live OS, an additional parameter “luksvol=” must be added to the boot commandline. Note that there is nothing at the right side of that equal sign! The two parameters together look like “nop luksvol=“.

After logging in to a pristine Slackware Live you can then remount the Linux partition of your USB stick to make it writable:

# mount -o remount,rw /mnt/livemedia

Now that the USB stick’s partition is writable you can either prune the persistence directory “/mnt/livemedia/persistence” (i.e. delete all data in there) and/or fix the content of your LUKS container file “/mnt/livemedia/slhome.img“.

Have fun! Eric

Below, you will find all the comments made by visitors since the original announcement was posted here on the blog.