October 10, 2003 Edition

By Amit "Prototyped" Gurdasani and Jorge "whiprush" Castro

So we're back with a mega-issue, and we've received lots of great logo submissions for Linux.Ars. Thanks to everyone who submitted. We're going to let the contest run for another edition, so keep them coming. We promised we would look at Slackware 9.1, and we haven't disappointed as ctkrohn takes Slackware around the block and lets us know the scoop. We also promised to look at the newly minted Samba 3.0. Unfortunately, as we did research into the new features of Samba 3.0, we found ourselves finding more and more great things to do with Samba. So we're just going to leave you with a "Hold here . . . the Imperator has something special planned for them; we only need to keep them from escaping." Now, on with the show . . .

 

Slackware 9.1: No Frills Linux

Version 9.1 of the venerable Slackware distribution has just been released. Slack is one of the oldest among the currently-maintained Linux distributions; in April, it celebrated its tenth anniversary. While the individual software packages have been changed over the years, the Slackware philosophy has remained the same.

What is the Slackware philosophy? "We have always considered simplicity and stability paramount," says Patrick Volkerding, the distribution's creator and maintainer. Slackware's key features all follow from this key point: a minimal package system, lack of automatic configuration for most hardware, a no-frills text-based installer, no custom patching or branding of software.

Slackware's package system is perhaps its most salient feature. Some hesitate to even consider it a package system, since it does not perform dependency checking of any kind. Third party solutions for dependency checking and automatic software updating do exist, but they are not part of the main distribution. Of these, the most well-known is Swaret, available on CD2 in the "extra packages" directory. The Slackware community is much smaller than that of Debian, so in general there are far fewer precompiled Slackware packages available than, say, DEB or RPM archives. This means that if you want some package that isn't included in the distribution, you will most likely have to compile it yourself.

Knowing this, your most pressing question might be "Which packages come with Slackware?" Release 9.1 has a large set of packages compared to previous releases: this is the first 2-CD release of Slackware. Presumably the space was used for the complete KDE 3.1.4 and GNOME 2.4 desktop environments. Each desktop environment is well-equipped with other applications. For example, the GNOME package set comes with GNOME Office, gxine, Galeon, and several other useful GNOME apps, whereas the KDE package set comes with KOffice, KDevelop, and the Quanta HTML editor. Most users will be very well off installing either one of the desktop environments.

What's notably missing? Users of GNOME will immediately notice that there is no proper audio player in the Foot menu. XMMS is installed as you might expect, but this is an older program which uses the now-obsolete GTK+ 1.x libraries. Discriminating GNOME users expect a GTK+ 2.x audio player such as Rhythmbox. Gxine, a GTK+ 2.x video player which uses a Xine backend, has been included. It's a nice little program, but at version 0.3 it still seems a bit unpolished.

In addition, OpenOffice.org is not included. KOffice and GNOME Office devotees may consider their respective suites to be sufficient, but those of us who work with Microsoft Office formats appreciate the quality of OpenOffice.org's import filters.

Every distribution review must include at least a passing mention of the installation process. I am quite happy to say that Slackware's installer is the same as ever: a text-based, brutally simple, yet extremely effective tool that will get the job done quickly with a minimum of fuss. The only change I noticed from previous versions is the ability to install from DVD. As far as text-based installers go, Slackware's handily defeats Debian's. It is even superior to many GUI installers, though RedHat's Anaconda tool is still this author's favorite.

Slackware 9.1 is the second version of Slackware (9.0 was the first) to include support for the automatic detection of some hardware. Through the use of the "hotplug" system, the Slackware kernel will automatically load whichever modules are necessary to configure things such as the sound card or network card. Equipment which does not need a kernel module (such as a video card or a printer) is not configured. Nvidia cards are not configured either; however, I had no problems configuring mine. If you are planning to install Slackware on a computer, it would be wise to have a working XF86Config file beforehand, if possible.

Old-time Slackware users will notice a relatively major shift in the Slackware philosophy. In a distribution that once forced users to do almost everything, users no longer have to deal with configuring their sound card or network card. Most users will not have to even re-compile their kernels. The default simply works quite well. Likewise, Swaret represents a major potential change: users may no longer have to go through the ritual of hunting around on Google or linuxpackages.net for .tgz's, and then compiling from source when none could be found. While users will still have to do this if they do not install Swaret, the fact that it's included as an extra package points to possible eventual inclusion in the main distribution.

