This will be a command-line tutorial-style article, and we’re gonna get down to basics, so no GUIs or automated installatinos from the Internet (automated dependency management) here. I will, however, make a recommendation as to which dependency management system you should use, because nowadays it would be rather insane to do the following work manually — except for very particular cases in which this tutorial will come in very handy.

Installing packages

You want new software? You have to install it. First you download it from the ‘Net (you’re gonna be looking for a file ending in .rpm), then you install it on your system. As simple as that… in theory.

The basic installation operation in RPM is rpm -i packagename-x.y.z.rpm. I tend to combine it with the -vh arguments which cause a progress bar to appear, and verbose messages to be printed onscreen for a variety of operations within the transaction.

Transaction. With RPM, to ensure the integrity of your computer, either the package installation happens, or it doesn’t happen at all. If you request to install 450 packages in a single command (which you could easily do), and one of them cannot be fit into the system, the transaction fails and your system remains untouched. Reasons for a failure may include that:

• the package you requested to install is already installed, whether the installed one is an older or a newer version
• the package would trample on files owned by another installed package
• the package is bad
• the package requires another package or set of packages installed beforehand — this is called a dependency

All of those reasons, and a couple more, could leave your system broken if RPM were actually to go through with installation. Therefore, RPM stops when it detects any of these conditions.

--force

Unless you augment the command with the --force argument. Trust me when I say this: if RPM is refusing to install a package, under no circumstances should you use --force even if you badly need to. RPM is probably much better informed than you are as to what the system actually needs to continue functioning properly, and you should trust it. --force is only handy when you’re absolutely sure of how the different related components of your system relate to each other.

Upgrades and downgrades

We see that rpm -i will fail if you attempt to install a newer or an older version:

• If you really need to downgrade, you can always append --oldpackage to the command line, and if the integrity checks are A-OK, RPM will downgrade a package for you.
• Conversely, if you want to upgrade, you use rpm -U instead of rpm -i. As a matter of fact, rpm -U will both install and upgrade packages happily, so you can just use rpm -U most of the time, and forget about -i.

RPM will also, in the spirit of preserving your system as pure and functional as possible, refuse to overwrite custom configuration files in your computer. It will, however, deposit them in the folder where they were meant to live, by appending a .rpmnew extension to the new file — so you can use the standard find command to find and inspect these config files, see if they bring anything new and useful to the table.

Controlled mass upgrades of what you already have

What if your best friend shared a CD-ROM with the latest updates — say, 850 RPM files — for your Linux distribution? You could go one by one and install each. That’s not gonna go well, because many of those updates may not be installed on your system.

What you could do instead is use rpm -F. Like issuing a command rpm -Fvh *.rpm while on the CD-ROM directory. -F means freshen — it will only upgrade packages for which older version are already installed on your system.

In theory, you could perform an entire operating system upgrade this way. In practice, it’s a little more complicated because as distros evolve, they start requiring more base packages which you don’t have installed, and -F won’t know which ones are these (although it will tell you which dependency it failed to find installed!). When I say in practice, I mean it — I have used this method to upgrade a machine that just didn’t have enough RAM to run an installer on — and I succeeded, but I had to go in smaller batches of rpm -F’s with some rpm -U’s in between.

Package removal

Want to remove a package? rpm -e is what you’re looking for. As discussed in the previous section, if a removal would break your system, RPM would not let you perform.

Config files are also dealt with gracefully. If you’ve changed any, RPM will save them with the same file name, and a .rpmsave extension. This is incredibly well-thought-out, because you will often need them sooner or later!

Listing and inspecting packages on your system

Do rpm -qa. The -q stands for query, and the -a stands for all. Most RPM commands accept -a as an argument to say all anyway, so it’s good to keep it in mind.

By default, it will present you a one-column list with all the package names and currently installed versions of them. If you want more specific information, rpm -qi packagename (note the use of a package name as opposed to a file name) is usually what you want. And rpm -qpi packagename-x.y.z.rpm (note the filename) is used to inspect uninstalled RPM packages on disk.

Want to know which package a file belongs to? rpm -qf /path/to/said/file will tell you. Very handy!

Integrity verification

Want to see if any files have been modified, and how? rpm -V packagename is the command. It will display a series of lines, one for each file that has been modified, or nothing at all if no files have been touched. Several aspects are displayed in a column-packed display: file times, permissions, integrity and a whole lotta more are included. Checkt he RPM manual page to see what each column means.

Perhaps you’d like a full audit of what’s on your system and what’s been changed? Combine two popluar arguments into rpm -Va. Verify all. It will probably be a long list so make sure to redirect the output to a file.

Getting packages for your distro

Easy. Go to Google, type the name of the package followed by a space and the letters “RPM”. Lots of results will follow. Find those results that appear from RPM repositories (those sites usually say they are RPM repositories, so you’ll have no problem). If one of your packages has a dependency problem, you can also type the dependency name into Google followed by “RPM” — and that will most likely help you solve dependency problems.

Get Smart!

But, honestly, that’s inefficient. Just get Smart, where you’ll be able to add said repositories to the Smart configuration (don’t panic, it’s usually an URL that needs to go into a file in /etc/smart/channels plus a command to import the security key of the repository — and repositories explain this procedure quite more eloquently than I do when I’m this sleepy). Then you will be able to invoke Smart via the command line or the nice GUI it has, request a particular package and install it. Smart will automatically download all the depended packages and install them for you.

Don’t forget to read the Smart manual page!

Conclusions

And that concludes our RPM crash course. If you have any doubts, please add them as comments below. And discuss!

What you’re about to read is a short, true story that details how I went from idea to solution, using the “UNIX way” (divide a problem in little pieces, then jump each hurdle with the help of a domain-specific solution, and finally combine each response).

The story is — honest! — more about the underlying thought process than the technology I used — in fact, while I do know Python and I’ve grown white hairs using Linux, most of the stuff you’ll see here I taught myself in the course of this challenge.

TorrentFlux: what it is, how it works

TorrentFlux is a very interesting Web application you can install on your Web server. Once installed, it lets you in to a nice interface like any other BitTorrent program where you get to add .torrent files so the torrent gets downloaded directly in your Web server. Here it is:

Advantages of using TorrentFlux

The reasons to use such a program instead of a normal desktop BitTorrent client are varied:

