Friday, November 8, 2013

Slackware 14.1 is released!

After over a year of development (including the beta release and several release candidates to get everything polished up) we're proud to announce the availability of the new stable release. You'll find updates throughout the system, with the latest compilers and development tools, and recent versions of applications, window managers, desktop environments, and utilities. The Linux kernel is updated to version 3.10.17 (part of the 3.10.x kernel series that will be getting long-term support from the kernel developers). The x86_64 version of Slackware also adds support for installing and booting on systems running UEFI firmware.For additional information, see the official announcement and the release notes. For a complete list of included packages, see the package list.
Build scripts for all kinds of additional software for Slackware 14.1 can be found on the slackbuilds.org website.
Need help? Check out our documentation site, docs.slackware.com. Stop by and share your knowledge!
Please consider supporting the Slackware project by picking up a copy of the Slackware 14.1 release from the Slackware Store. The discs are off to replication, but we're accepting pre-orders for the official 6 CD set and the DVD. The CD set is the 32-bit x86 release, while the DVD is a dual-sided disc with the 32-bit x86 release on one side and the 64-bit x86_64 release on the other. Thanks to our subscribers and supporters for keeping Slackware going all these years.
Thanks to the Slackware team for all the hard work getting 14.1 ready for action! And of course, thanks to all the open source developers upstream, and to the Slackware community on linuxquestions.org for all the help with bug reports, suggestions, and patches. We couldn't have done it without you.
Enjoy the new stable release!
Pat and the Slackware crew
+--------------------------+
Slackware 14.1 for ARM is also available. For details, see:http://arm.slackware.com

Tuesday, July 16, 2013

Slackware Linux is 20 years old!

Slackware Linux is 20 years old!



Slackware Linux 1.00 (16 July 1993)

   From: Patrick J. Volkerding (bf703@cleveland.Freenet.Edu)
   Subject: ANNOUNCE: Slackware Linux 1.00
   Newsgroups: comp.os.linux
   Date: 1993-07-16 17:21:20 PST

 The Slackware Linux distribution (v. 1.00) is now available for
 anonymous FTP. This is a complete installation system designed for
 systems with a 3.5" boot floppy. It has been tested extensively with
 a 386/IDE system. The standard kernel included does not support SCSI,
 but if there's a great demand, I might be persuaded to compile a few
 custom kernels to put up for FTP.

 This release is based largely on the SLS system, but has been enhanced and
 modified substantially. There are two main disk series, A (13 disks) and
 X (11 disks). Some of the features:  

 Series A:
   About what you'd expect from SLS series A, B, and C. Plus:
   Source for the Linux DOS emulator version 0.49.
   The FAQ for kernel level 99pl10.
   Kernel source and image at .99pl11 Alpha.
     [compiled with these options: math emulation support, normal hard drive
     support, TCP/IP, System V IPC, -m486, minix fs, ext2 fs, msdos fs, nfs,
     proc support, and PS/2 style mouse support. You may need to recompile if
     you have some other type of busmouse. The kernel was compiled with libc
     4.4.1, g++ 2.4.5]
   The new keytable utilities.
   The NET-2 networking package, preconfigured to use loopback.
   A public domain version of ksh, and tcsh 6.04 (with the bugs worked out)
   GNU gcc, g++, and Objective-C at versions 2.4.5
   Includes and libraries at version 4.4.1
   mailx, quota utilities, experimental winapi source, sound drivers.
   The TCL toolkit and samples.

   In addition, the installation program has been improved to offer more
   information about the packages (and the installation procedure itself)
   as you install.

   The install program can also automatically install LILO, configuring it
   to boot either from your master boot record or from OS/2's Boot Manager.

 Series X:
   Also, all the packages you would get in the SLS X series, plus:
   XFree-86 version 1.3.
   Open Look Virtual Window Manager made the default window manager.
   XS3 server offers support for S3 based video cards.
   XV 3.00 Image viewer is included.
   PEX files from the XFree-86 distribution are included.

 Although TEX support is not included in the Slackware release, the you may
 install the SLS T series from the install program.

 At this point, the install disk itself is running .99pl8. I'm working on it :^)
 Also, installation from other than a 3.5" floppy has not been tested, but might
 work. 5.25" floppy will not work because of file sizes. At this point, I have
 no plans to support a 5.25" version.

 How to get the Slackware(tm) release:

 The Slackware release may be obtained be anonymous FTP from
 mhd3.moorhead.msus.edu in directory /pub/linux/slackware. At least initially,
 this release will be in the form of 3.5" disk images which should be copied
 to floppies using the RAWRITE.EXE program, or dd under Linux.

 Please note that our FTP software does not support limiting the number of
 concurrent anonymous logins. PLEASE try to go easy on this machine. If things
 get out of hand, access may be restricted.

 Other sites are, of course, welcome to help out with the load by mirroring
 the distribution.

 If you find any problems with the distribution, or if you have any suggestions
 for improvements, please let me know. If you know of more up-to-date versions
 of software in the distribution, I'd like to hear about that, too.

 --
 Patrick Volkerding
 volkerdi@mhd1.moorhead.msus.edu
 bf703@cleveland.freenet.edu

http://www.slackware.com/announce/1.0.php

Friday, July 5, 2013

Ten reasons to choose Slackware Linux (by Niki Kovacs)

This summer, the Slackware Linux distribution will celebrate its twentieth anniversary. Patrick Volkerding's official release announcement for Slackware 1.0 on July16th 1993 is still online. Read it here.

Here's a list of ten reasons why Slackware is still the perfect choice on servers, desktops and workstations.
  1. Experience. Slackware is the oldest surviving Linux distribution, it's been around even before Debian and Red Hat. There's a famous Nutella ad in France: Twenty years of experience make all the difference. The same thing applies to Slackware. The odd critic may have been pointing out the fact that Patrick Volkerding's favourite hobby is blindfolded jogging in front of buses. In the meantime, he's managed to avoid them all, and Slackware is here to last.
  2. Perennity. The Slackware installer and the collection of basic administration tools remain the same proven tools that have been shipping over the years. Which means that if you're a system administrator, you won't have to relearn your basic skills from scratch every time a distributor decides on a whim to switch init systems like he would change his underwear. Changes to the distribution only happen in small incremental steps and without drama, like the addition of slackpkg to Slackware 12.2. Some folks like to complain that Slackware tools like the installer or the package management tools are bone-headed dinosaurs. Remind them curtly that it still takes a meteor strike to wipe them. 
  3. Stability. Only proven and tested software gets added to a release. One thing you'll never find in Slackware is the unholy collection of half-assed technology previews sported by the more popular distributions, which tend to make your admin's life a misery.
  4. Flexibility. As an admin, I have a pretty good idea of what I want on a LAN server, on a public server or on a desktop. Unfortunately, no canned distribution ships these configurations out of the box. But Slackware is pretty much the only distribution that doesn't make me jump through burning loops to simply configure things like I want to configure them. 
  5. Flexibility (cont'd). If a package is not included in the distribution, I can be pretty sure SlackBuilds.org has a build script for it. Otherwise, I'll just write one myself. Right now I have a collection of about 140 extra packages, and every single one built just fine. No distribution makes building stuff from source so easy.
  6. Simplicity. I often install desktops and workstations on old and/or exotic hardware, and Slackware lets me configure the more problematic stuff where the usual suspects among the installers just choke on it. The KISS principle reveals its full strength here, the more so since you won't find any DO NOT EDIT THIS BY HAND nonsense in Slackware.
  7. Humanity. I know, this is a word the Ubuntu folks claim for themselves, but one of the things I like about Slackware is its human size. Small distro, not too many packages, but carefully tendered. Folks in the Slackware forum at LinuxQuestions.org are a nice and competent crowd, and I like the general tone and no-bullshit attitude. Plus, the average Slackware user doesn't have the GNU/Linux taliban touch to it, which you see all too often here in France. Last but not least, Ubuntu is an old african word meaning I can't configure Slackware :o)
  8. Transparency. This one's obvious, but one less obvious factor is that it makes Slackware a great tool for actually learning Linux. Earlier this year, I've been teaching a class of ten sysadmins, and most of the course was based on Slackware.
  9. Efficiency. My Xfce-based desktop runs great on twelve year old hardware, and that's something I could only achieve with Debian or a handful of lightweight distros like Puppy or Slitaz, but not with the mainstream stuff like Ubuntu or openSUSE.
  10. Release policy. Slackware Linux pushes out a new release roughly once a year, when it's ready. Every release gets security updates for at least five years. Which makes Slackware perfectly fit for your business. 