Is all this a bad thing? I think not. But I wonder what will happen to Slackware's niche as it begins to acquire features that are traditionally found in more mainstream distributions. I think it would be a shame if Slackware became just another Debian; after all, Debian is a perfectly good distribution which doesn't really need to be duplicated. Thus, Patrick Volkerding is faced with a bit of a dilemma. He can either keep his distribution the way it is and refuse to acquiesce to what some would call 'modernity,' or he can allow his distribution to become less unique, more mainstream, and Just Another Linux Distribution. It's a difficult choice, one which I believe is largely dependent on the Slackware community as a whole.

Considering the current state of the distribution, which type of users should use Slackware? In my opinion, the following types of people would benefit most:

Because I enjoy such frills as easy software installation, automatic hardware detection, and a large collection of third-party packages, I think I'll stick with RedHat 9 for the time being. Yet I would certainly consider Slackware for a number of special purposes, where such features are not necessary. It is put together very nicely, but it is targeted at a niche that I am not a part of. For the Linux enthusiast looking for a pure Linux experience that doesn't pull any punches, it doesn't get any better than Slackware.

~write-up by ctkrohn

 

Cairo: Bringing X to the forefront

The predominant UI architecture on Linux, The X Window System, is quite adequate in providing basic primitives for drawing items like text, rectangles, arcs, lines, points, and such onscreen. Unfortunately, core X11 doesn't support things like antialiasing (XRENDER, an extension to the X11 protocol, adds this support, however) or scaling and niceties like that, and it's not completely suitable for things like rendering to a plotter or to a vector graphic, especially since it tends to render things as bitmaps—raster images. To allow applications to be able to do WYSIWYG (What You See Is [nearly] What You Get), code libraries like Qt have to provide their own abilities to produce device-independent vector graphics. As a result, each new class of applications that needs to do device-independent graphic output ends up with its own version of the code, tailored to the specific need. This also often results in inconsistent output on the screen versus paper or image.

New GUI architectures that have been developed more recently than X11 (and a few predating it) have some sort of system to provide a device-independent way to draw text and graphics, so that drawing to a screen, printing to a printer or writing to a graphics file isn't very different. The X Window System itself has an extension, pioneered by Sun, called Display PostScript, where PostScript (a programming language most commonly used to describe printer output) could be sent to the X server just as well as a printing device or encapsulated as an EPS graphic. However, Display PostScript, while a great idea, didn't catch on—primarily because PostScript generation and interpretation turned out to be too much of a performance drain on the systems of the time. In the face of criticism from developers about the lack of a suitable means to easily draw scalable graphics independently of target device, Keith Packard and Carl Worth have made a well-designed system for device-independent graphic generation. It's called Cairo.

Cairo, once known as Xr, is a vector graphics library which boasts device independence, a stateful thread-safe API, optional hardware acceleration and a drawing/imaging model similar in scope to PDF 1.4. It adds the ability to easily draw complex graphics utilizing primitives such as splines. Thanks to Cairo, we are more likely to see applications that can produce similar graphical results onscreen, on paper and in images with less effort.

Why all the hype about vector graphics? Well, they can be scaled without detail loss which opens the way to complete resolution independence. They're also small and easily compressible, which is great for low bandwidth links. This should allow for more accurate WYSIWYG processing, more widespread use of scalable images (which should allow for fewer jaggies when you zoom into that Tux image), and (we hope) faster rendering.

If you want to see Cairo in action, the Cairo GTK+ engines and SVG viewer are good places to start.

 

Attack of the lightweight window managers!

We spend lots of time covering the larger desktop projects, like GNOME and KDE. This week we're going to shed light on two projects from the lighter side of the resource meter. Many people start off in Linux with a second hand box or a hand me down from a friend. This means resources are scant, and this is where lightweight window managers can make that Pentium 166 bearable. These two are so slim and elegant, that they can easily find their way as your main desktop of choice. This week we look at XFCE 4.0 and the newcomer, Kahakai.

 

Kahakai

The *box window managers (like Blackbox and Fluxbox) have always been famous for their lightweight and nimble interfaces. One variant, Waimea, picked up a rather loyal following, but development was beginning to slow, and then one day, it just plain stopped.

Not being ones to take things lying down, a group of dedicated "rebels" forked the project, and Kahakai was born. Kahakai is a "fork of the Waimea window manager, with the intent to create a language agnostic scriptable window manager, while maintaining the original features of Waimea, and extending upon them." Enlightenment users are familiar with the power of scriptability in a window manager, as eesh's flexibility has proven. Kahakai will take this further by allowing the user to script the WM in other languages. Right now Python is supported, with Ruby and Perl on the way.