• you would like to have a particular, big file (think Linux distro) right away on the server instead of uploading it through your ISP’s connection
• your ISP throttles or blocks BitTorrent (think Comcast)
• you would like to avoid downloading through 50 TCP connections at home, and just use one (think speedier Web browsing)
• you want to take advantage of the (usually) higher bandwidths available in your Web server during the day, and you’d like to download the file once it’s done, from beginning to end (think videos)
• you would like to queue up a download while away from home (think vacations)

Disadvantages

The disadvantages, compared to a regular BitTorrent client, are that:

• if you want the download in your PC, you need to queue it up separately in a download manager on your PC through FTP,
• you need to check TorrentFlux periodically to see if the torrent is done downloading, because you can’t download a torrent to your PC until the torrent is done,
• you can’t queue up downloads from TorrentFlux to your home PC if you’re away from your computer, can you?
• disk space might be limited in your Web server.

What we’ll do in this article is destroy these disadvantages.

The problem in a nutshell

From the aforementioned disadvantages we can clearly see what the problem is. Being the lazy bastards we are, we want the downloads in our home computer ASAP, without manual intervention. Our ultimate goal is to:

1. queue up a BitTorrent download in TorrentFlux, and
2. as soon as it’s finished, have our home PC automatically “check it out from the counter”, and then
3. erase the file from the TorrentFlux server.

Let’s go do it.

How I solved it

Remoting my server

How am I going to talk to my server? This question crossed my mind many times. In the end, I chose SSH, because it’s extremely easy to automate and have it work securely without constant interruptions — remember, we don’t want to be interrupted with password prompts or anything like it.

I wrote the code that more or less provided enough help for it to work. As programming languages go, Python is by far the best for the task at hand, so I used it. OK, I’ll admit it, I’m a Python junkie:

#!/usr/bin/env python

from subprocess import Popen,PIPE,STDOUT,call import fcntl import re import os import sys import signal

def getstdout(cmdline): p = Popen(cmdline,stdout=PIPE) output = p.communicate()[0] if p.returncode != 0: raise Exception, "Command %s return code %s"%(cmdline,p.returncode) return output def getstdoutstderr(cmdline,inp=None): # return stoud and stderr in a single string object p = Popen(cmdline,stdin=PIPE,stdout=PIPE,stderr=STDOUT) output = p.communicate(inp)[0] if p.returncode != 0: raise Exception, "Command %s return code %s"%(cmdline,p.returncode) return output def passthru(cmdline): return call(cmdline) # return status code, pass the outputs thru def getssh(cmd): return getstdout(["ssh","-o","BatchMode yes","-o","ForwardX11 no",torrentflux_server] + [cmd]) # return stdout of ssh. doesn't return stderr def sshpassthru(cmd): return call(["ssh","-o","BatchMode yes","-o","ForwardX11 no",torrentflux_server] + [cmd]) # return status code from a command executed using ssh

Interesting, isn’t it? Now I have two functions:

• one that gets me the text of a command executed by SSH, and
• another that discards the text but returns the return value of the executed command — which, if you know the UNIX convention, it’s zero for success, and anything else for errors.

Determining which torrents are done

The first hurdle I need to surpass: which torrents from the torrent list are already done? After a little poking around the Web, I discovered that with the help of a command called fluxcli that ships with TorrentFlux, I can get a list of active torrents in text form.

So that’s solved. All I needed is some code that parses the rows returned, selects only those rows that say Done or Seeding in the status column, and that should return the name of each torrent that’s ready to download.

The code in question is this:

def get_finished_torrents():
        stdout = getssh("%s transfers"%fluxcli)
        stdout = stdout.splitlines()[2:-5]
        stdout = [ re.match("^- (.+) - [0123456789.]+ MB - (Seeding|Done)",line) for line in stdout ]
        return [ match.group(1) for match in stdout if match ]

Stupidly simple, and it makes use of the SSH remoting functions (dare I say hacks?) I wrote before. And, may I say, only three lines, really. It returns a list with the names of the torrents.

Next up, getting the file names inside the torrents.

• Real speed
• Guaranteed bandwidth
• Unfiltered, unthrottled service
• Reliability and quality of service
• Access from the outside world
• Privacy, neutrality and censorship

Each and every one of these aspects can make or break the honeymoon with your ISP. Each matter independently, and once you’ve done a little research on what your ISP of choice is doing to grant (or deny) them to you, you’ll be in a position to make a much more informed decision.

Bandwidth is not speed. Latency is.

If you are anything like the next person, by now you’ve been led to believe that your Internet experience is determined by bandwidth. That’s bullshit. Bandwidth is hoy many bytes you can download per second — and nothing more.

Anything above 500 kbits per second guarantees enough speed to make Web surfing snappy — if, and only if, the latency of your connection is low enough. Becaus, you see, latency is key — it’s the time your computer takes to initially communications with Web (or other types of Internet) servers.

What happens when you click on a link

After you click on a hyperlink, your Web browser (more or less) goes through the following steps:

1. It connects your computer to a Web server and requests a Web page.
2. It receives the response, starts processing it and (in parallel) starts other requests — to get the images, videos, styles and scripts that actually form the page. But only four of those at a time.

If each of those steps can be started in, say, 50 milliseconds, you’re golden — the page more or less snaps in front of your eyes. But if they take over a second each… well, let’s say you have a problem because, for the average Web page, you will never see it settle down before ten or so seconds since your last click.

What happens when you play games over the Internet

Let’s imagine for a moment that you’re playing Unreal Tournament, or any other fast-paced first person shooter kinda game. Just blink once — boom, you’re dead. That’s how long it takes for someone to shoot your neck and rip your head off.

A blink of an eye is, literally, 25 milliseconds. Not a problem for wireless or wired local networks — because the bullets traveling through the network take less than two milliseconds to get eaten by your enemies. But if you’re gaming through an Internet connection and your enemy is sitting just 200 milliseconds “away”, you’re going to have real trouble making any kills.

Sure, modern games incorporate mechanisms that attempt to compensate for that latency problem. But they only go so far.

What determines latency

Latency is determined by two factors:

1. The physical distance of the route that information takes through the Internet. Not a really big hurdle, since information travels at a rather close factor to the speed of light.
2. The time each “hop” (Internet router) takes to process and forward that information to the next hop.

You can verify this yourself. Open a command line (cmd.exe on Windows, konsole or gnome-terminal on Linux) and type (on Windows) tracert google.com (on Linux, substitute tracert for traceroute). You’ll see a table grow: each row is a hop, and the three columns on the right side are the times, in milliseconds, that information took to reach that hop. The last row will contain the final destination’s latency measurement. You can substitute google.com for your favorite Web site’s address or your gaming friend’s IP address.