Source: http://www.kikinovak.net/index.php?post/2013/06/10/Ten-reasons-to-choose-Slackware-Linux

Thursday, May 2, 2013

NetworkManager: A new option for the Slackware Linux network configuration!

Wicd (in "/extra" directory) is a good option for managing network connections. Until Slackware Linux 14.0 release, it was the only official graphical network configuration service option for managing the network connections besides the traditional CLI (Command Line Interface) based manual configuration. Together with the Slackware Linux 14.0 release, a Network Manager (NetworkManager) was integrated to the main tree of the release for easy setup and management of wired and wireless networking retaining full support for the traditional Slackware Linux networking scripts and for the wicd network manager. 



Before configuring network connections, open a terminal emulator and become root by,

$ su 

The NetworkManager daemon will not be started by default at boot, because the other network management options are still retained and users may want to prefer them instead of the NetworkManager. To start the network daemon automatically at boot, make the NetworkManager initialization script executable by using below command.

# chmod +x /etc/rc.d/rc.networkmanager

Start the NetworkManager daemon manually by,

# /etc/rc.d/rc.networkmanager start

or

# NetworkManager

The NetworkManager will appear in system tray by default even without starting the NetworkManager daemon, but you need to start the NetworkManager daemon for configuring the network connections.

Slackware Linux 14.0 comes with KDE widget for the Network Manager. Graphical configuration part of this guide is completely valid for the KDE.


Click on the NetworkManager icon in system tray. 


Make sure that "Enable networking" and "Enable wireless" boxes are checked and click on the "Manage Connections" tab on the right side. 


Click on the "Add" button.


Rename the wired connection, check the "Connect automatically" box (this will provide an automatic network connection on every login) and click on the "OK" button.


Click on the "OK" button.



Click on the "NetworkManager" icon in system tray.



Click on the wired connection you named previously on the right side and wait until the wired connection to be established.


Now, you are successfully connected to the wired network. To connect a wireless network, click on the WLAN interface tab on the left side. Then, SSIDs (names of the wireless networks) in the coverage of your WLAN network adapter will be listed.


Click on the SSID of the wireless network you want to connect.


Check the "Connect automatically" box (this will provide an automatic network connection on every login), enter the security password and click on the "OK" button.


Click on the "NetworkManager" icon in system tray.



Click on the wireless connection you configured previously on the right side and wait until the wireless connection to be established.


Now, you are successfully connected to the wireless network. 


NOTICE: If you are using XFCE, Slackware Linux 14.0 full installation includes NetworkManager applet (nm-applet) that works well under the XFCE. After initializing the NetworkManager daemon and relogging on, applet icon will appear in the system tray of the XFCE. Configuration GUI (Graphical User Interface) of the applet differs slightly from the KDE NetworkManager widget.  


Friday, March 8, 2013

Slackware Linux Graphics v1.3

Slackware Linux Graphics Project aims to provide a set of visual components related to GNU/Linux Slackware in both vector and raster graphics formats for its users. Source SVG graphics and exported PDF and PNG graphics in the project were all generated by using Inkscape under the GNU/Linux Slackware. 

Thanks to contributors for getting v1.3 ready!


http://slackware-linux-graphics.blogspot.com

VERSION:

1.3

DATE:

08/03/2013

FILE INDEX AND CHANGELOG: 

Version 1.3

* Slackware.Linux.Domed.Tux.Logo
* Slackware.Linux.Eggstone.Tux.Logo
* Slackware.Linux.Power.Button.Logo
* Slackware.Linux.Power.Button.Logo.with.It.powers.up.freedom
* Slackware.Linux.Classic.SuperTux.Logo.with.Pelerine
* Slackware.Linux.Crystallized.SuperTux.Logo.with.Pelerine
* Slackware.Linux.Classic.SuperTux.Logo.without.Pelerine
* Slackware.Linux.Crystallized.SuperTux.Logo.without.Pelerine
* Slackware.Linux.Superman.Logo
* Slackware.Linux.GNU.Logo.with.Classic.Tux
* Slackware.Linux.GNU.Logo.with.Crystallized.Tux
* Slackware.Linux.System.Case.Sticker.Logo
* Slackware.Linux.GNU.Linux.Slackware.Three-digit.Black.Logo
* Slackware.Linux.GNU.Linux.Slackware.Three-digit.Grey.Logo
* Slackware.Linux.Traditional.Logo.with.Classic.Tux
* Slackware.Linux.Traditional.Logo.with.Crystallized.Tux
* Slackware.Linux.Traditional.Logo.with.Domed.Tux
* Slackware.Linux.Traditional.Logo.with.Eggstone.Tux

Version 1.2

* Slackware.Linux.Phear.the.Penguin.Logo.with.Classic.Tux
* Slackware.Linux.Phear.the.Penguin.Logo.with.Crystallized.Tux
* Slackware.Linux.Classic.Tux.Logo
* Slackware.Linux.Crystallized.Tux.Logo
* Slackware.Linux.Download.Logo
* Slackware.Linux.ARMedslack.Logo
* Slackware.Linux.ARMedslack.Logo.with.Home.Page
* Slackware.Linux.slackARM.Logo
* Slackware.Linux.slackARM.Logo.with.Home.Page
* Slackware.Linux.slack390.Logo
* Slackware.Linux.slack390.Logo.with.Home.Page
* Slackware.Linux.Powered.Logo.with.Classic.Tux
* Slackware.Linux.Powered.Logo.with.Crystallized.Tux

Version 1.1

* Slackware.Linux.KDE.Logo
* Slackware.Linux.XFCE.Logo
* Slackware.Linux.Documentation.Project.Logo
* Slackware.Linux.Traditional.Logo.v2
* Slackware.Linux.Bag.Badge.Logo.v2
* Slackware.Linux.Current.Branch.Logo
* Slackware.Linux.Current.Branch.Logo.v2
* Slackware.Linux.Current.Branch.Logo.v3
* Slackware.Linux.Current.Branch.Logo.v4

Version 1.0

* Slackware.Linux.Traditional.Logo
* Slackware.Linux.Traditional.Logo.with.Home.Page
* Slackware.Linux.Traditional.Logo.with.Because.It.Works
* Slackware.Linux.Traditional.Logo.with.Because.It.Secures
* Slackware.Linux.Traditional.Logo.with.Tux
* Slackware.Linux.Spherical.Logo
* Slackware.Linux.Blurred.Spherical.Logo
* Slackware.Linux.Favicon.Logo
* Slackware.Linux.Bag.Badge.Logo
* Slackware.Linux.Security.Shield.Logo

Saturday, March 2, 2013

How to compile the 9th long term supported stable linux kernel release 3.4.x under Slackware

https://www.kernel.org

The Linux Kernel Archives home page with a new theme!

Today, I noticed that the Linux Kernel Archives home page has changed. A new theme with freshened up view totally reflects today's design approach.

How to compile the 9th long term supported stable linux kernel release 3.4.x under Slackware

Kernel version 3.4.x is the 9th long term supported stable kernel release maintained by Greg Kroah-Hartman. According to e-mail posted from him to the linux kernel mailing list, kernel version 3.4.x release will be supported at least two years from the date 20th of May 2012 on which kernel version 3.4.x released.

NOTE: Latest stable version of 3.4.x kernel was 3.4.34 at the time when writing this guide. Before starting the kernel upgrade process, please check the Linux kernel home page at "https://www.kernel.org/" and then replace 3.4.34 with the latest 3.4.x version number. In this guide, upgrade from kernel version 3.4.33 to 3.4.34 was explained. For the latest kernel release compilations, replace the version numbers with the correct version numbers for the day you would like to compile latest 3.4.x Linux kernel.

