So it seems Ubuntu, a distribution I have grown to like more and more of late (especially every time something breaks in Debian Sid), has decided that init has got to go. Their answer? Not any of the various attempts to replace it in the past, but once again start from scratch with something called Upstart. While I agree that init is one of the many parts of typical GNU/Linux system that desperately needs to grow out of the 1970s, I'm not sure that Upstart is the right way to do it.

As both of my avid readers have likely noticed, this blog has not been particularly active of late. That is to say, today is the one year anniversary of the last time it was actually used. :-) So what do I do to celebrate? Rebuild the whole thing from scratch, of course!

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.

Like most people on the Net, I make some use of Yahoo! services. It's not easy to avoid it. Hundreds of thousands of people have a Yahoo! email address, just as many use Yahoo! Messenger, and Yahoo! Groups is "the new usenet" for many subjects. That's not even counting Yahoo!'s various other branding efforts.

Before I continue, I'm going to drop the stupid ! in the company name. Yes it should be there for accuracy, but good grief can we be a little less self-important? Thanks. Anyway...

The advantage of one company offering all of those services is that you have only a single sign-on to worry about. One name, one password, one bookmark, and you have all of your services at your fingertips. That's great... right up until you get butterfingers. It's also a single point of failure; one problem can bring down your entire PIM network.

So I finally bit the bullet and switched to KDE 3.4. Those who know me will know that I am a big fan of the KDE team's work, and every version has some compelling reason to make me upgrade. There are a couple of them this time around, although as always there's a few places that need some work.

My main desktop runs Debian Sid, the "Unstable" variant. Of course, in practice it's still fairly reliable despite the name. Things do get weird on occasion, but so far nothing show stopping. It's also reasonably up to date (usually more so than Gentoo stable but less so than Gentoo unstable, or masked, or whatever they call it), but KDE 3.4 has been delayed because Sarge, the current Testing version of Debian, is soon to go stable, and the fewer big changes there are in Debian right now the easier that will go. Fair enough, I suppose. Fortunately, the Debian-KDE team has made pre-release packages available for impatient folks like me. Thanks guys! Installation was fairly smooth, except that the kdelibs-data package wanted to overwrite a file owned by kplayer (a video player based on the mplayer engine, for those not familiar with it) and kplayer wouldn't uninstall until kdelibs-data was done installing. A quick Force Overwrite (a useful Jedi power) solved that, and I was soon staring at the new and improved KDE 3.4.