So latency is key — now you know that.  Next up: how much bandwidth you’re really getting?

This is a work in progress. I expect and will take your contribution into consideration — use the comment form below to voice your doubts, tips or flames.

With so many companies finally realizing the potential of free software and open source, it’s not surprising at all that some are failing miserably to engage free software communities effectively. Instead of focusing on what they’re doing wrong, let’s focus instead on what they must get right.

With that intent in mind, let’s explore seven principles that will make your life easier when engaging free software types. In summary:

1. Know your audience
2. Your argument must rely on facts and reason
3. Respect community members’ time, rules and terms
4. Develop a thick skin
5. Contribute
6. Be humble
7. Make it interesting, make it fun

Here’s each principle explained.

Know your audience

We’re not all the same. Before even attempting to address us, do your research and figure out the “rules” of the particular community you’re trying to touch base with.

Despite the title of this article, there is most definitely no single “free software community” to address in the first place. It’s all a multitude of communities centered around their own projects, and collaborating between each other in a loosely coupled fashion.

You see, the closest thing we get to have in common is the common core value of sharing = good — and even so, many in our own collective of communities do not necessarily place that value up high in their own scale of values (witness Linus Torvalds, for example). You could possibly argue we all share a passion for technology — which might be true — but we all most definitely do not share even technical proficiency; modern free software communities are chock-full of people doing translation, usability and multimedia artwork.

Some communities are led by consensus. Others, by meritocracy. Some have benevolent dictators. Many projects out there have no defined leadership and are in a stage of transition.

Corollary: do not assume. Do your homework.

Fortunately, this homework is easy:

• You can easily poke around a project’s Web site, skim over technical documents, and invest a couple of minutes reading mailing list archives, to get a general idea of how that particular community beats its drum.
• You can also look stuff up (Google is very free software-friendly).
• Try to familiarize yourself with the issues (esp. technical details). That goes double if you’re a reporter — there are reams of inaccurate stories out there, just because the reporter was lazy enough not to “go to the source”.
• Some communities (the most mature ones, usually) even list guidelines for contributors and explicit rules of engagement.

Therefore, be informed. An ounce of prevention beats a hundred pounds of hammering.

Your argument must rely on facts and reason

In general, free software communities place extremely high value on the ability to argue and persuade using facts and reason.

The reason this is so pervasive in free software is quite clear: every single last drop of development and communication happens absolutely in the open — usually with easily accessible public records. Think about it: past discussions, decisions and the reasons behind each and every one of them are archived somewhere and usually accessible by poking around search engines with the right keywords.

Another reason (I love to call it the “doers factor”) is that, since new ideas can be tested quickly and pitted against each other. Do you think Project X will fare better with wings rather than legs? Prove it! In fact, cloudy proposals usually meet head-on with that sentence in our public discussion forums.

As you can see, “conventional politics” stand little chance against the gospel of “try it and support it” (though they infrequently win some points).

So don’t attempt to convince a community of developers by using slick persuasion. You will be called on it and asked to provide facts backing your points of view. You might also get reprimanded by project leaders because you weren’t diligent enough to “check the archives”. In the worst case, you will be shunned for long.

Respect community members’ time, rules and terms

You need to understand that many people involved with the free software movement are volunteers. Though a large subset of those people will be happy to help you fix any issue you may have, efficiency is key.

That’s why we:

• use mailing lists with public archives,
• use bug tracking systems,
• idle a lot on Internet relay chat channels,
• respond sparsely and oftentimes with the dreaded RTFM acronym.

If you find a bug, please don’t just mumble to yourself — report it through the appropriate channel. Doing so, while requiring a bit of an extra effort on your part, multiplies the effect your report has, because it benefits everyone — not just you.

If you have an idea that you think it may be worthwhile to pursue within the scope of a community, bring it to the table. Try to address everyone in the conversation, not just particular project authors. That way everyone gets an opportunity to shape the idea or to strike it down (in case it’s a bad one).

Same goes if you need help. Especially in this case, you should try to consult with the Lazyweb — mailing lists and search engines should be your first stop. Chances are, someone else already asked and got a publicly available reply.

Develop a thick skin

If you make a mistake, most free software types will call you on it.

Some of us are callous individuals. Sometimes, everyone is distressed or tired. We all are guilty of calling people names at some point. Don’t get discouraged by these events. We might call you an idiot today — that doesn’t mean you’re really an idiot, and sometimes we don’t even mean it!

Some communities appreciate sparseness in discourse. This might be construied by some people to be the equivalent of “go away, outsider; we don’t need you here”. Nothing could be further from the truth — most free software aficionados are efficiency buffs, and talk is expensive. Imagine yourself dealing with hundreds or thousands of e-mails daily in addition to coding or management tasks, and you’ll have a clear idea of what managing a free software project is like. Efficiency is key.

Source code and conversations may contain tons of expletives. I read years ago a report on profanity in the Linux kernel. It’s not pretty if you’re into political correctness but, come to think about it, doesn’t it work just fine that way? Then who cares about the cuss thrown around sparsely?

So try to develop thick skin. Become immune to callous comments, and keep pressing important issues calmly.

And comfort yourself with the fact that, in the medum-to-long run, projects with truly contentious members drown anyway.

Contribute

The whole notion of free software is based on quid pro quo.

We give you something for you to take advantage in any way you please. We expect you to share in equal terms with you. And your contribution has value. We need you. Here are some clever ways you can contribute in effectively:

• We hate bugs, so please report them. Try to provide as much info as you humanly can within time constraints. Try to keep yourself “in the loop” during the process.
• Maintain Web sites and blogs.
• Help with project marketing.
• Write manuals, guides or tips on public sites.
• Deploy a project across the board — then report your issues so everyone benefits.
• Publish improvements to free software projects.
• Develop new code.
• Allocate manpower on collaboration with non-engineering tasks: artwork, translations.
• Fund or donate to projects. A million dollars is fine, but $10 may do it as well.

If you do any of these things (OK, OK, I’ll recognize, some of them are more valuable to us than others), your message is way more likely to come across. Bonus points (yay!) for directly helping the project build its next “killer feature”.

Fact is, if you have something to show, you’ll generate an incredible amount of goodwill towards you.

Be humble

I’ve heard all manner of derogatory comments against us free software developers, from the classic “pinko” to the Cold war-era “hippie”, through the equally ignorant “amateur”.