To begin with, open a Linux terminal emulator as user and become superuser.

$ su

Change current directory to "/usr/src/", download kernel source and signature archive files.

# cd /usr/src/

# wget https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.4.34.tar.xz

# wget https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.4.34.tar.sign

Extract compressed kernel source archive and verify it.

# unxz -v linux-3.4.34.tar.xz

# gpg --verify linux-3.4.34.tar.sign

Output will be something like below:

gpg: Signature made Fri 09 Dec 2011 12:16:46 PM EST using RSA key ID KEY_ID
gpg: Can't check signature: public key not found

Copy KEY_ID and paste into following command.

# gpg --recv-keys KEY_ID

Output will be something like below:

gpg: requesting key KEY_ID from hkp server subkeys.pgp.net
gpg: key KEY_ID: public key "Abc Xyz
     (Linux kernel stable release signing key) " imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   3  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: depth: 1  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 1f, 0u
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

# gpg --verify linux-3.4.34.tar.sign

Output will be something like below:

gpg: Signature made Fri 09 Dec 2011 12:16:46 PM EST using RSA key ID KEY_ID
gpg: Good signature from "Abc Xyz
     (Linux kernel stable release signing key) <abc@def.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: PRIMARY_KEY_FINGERPRINT

Extract uncompressed kernel source archive.

# tar -xvf linux-3.4.34.tar

Remove symbollic link for old kernel source directory and regenerate it for the new kernel source directory.

# rm linux

# ln -s linux-3.4.34/ linux

# cd linux/

Remove any existing kernel configuration file in current kernel source directory.

# make clean

# make mrproper

Download one of the kernel 3.4.11 configuration files compatible with your system in testing directory of Slackware 14.0 file tree.

 - For Slackware 14.0 (32-bit),

# wget http://mirrors.slackware.com/slackware/slackware-14.0/testing/source/config-testing-3.4.11/config-huge-3.4.11

 - For Slackware64 14.0 (64-bit),

# wget http://mirrors.slackware.com/slackware/slackware64-14.0/testing/source/config-testing-3.4.11/config-huge-3.4.11.x64

Rename downloaded kernel configuration file as ".config".

 - For Slackware 14.0 (32-bit),

# mv config-huge-3.4.11 .config

 - For Slackware64 14.0 (64-bit),

# mv config-huge-3.4.11.x64 .config

For additional kernel options, configure the kernel source by "make menuconfig" command and save the new configuration.

# make menuconfig

Compile new kernel.

# make all

After executing "make all" command, you will possibly be prompted to choose some kernel options because latest kernel source is newer than than the ".config" file downloaded from the testing directory of Slackware 14.0 file tree. For question do not make any sense for you, just press ENTER key for the default options which are usually fine.

Remove previously installed kernel modules in "/lib/modules/" directory, before installing the new kernel modules.

# rm -rv /lib/modules/*/

Install new kernel modules.

# make modules_install

Copy bzImage files.

 - For Slackware 14.0 (32-bit),

# cp arch/x86/boot/bzImage /boot/vmlinuz-huge-3.4.34

 - For Slackware 14.0 (64-bit),

# cp arch/x86_64/boot/bzImage /boot/vmlinuz-huge-3.4.34

Actually both “bzImage” files linked as above are identical.

Complete the kernel installation process by executing below series of copy, remove, link and navigation commands.

# cp System.map /boot/System.map-huge-3.4.34

# cp .config /boot/config-huge-3.4.34

# cd /boot/

# rm vmlinuz

# ln -s vmlinuz-huge-3.4.34 vmlinuz

# rm System.map

# ln -s System.map-huge-3.4.34 System.map

# rm config

# ln -s config-huge-3.4.34 config

# cd /etc/rc.d/

# rm rc.modules

# mv rc.modules-3.4.33 rc.modules-3.4.34

# ln -s rc.modules-3.4.34 rc.modules

For editing "lilo.conf" file, open it in a text editor.

# nano /etc/lilo.conf

Add following lines into "/etc/lilo.conf" file replacing old kernel section and save.

image = /boot/vmlinuz
root = /dev/sdax
 label = 3.4.34
 read-only

Finally, run the commands "lilo" to overwrite lilo configuration and "reboot" to restart your Slackware installed box.

# lilo

# reboot

After booting into new kernel, you can check your new kernel version.

$ uname -r

Output will be something like below:

3.4.34

References:

Slackware Documentation Project at "http://docs.slackware.com/".

Tuesday, February 19, 2013

TeamViewer 8.0.x installation in Slackware 14.0


For installing TeamViewer 8.0 in Slackware 14 usngRPM2TGZ Method;

Download the TeamViewer 8.0 Red Hat RPM package from TeamViewer home page.

$ wget http://www.teamviewer.com/download/teamviewer_linux.rpm

Follow below steps.

$ su
rpm2tgz teamviewer_linux.rpm
# installpkg teamviewer_linux.tgz
# ln -s /opt/teamviewer8/tv_bin/TeamViewer /usr/bin/
# ln -s /opt/teamviewer8/tv_bin/teamviewerd /usr/bin/
# teamviewerd
# exit

Execute launcher as user and have a fun with TeamViewer 8.0.

$ teamviewer

To generate symbollic link of TeamViewer 8.0.x launcher on desktop, run below command. 