It seems as though Kahakai is the latest hip window manager in the Linux world, and why wouldn't it be? It definitely nails my favorite feature perfectly—lots and LOTS of transparency! So Arsians, what's the verdict on Kahakai? We're excited to see where this WM goes.

 

XFCE 4.0

XFCE, after a nice long incubation, has released version 4.0 of their desktop. Actually, we've cheated a little bit. XFCE isn't really just a window manager—it's a full blown desktop, but its performance will make you think otherwise. Like GNOME, XFCE is built on the GTK+ 2 toolkit, so it shares many inherent benefits of the toolkit, in fact, at first glance you could almost call it GNOME Lite. It's difficult not to compare XFCE with GNOME, since many of the visual clues are there, but XFCE has its own "personality" that you need to experience. Don't let the initial layout similarity to CDE fool you, this modern desktop is both visually appealing and functional.

The main desktop is characterized by a top menu bar, and a thicker, centered bar on the bottom of the screen. We were particularly impressed with the set of "familiar" themes from other window managers, as well as XFCE's excellent handling of dual monitor setups. A perfect complement to other GTK+ 2 applications, we see XFCE being popular with UNIX fans who like a modular system that's built to get the job done. Freedesktop.org compliance ensures that this desktop will be compatible with the direction of the rest of the Linux desktop.

 

Penguicon 2.0

The Midwest is barren when it comes to tech conferences and trade shows, let alone Linux-specific events. Last year a group of daring people decided to combine the Linux community with the Science Fiction and Fantasy community into one weekend long geekfest in Detroit, MI. It was a smashing success. Next year Penguicon 2.0 will return, April 16-18 2004, in Novi, Michigan.

The guests this year are Neil Gaiman, creator of The Sandman series, Jeff "Hemos" Bates, from Slashdot.org, Steve Jackson from Steve Jackson Games (OMG GURPS!), Wil Wheaton (Wesley Crusher of ST:TNG, and author). Oh, and someone you might have heard of, Jon "Maddog" Hall—Executive director of Linux International. There will be tech panels and plenty to learn from other Linux users, as well as a weekend long Installfest, a trade show, Wi-Fi access, and a LAN party.

We attended the last Penguicon, and many Midwest Arsians made the trip into what turned out to be a great geekfest and Ars Meet. This year we're planning ahead of time, so bring your orange Ars shirt, and come hang out with the #linux regulars and the Metro Detroit Linux Users Group. Of course there will be a repeat of last year's Motown Ars Meet, and and lots of Dragonmead. Registration is already open.

 

TTT: Tools, Tips and Tweaks

This week's tip jar, we've pulled out two tools that can save you a heckuvalot of hassle: sudo and cron.

 

Sudo: How to Let your Users Shoot You in the Foot Without a Password

Sudo is a tool used to delegate the ability to run applications and utilities with the privileges of a different user, on a user-by-user and command-by-command basis. This can, for instance, allow an administrator to permit a user to be able to run system backups (and only system backups) without having to (or, for that matter, being able to) log in as the superuser. It can also allow a desktop user to be able to stay logged in as a regular unprivileged user, and yet run commands as the superuser without having to supply a password. (Use this ability with caution.)

Sudo compiles and runs on many different operating systems, and most Linux distributions already come with a package for it. The BSDs, too, incorporate sudo as a port. Linux-from-scratch users and users of proprietary UNIXes can build and install it from source.

Sudo is configured through editing the file /etc/sudoers with the visudo editor, which runs $EDITOR (as long as it's in the safe editors list; vi otherwise), and sanity-checks the result. Visudo locks the /etc/sudoers file during the edit session, so that no one else can edit it at the same time (and potentially cause lost updates). Also, sudo requires the file to be owned only by root, and have the permissions 0440 (i.e. only readable by root and, on systems that support it, the wheel group).

Here's an example configuration, annotated with comments about what the different sections mean:

# Add jed to the safe editors list, as a default.
Defaults editor = /usr/bin/vi:/usr/bin/jed
 
# You can specify "aliases". That's just fancy talk for groups of users
# or hosts (in case the sudoers file is on a network filesystem mounted
# on many hosts--convenient for network deployment, too.)
 
# Here's a sample host alias.
BACKUPSERVERS = athene, zeus, hera, aphrodite, poseidon
 
# And user aliases (for instance, for a set of backup operators)
BACKOPS = bill, mary, evan, carol
FULLOPS = jack, jill, henry, faith
 
# A group of commands we want them to be able to use.
# In this case, we've just provided them shellscripts to do the jobs as needed
# so we don't delegate them too much power, but we need them to be able to do
# some network maintenance.
BACKCMDS = /usr/local/bin/backup-systems.sh, /usr/local/bin/rotate-backups.sh, \
   /usr/local/bin/restore-backup.sh, /sbin/route, /sbin/ifconfig, \
   /sbin/modprobe
 
 
# Here are some simple rules.
 
# We let the full ops have full control via sudo, without having to type a
# password. (The use of ALL implies that there are no restrictions on hosts
# or commands.) terry needs to provide a password, however.
FULLOPSALL = NOPASSWD: ALL
terryALL = ALL
 
# Backup operators need to provide their own passwords to do backup jobs.
BACKOPSBACKUPSERVERS = BACKCMDS
 
# jill is allowed to mount and unmount devices too. She can also run any
# command as the user nobody using sudo -u nobody cmdhere -options -here
jillBACKUPSERVERS = /sbin/mount, /sbin/umount, (nobody) ALL

This is just the tip of the iceberg of possibilities. (Well, like an iceberg can sink a ship, a carelessly-configured sudo can wreck your security, so triple-check your rules.) The /etc/sudoers file can have some very, very flexible rules (including restrictions on what parameters you can provide to a command).

The simplest sudoers file that will let a user (say, bill) total access as root without requiring a password is

billALL = NOPASSWD: ALL

Now, bill can just run

$ sudo rm -rf /

and give you a major headache. ;)

 