We’re not amateurs, so get rid of those misconceptions. Each and every one of us is highly likely to be much more proficient and professional in our field of expertise than you. We’ve made a career out of seeding high-quality products and harvesting respect and reputation out of it. Technical prowess is the name of the game for us.

In each field of technical expertise, there probably are a handful of gurus in the closed software industry — and probably an even smaller group of free software developers which are in all likelihood as proficient or even more so than their counterparts doing closed source. This should be self-evident, since free software developers have had access to much more code and learned much more from collective experience resources while having fun at it, whereas the rest probably did it for the money only. You might be recognized by anywhere between ten and a hundred punks in your company, but we’re recognized, revered and relied as sources of opinion and technical expertise for considerably many more people — some of us count their fans and users in the tens of millions.

Each and every one of us has made a name for ourselves. Can you say the same of you? Even if you could, can you co-opt your reputation and technical expertise for the community you’re about to address?

So coming with an attitude of superiority (whatever your reason for that attitude) isn’t going to help your cause.

Be humble, punk.

But don’t get the idea that we’re arrogant just yet. 99% of us are eager to share a few beers with anyone else in equal terms. The other 1% usually die young from lack of human warmth (and alcohol?).

Make it interesting, make it fun

Free software types, believe it or not, are much more play than work. We are honestly entertained by what we do, and when we no longer have fun, we usually delegate our project to someone else with a more pressing need or a newfound passion for our project.

In a sense, we are probably the luckiest people in the world. People who actually enjoy what they do from the outset (as opposed to people who secretly want to hang their boss, or people who have had to learn to like what they do by sheer necessity) are far and few between. And some of us even get paid doing it. I know I do.

Moral: If you can wrap your message around fun and challenge, you’ll benefit.

Conclusion

Let’s recap, one more time:

1. Know your audience
2. Your argument must rely on facts and reason
3. Respect community members’ time, rules and terms
4. Develop a thick skin
5. Contribute
6. Be humble
7. Make it interesting, make it fun

These principles might sound like common sense, mixed with a few unexpected nuggets of unique free software idiosyncrasies. Even so, every day people fail to heed this advice — hey, I’m guilty of it myself! But it’s never too late to bump the steering wheel and change course.

I hope this article enriches your future experiences with the free software community as much as writing it has enriched me. I wish you the best of luck, and welcome to the free software world!

The problem

What’s the number one cause of desktop performance problems?

Let me answer that question with another set of questions:

• Have you noticed how slow your computer is after after unzipping a big file?
• Perhaps you can also notice this effect overnight as well — you return to your computer, and every open application takes a while before they behave snappily again.
• Do you use Amarok? Then you’ll notice this effect after Amarok has finished scanning your music collection.

This problem happens all the time. In fact, I would be willing to bet this is the cause most people find Linux to be slow.

The source of the problem

Here’s my chief finding: desktop performance has very little to do with schedulers and real performance. It has everything to do with disk caching and perceived performance.

Now, bear with me for a second, because what I’m about to explain will let you understand the following. Based on my limited understanding of the Linux kernel (please correct me if I’m wrong, especially about the terminology), there are two distinct cache types:

• a block cache: caches block device contents
• a inode/dentry cache: one layer above the block cache, caches directory entries and other filesystem-related things that cost more to look up than just block device contents

Problem number 1 is that the block cache competes with applications for RAM. Problem number two is that the block cache competes with the inode/dentry cache.

On a normal desktop Linux computer, when you’re short of RAM, Linux will aggressively try to free memory to enlarge the caches. It usually does this by paging out unused portions of applications to disk. This is not good.

Why? Since disks are slow, the following consequences follow:

Let’s get technical (skip this heading if you’re uncomfortable with technicalities)

For desktop performance, where workloads are unpredictable, responsiveness needs dictate that applications’ working sets should be in core as much as possible, because the probability of major page faults in desktop loads is much larger than on server loads.

Let me rephrase that: Screw data. Prioritize code.

In other words: it’s OK if your application stalls a bit while reading non-cached data from disk, because that isn’t going to make the application seem frozen for a couple of seconds. It’s not OK if the application freezes because it needs to execute code that was paged out to disk.

All in all, how Linux uses your RAM matters a lot for desktop performance

You can see where this is going: if you have 1 GB of RAM (or less) you unzip a 300 MB archive, and the Linux kernel will swap out portions of your applications to disk in an effort to accomodate both the 300 MB file and the blocks of the uncompressed files about to be written on disk. It will also shrink the inode/dentry cache.

Linux, of course, thinks it’s doing a good thing — the archive uncompresses, in effect, rather quickly because of this. You, of course, want to kick Linux in the nuts because while (and after) the uncompress took place, starting an application or opening a new browser window suddenly takes ages, and your open applications “blank out” for a couple of seconds before reacting to your clicks and keystrokes.

Think about it: Linux is catering to the needs of the uncompression program, and you are actively telling your computer you want to do other stuff while it happens. Linux starts to scramble between reading the archive, writing data to disk, and bringing the portions of the applications you’re using “back from the dead” (from swap). Guess who loses? If you guessed “the applications” or “you”, you’d have been right.

Even worse: suppose you want to browse your home directory while all of this happens. In addition to the fact that your file manager is probably half-on-disk by now, you’ve got the problem that Linux needs to re-read your home directory, since the inode/dentry cache has been squashed.

Not good. I posit that the default settings may be very good for workloads with many repeating tasks, but definitely ungood for desktop situations, when applications (and code paths) are diverse and respond only to the whims of the user.

What we want is perceived performance

Let’s take a file manager for example. Let’s focus on Konqueror (it’s a nice case study, and it’s a nice file manager). Suppose I hit the home button on my panel, which shows one of the (usually hidden and prelaunched) Konqueror instances and prompts it to browse my home directory.

If you have lots of RAM, it won’t be a problem — both Konqueror and the contents of your home directory will be in memory, so it’ll be blindingly fast. But if you’re rather short of memory, it’s a different matter — what happens next determines whether you feel your computer slow or fast.

If Konqueror has been paged out, it will appear to be frozen (or take longer to “start up”) for a couple of seconds, until Linux has paged necessary code paths in. If, on the contrary, my home directory has been evicted from the RAM cache, Konqueror will show up instantly and be responsive, while the home directory loads.

