Some people complain about how GNU/Linux isn't desktop-ready. It's too hard to use, the applications aren't there, it does things in silly and quirky ways... We've all heard the list. And some of us persevere anyway.

Recently, though, I've been working on-site with a client for a few weeks on a PHP project. The web app we are building is on a remote GNU/Linux server. Our desktops are all Windows XP SP2, of course. Because I need to edit the files locally but test them remotely, I need a fair bit of network transparency. Of course, Windows XP provides none unless everything is using SMB, which our production web server does not (naturally). So what setup did I have to cobble together?

In an earlier post, I mentioned some research I'd been doing with regards to Linux-based server software. To be more specific, I was investigating shared web hosting control panels. Most any web hosting service you find offers a web-based control panel. Generally such a system allows each user to manage their domain information, files, mail accounts, FTP accounts, and other such common features, and allows the admin to manage different user and reseller accounts. Some users get access to run web scripts, some don't, some have more disk space than others, etc. Some require specific underlying server software (a specific Apache version, postfix vs. qmail for email, etc.), others support a variety of alternatives.

As various associates and friends of mine know, my typical Linux distribution of choice is Debian. Once upon a time, the main thing that differentiated Debian from other distributions was a nifty suite of tools called APT, or Advanced Packaging Tool. While users of "those other distributions" wallowed in RPM hell, having to track down package dependencies manually, Debian users relied on a vast online archive of packages all parsed by the apt system. By using the apt-get tool Debian users could install one package, and all required dependencies would be installed and configured automagically. No scouring the 'Net for a specific version of an RPM. Coolness!

Lately I've been reviewing Linux-based server software for a client. I have setup a dedicated test server that I can break, and to avoid rolling my office chair around the room to get anything done (fun as that may be), I've been accessing it almost exclusively via ssh from my desktop.

Generally when I need to download a new program to test, I just wget it on the server and then do whatever it is I'm going to do. That is, until one program didn't offer an actual URL. No, to use their software, you had to use their super-cool download redirect method. Boy I hate those, even apart from the problem of not being able to just wget a file. So I had to download the file on my main desktop and then shuffle it over. Minor annoyance, and computers are supposed to be helpful, not annoying.

In recent weeks I've been looking into a few open source Content Management System (CMS) projects. My initial interest was not, actually, in using a CMS but in finding one to dissect in order to get a better feel for building large, plugin-based application frameworks. There is a severe lack of documentation on plugin-based frameworks in general, so in true open source fashion the next step for me was "Use the Source, Luke!"

I only looked at a few, really, before I stumbled across Drupal. (To be fair, it had been recommended to me by a friend and fellow blogger.)

At the end of my last entry, I hinted at some network restructuring I'd done in the fallout of Yahoo deciding to take its network and go home. To be more specific I was just putting the last finishing touches on what was already (I think) a cool use (or abuse, I'm sure some would claim) of the DNS network. While my setup has evolved a bit over time, I am going to explain its current, theoretically final incarnation in the hopes that it proves useful to others who wish to go nuts with DNS in order to run fancy servers on a dynamic IP address.