Differences

This shows you the differences between two versions of the page.

--- app [2015/05/17 11:56]
slackermedia
+++ app [2021/06/03 19:48]
@@ Line 1: / Line 1: @@
-[[{arrowp.png|border:0;background:none;width:0;display:inline-block;position:absolute;top:0;left:0;}workflow|]]
-[[{arrown.png|border:0;background:none;width:0;display:inline-block;position:absolute;top:0;margin-left:2.5em;}apps:audacity|]]
-====== 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 job as an artist new to Linux is to find out which application(s) you like
-for what 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. Conversely, 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. Linux is
-not a social club that you join or a company that you work for, 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.
-===== Evaluating Software Like a Pro =====
-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.
-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
-will 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 open source 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:
-. 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.
-. 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 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.
-. 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.
-    In other words, 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! 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 stubbort to
-        recognise that there are more than one way of accomplishing something.
-. 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.
-. 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
-As you have learned from
-Chapter 2.  Understanding How Applications are Managed
-Table of Contents
-Slackware Packages
-The pkgtool, installpkg, and removepkg Utilities
-Slackware Packages and slackpkg
-Finding Additional Slackware Packages
-sport
-Before you begin to build your multimedia system, it's important to understand
-how software is installed, uninstalled, and upgraded on a Slackware system.
-Generically, this is referred to as "package management".
-GNU Linux systems have become known for having a progressive and unique method
-of installing software, referred usually as the "repository" or "package
-management" systems. Red Hat Linux introduced this idea when they created,
-essentially, a database to keep track of all software installed on the
-computer. This database could then be automatically checked to see if newer
-versions of the software existed on a remote server, and in the event that a
-newer version was released then the user's local computer could be updated.
-Other distributions have since either re-invented this methodology or adapted
-it, or they use it directly. There are a few notable exceptions, one of which
-is Slackware.
-Slackware, for all practical purposes, has four primary methods of managing the
-software installed on a system:
-. pkgtool and related tools like installpkg and removepkg, slackpkg, and
-    rpm2tgz
-. Slackbuilds
-. Source code and makepkg (technically a part of the pkgtool set, but most
-    useful for compiling source code)
-. Statically linked binaries or custom packages
-Each of these offers a variety of choices for how a user manages the software
-on a computer; none of them impose update schedules, automatic dependency
-installation and removal, or demand a complex system of database calls be
-learned.
-Slackware Packages
-The basic pkgtool suite is designed to help the user install, upgrade, and
-remove pre-built Slackware packages.
-Slackware packages are ordinary compressed tar files. They contain, quite
-simply, a collection of pre-built files that have been archived; they generally
-have the file extension .tgz, .tbz, or .txz, although not all .tgz, .tbz, or
-.txz are necessarily Slackware packages.
-Those that are Slackware packages contain, generally speaking, these files:
-  * slack-desc
-    A description of the application this package will install.
-  * doinst.sh
-    A shell script doing post-install tasks, like adding support in one program
-    for the application just installed.
-  * /usr, /usr/share, and similar
-    The folders into which the executable application itself exists and from
-    which it will be copied out into the rest of the system.
-A traditional package, therefore, is a mimicry of your Linux system; it
-contains a few descriptive files or scripts to do a few specialized tasks, but
-mainly it is simply an isolated /usr, /etc, and whatever else is required for
-the application to run, with all the compiled files in place.
-The install process is to take all of these files and to superimpose them over
-your existing Linux system. In other words, you could literally go through each
-file in the package and copy it over to the corresponding folder on your
-computer; ie, cp package/usr/bin/foo /usr/bin/foo and so on. Once the files are
-copied from the package to your larger system, the application can be run on
-your computer.
-This would be tedious and impossible to track and therefore difficult to
-reverse, so it would be smarter to have a shell script do it for you. The
-scripts included on Slackware for these and related tasks are:
-  * installpkg
-  * removepkg
-  * pkgtool
-The pkgtool, installpkg, and removepkg Utilities
-installpkg is a simple front-end to the process of decompressing, copying files
-from, and keeping a record of a Slackware package.
-    $ su -c 'installpkg
-        /media/cdrom/extra/foo/foo-*.txz'
-Once a package is installed, all of the files that have been placed on your
-system are recorded in /var/log/packages. Using this information, two other
-scripts can upgrade packages, or remove packages.
-  $ su -c 'upgradepkg
-  /var/log/packages/foo-version.txz foo-newVersion.txz'
-  $ su -c 'removepkg
-  /var/log/packages/foo-version.txz'
-Tip
-To see exactly what is going to be installed before installing it, you can use
-the pkgtool command, which provides a menu, including the option to view a list
-of all the files in the Slackware package.
-Most of these commands can be done with pkgtool. pkgtool is an empty shell that
-looks for Slackware packages in any directory defined by the user. Pkgtool is
-able to install a package, remove a package that has once been installed, and
-even upgrade packages. It is a graphical tool that runs in the terminal, so its
-use is fairly self-explanatory; simply choose whether you want to install
-packages from a directory, remove packages, or view a list of installed files
-associated with a package. Since Slackware itself uses Slackware packages to
-install itself in the first place, you can also run the initial install scripts
-again, including the font cache, lilo config, choose a default window manager,
-and more.
-Slackware Packages and slackpkg
-The first Slackware packages you'll deal with are the ones installed onto your
-system during the normal installation process. You probably won't interact with
-these directly, but they are always available for reinstallation, either from
-your install media or via the internet.
-Aside from the default packages installed with a full install, there is an /
-extra directory containing additional packages. To install them from the
-install DVD, use installpkg:
-  # installpkg /dev/cdrom/extra/foo-0.1.tgz
-If you don't have the install media, then of course all of this is possible
-from the internet.
-To install a package from the internet, you could download the .tgz file from a
-Slackware mirror and then use installpkg or pkgtool, but there is a simple
-shell script that can make the process easier, called slackpkg.
-To configure slackpkg so that it knows where online to look for packages, open
-/etc/slackpkg/mirrors (a text file) as root and find the mirror that is
-associated with your Slackware version and that is geographically close to you,
-and uncomment it. This list of mirrors offers ftp and http access, but you must
-uncomment only one.
-Note
-In terms of slackpkg, there is no functional difference between ftp and http.
-If you use a network that restricts, for instance, ftp traffic, then http would
-have the obvious advantage for you.
-Using slackpkg is simple and much like using tools like yum or aptitude. You
-should update your list of available packages by issuing the initial command
-slackpkg update and from that point on, the repository can be searched by using
-the command slackpkg search foobar as root, and an application can be installed
-with slackpkg install foo. As usual, reading the manual page for slackpkg will
-reveal a full listing of associated commands.
-Once a package has been installed with slackpkg, it can be removed or upgraded
-using pkgtool and the other package management commands.
-Since a full install of Slackware contains nearly everything that slackpkg has
-access to anyway, the most common use for slackpkg in Slackermedia will be for
-security updates. You should perform a periodic update of slackpkg followed by
-  $ slackpkg upgrade-all
-Look through the list of available updates, and update as you see fit. Only
-essential security updates are distributed via slackpkg, so even in-production
-machines are safe to patch.
-Finding Additional Slackware Packages
-If you installed the full Slackware install base, then the only additional
-packages that slackpkg provides are applications found in the /extra and /
-testing directories (also available on your install disc). Aside from these
-directories, everything else on the server or disc has been installed on your
-system.
-Distributors of Slack Packages
-Slackware packages can be found elsewhere online, but you should make sure you
-trust the source of those packages, just as you would when considering
-installing applications on any other operating system.
-A few reliable places with good reputations:
-Recommended Slack Package Distributors
-AlienBob
-    slackware.com/~alien/slackbuilds is a repository of useful applications,
-    including Scribus, the OpenJDK Java dev kit and runtime, the Chromium web
-    browser, and the Opus audio codec. Not all of the applications he offers
-    are always terribly up-to-date, and some are, so take that into
-    consideration before deciding what you want to install from this server.
-    slackware.org.uk/people/alien/restricted_slackbuilds is a repository of
-    useful applications that include codecs or code that cannot be distributed
-    on USA-based servers. Most notably this includes VLC and HandBrake. Not all
-    of the applications he offers are up-to-date, and some are, so take that
-    into consideration before deciding what you want to install from this
-    server.
-Slacky.eu
-    slacky.eu is a long-standing and vibrant community of Slackware users in
-    Italy. The site has both 32-bit and 64-bit repositories with useful
-    software spanning all categories.
-    Not all of the applications offered here are up-to-date, and some are, so
-    take that into consideration before deciding what you want to install from
-    this server.
-Slackermedia
-    slackermedia.info/slackbuilds offers useful (and some not-so-useful)
-    packages, including JSampler, butt audio streamer, and most importantly the
-    Slackermedia-approved, everything-plus-the-kitchen-sink compile of ffmpeg.
-    Not everything is always up-to-date, but they are the versions of software
-    that the author of Slackermedia is using.
-Studioware
-    studioware.org/packages is full of current builds of all kinds of
-    multimedia tools. There are a wealth of new production toys to be
-    discovered here, so it will probably take you a few days to explore and
-    test what you find.
-    Not all of the applications offered here are up-to-date, and some are, so
-    take that into consideration before deciding what you want to install from
-    this server.
-rpm2tgz
-A useful command that can be used in conjunction with pkgtool is rpm2tgz, which
-converts a pre-built package for Red Hat or Fedora Linux into a slackpkg (ie, a
-.tgz file) that can then be installed via pkgtool. This is similar to finding a
-pre-built .tgz on any given software's download page, except that rpm files are
-ubiquitous to Linux package formats and the likelihood of finding a .rpm file
-often exceeds the likelihood of happening across a Slackware package.
-Once you've downloaded the .rpm file, use rpm2tgz to convert it:
-  # rpm2tgz foobar-x.x.xx.rpm
-The result is a .tgz file, so after the conversion is finished the original
-.rpm can be discarded and pkgtool can be used to install the .tgz file. You
-will need to ensure that the computer contains the dependency code for the
-application to function; this means that you might need to install other
-software before installing the application you really want to install. For
-instance, the Red Hat documentation tool publican offers an .rpm, but in order
-to install it there are about twenty perl modules that must be installed first.
-Warning
-The user should also trust the source of the package such that they can be sure
-there is no broken, disabled, or malicious code present.
-Source Code
-Slackware users often prefer to compile the software they install themselves;
-that is, they take the raw text files containing the application's raw code and
-process it through the GNU gcc compiler, and then move the executable result of
-this process into their system. This has a wide variety of advantages:
-  * It allows the user to control where the executable binary (the application)
-    is installed.
-  * It allows the user to enable or disable features of the application before
-    the application is built.
-  * It allows the user to optimize the application for a specific processor.
-  * It allows the user to review the code that goes into the building of an
-    application should the user wish to do so.
-  * It allows the user to change the code that goes into the building of an
-    application should the user wish to do so.
-  * It ensures the availability of applications to all users on any GNU, Linux,
-    or unix-like system; source code is universal in that if an application was
-    written for a GNU Linux system then it will compile and run on any GNU
-    Linux system regardless of distribution.
-The general process of compiling is in theory simple. Obtaining it is much like
-obtaining any downloadable software; you go to a website or a code management
-site (like Sourceforge or Github) and download the source code of an
-application. Typically, free software is available in both a work-in-progress
-("current" or "nightly") form as well as a packaged "stable" release version.
-Slackermedia reccommends, with few exceptions, downloading the stable version,
-which indicates that the code has been tested to some degree and that the
-programmers of the application feel confident enough in the code to package it
-into a .zip or .tar.gz or .tar.bz2 archive, give it an official number and
-sometimes a release name, and offer it for download to the general
-non-programmer public.
-Once the code has been downloaded, it is uncompressed, and a series of two or
-three commands are issued which starts GNU gcc, which compiles the code and
-then sends the binaries into the system (viz. it is "installed").
-How to Compile Software from Source
-Before you compile from source code, you should ask yourself why you are
-compiling from source code. The acceptable reasons are:
-  * You cannot find an existing Slack package or Slackbuild script for the
-    application you are about to compile. There are also no .rpm versions
-    available, or if there are, they do not install or work as required.
-  * You need new features found only in a fresh release. You have tried to
-    modify an existing Slackbuild script but it fails to compile the software
-    for you, so you want to give it a go yourself.
-    This can be difficult, because usually if an existing buildscript has been
-    broken by a new release, then the code has either changed so drastically or
-    else it (or its build system) are broken, and serious hacking will be
-    required. Still, it's free to try.
-  * You just want to build from source code.
-There is not just one way to compile software. There is the "usual" way
-(meaning the one that you see most often), but any programmer may choose a
-different method to manage how their software is compiled. The compilation
-itself is usually performed by the GNU C Compiler (gcc). The way that gcc knows
-what steps to take during the compile is with a Makefile, or some configuration
-list; that is, a document written in a syntax specific to the compiler, which
-informs the compiler what procedures and where to find supportive code to use
-while building the application. It may contain pointers to other code that is
-expected to already exists on the user's system, or to other parts of code
-within that application's project, and it may contain special instructions for
-installing the software after it has been built as well as instructions on how
-to uninstall that application should the user decide it is no longer needed.
-Note
-The source code downloaded may or may not include all of the code it actually
-requires to compile and run. If, for example, Developer Foo has developed code
-for a graphics application that requires heavily on Developer Bar's opus codec,
-a set of code that enables the computer to handle a particular audio format,
-then Developer Foo is obviously not going to distribute libopus along with the
-application's code, because libopus is maintained by Developer Bar. It is up
-the user, therefore, to read the README file (or similar) packaged along with
-Developer Foo's application and find out what other code is required to be
-present on the computer for Application Foo to work (this is called "dependency
-resolution") and what build system the project uses, and what steps must be
-followed for the code to compile as expected.
-The general steps in compiling code, abstracted away from any specific build
-system, are:
-. Prepare the build scripts for the exact configuration of your system.
-. Start the compiler to build the code, and then link that code to libraries
-    it needs in order to run.
-. Copy the new files to places that your operating system expects to find
-    them. Icons are moved to the system icon directory, documentation to the
-    system doc location, libraries to the system library path, executables to
-    one of the system's application directories, and launchers to the system
-    launcher location.
-Things can go wrong, of course, so here are common problems that arise in even
-a simple build.
-Common Compilation Problems
-configure, cmake, etc.
-    By far the most common problem during the configuration step are missing
-    libraries. If an application requires libfoo to compile (because the
-    developer has borrowed some code from libfoo, so counts on that library
-    being on your computer), and it cannot find it, then it is the job of the
-    configuration script to alert you.
-    The solution is to install the missing libraries, and then run the make
-    command again. If there is a make clean command, run it first to clear out
-    any progress prior to the error.
-    Another potential solution is to look at configuration options (usually
-    done by adding a --help flag to the configure command) to see if the
-    missing library is indeed absolutely necessary. Sometimes it is possible to
-    build without a library by using a flag like --without-libfoo or similar.
-    Of course, you would not want to do this arbitrarily; usually the correct
-    solution is to install the missing library.
-make, build
-    A problem during the actual compiling of code can mean that either the
-    configuration step made an error, or that there is an error in the code
-    itself.
-    If the configuration step made an error, then the compiler is likely
-    looking in the wrong location for libraries that it needs. This can usually
-    be solved by either manually correcting configuration files, or by
-    overriding configuration files with environment variables. Unless the
-    compiler error tells you what to look for, or you can debug the code
-    yourself, your best chance of fixing such a problem would be to do an
-    internet search on the error.
-    If there is a bug in the code that is preventing it from compiling, you can
-    either fix it (if you are a skilled programmer) or you can do an internet
-    search on the error to see if anyone else has encountered and fixed the
-    problem.
-make install, install
-    This step rarely fails, since all it should be doing is copying files to
-    your system. If it does fail, it is probably because you do not have
-    permission to write files to system folders. Re-try the command with root
-    privileges.
-The problem with compiling and installing source code in this traditional way
-is that tracking what you have installed is nearly impossible. Any given
-application might install several libraries, icons, sets of documentation, and
-binary executables. This makes it extremely difficult to accurately and safely
-update components of your system when, for instance, an application requires
-you to update multiple libraries which in turn are being used by other
-applications which may be effected by the update, and so on.
-For this reason, Slackware has a built-in method of wrapping up a compiled
-application as a custom-made Slack package: makepkg.
-Makepkg
-To use makepkg, you do need to understand what build system the developer is
-using so that you can redirect the install process (usually the final step,
-after the code has been compiled) to a directory of your choosing, rather than
-to the root of your system. Run makepkg on that directory, and you have a Slack
-package.
-Here is an overview of common ways of defining a new installation directory:
-Makepkg Interceptors
-Autotools
-    Autotools is a collection of tools within the GNU build tools. Being the
-    original freely-available build system in the world, it is by far the most
-    common.
-    To redirect an install, you run the usual commands, with one small addition
-    to the install command. Therefore the first two steps are the same as
-    always:
-                $ ./configure
-                $ make
-    The final step intercepts the default install path and forces automake to
-    treat a DESTDIR of your choosing as if it were the root of your filesystem:
-                $ mkdir /tmp/pkg-foo
-                ; make install DESTDIR=/tmp/pkg-foo
-    Move into the DESTDIR and use makepkg to create your Slack package:
-                $ cd
-                /tmp/pkg-foo
-                $ makepkg -l y -c n
-                /tmp//foo-version-$(uname -m)_SMi.tgz
-    You can store this Slack package somewhere for later use or for
-    re-distribution, and of course you can install it with installpkg.
-Cmake
-    Cmake is a build system that features a rich interactive GUI and a highly
-    customisable build environment. In practise, the difference between Cmake
-    and Automake is in the configuration step, so in practise using makepkg
-    with it is the essentially the same as with Autotools.
-    The first two steps are the usual cmake commands:
-                $ mkdir build ; cd build
-              ; cmake ..
-                $ make
-    The final step intercepts the default install path and forces automake to
-    treat a DESTDIR of your choosing as if it were the root of your filesystem:
-                $ mkdir /tmp/pkg-foo
-                ; make install DESTDIR=/tmp/pkg-foo
-    Move into the DESTDIR and use makepkg to create your Slack package:
-                $ cd
-                /tmp/pkg-foo
-                $ makepkg -l y -c n
-                /tmp//foo-version-$(uname -m)_SMi.tgz
-    You can store this Slack package somewhere for later use or for
-    re-distribution, and of course you can install it with installpkg.
-Python Distutils
-    Distutils is the default method for installing Python applications, since
-    it is the distribution tool that ships with Python itself. Generally, it
-    places all configuration and installation actions in a setup.py file. It
-    is, however, highly customisable, so be sure to read any docutmentation
-    about installation that the developer of the code provides.
-    To re-direct the destination of the installable files, use the --root flag
-    when launching the setup script.
-                $ python setup.py install
-                --root=/tmp/pkg-foo
-    Move into the DESTDIR and use makepkg to create your Slack package:
-                $ cd
-                /tmp/pkg-foo
-                $ makepkg -l y -c n
-                /tmp//foo-version-$(uname -m)_SMi.tgz
-    You can store this Slack package somewhere for later use or for
-    re-distribution, and of course you can install it with installpkg.
-There are many more build systems out there, and there is even the remote
-possibility that entirely custom install commands or no install commands could
-turn up. In the event of non-standard build systems, you have several options.
-You can read the documentation included with the code and attempt a build. If
-you can't figure out how to redirect the install process, you can choose to
-install without creating a Slack package; theoretically, that will be harder to
-uninstall or update, but it might be a trade-off worth making, depending on the
-application and how badly you want it. Finally, you can contact Slackermedia
-for assistance; we may be able to build a package for you (generally, this can
-be done for free, although if it is critical that a package is created
-promptly, or if the package proves difficult to build even for us, then we
-might have to provide you with a price quote in order to get the job done to
-your specifications).
-The good news is that many applications already have scripts that configure,
-compile, and create a Slack package for you. These are called Slackbuilds
-(because they are simply scripts that you run in order to automate the steps of
-compiling). The SlackBuild system allows you to get the best of both of worlds:
-the ability to compile from raw source code and transparently take the
-intermediate step of creating a Slackware Package that will be logged in /var/
-log/packages along with everything else installed on your system, but without
-doing any of the leg work. Slackbuild scripts are published in many places, but
-the largest repository of them is slackbuilds.org.
-SlackBuilds
-One of the hallmarks of Slackware is its SlackBuild system, a powerful yet
-easy-to-understand and easy-to-learn method of scripting how an application is
-built. The SlackBuild system enables the user to script exactly how
-applications are compiled so that the same SlackBuild can be used on a variety
-of computers (useful in a production studio) or from computer to computer after
-a major system upgrade has been performed. SlackBuilds result in .tgz files as
-well, so managing the applications after they have been compiled is as easy as
-using pkgtool.
-This essentially combines the best of both worlds: it allows the user to
-compile from source code and to enable all the options required for the
-application to work best for the user, but also feels like a pre-built package
-since it requires very little interaction from the user in order to be
-installed.
-Note
-There is a unixy beauty to this system in that there is really nothing
-distribution-specific to it, and nothing redundant about it. It consists simply
-of a shell script which can be easily hosted on minimal storage, quickly
-downloaded, and used by anyone. Consider for a moment .deb or .rpm files, which
-in their most popular and common forms literally contain compiled code of the
-software it intends to install. This means that the source code itself is
-hosted on the appliction's homepage, it is possibly then modified by the .deb
-or .rpm maintainer, so that the application is now stored in at least two
-separate locations (its source homepage and the repository containing its .deb
-or .rpm), it can be a hefty download, compiled without any involvement from the
-user, and installed without any involvment from the user. Such complexity is
-un-unix-like, but fortunately Slackware doesn't use this method, using instead
-build scripts that are clean and efficient.
-This system was so powerful that, for Slackware 11.0, a group of Slackware
-users decided to establish a community around it, which can be found at
-SlackBuilds.org. An advantage to slackbuilds.org is that hundreds of
-applications have had scripts built for them, which are all fully editable by
-the individual user so that the compiling options are exactly the way the user
-wants them. Each user can then either maintain their private repository of
-customized SlackBuilds or simply continue to use the Slackbuilds.org versions.
-All of the scripts are reviewed and tested by the Slackbuilds.org
-administrators but can also be reviewed in advance by the user for security and
-functionality.
-To use a Slackbuild:
-. Open a web browser
-. Search for, or navigate to, the tarball of the SlackBuild files and
-    download it.
-. On your local machine, navigate to the downloaded file and untar it.
-          tar -xzvf foo-sbo.tar.gz
-. Read the README and .info files to confirm that you have all the
-    dependencies installed. If you do not, repeat these steps for each
-    dependency, and install each in the order they are required.
-. Download the source code. A Slackbuild script is just that: a script. It
-    does not contain the source code for the application. The source code must
-    be downloaded from the source code's website.
-    If there is a stable version of the source code that is more recent than
-    what the Slackbuild was written for, you may change the $VERSION setting in
-    the Slackbuild script to match the new version number.
-. Move the source code tarball into the SlackBuild directory
-          mv foo-src.tar.gz foo-sbo/
-. Change directory into the SlackBuild directory.
-. Make the SlackBuild script to be executable.
-          chmod +x foo.SlackBuild
-. Run the SlackBuild, as root.
-          su -c './foo.SlackBuild'
-. Install the resulting package.
-          su -c 'installpkg /tmp/foo_sbo.tgz'
-Introduction to sbopkg
-Prior to the release of Slackware 12.1, a frontend to Slackbuilds.org called
-sbopkg was released. Sbopkg is a command-line and dialog-based tool to mirror
-the SlackBuilds.org repository and to operate on the local copy or to operate
-on a user's own repository of SlackBuild scripts. Sbopkg allows the user to
-browse the local copy, read associated ChangeLogs, view pertinent README files,
-read and modify the SlackBuild script itself, the .info file, and the
-slack-desc files. Sbopkg also allows the user to select packages to build and
-it will download the source code for the user, check the md5sum, and build a
-Slackware package. It will also optionally install the package onto the system.
-Sbopkg does not check or resolve dependencies. It does not automatically
-install packages. It does not track what has been installed. In other words,
-this is in no way apt-get or rpm for Slackware; it is a local front-end for
-Slackbuilds.org and does not duplicate or overlap the function of pkgtool or
-the responsibilities of the user as the primary manager of the system.
-To obtain sbopkg, visit sbopkg.org and download the Slackware package. Then,
-open a terminal and use either pkgtool or installpkg:
-$ su -c 'installpkg sbopkg-VERSION-noarch_1-cng.tgz'
-Among the files installed along with sbopkg, there is /etc/sbopkg/sbopkg.conf,
-which contains all pertinent configuration options for sbopkg. It is safe to
-use the default settings. To start sbopkg, launch it as root by typing su -lc
-sbopkg (The -l is to obtain the root environment some packages require).
-Upon first launch, sbopkg creates, as defined in the sbopkg.conf file, a local
-copy of the scripts available from slackbuilds.org in /var/lib/sbopkg/SBo/x
-(where x is the latest stable release of Slackware), a log in /var/log/sbopkg,
-a queue directory in /var/sbopkg/queues, a cache in /var/cache/sbopkg, and a
-local tmp directory called /tmp/sbopkg.
-After sbopkg has launched, the user is delivered to an ncurses interface; use
-the Up and Down arrow keys to navigate through the main menu, Return to make a
-selection, and the Right and Left arrow keys to select which button on the
-bottom of the menu (OK, Cancel, Back, etc) the Return key activates.
-The first step with sbopkg is to sync with the remote server; this is the top
-selection in the sbopkg main menu. This copies all available scripts from
-SlackBuilds.org and saves them into directories corresponding with the
-categories defined by SlackBuilds.org (academic, accessibility, audio, etc).
-This allows the user to browse the mirrored repository in sbopkg whether or not
-the user is online, and also modify the scripts before using them to install
-software.
-After the initial rsync, the user can view the SlackBuilds.org ChangeLog, which
-documents the most recent updates applied to the SlackBuild repository, whether
-these are bug fixes in the scripts or updated packages. A user may also
-subscribe to the SlackBuild user mailing list at http://lists.slackbuilds.org/
-mailman/listinfo/slackbuilds-users.
-A list of all SlackBuild packages installed on the user's system may be viewed
-via the Packages menu selection, which looks at /var/log/sbopkg and displays
-the packages installed whose tags match the currently active repo's tags (by
-default, _SBo). Similarly, selecting the Update menu item will compare
-installed packages to those available in the local mirror and identify any
-packages that have updates available.
-Finding a package to install is done with the Browse menu selection, or the
-Search selection. Browse takes the user to a list of top-level categories as
-defined by SlackBuilds.org; use the Return key to select a category and browse
-through the packages. Hitting Return again will display the details about a
-package, such as the README file, the SlackBuild script itself, and more. To go
-back in the list of packages or to the list of categories, use the Right arrow
-to select the Back button on the bottom row of sbopkg's interface, and press
-Return or type Alt+B. The convention of using the Up and Down arrow keys (or
-accelerators) for the top menu of sbopkg and the Right and Left arrows (or Alt+
-accelerator) for the bottom row is used throughout sbopkg, except in textbox
-dialogs where the arrows scroll the text.
-The search function in sbopkg works as would be expected: hit Return on Search
-to be taken to a pop-up search field, type in the term you are searching for
-(it is case-insensitive) and hit Return again. Sbopkg returns all packages
-matching the search term; i.e., if a search is performed for the term "ink"
-then sbopkg will return "link-grammar", "inkscape", "libnfnetlink", "elinks",
-"wink", etc. Common bash wildcard characters are also supported, such that a
-search for "?ink*" returns the same list minus "inkscape" which has no
-character prior to "ink".
-Building and Installing Software with Sbopkg
-Sbopkg can build and install software. These are two separate processes. If you
-elect to only build software, the resulting Slackware package (.tgz file) is
-left in /tmp by default. This location is controlled by the OUTPUT variable in
-the config file. It can then be installed via pkgtool or installpkg, or taken
-to other machines of the same architecture and installed on those, or simply
-stored for later use. Alternatively, sbopkg can be set to install the software
-after it has been compiled.
-Building and/or installing can be done from different places; the Build item is
-the final menu item on each individual package menu of unbuilt packages, and it
-is invoked with the Process Queue item in the Queue sub-menus. Sbopkg will
-prompt the user to perform only a build of the software or a build-and-install.
-Slackermedia recommends build-and-install for single or small groups of users
-in which compile time is not an issue; for building larger install bases, it
-may be more efficient to build once and install the resulting binary rather
-than having each computer compile it individually.
-To build or install a package via sbopkg, the first step should always be to
-view the README file. This displays a brief description of the application
-about to be installed, any options that may be passed to the SlackBuild, and
-any applications upon which the application depends (required dependencies can
-always be found on SlackBuilds.org). Sbopkg does not automatically resolve
-dependencies so it is up to the user to ensure that all listed dependencies are
-installed on the system before proceeding. READMEs can be viewed from various
-places, including selecting Queue ? Process ? View READMEs when using the
-dialog interface or using the -R flag from the command line.
-Assuming, for the purpose of this example, that there are no dependencies, the
-next step might be to view the .info file, which is a SlackBuilds.org-specific
-file of metadata which lists the canonical program name, the version for which
-the SlackBuild script was written, the project's homepage, the exact link where
-the source code for the program can be downloaded, the md5sum of that
-downloadable package, the SlackBuild script's maintainer's name and email, and
-the SlackBuilds.org administrator who approved the script.
-Next, the SlackBuild script itself can be reviewed. Although all SlackBuild
-scripts have been reviewed and tested by SlackBuild maintainers, it is a good
-idea to review the script, both for security purposes as well as to ensure that
-the application is going to be installed the way the user thinks it's going to
-be installed. There are some scripts that feature options that the user can
-take advantage of (like turning off or on codec or plugin support), while other
-scripts simply help elucidate optional components that the application will use
-if available but that are not dependencies themselves. Other applications
-feature an unusual build process such that a SlackBuild script may be more
-convenient for most users but a disadvantage to a user who relies on that
-program and would be better off installing directly from the project's code
-repository.
-If additional options are available in the SlackBuild script, the user's local
-copy of the script and/or .info file can be edited from within sbopkg by
-selecting the Custom menu item. This will open the SlackBuild script in the
-user's text editor of choice (defined by the EDITOR environmental variable).
-For example, if the SlackBuild script for LiVES was written for version 1.1.8
-but a new version of LiVES has been released and a user wishes to install the
-newer version, all that is required of the user is that the version number be
-changed from 1.1.8 to, for instance, 1.2.0 (making the corresponding changes to
-the .info file's VERSION and DOWNLOAD fields). The script can be saved and run
-in sbopkg and the correct version of LiVES would be downloaded, compiled, and
-optionally installed.
-Any change can be made to a SlackBuild script in this way, whether the user
-wishes to hard code a unique feature into the script, or define a variable that
-is described in the README file, update the version number, modify build paths,
-and so on. If the only thing that is desired is to set a build option, however,
-this can be done by selecting the Options item and typing OPTION=value ? in the
-entry field. While editing the SlackBuild is a persistent change, the edited
-version would have to be kept in sync with version changes which happen often.
-Using custom options also persists but only needs to be kept in sync with
-option changes which happen rarely. Changing a SlackBuild script, of course,
-requires at least some very basic knowledge of bash scripting and the
-installation process. It may be that a software package has changed
-substantially from one version to the next and so a simple update of the
-version number may not be all that is required, so if a user is opening a
-SlackBuild script for modification then the user should truly understand what
-is being done in the script, or be prepared for the build to potentially fail.
-The Sbopkg Queue
-One of the most powerful features of sbopkg is its queue, which makes it
-possible for a user to create a list of packages to have installed in a
-particular order and use the list on other computers. Slackermedia makes
-extensive use of queue files to co-ordinate which packages should be installed
-as a basis for a good multimedia system. From the main sbopkg menu, select
-Queue and press Return. The Queue menu contains items to view the current
-queue, to modify the queue, load an existing queue, save a queue, rename or
-delete existing queues, add all installed packages to the queue (for creating
-package templates to enable restoration of the current package list or to
-transfer to another machine), and to process the current queue.
-A queue is created from the sbopkg GUI by finding a package via either Browse
-or Search and selecting Add to Queue. This adds the package to a temporary
-session-only queue file.
-A typical use for this would be, for instance, when installing Inkscape. Doing
-a search for Inkscape reveals that there is a SlackBuild available, but that it
-depends on a number of other packages such as pangomm, cairomm, and others.
-Adding Inkscape to the queue allows the user to then go seek out SlackBuild
-packages for Inkscape's dependencies and either install them one by one, or add
-them to the queue as well. If they are added to the queue, then obviously the
-queue will attempt to install Inkscape before it installs the dependencies, so
-there are special functions in the Sort Queue submenu of sbopkg's Queue menu to
-either manually rearrange the order of the queue, or simply reverse the queue
-such that it is processed in reverse order. A simple reversal of the queue
-sometimes does work, but it may be insufficient since a dependency of one
-application may have its own dependencies which may require manual re-ordering
-to do subsorts in the queue. Alternatively, queuefiles can be created and
-edited with a text editor.
-The Queue menu is accessed from the main sbopkg menu by selecting Queue and
-contains items to view the current queue, which is dynamically created by the
-user during an sbopkg session and will be erased (unless saved) when sbopkg is
-stopped. The Sort item allows the user to reorder the list of applications in
-the queue while Remove allows the user to delete items from the queue. Save
-allows a queue file to be saved to the harddrive for later use; this is useful
-when doing multiple installs of Slackware on a number of machines; a queue file
-can be used on each machine so that the same packages are installed with
-minimal effort. By default, queue files are saved in /var/lib/sbopkg/queues.
-To load a pre-existent queue file into sbopkg, select Queue ? Load and check
-the desired queuefile(s) in the list. To run a queue file, select Process Queue
-from the Queue menu.
-For example, if you have downloaded the av queue file from Slackermedia, then
-to load it into sbopkg, simply invoke sbopkg as QUEUEDIR=/path/to/dir/
-containing/queuefile sbopkg and it will appear in the checklist and can be
-checked as usual. The queue file would then be loaded into sbopkg and you can
-view it, modify it, remove or reorder applications, and finally process it.
-Advanced Uses of sbopkg
-Sbopkg can also be used directly from the command line. Its options can be
-listed with sbopkg -h and details can be found via its manual page (man sbopkg
-), but the most direct and simple command is (to use the earlier example) su
--lc 'sbopkg -i av' which will search for an application or queue file called
-"av" and install it (if an application) or the programs in it (if a queuefile).
-If both a program and queuefile exist with the same name, you'll be prompted to
-specify which. If a queuefile is intended, specifying the .sqf extension will
-avoid the prompt. If you know the name of an application and feel confident
-that you you have met all its dependencies (or can meet them all within the
-same command), this is probably both easier and simpler than loading sbopkg's
-graphical environment.
-Other command line options include causing sbopkg to rsync to slackbuilds.org,
-building without installing, diverse search options, viewing changelogs, and so
-on.
-It is also possible to maintain a local repository of customized SlackBuilds
-rather than, or in addition to, synchronizing with SlackBuilds.org. The local
-repository is stored in /var/lib/sbopkg/local by default and can be made active
-by either selecting it from Utilities ? Repository or by invoking sbopkg as
-sbopkg -V local. Additionally, the location of the sbopkg repository can be
-defined in the /etc/sbopkg/sbopkg.conf file. If necessary, you may also pass
-the -d flag to specify an alternate directory for SlackBuilds repositories or
-by maintaining two configuration files, since sbopkg can be passed an alternate
-configuration file (sbopkg -f FILE) on the command line.
-sport
-Sport, the "Slackware Port" system, is a simple shell frontend to
-Slackbuilds.org. It is meant to be simpler and less interactive than sbopkg,
-and instead emulate the BSD port system, or Gentoo's emerge.
-Like other Slackware package installation applications, sport is not a package
-manager. However, it does help you search through your collection of
-SlackBuilds, read relevant files about each SlackBuild, and then execute the
-build and install processes.
-Note
-Since the most prolific and uniform collection of SlackBuilds is
-SlackBuilds.org, and since Slackermedia is so heavily reliant upon
-SlackBuilds.org, sport was largely modeled after the structure of SB.o,
-although it is not restricted to it and technically will work with any
-collection of builds (such as your own personal collection of modified builds,
-or those of trusted associates).
-To install sport, download its source code and use sport to install sport (yes,
-you can use sport to install itself):
-  $ git clone gitorious.org/slackport/sport.git sport.git
-  $ cd sport.git
-  $ su -c
-  './sport install .'
-To use sport, you must have a local repository of SlackBuilds. Since
-Slackermedia relies heavily upon slackbuilds.org, it is worth while to pull the
-entire listing of SlackBuild scripts from the site:
-  $ su -c 'mkdir -p /usr/ports'
-  $ su -c 'rsync -av rsync://slackbuilds.org/slackbuilds/$(awk '{print $2}' /etc/slackware-version)/ /usr/ports/'
-If you want to use sport and sbopkg on the same system, you should use the same
-location that sbopkg uses (or else use the sport location for sbopkg). An
-example of the former:
-  $ su -c 'mkdir -p /var/lib/sbopkg/SBo/$(awk '{print $2}'
-  $ su -c 'rsync -av rsync://slackbuilds.org/slackbuilds/$(awk '{print $2}' /etc/slackware-version) /var/lib/sbopkg/SBo/xx.x/'
-Before you can use sport, you must set the location of your local SlackBuild
-repository. Open /etc/sport.conf and edit the SBOPATH and MASTER variables. For
-example, assuming xx.x is your version of Slackware:
-    SBOPATH=/usr/ports
-    MASTER="rsync:?/slackbuilds.org/slackbuilds/xx.x"
-There are a few different ways to use sport, but it was written with BSD Ports
-in mind, so its intended workflow mimics the way that the BSD Handbook guides
-users through the intended usage of their Ports system.
-In general, the workflow would be:
-. Search for a term or package name that you want to install
-. Read about the package you find in order to learn about what libraries and
-    other applications it depends on, as well as any important build notes
-. Download, build, install
-These tasks are each individual commands within the sport toolset. For each
-flag, you can use every common convention for switches. For example, these
-would all do the same thing:
-  * sport --search foo
-  * sport search foo
-  * sport s foo
-  * sport -s foo
-Sport Walkthrough
-The first step in the workflow is to find what you want to install. If you only
-have an idea of what you want, then you'll want to search for matches to some
-keyword:
-    # sport search foo
-    network/emacs-foo.tar.gz ... emacs-foo
-    (simple Emacs interface of foo)
-    network/foo.tar.gz ... foo (text based web
-    browser and pager)
-The search function of sport performs a fuzzy search on any term you provide. A
-search for "foo" therefore returns the category and packages names for both the
-stand-alone foo and the Emacs foo mode.
-Note
-If you only want to browse through your SlackBuilds tree without having to
-think up search terms, cd into /usr/ports (or whatever you have set SBOPATH to)
-and browse its contents.
-If you find something of interest but want to see if you already have it
-installed, use sport check:
-  # sport check foo
-If nothing is returned, then you do not have that application installed.
-The next step in the typical workflow is to read about the package you are
-about to install, so that you know about any important build configuration
-options, or dependencies that you should install first. Use sport cat to see
-all relevant notes in a SlackBuild. If the package search returned only one
-match, then you can use just the packagename, but if there were multiple
-matches then you should provide both the category and package name:
-  $ sport c net*/foo
-If you have changed directories into your SlackBuild tree and are in the same
-directory as the SlackBuild file, you can cheat and provide the path to the
-package with a dot-slash:
-  $ sport cat ./foo
-Or if you are in the SlackBuild's directory, just use a dot.
-  $ sport cat .
-This displays the README and the .info files of the package, so that you can
-see what the application claims to do, and what dependencies are recommended
-and required.
-If the package you want to install has dependencies, you should resolve those
-dependencies before continuing. Unlike the BSD Ports and Gentoo emerge systems,
-sport does not resolve dependencies for you. That way, if you have already have
-a package or a SlackBuild for a dependency (or you prefer to compile it
-yourself), you can use it instead of whatever an automated "package manager"
-happens to find lying around.
-Note
-"Resolving dependencies" may sound mysterious but all it means is that you will
-have to install some additional system libraries or smaller applications before
-you install the application you are trying to obtain. To resolve the
-dependencies of foo, you would take note of the libraries it requires (bar and
-baz) and then use sport to install each one before then installing foo itself.
-Once you have resolved all dependencies, you are ready to build the package.
-There are two commands you can use; sport install will build the package and
-install it onto your system (leaving a copy of the finished Slack package in
-the default build location for SBo packages: /tmp), while sport install
---build-only only builds but does not install the package.
-  # sport install foo
-Again, if you are in the directory containing the SlackBuild you want to
-install, you can cheat and provide the path to the package with a dot, meaning
-that the build script is in the current directory:
-  # sport -i .
-If you are fastidious about disk space or keeping a tidy SlackBuilds tree, use
-sport clean foo to remove the directory containing the source code and
-SlackBuild. It of course leaves any compressed copy of your SlackBuild
-directory (the SlackBuild.org structure).
-Warning
-If you are not using the SlackBuild.org tree, then you should either keep your
-originals as compressed .tar.gz archives or you should either modify or not use
-the clean command.
-As you can see, sport may be used from anywhere in your filesystem, or you can
-use it as you "crawl" through your SlackBuild tree. It's a handy and flexible
-tool that can help make the potentially repetitious process of downloading,
-compiling, and installing software easier.
-Advanced Sport Usage
-Since sport is just a BASH script, you can use the usual BASH conventions to
-add flexibility to your commands.
-To pass build options through sport, provide the option (usually defined in the
-README of the SlackBuild).
-  # WIDGETS=yes sport install foo
-To pass make flags through sport, use MAKEOPTS.
-  # MAKEOPTS='-j8' sport install foo
-If you need to do some special kind of install (such as an upgradepkg rather
-than an installpkg) then preface your sport -i command with the INSTALLER
-environment variable:
-  # INSTALLER=upgradepkg sport i .
-Or something more complex:
-  # INSTALLER="upgradepkg --install-new" sport -i multi*/foo
-And so on.
-Queue Files
-Sport supports batch, or queue, files.
-For your initial Slackermedia install actions, you will use a Slackermedia
-queue files (slackermedia-huge.sqf, for example) but you can also create and
-maintain your own queue files. To create your own queue, just echo the package
-names into a plain text file, newline delimited, in the order you wish for them
-to be installed.
-Note
-In the event of two packages sharing the same name, use both the category and
-package name, but usually just the package name will do.
-Here is an example of a simple queue file for foo:
-baz
-bar
-foo
-Save these three lines as foo.list (or any filename) and then have sport
-process it using standard BASH re-direction:
-# sport $( < foo.list)
-For full details on using sport, view the man and info pages bundled with it.
-, the typical process for installing applications on Slackware is:
-. Learn about an application from Slackermedia, other Linux multimedia sites,
-    Linux multimedia distributions, and your own research.
-. Look for an install script for the application on slackbuilds.org. If
-    available, install.
-. Look for the application on another trusted site such as:
-      + slackermedia.info/slackbuilds
-      + slacky.eu
-      + slackware.com/~alienbob/slackbuilds
-      + ccrma.stanford.edu/planetccrma/software (for use with rpm2tgz)
-. Install the application.
-In some cases, it might be preferable to compile an application yourself.
-Compiling software, second only to compiling a custom Linux kernel, is often
-discouraged by proponents of a so-called "user friendly" system. They assert
-that a truly user friendly system is already set up and configured for the
-user, ignoring that the user may want something completely different than what
-the system designer has given them. GNU Linux makes no such assumption, leaving
-you free to compile your own software so that it does what you want it to do,
-and then to configure the applications so that you may interact with them the
-way you want to.
-The preferred method to compile software on Slackware is the same way that
-Patrick Volkerding, founder and maintainer of Slackware, does in releasing
-Slackware: using SlackBuilds. If you have a SlackBuild script do the compiling
-and installation for you, then you will have a permanent record of everything
-that has been installed on your system, and an upgrade path in the event that
-you need to update what has been installed.
-You don't have to be a programmer to leverage SlackBuilds. Many of the
-applications that you will use on Slackermedia already have SlackBuilds written
-for them, available on SlackBuilds.org. Therefore, even a novice can download a
-SlackBuild script, modify a few fields, build and install, and end up with an
-up-to-date version of an important application.
-If you want to modify a SlackBuild:
-. Locate and download the existing SlackBuild. This is often delivered as
-    foo.tar.gz and contains the SlackBuild script itself, a README, a .info
-    file, and possibly a few other files. It does not include the source code
-    for the application it is designed to build.
-. Next, locate and download the latest stable version of the application you
-    want to build. Place the downloaded file (usually a .zip or .tar.gz or
-    .tar.bz2 file) in the SlackBuild folder.
-. If the SlackBuild you are using was written for foo-1.0.tar.bz2 but you
-    need to compile foo-2.0.tar.bz2 because you need support for a fancy new
-    plugin, or you want to add in codec support that was missing from 1.0, then
-    you probably only need to change one thing in the SlackBuild.
-    Open the .SlackBuild file in a text editor and locate the line in the
-    script that defines the VERSION number. Change the version number to the
-    exact version number provided in the filename of the source code download
-    (in this example, 2.0 rather than 1.0) and save and close the document.
-. Build and install with your customized SlackBuild as usual.
-            #
-            ./foo.SlackBuild &&
-          installpkg /tmp/foo*2.0*t?z
-Most modifications to applications can be done with simple SlackBuild
-modifications, so don't be afraid to open up the SlackBuilds that build your
-software and try out some simple customizations.
-If there is no existing slackbuild script, then you will need to compile from
-source code manually, and use makepkg to create a package.
-The rest of this handbook contains instructions on how to build some
-applications from source code, how to install from alternate providers, and an
-overview on how to use each application. It is not all-inclusive or a complete
-manual for each application, but it does provide a general sense for what is
-available for Linux. It should serve as a launchpad for further exploration,
-not a definitive guide.
-Have fun!