I’d much rather wait for the directory display than have to wait for Konq to unfreeze because it was paged out. The difference is that in the first scenario, I can close the window, use the menus, navigate among the window controls, change the URL, abort the operation; in the second case, I’m screwed until Linux decides to fully pagein whatever Konq needs.

That’s what I’m arguing for — perceived performance, not throughput. It matters to me that I can manipulate my file manager half-a-second after I’ve hit the home button. It doesn’t matter to me that, because of this preference, the home directory actually takes one second longer to finish displaying.

Variations of this pattern can be found everywhere: in file open dialogs, in multimedia applications with collection managers, basically everywhere an operation requires some sort of progress report.

The solution

There are two distinct and complementary measures we’ll take to solve this problem. Keep reading to find out about them.

So what do I do?

I run Nuendo on Linux. Here’s a quick primer — you should be familiar, very familiar with Linux in order to do this.

But Nuendo didn’t work originally. That’s because Nuendo requires something called ASIO, related to low-latency audio output — why this is required on Linux as well escapes my comprehension, since Linux already has very low-latency output.

Here’s what I did.

Install wine and wine-dev

I’m using KUbuntu Feisty, so your mileage may vary, but you need both packages (yes, the development package as well) because you will be compiling something after a few minutes. In case you’re using RPM-based distros like CentOS or Fedora, the development package is wine-devel.

Link Nuendo to your ~/.wine/drive_c folder

I never “installed” Nuendo using the installation software. I just linked my Windows partition to /home/rudd-o/.wine/drive_c. In my machine, that’s where Wine expects to find the C: drive.

Your mileage may vary. You may want to copy the contents of your C: drive there, or use winecfg to point Wine to the right directory.

Download wineasio

wineasio is a library that allows Wine’s JACK output plugin to serve ASIO programs. Nuendo is one of those.

Here’s the download.

Install JACK and its development files

In my machine, the two packages I needed to install were jackd and libjack0.100.0-dev. Again, your mileage may vary.

Get asio.h

asio.h… I got that file using a samizdat method, because otherwise I would have had to sign an agreement with Steinberg. Turns out asio.h is quite widespread in the World Wide Blag. Just jump here and copy the text. If this link ever dies, just look for file:asio.h in Google Code Search.

Uncompress the wineasio tarball

And then place the asio.h file in the uncompressed folder.

Compile and deploy

• Open a terminal and change to the wineasio uncompressed folder.
• Run make. At this point, if you failed to install the required development packages, you will see a slew of compiler error messages. Go back and reread the earlier sections.
• Then, as root, run make install.
• Then, back as your regular user, run regsvr32 wineasio.dll.

Configure Wine to use the JACK driver

Run winecfg on the terminal. On the Audio tab, select the JACK output plugin.

Now I had to do a fix, because my Wine installation wasn’t finding a file named libjack.so.0. I did this:

ln -s /usr/lib/libjack-0.100.0.so.0.0.23 /usr/lib/libjack.so.0

So go find a library named libjack-0.something.so.something, and link it so it’s named /usr/lib/libjack.so.0. Why my distribution failed to do this for me, escapes my understanding.

Start the JACK driver

This is easy. I used the command jackd -d alsa -r 44100.

Start Nuendo

Use your terminal to change to your Nuendo folder, and then run wine nuendo.exe.

Pay attention to any of the error messages. If Nuendo starts up and doesn’t say that the audio engine couldn’t be enabled, then you’re set to start recording and playing back.

Good luck with your Nuendo and Linux. Now, if you’ll excuse me, I’m heading for my latest 6-hour set/megamix.

Update: I have a showcase of two alternate methods that use VMware and Windows directly if you can’t make this work. I know it’s hard to make this method work, and with my machine recently updated to Kubuntu Gutsy Gibbon, this method stopped working.

If you’ve been using Linux for a while, no doubt you’re already amazed with the amount of software there is for you to use, for free. My own last count revealed in excess of three thousand applications ready to install and use. But how do we find the gems?

Look no further, because here they are. These are tools I use on a daily basis to both diagnose my own Internet connections and network performance in remote hosts. You can’t claim to be a network management expert if you haven’t used at least 5 of these tools, but you don’t need to be an expert to use them either, because they’re brutally easy to use.

The net essentials in our toolbox

Let’s explore the first three tools in our toolset. They’re powerful and easy enough for you to get an overview of what’s going on with your Net connection.

KSysGuard: view aggregate network traffic

My favorite, in all aspects, is KSysGuard. With it, you can plot network usage for all your network interfaces (even though in 99% of all cases, there’s only one network interface, and it’s named eth0). Take a look at this screenshot:

It’s not black magic. It’s a sheet divided in rectangles, where you can drag and drop the sensors listed on the left to any of the empty rectangles on the right. When you place any of the sensors on the left, KSysGuard starts plotting.

Bonus points for KSysGuard: you can keep tabs on a remote machine via SSH. All you need to do is:

• create an account on the remote machine,
• install a small program named ksysguardd (which you can find after installing KSysGuard in the path /usr/bin/ksysguardd) on the remote machine,
• set up passwordless SSH authentication for that account,
• connect with KSysGuard to the remote machine using File -> Connect to machine…

The ksysguardd program is self-contained so you can be confident you won’t be introducing security issues.

Here’s an overview sheet plotted from a remote machine (in this case, this Web host):

Here’s another, showing my MythTV PVR and backup machine:

Oh, did I mention KSysGuard can plot much, much more than just network traffic? I guess not, but the screenshots speak for themselves. Oh, and the screens are fully customizable, down to the colors used to plot the graphs. You can save the worksheets for later usage as well.

To install this tool, use your distribution’s favorite package manager, and look for KSysGuard or the kdeadmin package.

In the next page, we’ll explore the different uses of netstat.

(May I respectfully request, if you like this article, that you use one of the links right below to submit it to your favorite news site?)

Misbehaving application frozen?

Has an application stopped responding on your machine? Well, as long as your machine is still responsive, you can use these tricks to nuke it safely.

On KDE

Hit Ctrl+Alt+Esc. Your mouse cursor will change — from an arrow to a small skull/crossbones combo. Hit the stubborn application with the skull.

It’ll die.

On GNOME

Add a new launcher to your panel and set it so it executes the xkill application. Now, when an application starts stupidifying itself, just hit the launcher you created (the cursor will change to a square-type “target”), then hit the application with your mouse cursor.

It’ll die.

Application choking your machine?

Of course, if your machine is already too slow to use these tricks, they won’t help you much. Here’s why, sometimes, your machine ditches itself into a molasses pit, and how to rescue it from certain death.

