Application Catalogue

One of the most powerful aspects of using open source software is the proliferation of software. There is no comparison in the closed source world because making lots of small, couture, personal applications just doesn't pay like big monolithic flagships do. So there can be no practical catalogue of all the useful open source applications; there are too many.

Your first job as an artist new to Slackware (after learning Linux) is to find out which application(s) you like for which task. You need not limit yourself to just one or two per task. It's acceptable to use one application for some task under certain conditions, and another for the same task under a different set of conditions.

It will be your impulse to identify the applications you used to use, and try to find clones of those. It's an unavoidable tactic, but time and time again it has disappointed users from all disciplines; applications are not built according to some mysterious universal specification. Applications are designed from the ground up according to the way that their programmers feel best. It may act completely different to what you are used to. The sooner you accept that you are embarking on a quest to learn new applications and not uncover the hidden “freeware” versions of the applications you learnt in school or on a job, the better!

Learn new stuff, make great art.

It's also acceptable to use just one or two applications for everything you do. There is no right or wrong way of doing this; the point is not to unravel the puzzle into an intended result, but to use the puzzle pieces to create whatever result suits you best.

This is possibly the greatest point of confusion to new Linux users: Linux is whatever you make it.

At this point, most computerists have been trained to conform strictly to prescribed workflows using only name-brand tools. In spite of its widespread and often passionate userbase, Linux is not a social club that you join or a company that you work for nor a corporation from which you make purchases; it's an operating system that bends to your will. Explore the tools available to you, try them out until you feel comfortable with them, and then decide which one is for you.

On Switching

If a user has been trained on, for instance, Final Cut Pro and gets a job as, for instance, an Avid editor, the user is as good as a beginner.

If a user is a certified genius on Windows, that same user is at primary school level when placed in front of an Apple Mac. A user who can produce amazing animation in Adobe Flash is useless with Toon Boom, and a musician that knows Pro Tools flails helplessly in Cakewalk.

Switching to open source solutions is no different.

Evaluating Software Like a Pro

Do not assume that just because you know one closed-source application, you can pick up an open source “equivalent” and keep going from where you left off. You need to go back to the beginning, you'll need to learn about what the application is capable of doing, how it works, what file formats it agrees with and what file formats cause it problems, and so on.

It is painful to experience such setbacks. The good news is that while there is a ceiling in closed software, there is none in open source, meaning that even though you are destined to start out a beginner all over again with open source software. Once you have learnt to use it well, then you can continue learning, refining, perfecting, customising, and building upon that open foundation that you have established.

Open Source has no upper limit.

The appropriate steps in evaluating a software for production use are entirely up to you, but you should have a methodology to it. There is no excuse for launching an application, poking around at it for an hour, and then closing it in frustration with the declaration that it is unfit. Almost no new application (open source or otherwise) is going to fit your current workflow, because your current workflow is designed around specific applications.

This is a sample evaluation process:

Requirements

Make a generic, software-independent list of your actual workflow. Ask yourself what steps actually need to occur with a set of assets, and break this into several steps.

Target

From this generic list, locate potential software that appear to perform each step. It may be that one monolithic software claims to do everything you need, or it might be that several applications cover a few items on your list, creating a pipeline.

Read the Docs

Read the application's documentation. This is the key to the application's intended use. The application may, on a superficial level, resemble something familiar to you, but that does not mean that the application works the same as the one that is resembles. In fact, chances are good that it does not.

If you are serious about finding an alternative, then the burden is on you to understand how the software works. You cannot insist upon using software the wrong way, because that is how you have been trained to achieve a result, and then close the software and call it confusing, unintuitive, or insufficient. You are not using the software as intended. Do the research and make sure this is not how you are evaluating software.

Evaluate

Armed with a few potential pipelines, you can now begin to evaluate the software that claims to solve your problem.

Read online documentation and tutorials of the software you intend to use. Get a feel for not just what the software claims to do, but how it achieves the results.

Practise using each application in test environments. Create a test project with realistic assets typical of what you would use in your production environment. Use the application that you are evaluating to create something out of those assets. Remember that you are a beginner in this environment, so the end result probably will not be as technically complex as something you would create in the environment you usually use.

This will be frustrating to you. Count on that. It's difficult, as a skilled craftsperson, to do something familiar to you, but with one hand metaphorically tied behind your back. However, you can also use this as an artistic exercise; take this opportunity to stop relying on the tools of your trade, and get back to experimentation and raw creativity. You might find it surprisingly refreshing.

When you encounter problems, post questions online for the software's author or support team. Usually, a software will have a forum or bug report link on its homepage; use it. For commercial software, you probably either had or still have resources for support; find the same resource for your open source tools.

You will have to look in different places than the sites you are already familiar with; you will not be able to get help with open source software on sites that cater exclusively to restricted software, and you won't find quality help on open source software on sites that cater primarily to restricted software. Go straight to the source, or email Slackermedia.

Don't be afraid to customise. As you learn, you may well find shortcuts or preference tweaks that make an application more comfortable for you. That's part of the power of open source, so use them! If something annoys you, or if you find a quicker way to achieve something, customise applications, tweak the interface, change the keymaps. Do whatever you please. As long as you save the configuration files (written as invisible files in your home directory), you can carry your changes around with you from computer to computer (many applications can dynamically change where they look for config files, but if not then you can just install your config files and the applications will adapt).

Sometimes, new users are hesitant to do this for fear of learning an application “wrong”. In practise, if you find yourself using an un-customised version of some application, the brain tends to switch over to its lowest-common usability settings; your work might be slower without your own configuration, but you will be far from helpless.

Unless you have no standard operating environment, it's best to customise an application for efficiency.

Adapt, or do not adapt. In a perfect world, you would not have to adapt to anything new. The reality of computing is that you do adapt. You adapted, whether you knew it or not, to closed source software when you chose to do everything in the way it makes you do things (in other words, you used its file formats, ingested media, dealt with licensing, exported to finals, and so on, in the way that closed source software told you). Since many people learnt well-promoted and -marketed closed source software first, it does not feel like you are adapting to something, because you are instantiating habits and workflows that simply did not exist previously.

If an open source application is not working, try adapting a little. If you need to change file formats, or ingest media in a different way than what you think is obvious, or do different steps of your workflow in a different order, be willing to mix things up. Don't sacrifice quality, but do recognise that most of your habits have been built entirely upon one specific set of tools. Don't be too stubborn to recognise that there are more than one way of accomplishing something.

Reflect

Once you have learned a software sufficiently to be critical of its results, decide whether or not it will work for you. If not, move to the next candidate.

Practise

If the software will work for you, then the next perpetual task is to practise. You did not learn all that you know about closed source software in a day or even a year. Switching to something entirely new and different is going to take practise.

Installing the Applications

The rest of this handbook contains instructions on how to install and configure some applications, and in some cases, an overview on how to use them.

It is not all-inclusive; there are heaps of great applications out there, and this is mostly just a list of the apps that Slackermedia users have used and tested and, for that reason, recommend to others.

This is not a complete manual for each application; there are some tips on how to use the applications, and there are tips on how to integrate it with other important applications.

The following overview of applications provides a general sense for what is available for Linux. It should serve as a launchpad for further exploration, and as a list of known-good and robust applications that are in use in real-world production environments, some of which are a bedroom music studio and others are multi-million dollar production facilities.

Have fun!

R S Q