$ ln -s /opt/teamviewer8/tv_bin/desktop/*.desktop ~/Desktop/

For above method, before launching the Teamviewer 8.0.x on next boots, you always need to start TeamViewer daemon by teamviewerd command manually as root. Currently, I am working on a SlackBuild for building TeamViewer 8.0.x package and start-up script that starts TeamViewer Daemon while booting. 

NOTE: If you have Slackware64 14.0 installed on your box, firstly you need to switch to multilib to make TeamViewer work. Because it requires requires these 32-bit packages: glibc, zlib, freetype, alsa-lib and GConf. After switching to mutilib, all of these dependencies are automatically met . In Slackware 14.0 (32-bit) full installation, there is no need for any of these dependency packages. Just follow the above instructions and run the TeamViewer. 

Thursday, January 31, 2013

TeamViewer 7.x installation in Slackware 14.0

Although TeamViewer is a closed source proprietary software, it is unbelievably a good choice for establishing remote control, desktop sharing, online meetings, web conferencing and file transfer between computers. In contrast to most of the popular industry software, it supports a group of operating systems including GNU/Linux and Android. It does not require any additional installation or specific configuration to work. For personal and non-commercial purposes, it is free (without any payment) to use. 


It is seen as a *life saver* software especially by *wives* and *girl-friends* of men and boys :), because of its ease of handling and efficient functioning. After running the software, just obtaining ID and Password and then telling them to client side via e-mail, instant messaging, SMS or voice calling, remote connection can be easily established between two hosts. 

I explained here two installation methods of the TeamViewer in Slackware 14.0, SBOPKG and RPM2TGZ. Both of the methods uses binary packages of the TeamViewer. Because of that you do not need to wait for the compilation process as in building from source code.

For the installation of TeamViewer 8.0.x in Slackware 14.0 look at here!

1. SBOPKG Method:

Download and Install SBOPKG tool. If you prefer pre-build slackware package of SBOPKG, it will be easier. You can download the latest version of the tool from the project's home page or Google code page.

$ su
# wget http://*sbopkg-*.tgz
# installpkg sbopkg-*.tgz
# sbopkg

The following directories do not exist:

Variable                   Assignment
--------                   ----------
REPO_{ROOT,NAME,BRANCH} -> /var/lib/sbopkg/,SBo/,14.0
LOGFILE directory -------> /var/log/sbopkg
QUEUEDIR ----------------> /var/lib/sbopkg/queues
SRCDIR ------------------> /var/cache/sbopkg
TMP ---------------------> /tmp/SBo

You can have sbopkg create them or, if these values are incorrect, you can
abort to edit your config files or pass different flags.

(C)reate or (A)bort?: C


































# exit
$ teamviewer




































2. RPM2TGZ Method

Download the TeamViewer 7.0 Red Hat RPM package from TeamViewer home page.
(This method will not work for releases other than 7.0.x. For TeamViewer 8.0.x look at here.)

$ su
# rpm2tgz teamviewer_linux.rpm
# installpkg teamviewer_linux.tgz
# ln -s /opt/teamviewer/teamviewer/7/bin/teamviewer /usr/bin/teamviewer
# exit
$ teamviewer

NOTE: If you have Slackware64 14.0 installed on your box, firstly you need to switch to multilib to make TeamViewer work. Because it requires requires these 32-bit packages: glibc, zlib, freetype, alsa-lib and GConf. After switching to mutilib, all of these dependencies are automatically met . In Slackware 14.0 (32-bit) full installation, there is no need for any of these dependency packages. Just follow the above instructions and run the TeamViewer. 

Wednesday, January 30, 2013

Slackware Linux Graphics v1.2

Slackware Linux Graphics Project aims to provide a set of visual components related to GNU/Linux Slackware in both vector and raster graphics formats for its users. Source SVG graphics and exported PDF and PNG graphics in the project were all generated by using Inkscape under the GNU/Linux Slackware. 


VERSION:

1.2

DATE:

30/01/2013

FILE INDEX AND CHANGELOG: 

Version 1.2

* Slackware.Linux.Phear.the.Penguin.Logo.with.Classic.Tux (*.svg, *.pdf and *.png)
* Slackware.Linux.Phear.the.Penguin.Logo.with.Crystallized.Tux (*.svg, *.pdf and *.png)
* Slackware.Linux.Classic.Tux.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.Crystallized.Tux.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.Download.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.ARMedslack.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.ARMedslack.Logo.with.Home.Page (*.svg, *.pdf and *.png)
* Slackware.Linux.slackARM.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.slackARM.Logo.with.Home.Page (*.svg, *.pdf and *.png)
* Slackware.Linux.slack390.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.slack390.Logo.with.Home.Page (*.svg, *.pdf and *.png)
* Slackware.Linux.Powered.Logo.with.Classic.Tux (*.svg, *.pdf and *.png)
* Slackware.Linux.Powered.Logo.with.Crystallized.Tux (*.svg, *.pdf and *.png)

Version 1.1

* Slackware.Linux.KDE.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.XFCE.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.Documentation.Project.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.Traditional.Logo.v2 (*.svg, *.pdf and *.png)
* Slackware.Linux.Bag.Badge.Logo.v2 (*.svg, *.pdf and *.png)
* Slackware.Linux.Current.Branch.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.Current.Branch.Logo.v2 (*.svg, *.pdf and *.png)
* Slackware.Linux.Current.Branch.Logo.v3 (*.svg, *.pdf and *.png)
* Slackware.Linux.Current.Branch.Logo.v4 (*.svg, *.pdf and *.png)

Version 1.0

* Slackware.Linux.Traditional.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.Traditional.Logo.with.Home.Page (*.svg, *.pdf and *.png)
* Slackware.Linux.Traditional.Logo.with.Because.It.Works (*.svg, *.pdf and *.png)
* Slackware.Linux.Traditional.Logo.with.Because.It.Secures (*.svg, *.pdf and *.png)
* Slackware.Linux.Traditional.Logo.with.Tux (*.svg, *.pdf and *.png)
* Slackware.Linux.Spherical.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.Blurred.Spherical.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.Favicon.Logo (*.svg, *.pdf, *.ico and *.png)
* Slackware.Linux.Bag.Badge.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.Security.Shield.Logo (*.svg, *.pdf and *.png)

Thursday, January 24, 2013

Slackware Linux Graphics v1.1

Slackware Linux Graphics Project aims to provide a set of visual components related to GNU/Linux Slackware in both vector and raster graphics formats for its users. Source SVG graphics and exported PDF and PNG graphics in the project were all generated by using Inkscape under the GNU/Linux Slackware. 



VERSION:

1.1

DATE:

24/01/2013

FILE INDEX AND CHANGELOG: 

Version 1.1

* Slackware.Linux.KDE.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.XFCE.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.Documentation.Project.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.Traditional.Logo.v2 (*.svg, *.pdf and *.png)
* Slackware.Linux.Bag.Badge.Logo.v2 (*.svg, *.pdf and *.png)
* Slackware.Linux.Current.Branch.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.Current.Branch.Logo.v2 (*.svg, *.pdf and *.png)
* Slackware.Linux.Current.Branch.Logo.v3 (*.svg, *.pdf and *.png)
* Slackware.Linux.Current.Branch.Logo.v4 (*.svg, *.pdf and *.png)

Version 1.0

* Slackware.Linux.Traditional.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.Traditional.Logo.with.Home.Page (*.svg, *.pdf and *.png)
* Slackware.Linux.Traditional.Logo.with.Because.It.Works (*.svg, *.pdf and *.png)
* Slackware.Linux.Traditional.Logo.with.Because.It.Secures (*.svg, *.pdf and *.png)
* Slackware.Linux.Traditional.Logo.with.Tux (*.svg, *.pdf and *.png)
* Slackware.Linux.Spherical.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.Blurred.Spherical.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.Favicon.Logo (*.svg, *.pdf, *.ico and *.png)
* Slackware.Linux.Bag.Badge.Logo (*.svg, *.pdf and *.png)
* Slackware.Linux.Security.Shield.Logo (*.svg, *.pdf and *.png)

Sunday, January 13, 2013

An Interview with Patrick Volkerding of Slackware (7th of June 2012)

Patrick Volkerding, the founder of Slackware Linux, agreed to an interview with LQ. Here is what he had to say. Some question were contributed by members. Those questions have the member's name in parenthesis after them. Thanks Pat!

--jeremy (LQ Member) 

LQ) To get us started, can you give us a little background information about yourself? (LQ)

volkerdi) Sure. I was born in Virginia while my dad was stationed out there as a Navy dentist. We moved to North Dakota when I was very young. As far back as I can remember I was interested in science, the space race, and other typical interests of a kid who wanted to be some kind of scientist someday. I had an erector set, lots of Lego blocks, and a pretty decent chemistry set full of poisons they'd never allow kids to play with today. When I was 7 or 8 years old my class took a field trip to North Dakota State University to see the computer department, and it was there that I got my first taste of UNIX and realized that I wanted to work with computers. I had an Atari 2600 and wanted to get the fairly rare BASIC cartridge for it (but never did), and when personal computers started to appear, I began hanging out at Radio Shacks and electronics stores to get my computer fix. The Radio Shack at the mall had the TRS-80 Model I on display and a nice collection of books on BASIC. I learned to program typing in program listings from one of David Ahl's computer game books and then figuring out how to modify them. The store was happy to have me come in and enter some code, and save the programs to tape so they'd have demos. But alas, they did not make the sale, and my first computer was an Apple ][+, and with it I learned to program Pascal (UCSD p-System), an integer C called Hyper-C, Forth, and other languages. Forth led to appreciation of RPN, and I still use only HP RPN calculators to this day. After high school I entered college as a computer engineering major (kind of a 5 year EEE / CS degree), but after 2 years of that it was clear to me that hardware design really wasn't my calling and that a computer science degree would be better for me. Also, the school I'd chosen was very much focused on VMS. I ended up transferring to Moorhead State University, which had just been given a bunch of AT&T UNIX equipment and was actually connected to the Internet (the other school only had BITNET access, which was fairly useless). It was while finishing my degree at MSU that I first started working with Linux.

LQ) How did you get involved with Linux and Open Source, and what was the path that lead to you starting Slackware? (LQ)

volkerdi) It was 1992 when I first heard that there was this project going on where someone in Finland was trying to build a UNIX clone. At the time I was running OS/2 on a 16MHz 386/sx. It was a good operating system, but what I really wanted was some kind of UNIX. I'd looked at the ads for Coherent in Byte magazine and had considered that, as well as Minix. I'd even gone down to the local computer store and asked about SCO Xenix, which if I recall correctly, they wanted a couple of thousand bucks for a single-user license! I'll pass, thanks. So I was pretty excited to head to the computer lab and start checking out the USENET groups and FTP sites where the development was taking place. It almost seemed too good to be true at the time, but soon I had H. J. Lu's floppies running on my machine (it works!), and checked out MCC Interim Linux next. Yggdrasil was around back then, too, but I didn't try that one until much later since my machine didn't have a CD-ROM drive. I pretty quickly landed (softly) on one of the early releases of Peter MacDonald'sSLS distribution.

I was taking a class on artificial intelligence, and the coding was all done in LISP. We were provided with a DOS based LISP interpreter to use, but the CLISP interpreter that came with SLS turned out to be far, far better. I told my professor about CLISP, and about Linux, and he asked if I could help him install Linux on one of the lab's computers, an AT&T 486 with an S3 video card. We went down there and did the install, and it went pretty well. I took out my notebook ("time to fix the bugs!") and started fixing all the problems that I'd documented in the time I'd been using SLS, and this led to him asking if it would be possible to fix all those bugs on the floppy disks, and make the installer more automated, so that maybe future classes could do their programming on Linux and not have to license a fairly mediocre version of LISP. I was up for the challenge and started figuring out just how things had been put together. SLS had shipped as a mostly binary only release with hardly any source code for anything, and not a lot of clues as to how things were built. There weren't any build scripts for anything, though that was pretty typical for Linux distributions in 1993 (and was a trap I fell into myself early on until I got tired of having to relearn what I'd done every time something needed to be rebuilt). Over the next month or so I corrected all the bugs that I knew about in SLS, upgraded the kernel, and did a major cleanup of the installer. My friend Brett Person was my original beta tester (and contributed a lot to the installer as well), and by April of 1993 was encouraging me to share what I had back with the Internet. I got a few more beta testers around this time by directly emailing people who were posting on comp.os.linux running into problems with SLS and asking if they'd like to help test what we were working on. I got a lot of good feedback, and more encouragement to put the beta up for FTP. So, in July of 1993 I put the first public release of Slackware on an FTP site running on an AT&T 3b2 UNIX box and announced it to comp.os.linux. The response was pretty overwhelming... especially to the UNIX box that was hosting it. I tried to keep things running for a few days, but it wasn't going to cut it, and Linux wasn't yet up to the task yet either (TCP/IP still suffered from random hangs), so I put out a call for help hosting it. Among the responses was one from Rod Grimes of the FreeBSD project offering space on Walnut Creek CDROM's ftp.cdrom.com server, which I gratefully accepted. This led to a long relationship with the folks at Walnut Creek CDROM.

LQ) Which Slackware release to date has been the most demanding/difficult to put together? What about the most rewarding? (solarfields)

volkerdi) Thinking back, there are definitely a few of them that stand out as being particularly challenging, generally due to a major transition of some kind. The move from a.out to ELF was certainly one of them, as was converting from ELF libc5 to glibc when the first stable glibc release came along. I was _really_ glad to see glibc release as stable, because I'd adopted a policy of not shipping beta versions of critical components like the C libraries or compiler, but most other distributions had gone ahead and based on pre-releases of glibc. I was close to violating that policy when the long promised stable glibc finally came along. Probably the most difficult and also the most rewarding release was Slackware 13.0, the first release to support the x86_64 architecture. Eric Hameleers deserves a great deal of credit for his work on porting Slackware to AMD64/x86_64 systems, and for making sure that it would be possible to add multilib support to it fairly easily. I'd been inclined to support 64-bit only, using the same library directories as 32-bit Slackware, and viewed /lib64 as an unnecessary complication that was going to require patching a lot of sources to make it work. It did require a lot of patching initially, and still does in places, but /lib64 was the solution that everyone ended up using.

LQ) Slackware is reported to be the oldest surviving Linux distribution, to what does you attribute this longevity? (ChrisAbela)

volkerdi) I try very hard with Slackware to defer to the wishes of the upstream developers. This isn't the place to be patching in new features, or packaging beta versions (if that can be helped). Lao Tzu said that in order to lead, one must follow. I have my own ideas about how things should work, of course, but I try not to impose them in a selfish manner. The goal is to move forward without abandoning the project's roots. I have nothing against change, but at the same time I try not to let things get juggled around simply for the sake of making them different. People who come back to Slackware after a time tend to be pleasantly surprised that they don't need to relearn how to do everything. This has given us quite a loyal following, for which I am grateful. I guess we're doing something right.

LQ) Did you ever think Slackware would last this long? Do you still have the same enthusiasm for providing Slackware that you had when you started? (jmccue)

volkerdi) No, I didn't think that Slackware would last this long, or at least that I wouldn't still be working on it by this point, but it did reach a sort of a critical mass early on where it was going to continue forward in some form or another whether it was under my guidance or not. I'm still very enthusiastic about Slackware, but it is different than the early days when things were just getting rolling. Those were exciting times for Slackware and for Linux, watching the early adoption. Slackware had the first Linux related booth at COMDEX and we pretty much got mobbed demonstrating a web server running off of a laptop! The first Linux Kongress held in the Netherlands in 1994 was another highlight of the early rise of Linux. It's hard to top things like that. Later on, having Walnut Creek merge with BSDi and try to position ourselves to go public was exciting, and then devastating as the market crashed, the IPO was called off, and the company was sold off when the cash ran out. I'm happy to still be doing what I'm doing though. I love working on Slackware and being a part of the larger Linux community, and continue to believe that it's important work.

LQ) Where do you see Slackware 5 years from now? (smoooth103)

volkerdi) Your guess is probably as good as mine, as far as that's concerned. Five years is a really long time in the computer field. Thinking back over the history of the project, I really couldn't have predicted the course of events, and the majority of it is determined by upstream projects and the ever changing needs of the users. So, I like to stay focused on more immediate goals. As those are accomplished, what
needs to happen next comes into focus. It's been more a process of evolution than directed design. The challenge over the next five years will be to remain true to Slackware's roots in UNIX philosophy as other projects and developers to may have completely different goals contribute to Linux as a whole. The world seems to be moving away from personal computers and towards communication appliances, and applications (especially in business) are moving towards cloud services. How that will impact the direction of Slackware remains to be seen.

LQ) Have you considered a succession plan such as a Slackware Foundation, similar to Mozilla, Libreoffice, etc.? (kingbeowulf)

volkerdi) I'm not sure those examples could really be called "succession plans" -- the Mozilla Foundation is a non-profit organization, while Libreoffice is a fork that resulted from a general unhappiness with the direction that Oracle had taken OpenOffice (or at least a feeling that it was headed the wrong way). In the first case, I have considered something along those lines before. FreeBSD has a not-for-profit corporation that functions to accept donations of hardware and funds to help support the project, and it seems to work for them. I've considered that kind of thing, but wouldn't really know where to begin with it. Setting up any kind of non-profit or not-for-profit is a fairly major undertaking and it's not something that I see as feasible to try to take on without a lot of outside help.

Now to answer what I think you are really getting at -- is there Slackware after Patrick? I'd think that there would be. Back in 2004 when I got ill the team had many discussions about that, we did come to conclusions about how to handle the big "what if". The folks on the team weren't about to let the project drop.

So anyway, we don't have a succession plan, per se, but it's a bridge we would cross when we get there. Meanwhile we try to avoid riding together on the same bus.

LQ) What do you think about the panic that seems to ensue when the main Slackware site goes down? (kristizz)

volkerdi) Panic tends to create more panic, and when I see everyone freaking out I do the same. Especially when the code for the web site is something that was cobbled together long ago by people that have since moved on. Unfortunately, it seems like every time the project hits a bump in the road, there will be people who try to paint this as the tolling of the death knell. And it's been that way for a long time, and not just for our project. I think Netcraft has confirmed the death of just about every open source project that exists at one point or another. That said, it does hurt when the tone of comments tends toward suggesting that the reason there's no immediate solution is because I don't care. Believe me, I care, and when the trolls fire barbs at me I can get pretty discouraged and start thinking nonsense like "I used to be a Linux guru, but then I took an arrow to the knee." I try to come away with a sense of renewed determination, though. And the site is back up, ported to a newer PHP by Mark Post. We're looking at better things for the future, like a decent content management system that would allow us to post news items more frequently. It's been a while since slackware.com was really a hub of activity -- most of our web presence is here on LinuxQuestions, and personally I like that a lot better than thinking about trying to run our own web forum. We did that back around 2000 and found more of our time going into that than into advancing the project. And that's part of why we ended up porting the old site and getting it back online rather than proceeding with building up something from scratch. There was significant progress made towards a completely new website, but that effort should be going into getting -current in shape for a release instead. There's a lot of stuff in the queue.

LQ) Would you say your hard work pays, and the development of Slackware satisfies you economically and personally? (BlackRider)

volkerdi) Well, economically speaking the past few years have been pretty thin. If I hadn't made the strategic decision to head back to Minnesota several years ago there's no way I could have stayed afloat living in the bay area. California is not at all a cheap place to live, and I was always cutting it close out there. Lately I've been cutting it pretty close here, too. I don't even have insurance any more... knock on wood. Personally, absolutely. I've made friends all over the world. I hear from people every day who love Slackware and depend on it for critical tasks, and who don't want to run something else. Working on the project is exciting and fun, and the folks on the team are some of my best friends. It's just not possible to put a dollar value on that.

LQ) Can you describe your typical work day? (slacker77)

volkerdi) I don't follow a standard format, but my day would typically include coffee (very important!), reading my email and LinuxQuestions, and communicating with the rest of the team over IRC. I follow a lot of mailing lists such as BugTraq and oss-security, and many of the other lists run by upstream projects to keep tabs on the changes that are going to affect us. The other team members have areas they are handling, and keep queues of proposed packages, and I go over that to see if it's the right time to start integrating them into -current. There's a lot of compiling and testing of potential updates, and there's more patching involved now than there was in years past, so I do spend a fair amount of time either looking for patches that we need or writing them myself. We all have to do that, really. It seems like upgrades to the toolchain (gcc and glibc in particular) tend to break existing code more often, so what should be a simple version bump turns into porting something to the new compiler (I'm interested to see to what extent llvm/clang are adopted, because I suspect that might be less of a moving target). Of course, updating build scripts, compiling, packaging, and testing are the bread and butter of the project, but those come after a lot of research... I'd rather release well than release often because it's not always that easy to back away from a mistake after it's been merged into -current, much less as part of a stable release.

See: fortune -m "three lines" fortunes2

LQ) Can you describe your personal desktop setup (WM/DE)?

volkerdi) I'm running KDE on my personal desktop pretty much as Slackware ships it, and have used that almost exclusively since it was added. Before that I used FVWM for years. I've tried most of the popular window managers and environments at some point or another, long enough to get to know the ins and outs of them. I'm also a fan of Xfce because it is nice and snappy on my older machines while still providing a complete environment.

LQ) Can you give us some behind-the-scenes report of what hardware you use for testing/development/day-to-day work? (tuxrukes)

volkerdi) The machine I'm using for nearly all of the development here is an AMD Phenom II X6 1100T running at 3.3GHz, with 16GB of RAM. It's got 5 SATA drives in it, 4 of them running as LVM on RAID5, and another set up as a scratch drive for test installs. I'm a computer packrat and have many of my older machines running in some capacity or another, such as signing packages and generating the checksum and manifest files, and syncing out updates to the server we use to hold the not yet public trees. And there are examples of nVidia, Intel, and AMD video hardware so that I can make sure those are working properly. That was especially important leading up to the 13.37 release as everything was transitioning to drivers that use kernel modesetting... there were some tricky issues to overcome with that.

LQ) Slack had always had somewhat closed model of coming to life. What is the best way to contribute to Slackware? Maybe contributing to popular community projects? Or is it best to start Slack related project and see if it catches on? (bobzilla)

volkerdi) If you see something that's missing and that you think has wide enough appeal, you can always submit a SlackBuild for it to slackbuilds.org (if there's not one already... it's quite a large collection). That's also helpful to us if we ever decide to package it in the official tree. Starting a Slackware related project is also a way to go. When we quit packaging GNOME we were happy to see some teams step up to provide it. Testing what's in -current and reporting bugs is also a major help, especially if you've worked out a fix for them. Same goes for likely candidates for upgrades in the development tree. We get quite a bit of help from people who are testing things coming from upstream and find that the existing SlackBuild isn't working to compile them, figure out why, and let us know about it. A lot of this pending development discussion happens on LinuxQuestions, so please share what you know here.

LQ) How do you choose who you work with in your team? How did AlienBOB, Alan_Hicks, rworkman etc. get chosen? (suppy)

volkerdi) First a bit of history is in order -- Slackware core as it stands today is really the second generation team. The first team consisted of David Cantrell, Chris Lumens, and Logan Johnson. David and Logan approached me at a trade show in Chicago. At that time Slackware had never had a website and they volunteered to help build one. When I moved out to California to work for Walnut Creek, they offered them jobs as well, and they worked with me until the dot com bubble burst. David and Chris work for Red Hat now, mostly on the installer, and Logan is working at MOVL. Chris had a bit of fame a couple of years ago as the mastermind behind Fedora's hot dog theme.

The current team began as an unofficial Slackware mirrors system. Erik Jan Tromp (aka alphageek) ran a webpage listing these mirror sites and in addition to his own Slackware mirror there were several other mirror sites and administrators, and they had an IRC channel that they used to discuss what was going on with the mirrors. Eventually they ended up mailing me about it, and lured me into IRC. Initially it was to talk about issues pertaining to distributing the software, but it evolved into talking about development issues. People who have been in the IRC channel longer than I have include mrgoblin, amrit, karlmag, alphageek, and a few others who continue to lurk there but aren't so active any more. After that time, people who got added to core had usually made some kind of major contribution to Slackware in an unofficial sense, and were then invited to join. Robby and Alan were invited due to their work on SlackBuilds.org, and alienBOB through his work on creating a clean port to the x86_64 architecture and all of his extra public packaging work. Fred Emmott of Slamd64 (now working at Facebook) was also invited in and we still see him there. Mark Post was added after porting Slackware to the IBM S/390 mainframe (and feeding back bug fixes discovered along the way). Heinz Wiesinger was invited for performing various miracles, most recently figuring out the issues with mysql and PHP, including how to build PHP in a single pass and have the extensions remain compatible with all the various flavors of PHP in the package and the different Apache Multi-Processing Modules. We had also ended up absorbing a lot of his SlackBuilds from slackbuilds.org, so it seemed a good fit.

Amaze us appropriately and maybe we'll add you, too. But watch out for the terrible hazing rituals.

LQ) Have you considered ways to more consistently communicate with Slackware users (perhaps via a blog or Google+)? What about a more open development model, such as one based on git? (many)

I have considered making more use of social media. I have Google+ and Twitter accounts, and used them to announce or discuss Slackware related issues. I have Facebook, too, but don't use it all that much. I've never really been drawn to the idea of having my own blog (I'm glad alienBOB does, though). I've been trying to put more information into the ChangeLog than simply a list of changed packages though.

As far as a more open development model such as git or other version control, it's probably going to become necessary at some point moving forward, and rworkman in particular is really pushing for something like that to be integrated into our development model. Right now we have several people maintaining their own private trees and I spend an increasing amount of time reconciling differences between updates that were developed in parallel. I've always known that I don't scale, but it's becoming pretty painfully obvious that acting as the commit master for everything going into the -current tree isn't going to be sustainable for very much longer as the number of support packages needed for KDE and other things continues to grow. This is especially true if we ever expect the ARM and other ports of Slackware to all be working off the same source tree. On that note, it might also be time to start thinking about centralizing some parts of the SlackBuild system. While it's nice to have the build script completely self-contained, it's not very convenient when it comes time to support a new architecture. Nothing like deciding to add some new options to the ARCH block in there and having to edit every single SlackBuild in order to pull off what ought to be a simple addition. So these are some of the things to look at once we get this release out and start up another development cycle.

LQ) What do you think of the current trends in desktop environments (Unity, Gnome 3)? Years ago you chose KDE for Slackware; are you happy with the direction (semantic desktop) it has taken? (fgcl2k)

volkerdi) I haven't really had enough personal experience with Unity or GNOME 3 to have formed a strong opinion about them, but my observations of Unity lead me to believe that it's probably an intuitive environment for people that are used to smartphone or tablet interfaces. And my guess it that they're looking ahead to that market. I'm pretty sure I'd be more comfortable with GNOME shell myself. Between GNOME and KDE, I'm happy that it's KDE that's in the main Slackware tree. I like it a lot, and believe it has a more consistent feel to it. Maybe that's because the framework is developed primarily in C++. I tend to prefer C to C++ overall for most things, but I do think that C++ is the better language for GUI development because it's easier to make use of existing components and therefore the temptation to reinvent the wheel and do things outside of the provided framework isn't as strong. The transition from Qt3/KDE3 to Qt4/KDE4 was a bit bumpy (but we waited out the first couple of releases), and I think that most people would agree that KDE4 has evolved into a world class desktop environment. I'm looking forward to a newer Xfce too, but that's going to require absorbing a few of the GNOME dependencies that I was sort of glad to see gone. Not really a big deal though, since Robby's doing much of the heavy lifting there, and the new versions of Xfce look really good so the few additional support packages we'll need to add back will be worth the result.

LQ) Right now, there are a number of potentially intrusive technical changes coming to some of the major distributions. How do you feel some of these will impact Linux in general and Slackware specifically? Are there any you would considering merging into Slackware? (55020 & tuxrules)

volkerdi) Yeah, I see a few things coming down the line that may cause a shakeup to our usual way of doing things, and could force Slackware to become, well, perhaps less UNIX-like. I guess the two big ones that are on the horizon are Wayland and systemd. Whether we end up using them or not remains to be seen. It's quite possible that we won't end up having a choice in the matter depending on how development that's out of our hands goes. It's hard to say whether moving to these technologies would be a good thing for Slackware overall. Concerning systemd, I do like the idea of a faster boot time (obviously), but I also like controlling the startup of the system with shell scripts that are readable, and I'm guessing that's what most Slackware users prefer too. I don't spend all day rebooting my machine, and having looked at systemd config files it seems to me a very foreign way of controlling a system to me, and attempting to control services, sockets, devices, mounts, etc., all within one daemon flies in the face of the UNIX concept of doing one thing and doing it well. To the typical end user, if this results in a faster boot then mission accomplished. With udev being phased out in favor of systemd performing those tasks we'll have to make the decision at some point between whether we want to try to maintain udev ourselves, have systemd replace just udev's functions, or if we want the whole kit and caboodle. Wayland, by comparison, seems fairly innocuous, assuming that they'll be able to implement network transparency either directly or through some kind of add-on compatibility layer. Again, another thing that most desktop users don't have a lot of use for but many users can't do without. I like X11, and would probably stick with it if moving to Wayland meant losing that feature, even if Wayland's rendering method carried with it some benefits like reduced rendering artifacts or increased video performance. I guess we'll just have to see what the overall benefit is when it's far enough along to make such comparisons.

Right now, the big change that has me concerned about the future of not just Slackware but Linux in general is the impending implementation of Secure Boot in all Windows8 client certified hardware, and the total lockdown of ARM hardware with no option to shut this "feature" off. I'm imagining that we'll proceed forward initially requiring that Secure Boot be disabled in order to install Slackware, and was (to say the least) rather surprised that wasn't the path all the Linux distributions were taking. If that makes it impossible to dual boot without making a BIOS setting change, or leaves us without drivers because they are designed to only run against certain signed kernels then we'll have to reconsider that approach, but I can't imagine our users being happy if they suddenly found that they were prohibited from compiling their own kernels and modules. The goal here will be to maximize the end user's freedom to modify their own system, and if that means they'll need to go into the BIOS and flip a switch that doesn't seem like a high bar. Hopefully that won't evolve into needing to flash the BIOS because the switch has gone away when the next generation of machines comes out, if flashing the BIOS would even be possible. All it would take is making that a requirement for the next Windows hardware certification. I'd urge everyone to sign the Free Software Foundation's secure-boot-vs-restricted-boot petition to let the hardware manufacturers know where you stand on this issue. I'm especially disappointed to hear that the ARM based systems designed for Windows will be locked down out of the gate, but maybe it's possible that Google or some other company will come through for us. And maybe Alan Hicks was ahead of the curve when he bought an Apple laptop to do Linux development on. Interesting times we live in, indeed.

LQ) What do you think about Fedora and Solaris 'simplifying' the filesystem by doing stuff like merging /usr/bin and /bin? Something you would ever consider? (ruario)

volkerdi) Sure, I could see doing that, but we'll see how it goes elsewhere and to what extent things start to expect it to be that way. On Slackware (and other systems) a lot of the binaries that would otherwise install to /usr/bin have to be moved to /bin because they are needed before /usr is available, if /usr is on a separate partition. Likewise, libraries have also had to move. This has led to a lot of symlinks pointing from /usr/bin to /bin, or from /usr/sbin to /sbin, and elsewhere around the system. Now, I'm not sure that I consider this to be a bad enough situation that it's worth the pain of changing it, but it's certainly under consideration. Really, the most painful requirement about /usr was the rule that it had to be possible to mount it as a network volume. That might have been a good idea at the time when hard drives were expensive and small, but it probably isn't done a whole lot today. If we do make a change like that it would be a major change (and would warrant a major version number bump for sure), and I'm not sure how (or if) upgrading from an earlier version would work. Perhaps with a tool on the installer that would transform the system to the new layout? Dancing that dance on a running machine would be a difficult trick with the package utilities based on shell scripts that are using binaries at the same time that they'd have to be moved around.

On a related note, we're looking into how to best handle a top-level /run directory. This does make sense, if not to merge /var/run with it, at least to have it available in early boot.

As far as these kinds of changes are concerned, we have to be certain that they actually solve important issues and leave us better off than we were before, and without new problems that we didn't previously have. Sure, the way things are now until /usr comes online we may be dealing with a limited set of utilities, but we've been able to make due with them in early boot so far. If, for example, the changes make it a requirement to use an initramfs on every system, I wouldn't necessarily consider that to be simplifying things.

LQ) Given the success of some much younger distros, do you have any regrets with the direction he has taken Slackware in, and does he have any aspirations to get his creation more readily accepted by the masses? (vdemuth)

volkerdi) Heh... that's a tough one. Of course, with the power of hindsight I can look back and see a bunch of what might be considered "Gary Kildall moments" where doing things differently would have led to fame and fortune. Would that have been good for me, or for Slackware? It's very hard to say. Look at what happens to some of those lottery winners. The reason I didn't go along with some of those early offers that might
have followed that path was because the people with the cash didn't really want Slackware. They wanted Slackware's market share at the time. I wasn't even sure they wanted me -- I could have been quickly marginalized out of the business. I knew nothing of startups and venture capital, and early on was reluctant to accept payment for what I was doing at all because I felt like I was taking advantage of all the unpaid developers creating the components that I was putting together. Of course, since then an entire industry has grown around Linux, and I wouldn't mind having a bigger piece of that, but if my goal had been to make as much money as possible I'm really not sure that it would have happened anyway, and it's quite likely that Slackware would either have been a flash in the pan or turned into something completely different. In many ways, Slackware has evolved into a learning tool. There's a learning curve, and then the reward of understanding. Slackware's not going to fight you if you want to replace or recompile part of it. Somehow I think that's never going to be what the masses want, and I'm OK with that.

LQ) What tools do you use to keep track of all the packages in Slackware and how do you decide what gets updated and when? (trxdraxon)

volkerdi) Actually, it doesn't really require a lot of custom tools to track the number of packages that we currently have. I keep lftp bookmarks so that it's easy to find an upstream FTP site using "lftp ", and leave some hints in the tree (package.url). Otherwise, a lot of the TODO list and tracking here is in the form of a couple of notebooks. I know some of you might be laughing at the idea of tracking things on paper, but it's an efficient enough way to figure out what to do next. What is more difficult than finding stale packages is considering the impact that upgrading any given package is going to have on the system. Some of that is just guesswork, and some of it is based on past experience. After you've been doing this for a long time, you start to get a feel for which packages are going to be safe upgrades, and which ones you should be wary of (in spite of promises of ABI/API compatibility). Plus, we've all got our own favorite projects that we follow development and announcements for. User requests are also incredibly important in determining what gets updated, especially if an update is needed as a dependency for something that we don't ship. We do have a couple of tools that were written by Stuart Winter that we use to find packages that link against a given library, or binaries that need to be recompiled because libraries that they were linked against have gone missing. Those come in handy when shared libraries bump their major version numbers. I guess I wouldn't mind having a script that would search for newer upstream versions of all the Slackware packages and generate a report about what's available, but we do tend to find these things out anyway. Updates that are not libraries or dependencies for other packages can be done whenever there's time to do them. Packages that are dependencies for other things have to be done more carefully, and if it's going to cause a lot of rebuilds I might wait until there are updates available for some of the larger things that are going to have to be rebuilt (e.g. KDE). If bumping a dependency is going to cause other packages to need a rebuild, I'll do them all at once in the same batch. Even in -current, I don't like to see anything broken for very long, and leaving dangling dependencies is a definite no-no. Maintenance of older Slackware versions is mostly done for security reasons and there I prefer upgrading packages over patching them if the compatibility can be trusted (sometimes this will fix other problems as well), but if an upgrade might mean breaking compatibility then we'll patch the problems rather than possibly throwing a wrench in the works on production systems.

LQ) How does Slackware's reputation make you, personally, feel? Is it a point of pride that your distro is considered difficult to install/use and expert level, or do you view that negatively because it keeps new users from wanting to try Slack? (trademark91)

volkerdi) Hopefully that's not all of Slackware's reputation! And to the extent that it is, it's not something that I agree with. The goal back when the project was started was to make it easy, and to keep things simple. But to paraphrase Einstein, you want to make things as simple as possible, but not simpler. There's a point of diminishing return when adding additional layers and interfaces, especially when it comes to system configuration. I've seen automated configuration do things like strip out all the comments in a config file, or worse just completely rewrite the thing because you had the nerve to try editing it outside of the approved system. And I do feel like Slackware has been shafted in some of the reviews over the years, largely because there's a tendency to review only the installer and not the system itself. There is certainly a learning curve, but that's true for all versions of Linux. We've never tried to make things hard, but perhaps we also haven't tried to prevent people from shooting themselves in the foot. Things like aliasing rm to 'rm -i' don't help the user learn to be careful.

LQ) Slackware's passionate userbase is infamous. Do you have any words for them? (dugan)

volkerdi) Slackware may not have a huge userbase, but it is an extremely dedicated and loyal one. There are some really great folks in the Slackware community. Thanks for keeping me in line!

LQ) By default, Slackware installs an unusually large selection of text editors. Which one do you actually use? (dugan)

volkerdi) I actually use elvis most of the time (out of habit, and because it gets the job done), but I'm also a fan of vim. The vim color syntax highlighting has definitely saved me a lot of time debugging shell scripts.

When I was at Southeast Linux Fest last year, Andrew Psaltis gave a talk on Emacs that impressed the hell out of me, though. I was telling some of the people there that I was going to try switching to Emacs. I did try using it for a while, but not long enough to really got the hang of it (though I remained impressed). But, I drifted back to my vi comfort zone pretty quickly.

LQ) How are things going in general? Is there anything slackware fans can do to help with any inconveniences? (H_TeXMeX_H )

volkderi) Send lawyers, guns, and money! I've seen things better before, but I've also seen them worse, and I'm glad that we moved back to Minnesota before the economic downturn... it would have been a lot worse for us on the west coast, financially speaking. I am really grateful for the donations that have kept things afloat. If I had any ideas about how else Slackware fans could help out, I'd let you folks know. Frankly, a business model that's based mostly around selling physical media doesn't make a lot of sense in this era of widespread high-speed net access -- just look at what the record companies claim it has done to them. How to generate sustainable funding for the project is a looming question. Maybe have periodic fund drives similar to what public radio does?

LQ) Back in an old 1994 interview you stated that you were a homebrewer. Do you still have time for that these days? Related to that what is your favourite beer? Is beer your drink of choice? (ruario)

volkerdi) Yes, I did indeed brew beer, but it's been years now. I never did brew again after moving to California, but I kept most of my equipment, and have recently had the itch to try it again. So, I picked up some German pale malt and Spalt hops and will be brewing some Altbier one of these days. I've missed the cool season but the furnace room stays pretty chilly in the summertime when the air conditioning is running (it's also a good spot to keep the servers).

If I'm going to be drinking alcohol, yes, I'd say beer is my usual drink (otherwise coffee... and soda, but trying to cut back on that). Guinness is one of my favorites (especially the Foreign Extra). For cheap beer, I'll take a Pabst Blue Ribbon.

LQ) I caught your interview in Hacker Public Radio. Besides the Grateful Dead and incense, what other musical genres do you enjoy? When you're not working on Slackware, what other hobbies/activities do you enjoy? (kingbeowulf)

volkerdi) I also enjoy jazz, classic stuff from greats like Miles Davis and John Coltrane. I also like J.S. Bach, especially the harpsichord partitas. Gotta credit Hofstader and _Go:del, Escher, Bach: An Eternal Golden Braid_ for getting me interested in those (and Bach's "Musical Offering"), which are very interesting both musically and mathematically. Earl Scruggs and John Hartford are my favorite banjo players. Back in the mid 90s I went to see Jorma Kaukonen (who used to play lead guitar for the Jefferson Airplane) play a show not far from where I'm living now in Minnesota. John Hartford was also on the bill, but I wasn't yet all that aware of his music, which was an old time style banjo with lots of songs about steamboats and the Mississippi River. I ended up collecting a lot of his CDs over the years and picked up the 5-string banjo myself probably as a result of that one show. Other music -- blues, dixieland, big band, trance/glitch (like Oval), "found sound" mashups like Negativland, old country music. There's a great country AM radio station in Fallon, Nevada that I'd tune in when traveling through when all I had was a radio in my car. Now I've got satellite radio in my car... lately it's been tuned in to the 1940's station.

I like old cars, and have a 1967 Firebird that I've been driving for more than half my life. My wife acquired a 1950 Chevy last summer. It's got a 6 cylinder Stovebolt 230 in it, and only 53,000 miles. That one's going to take some work though... it needs almost full choke to run and seems to starve out once it's warmed up. I have a rebuild kit for the Rochester B carburetor on it which should help (it's got gas leaking from the gaskets), and might also be looking at vacuum leaks, or maybe the heat riser that's stuck is cooking the carb. Ah, great gearhead entertainment!

I'm also passionate about photography. I used to shoot black and white (Kodak Tri-X) and develop it myself. Now all my cameras are digital, and I don't own an SLR, but I still like to see if I can get good results from relatively cheap equipment. I use a Canon S90 point and shoot that's got the CHDK enhanced firmware on it that allows a lot of the advanced features that you normally only see in SLRs. The S90 can save RAW images natively, but even cheaper Canons can as well when using CHDK. I've taken a ton of bracketed photos, which is where you shoot a sequence of photos at different exposures that can be combined to make High Dynamic Range (HDR) photos. I've also done Kite Aerial Photography using CHDK's timer features, setting the camera to snap a picture every 15 seconds and sending it up on a kite. So far so good on getting the camera back in one piece, and I've gotten some really great shots that way.

LQ) Over the years, you must have done quite a few interviews. Is there any question you always wish an interviewer would ask but never has? (jeremy)

volkerdi) Do you want to come back to my place, bouncy-bouncy?

No, just kidding, but I couldn't resist having a Monty Python reference in here. :-) And to answer the question, not that I can think of.

Thanks folks, it has been fun! Let's do this on Reddit someday.

Take care,

Pat