Memory and pathologies

You see, almost all applications have this pathological idea (encouraged by the operating system) that memory is a limitless resource — and when they go overboard, the operating system just dips into the hard disk to simulate memory.

Sometimes, bugs in an application do cause them to go haywire, requesting memory like there’s no end. Once your machine goes down that lane, there isn’t a simple way to recover it, short of powering it off forcibly.

A fortress-like operating system like Linux isn’t supposed to die, and yet it does. However, the fortress I’m so proud of can, and does, provide you with effective measures against premature deaths of these sort.

A last-resort trick to recover your machine from the brink of death

Have you heard of the magic SysRq key?

No?

Well, it’s magic. It’s directly shunted to the Linux kernel. You press ALT, press the PrintScreen (SysRq) key, and while holding them both down, press one of the letters (each letter has a different function assigned to it).

It’s not normally enabled, but you can enable it by putting

kernel.sysrq = 1

in your machine’s /etc/sysctl.conf file. Oh, and then rebooting.

Here’s why it’s useful.

So, what does SysRq do, really?

Suppose a GUI application you just opened is starting to swallow massive amounts of RAM. Like, one gigabyte, perhaps? Your machine is locking up, and you feel the mouse start to stutter at first, then freeze completely — while the hard disk light in your computer’s front panel is lighting up frantically, gasping for airmemory.

You now have three choices:

1. Sit it out and let the Linux kernel detect this situation and kill the abusive application. This can take way more than 15 minutes.
2. Press the computer’s power off button for 5 seconds. This shuts your machine down uncleanly and leads to data loss.
3. Hit the magic SysRq combo: Alt+SysRq+K.

Should you choose option 3, the graphical subsystem dies immediately. That’s because Alt+SysRq+K kills any application that holds the keyboard open — and, you guessed it, the graphical subsystem is holding it open. This premature death of the GUI causes all GUI applications to die in a cascade, including the abusive application.

Two to ten seconds later, you will be presented with a login prompt.

Sure, you lost changes to all files you haven’t saved, and all the tabs in your Web browser… but at least you didn’t have to reboot uncleanly, did you?

But, Ctrl+Alt+Backspace?

Once the machine is in a critically heavy memory crunch, Ctrl+Alt+Backspace will take too much time to work, because the windowing system will be pressed for memory to even execute. The magic SysRq key has the luxury of not having that problem — if Ctrl+Alt+Backspace were an IV drip, SysRq would be like a central line.

Why this key combination exists

The reason this key combo exists is simple. Alt+SysRq+K is called SAK (System Attention Key). It was designed back in the days of, um, yore, to kill all applications snooping on the keyboard — so administrators wishing to log in could safely do so without anyone sniffing their passwords.

As a preventative security measure, it sure works against keyloggers and other malware that may be snooping on your keyboard, may I say. And it most definitely works against your run-of-the-mill temporary memory shortage ;-).

Advantages/disadvantages

Well, the major disadvantages are:

• Anyone with keyboard access can reboot or hang your machine using a SysRq key combination.
• Once you hit it, since the GUI dies, all of your open applications close, forcibly.

But, on a memory crunch, this beats rebooting hands-down. And that’s the biggest advantage.

A definitive cure to runaway applications

Become an administrator (root) and use your favorite text editor to open the file /etc/security/limits.conf:

# /etc/security/limits.conf
#

Each line describes a limit for a user in the form:

#

<domain> <type> <item> <value>

#

Where:

<domain> can be:

- an user name

- a group name, with @group syntax

- the wildcard *, for default entry

- the wildcard %, can be also used with %group syntax,

for maxlogin limit

#

<type> can have the two values:

- "soft" for enforcing the soft limits

- "hard" for enforcing hard limits

#

<item> can be one of the following:

- core - limits the core file size (KB)

- data - max data size (KB)

- fsize - maximum filesize (KB)

- memlock - max locked-in-memory address space (KB)

- nofile - max number of open files

- rss - max resident set size (KB)

- stack - max stack size (KB)

- cpu - max CPU time (MIN)

- nproc - max number of processes

- as - address space limit

Add the following line anywhere on the file:

*      soft      as      512000

You will need to restart any sessions (graphical/terminal) for this change to take effect. Additionally, you will need to restart the graphical session manager (GDM or KDM).

Of course, 512000 is just my favorite setting — but that’s because I have the privilege of using multi-gigabyte memory sticks on my machine. If you have much less memory than me, you will want to tune this, while keeping in mind that modern applications can and do take more than 300 MB under exceptional circumstances.

Like, for example, Firefox with 50 tabs/windows open. Or Evolution managing 2 GB of e-mail. Hey, both circumstances happen to me, but I guess I’m an oddball.

What this “magic incantation” in limits.conf does

limits.conf is the file that lets you set per-user/process/system resource limits. There are several limits to choose from.

One of them is the address space (as). The address space refers to the maximum amount of RAM (in kilobytes) that a process may request from the operating system. Any requests above the configured limit are simply refused.

Advantages/disadvantages

The fortunate side effect of this recipe is that the majority of applications will disappear and die a horrible death if they request memory indiscriminately. Which beats having to turn the machine off.

The unfortunate side effect of refused requests for more memory is that the majority of applications will disappear and die a horrible death if they request memory indiscriminately. That’s because they don’t know how to cope with more memory. Until software developers actually implement error handling for lack of memory, this will be a small nuisance — hey, save often and you’ll be safe ;-).

Temporarily disabling memory limits for picky applications

Another disadvantage: certain applications don’t run when a limit is set. WINE is among those applications. However, you can use a terminal window to disable this limit temporarily (within any applications started from the terminal):

[rudd-o@andrea /media/windows/UnrealTournament]$ ulimit -v unlimited
[rudd-o@andrea /media/windows/UnrealTournament]$ wine System/UnrealTournament.exe

That’s it for this tutorial

So, the infrequent dead application, SAKing your computer, or powering it off… what do you prefer? Me… well, once I upgraded my new “desktop” machine (1U Dell PowerEdge SC1425) to 2 GB, I haven’t looked back.

But my old machine did thank me a lot for keeping it off memory crunches :-). It’s now safe in PVR heaven, piratingtime-shifting TV shows for my pleasure.

Excellent picture quality is important if you use MythTV a lot. Unfortunately, if you’re using a standard Brooktree (bt848 or bt878) video capture card, the default settings of your card work against you. You might have noticed light colors washed out, color ringing on sharp vertical lines, brightly lit areas of the video flashing rapidly, and a general picture darkness that doesn’t make MythTV justice when comparing it to a TV set or TVTime.