Cron: I Really Didn't Forget, The Computer Messed Up

Cron is installed on most UNIX-like systems by default. It's essentially a job scheduler. You can setup 'cron jobs' to cause commands to be run on a schedule that you specify.

You setup jobs by writing a crontab—a file that contains details about when and how often to run a job, and the command to run. Any output from a job is sent as email to the user that set up the crontab. (Well, cron also obeys the MAILTO environment variable, which you can set to an email account to specify a destination for cron notifications, or just an empty string using MAILTO=""; export MAILTO to suppress email notifications altogether.) Here's an annotated example:

# minute   hour   day-of-month   month   day-of-week   command
 
# This job runs every ten minutes, running the command "getmail".
# (getmail is a utility to retrieve messages from a POP3 account.)
# Any output will be emailed to the user (say with userid omg)
    */10      *              *       *             *   getmail
    
# We also want a new fortune to be written to our signature file every fourth
# hour, at 23 minutes past the hour.
      23    */4              *       *             *   fortune > /home/omg/.signature
 
# We want a snapshot of the running processes every minute for the first five
# minutes every half hour.
0-4,31-34     *              *       *             *   ps -ef >> /home/omg/ps.log
 
# And we want an email sent to us every Friday the 13th at 1:13 pm.
      13     13             13       *           Fri   echo Boo | mail -s "Fri 13" omg

You create or edit a crontab by invoking

$ crontab -e

If you have a favorite editor, you can set the VISUAL or EDITOR environment variables; crontab -e will invoke the specified editor. If you have a crontab file on disk already, you can run

$ crontab mycrontabfile

You can list the current crontab (if any) by issuing

$ crontab -l

You can also use the at, atq and atrm commands to set up jobs interactively:

$ at 7:00 am tomorrow
warning: commands will be executed using /bin/sh
at> madplay WakeMeUp.mp3
at> echo Wake up you fool. | festival --tts
at> 
job 8 at 2003-10-11 07:00

(For the curious, madplay plays mp3 audio, and festival is a text-to-speech engine.)

As you can see, at is quite friendly about time specifications. (It even defines teatime as 4 pm. You can list queued-up at jobs using atq:

$ atq
8  2003-10-11 07:00 a amitg

...and you can delete a job before it's run using the atrm command and the job number (the first number on the line in a listing; it's 8 in the example above): atrm 8 will delete the pending wake-up job. (Someone who frequents the Other Hardware forum uses something similar to wake himself up, incidentally—festival cussing at him and some loud music to aid the wake-up process.)

On a system level, an administrator can insert shell scripts into the /etc/cron.daily, /etc/cron.weekly or /etc/cron.monthly directories as appropriate, and cron will automatically run the scripts at the appropriate intervals. Mail containing any output will be sent to the root user (or any alias specified in /etc/aliases).

 

Cool App of the Week

CD burning in Linux has always been about one application, cdrecord. Although useful for scripting and the CLI guru, the average desktop user is looking for an easier way to burn those coasters. Enter K3B, one of the premier CD burning suites in Linux.

These screenshots should give you an idea of the capabilities in K3B. If that doesn't excite you, the K3B team is planning on similar capabilities and user friendly interface for DVD burning, not to mention the DVD ripping and encoding capabilities of the application. K3B is definitely on our Best of the Best list.

 

/dev/random