We’re about to fix that for ya.

Step 1: install the adjust filter on each channel

First, we fix recording. Brooktree-based cards have a bug that causes it not to capture colors correctly. Using a MythTV filter, we can beat the color space delivered by the card into the standard.

Use the MySQL client to execute this command on the MythTV database (usually named mythconverg):

update channel set videofilters='adjust=0:255:1.0:2:253:1.0';

That adjust filter will map the incorrectly captured colors to the standard TV color space. Now recorded videos will contain the right color balance and brightness/darkness mix.

Note that, if you add any new channels, you will need to re-run this command.

Step 2: adjust gamma correction on your monitor and enable deinterlacing

Now it’s time to adjust the gamma correction and interlacing adjustments.

What gamma correction does is lighten or darken the picture up. Think of gamma as a way to make the picture brighter or darker in average, without making the light parts lighter or the dark parts darker. Brightness controls are inferior to gamma, because gamma, unlike brightness, doesn’t make light colors look “burnt”.

Unfortunately, the standard X Window System gamma control usually has no effect on video (Xv) windows (though NVIDIA card users can use the nvidia-settings gamma correction control which will work properly). Fortunately, the same adjust filter has a gamma correction argument, and we’ll leverage it. This time around, the adjust filter won’t change the color map.

Now open MythTV and go to the Playback options screen:

• Enable kernel deinterlacing (unfortunately, there isn’t a better deinterlacing algorithm in MythTV — TVTime still beats the competition in this department).
• If you could not alter the gamma of Xv video windows, do this: just below that option, set this playback filter on the playback: adjust=16:235:0.7:16:240:1.0. Change the 0.7 in there to suit your tastes: the lower the number, the “brighter” the picture will look. I use that number because my monitor is fairly old — in theory the ideal number would get your monitor from the standard PC gamma of 1.5 to the TV gamma of 2.2, but I have no idea what the right number is — I just set it up so my old monitor looks good.

The second step will cause loss of some color information on playback. However, the recorded video preserves the full color range.

Step 3: eliminate dot crawl (color ringing around sharp lines)

A frequent problem with Brooktree-based cards is dot crawl: vertical and diagonal lines on the picture display rapidly alternating patterns of colors in a vertical or staircase fashion. Besides being unnerving, it costs you picture quality, because the video encoder will spend many bits to encode these rapidly changing artifacts instead of spending them on the detailed portions in the real picture.

Install these commands on a file named /usr/local/bin/fixbttv. These commands will enable certain types of processing in your video capture card that will eliminate dot crawl:

#!/bin/bash

v4lctl -c /dev/video0 setattr 'combfilter' on v4lctl -c /dev/video0 setattr 'agc crush' off v4lctl -c /dev/video0 setattr 'whitecrush upper' 255 v4lctl -c /dev/video0 setattr 'whitecrush lower' 0 v4lctl -c /dev/video0 setattr 'full luma range' on

Full luma range ensures that your capture card captures the entire color range.

Oh, forgot to mention it: the AGC crush control we’re turning off here basically stabilizes the picture produced by my card. If you see a light “blinking” of the picture, this will help.

Don’t forget to make it executable with chmod +x /usr/local/bin/fixbttv.

Then create the file /etc/modprobe.d/bttvwith these contents:

install bttv modprobe --ignore-install bttv && /usr/local/bin/fixbttv

Finally add the command /usr/local/bin/fixbttv to the file /etc/rc.local.

Step 4: restart your machine

That’s it. I hope the good six hours I spent figuring this out helps you pimp your MythTV in ten minutes. Just to be sure, take a “before” and an “after” videoclip so you can compare the results.

Now, for a question: why on Earth does xvattr -a XV_GAMMA -v 1300 work for only a hundredth of a second, then stops working? I’m using an ATI Mobility Radeon if it’s relevant.

The netrepaird script

First off, here’s the netrepaird script. It’s a simple script that attempts to ping network addresses (that you can define yourself), and if all pings fail, it’ll attempt progressively agressive measures to repair your network connection. It’s really low-tech, but it works.

There’s an updated, more featureful script here.

#!/bin/bash

# edit these variables to suit your needs HOSTS="rudd-o.com gplhost.com mozilla.org" # define hosts to ping here INTERFACE="eth1" # define the name of your network interface DRIVER="cdc_ether" # define the driver (kernel module) of your network interface

SUDO="sudo" # define to use sudo

netconnected() {

for host in $HOSTS; do NETCONNECTED=no $SUDO ping -c 4 $host > /dev/null [ "$?" == "0" ] && { NETCONNECTED=yes ; return ; } done

}

ifdownifup() {

$SUDO /sbin/ifdown $INTERFACE $SUDO /sbin/ifup $INTERFACE

}

reloaddriver() {

$SUDO /sbin/ifdown $INTERFACE $SUDO /sbin/modprobe -r $DRIVER $SUDO /sbin/modprobe $DRIVER $SUDO /sbin/ifup $INTERFACE

}

netconnected [ "$NETCONNECTED" == "yes" ] && { exit ; } # network is OK

echo "Network problem, toggling network interface $INTERFACE" ifdownifup ; netconnected [ "$NETCONNECTED" == "yes" ] && { echo "Network OK after interface toggle" ; exit ; }

echo "Network problem, reloading driver" reloaddriver ; netconnected [ "$NETCONNECTED" == "yes" ] && { echo "Network OK after driver reload" ; exit ; }

echo "Network is definitely down" logger -t netrepaird -p local0.warn "Network is down, could not repair connection" exit 1

Installing this script

Put this in the file named /usr/local/bin/netrepaird and make it executable (chmod +x /usr/local/bin/netrepaird).

Making it run every minute

That’s right, it’d make no sense to just chuck the script on your hard disk. For this, we’re going to make it run periodically, every minute. Edit your administrator’s crontab file:

• Ubuntu users: sudo crontab -e
• Fedora users: su -c 'crontab -e'

and place this line on the crontab file:

* * * * * /usr/local/bin/netrepaird

Small gotcha: make sure you put a carriage return at the end of the file, otherwise cron doesn’t execute the command.

That’s it

That’s it. Now, every minute, the script will run and check for an available Internet connection. If the connection flakes out for whatever reason, it’ll attempt to take it down and up, and if that fails, it’ll attempt to remove and reload the device driver and restart the connection.

And if those measures fail, your root user will get an e-mail with the warning, and a message will be duly noted in the system log file.

Packagers?

If any of my readers is interested in packaging this for a distribution (which would entail separating the configuration from the script), please contact me to get help.

Happy hacking!

/usr/sbin/pppd pty "ssh myinternetserver.com -t -e none -o 'Batchmode yes' \
/usr/sbin/pppd" 192.168.16.1:192.168.16.254 local nodetach silent \

This is all you need to create a secure tunnel between your computer and a computer that has the SSH running (in the example, myinternetserver.com) on the Internet.

Once you run this command, both your local and your remote computers will have new PPP network interfaces:

• Local: interface ppp0, IP address 192.168.16.1
• Remote: interface ppp0, IP address 192.168.16.254

But a few quick and easy preparations are needed in order to run and take advantage of this kind of tunnel.

The SSH server installed on the server, pppd on both machines

This should be self-explanatory. Use your Linux distribution’s package management tools to install them — should take less than 1 minute.

The right pppd configuration

You use the /etc/ppp/options file to configure it. Most options, once set in the configuration file, cannot be overriden in the command line.

On the server’s /etc/ppp/options file

lock
noauth
ipcp-accept-local
ipcp-accept-remote
noproxyarp

On the client’s /etc/ppp/options file

lock
noauth
noproxyarp

The right security configuration

[root@mycompanyserver.com #] /usr/sbin/groupadd -r ppp
...(add your SSH login user name to the ppp group in /etc/group)...
chown root.ppp /usr/sbin/pppd
chmod 750 /usr/sbin/pppd
chmod +s /usr/sbin/pppd

Now only members of the ppp group (namely, you) can join the fun.

SSH public key authentication enabled

• Put PubkeyAuthentication yes in the server’s /etc/ssh/sshd_options.
• Generate an SSH key pair in your computer.
• Upload the public key of the generated pair to your server’s ~/.ssh/authorized_keys2 file. Don’t forget to chmod 600 that file, or else SSH won’t even look at it.

That’s it!

Now run the following command on your computer:

/usr/sbin/pppd pty "ssh myinternetserver.com -t -e none -o 'Batchmode yes' \
/usr/sbin/pppd" 192.168.16.1:192.168.16.254 local nodetach silent \

What this command basically does is start pppd locally, tell it to connect via SSH in batch mode (using the public key, so it doesn’t ask for your password), start pppd on the remote server, and use the SSH connection as their conversation path.

Wait a few seconds. pppd will utter a few things:

Using interface ppp0
Connect: ppp0 <--> /dev/pts/7

You will have to confirm that the PPP interface is up:

[youruser@yourcomputer $] /sbin/ifconfig ppp0
ppp0      Link encap:Point-to-Point Protocol
          inet addr:192.168.16.1  P-t-P:192.168.16.254  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:5 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:75 (75.0 b)  TX bytes:69 (69.0 b)

Now you can ping 192.168.16.254. If pinging fails, check the firewall rules on both the server and your computer.

To interrupt the tunnel, hit Ctrl+C on the terminal that holds the running pppd command.

What next?

Bringing the tunnel up is actually one part of the deal. If you’re like me, perhaps you’ll want to actually carry all of your network traffic across the tunnel.

Set up the remote server to route traffic for you

This is easy. On the server, either:

• set firewall rules that will do NAT between the PPP interface and the Internet; or
• replace noproxyarp with proxyarp in the (server’s) /etc/ppp/options file; then set aside an extra IP address in the (server’s) local network; then use it as the remote endpoint in the pppd command. If your server has IP address 2.3.4.5, then provision 2.3.4.6 and use it instead of 192.168.16.254.

Set the default route to be the tunnel’s remote endpoint

If you want to route all of your network traffic through your newly created PPP link, you need to do two steps in this order:

1. Manually add a route to your server, so the SSH traffic knows the physical route it should follow. If the IP address of your current default route is 4.5.6.7, then run route add mycompanyserver.com gw 4.5.6.7
2. Replace the default route. Run route add default gw 192.168.16.254 dev ppp0

Before you suggest the pppd’s defaultroute option: no, it won’t work, because it’ll disrupt the only communication route between your computer and the remote SSH server.

Perhaps you’d like to add manual, shorter routes to your DNS servers — otherwise Web browsing may get a little slow. You know, due to the latency of the tunnel and stuff…

After doing this:

• your computer will send all (SSH) traffic to mycompanyserver.com through your regular default route, so the tunnel keeps working fine;
• the rest of the traffic will go through the PPP interface (notice we named the remote IP address in the default route command?)

Combine this with the proxyarp option on the server, and you have a recipe to make your computer appear as a completely different computer on the Internet. Perfect for anonymizing your real computer!

More Linux questions?

Have a Linux question? Why don’t you drop by our Month of Linux Answers and leave your question as a comment? I’ll get to it right away :-).

Why automation?

If you’re running a single Web site or blog, it makes little sense to automate tasks, since 99% of your maintenance tasks will be ad-hoc. But that’s not my case.

I run three Web sites, two of them WordPress-based. In my scenario, WordPress upgrades and enhancements come in pairs. My sites demand an assortment of more than 100 plugins and themes, so those need to be upgraded as well.

I also sell a customized WordPress package, called Turbocharged. Remember the 100 plugins and themes? Well, every so often I do a new release of Turbocharged, which is almost exactly what powers my Web sites.

As you may have guessed, releasing such a huge package is is a time-consuming process! Combined with upgrading my own sites to the latest edition of Turbocharged, it often takes the better part of a day. And doing it manually is not an option, especially since my Web assets are expected to grow in the future.

Ideally, I’d like upgrades and enhancements to:

• be a 10-second process I can run on my Web server: saving a day, even if it’s just to squander it in drinks and clubbing with my buddies, is worthwhile. Less time spent in operations, more time for creativity and long-term progress.
• take advantage of my already-existing Subversion repositories: that way, I can make quick fixes on my Web server, and have the changes transparently imported into my development computer, and the other way around. Turbocharged customers also benefit from this, because I run a bleeding edge Turbocharged copy on each of my sites.
• be error-proof: if something fails, I want to know why it failed. If a file changes, I’d like to know when, in what way and why. I simply can’t take any downtime.

Can this be done? The answer is yes. I know it because I just invested six hours to make it happen.

And you can do it too. Be forewarned: this guide requires learning about new software.