March 2008 Archives

I've already written most of my Ubuntu 8.04 beta review, which I'm holding onto for the time being. I don't usually run -- or review -- beta releases, but this time I'm making an exception because a) most Ubuntu releases are hotly anticipated and b) Ubuntu's second-ever long-term-support release is a huge deal for me as a big fan of releases that have lives longer than the standard six months to a year.

I ran into a problem starting Friday. I couldn't get any updates from the Update Manager. I then ran Firefox and discovered that my networking was dead. I hadn't changed anything, but I couldn't even ping anything on the local network. I checked my static IP information in Network Settings. It all looked fine.

The next thing I did was reset my Ethernet switch. Then I rebooted into another OS to see if the problem persists.

In Ubuntu 6.06 LTS, with the exact same static IP specs, networking is working fine.

There's one good thing about this -- I have ample opportunity to use the "new" Network Settings utility, which requires a password to unlock (so the administrator of the box can control which users have control over the network settings). In my view, the more finely grained the control over permissions on the box (and the easier it is to change those permissions), the better.

To see if it would jump-start the network card, I created a new static IP "Location" with a different IP, and networking returned. Never mind that the original IP still worked on my other boxes.

Was Network Settings writing faulty info to the config files? I had saved both my new and old IP configurations as "Locations," and once I got networking working with the new IP, I switched back to the old one.

For some reason, that was enough to make things right. My original static IP was working, and Update Manager has 90 packages that are now downloading -- very slowly -- to my Hardy partition. Ubuntu's servers are getting hammered, and it's only going to get worse the closer we get to the official 8.04 release date.

Will networking in Ubuntu 8.04 survive a reboot? Stay tuned. No. I had to repeat this process upon rebooting.

Here's one good sign: Among the updates I'm downloading -- network-manager. I'm now downloading another bunch of updates. With another new network-manager.

Gnash vs. Flash: I thought I'd try Gnash the open-source replacement for the proprietary Flash plugin. I installed it through Firefox, a process that now invokes Ubuntu's own package management utilities instead of installing Firefox plugins that the overall system a) has no knowledge of and b) therefore will not update.

That's the good news. Once I had Gnash installed, I couldn't get it to work on any Flash-enabled Web sites. You Tube? No. Dailynews.com? Also no.

And while you can install Gnash via the browser, it appears that you need to go to Synaptic to uninstall it. I couldn't figure out any other way to do it. So I went to Synaptic, uninstalled Flash, then reopened Firefox, went to a Flash page, got the message that I needed a plugin, installed the "real" Flash, closed my browser, then reopened it. Only this time the browser insisted that I needed to install Flash. If I tried, the dialog box told me that Flash was already installed.

End result: I don't have Flash.

But I do have sound: I've heard reports of sound not working in Ubuntu Hardy due to the new Pulse audio system. No problem with that here.

Again, here's the expected "this many days till Hardy' tag from Ubuntu:

I'm just a user and wordy blogger, and I find it fascinating to learn how bugs are dealt with in software projects like Debian. I do hope my 2.6.24 kernel-related sound problem gets resolved (even though I can just use an older kernel and have all the sound I want).

The other bug that's bugging me is this one, in which the Epiphany browser (but not Iceweasel/Firefox) always starts in the "working offline" mode, no matter whether I have the Internet connected or not.

I don't know whether or not the Debian team is going to get around to "fixing" this bug, since there's a fix out there that anybody can do. Curiously, I had to find it in another Debian bug report.

Here it is: If you launch the Epiphany browser, and can't get a Web page to come up (or you get a version of the page from the time you last had Epiphany working properly), check under the File menu to see if the "Work Offline" box is checked. If it is, you've got the bug.

You can just uncheck the box every time you launch Epiphany, or you can fix it this way, using Debian's gconf tool (and no, you don't have to be root to do it):

$ gconftool-2 --type bool --set /apps/epiphany/general/managed_network false

That's it. Epiphany is now behaving itself.

I'm not opposed to the occasional long line of code at the console, but if you're trying to get new users, this ain't the way to get it done. These things need to be fixed so the users don't have to reinvent the wheel every time they run into a problem.

Not a bug, but an annoyance easily fixed: I added my 4-year-old as a user on the Debian Lenny laptop, on which she loves using Gcompris, Tuxpaint and Childsplay. But her account didn't have working sound by default. It turns out that Debian is very conservative when it comes to granting privileges to new users; I turned on sound for her under System -- Administration -- Users and Groups. I clicked open her account, went to Properties and clicked the box for "Use audio devices" under the User Privileges tab.

So I solved two Debian problems I've had for a few weeks (the sound in my daughter's account and the Epiphany browser issue), one I've had for months (by discovering the touchpad settings app in Lenny), and was confronted with a new one (the new kernel's lack of a driver for my sound chip) and solved it by using a different kernel.

It's nice to get everything working right, but it's also nice to have everything working right.

The Linux kernel is a funny thing. A new kernel should mean increased functionality, but for me and my old-and-getting-older machines, the newer the kernels, the more functionality I lose.

I hadn't updated Debian Lenny in a while on the $0 Laptop (the Gateway Solo 1450). When I did it today, I noticed a new kernel being added to the system: 2.6.24-1.

Now I have three kernels in Debian: 2.6.18 (a holdover from Etch), 2.6.22 (my first Lenny kernel) and now 2.6.24.

I didn't think about the new kernel when I next booted into Lenny, but when I did, I soon discovered that my sound card didn't work anymore. I looked at all the settings, tweaked a bit here and there, but still nothing.

Then I had an idea. I rebooted and loaded 2.6.22, and sound returned.

That's a curious thing. The Gateway uses the ESS 1988 Allegro PCI sound chip, so I imagine that anybody who also uses this chip and is running Lenny will run into problems.

Here's a bug report on the problem via Google Groups. It's Bug No. 464191. Here's the same thing on the Debian site.

If some of the commenters are correct, it appears that sound quit working due to removal of a binary blob:

I am also left with a mute laptop, a HP 6100 with ESS Technology ES1988 Allegro-1 (rev 12) sound chip. Matìj Laitl seems to be spot in his post since in I found this in Debian kernel changelog :

linux-2.6 (2.6.23-1) unstable; urgency=low

* Remove binary only firmwares for:

- ESS Allegro/Maestro3

While I understand and support the whole "up yours, binary only
firmwares" view, I also do like having sound. Is there any chance of
getting the needed firmware in kernel or as a module in Debian.
Package alsa-firmware-loaders doesn't seem to handle a module for
these chips.

Cheerio,
Mikko Nurminen

And here's a subsequent message:

So now I've got to recompile my kernel just to have sound? How nice. I haven't had to do that since about 1998. I guess this is good enough reason as any to remove Debian from my laptop. Sad too, it's been Debian since before Woody was released.

...Rob

-------------------------------

In Debian Etch, the 2.6.18 kernel controlled the Gateway's CPU fan without intervention. CPU fan control can be implemented in later kernels with a line in /etc/rc.local that shuts the fan off, after which it is managed fine by ACPI. Dropping the line into rc.local is not as easy as doing nothing, but it's not the worst thing in the world, either.

Luckily going from Debian Etch to Lenny made the laptop's Alps touchpad work pretty much close to perfect. There were a few bugs in Etch in regard to this touchpad that are probably never going to get fixed, and Icredit the GNOME and Debian teams with addressing these bugs and making the most recent versions of the GNOME desktop in Lenny a joy to use on this very laptop.

Note: The best distros so far when it comes to configuring the Alps touchpad in the Gateway are Ubuntu (7.10 and 8.04 beta), Debian Lenny and PCLinuxOS 2007. The best Linux kernel for the Gateway Solo 1450 is 2.6.18 (although later kernels can be tamed, as I say above). Honorable mention goes to Puppy Linux, all recent versions of which don't allow tap-to-click, which is better than not allowing tap-to-click to be turned off.

---------------------------------

But back to sound in Lenny. Will anybody else notice? Will the Debian team patch the kernel? I certainly hope so. Just this morning I was thinking about how stable Debian (even the less stable Testing branch) is on this laptop.

And then my sound goes away.

It's enough to send one running into the arms of Ubuntu. I'd hate to think that Debian is going to tell users with these specific sound chips to take the proverbial long walk off a short pier.

In other news: My initial excitement in regard to FreeBSD 7 managing the Gateway's CPU fan with no intervention has given way to slight dismay. Today when booting into FreeBSD, the fan blasted away as if my previous computing sessions with the OS had never happened. Come to think of it, the same thing happened to me with DesktopBSD recently. There's something about FreeBSD and this laptop that makes working ACPI a very intermittent thing.

Along the same line: I tried to get ACPI working in OpenBSD 4.2 on the Gateway. I don't have OpenBSD installed on this hard drive, so I used the live CD (which, by the way, is not easy to find but is a very useful tool). I followed instructions elsewhere to implement ACPI. But as far as fan control goes, nothing happened, and I have no clue as to how to proceed. I'll wait for OpenBSD 4.3 and try again. Or maybe a solution of some sort will fall into my lap(top).

Let's just say that if I could get OpenBSD to tame the Gateway CPU fan, I'd be using the security-rich OS a whole lot more. It's been great on the $15 Laptop, which has neither ACPI capability nor a noisy fan. The old Compaq has a relatively quiet fan that runs all the time; and yes, I prefer that to one that is silent 95 percent of the time, and loud the other 5 percent (or loud 100 percent of the time with no ACPI control).

And finally: It's time I fixed the broken PCMCIA slot in the Gateway. The part only costs $20, but I remember the last time I opened up the laptop's case. It's not exactly a fond memory. After pulling about 20 screws out, I still couldn't get the thing all the way apart.

I was able to do what I needed to pull out the broken power plug and solder leads to a new one to the top of the PC board, which, if I could get out of the case would probably never get put back in.

I wonder if I can even get the old PCMCIA card slot out of the damn thing. Still, $20 is worth gambling. I'd love to take my Orinoco WaveLAN PCMCIA 802.11b card out of the $15 Laptop (Compaq Armada 7770dmt, circa 1999) and use it with the newer and faster $0 Laptop (Gateway Solo 1450, circa 2002).

Absolutely final note: Here at the Daily News, we've been trying to get the comments working properly in Movable Type 4. The whole point is to not allow anonymous comments, since this blog, in particular, gets probably 500 spam comments a day, and all the legit comments are mixed in between. It makes a lot of work for the blogger. To see how it's supposed to look, go to our new pro wrestling blog.

We're moving to a sign-in-only comments model with many choices of sign-in: Movable Type native (new in MT 4), Typekey, OpenID, Live Journal, and a few others I've never heard of. But at this point, we can't get the code working due to blog-rebuild issues.

Any of you who use Movable Type heavily probably know the pain of which I speak. But things should be resolved by mid-April. That's the plan anyway. Until then, I'm sorry that you can't comment on the blog itself. But if you do have a comment, please e-mail me at steven.rosenberg@dailynews.com, and I will either turn it into a new post, or attach it to the relevant post itself.

Coming up: A review of Dru Lavigne's "The Best of FreeBSD Basics," and a look at the Ubuntu 8.04 beta (yes, I'm reviewing a beta release; I usually don't run beta software, much less review it, but the anticipation of Ubuntu's forward-looking LTS release made me do it).

First off, when I'm in X, using Twm, exiting the window manager (and X) hangs the box. Ctrl-alt-backspace gets me back to a console. I have a feeling that even though X looks good, there's some configuration work I need to do.

Secondly, I tried to build a couple of ports. Scite didn't work. It said it needed GTK2 instead of GTK1. Does that mean installing Dillo first screwed things up for Scite? Anyhow, I only installed Scite because I couldn't find Geany in /editors ... turns out it's in /devel. In the interim, I installed Ted. It took over a half-hour. In the middle, I installed Geany as a package, not a port, and it installed in maybe 20 seconds.

So if you've got time and don't want to install too much, ports are great. I just don't have that kind of time.

While I was all set to slap the Ubuntu 8.04 beta on the $0 Laptop (the Gateway Solo 1450 with 1 GB of RAM), I had the FreeBSD 7 install CD already burned ... and while it didn't work so well on the $15 Laptop (Compaq Armada 7770dmt), it booted right up on the Gateway.

After a few OpenBSD installs, during which I followed the well-written FAQ religiously (and as a result had no trouble whatsoever), I felt I was more than ready to throw FreeBSD on the laptop.

And while the FreeBSD Handbook is legendary for its comprehensiveness, I figured I could just fly by the seat of my proverbial pants.

And so I did.

Things were going well before I did a thing: the FreeBSD 7 installer automatically managed the Gateway's CPU fan. I'm able to get most Linux distros to do this with some easy configuration work once the install is done, but I have no clue whatsoever how to accomplish this very task in OpenBSD and NetBSD, no matter how hard I've tried. But having FreeBSD do it automatically is a great thing, indeed.

Once in fdisk, I deleted the PCLinuxOS partition and replaced it with one for FreeBSD. I created a 500 MB swap "slice," then one big slice for the rest. I followed the instructions for the rest of the install.

I chose the generic "user" array of packages, along with X, and once I went through all the menus and the system was installed from the first CD (I didn't bother to download or burn the ISOs for discs 2 and 3).

The last time I tried a FreeBSD install -- quite some time ago -- I chose a whole bunch of packages (or was it ports?) for my default install, and my partition ran out of space before the whole thing finished.

So this time I figured it would be better to start with the basic install and X. After using OpenBSD with its basic install (Fvwm window manager, Lynx browser ... and quite a bit more), I figured I could get around well enough in the basic FreeBSD install to make things happen.

After the install, I booted to a login prompt. After logging in, I did startx and found myself in the Twm window manager. I needed to test whether or not my static IP was working. I became the superuser and tried to ping google. Nothing. I pinged local machines on the network, and everything was fine.

I thought networking was broken and searched awhile for a solution.

If I even had Lynx (which is in the default install of OpenBSD) I would've tried it first, but even that text-only browser is not preinstalled.

Like I said, after awhile, I suspected that I was having trouble with ping and not with networking.

In OpenBSD, I've always installed packages, never ports, but since I opted in the FreeBSD install to download the ports tree, I figured I'd try to install my first port.

I needed a Web browser. So I started with Dillo.

This time I did consult the FreeBSD Handbook. I followed the instructions, going into the ports directory for Dillo, then running:

# make
# make install
# make clean

I read another paragraph down and learned that I could have just done:

# make install clean

At any rate, I did have Internet connectivity (despite the inability to ping Internet IPs, as root or otherwise), since files began downloading and building. In addition to Dillo itself, I needed GTK plus a bunch of other stuff. It took quite a long time -- for me anyway. The whole process lasted maybe 10 minutes. I'm used to apt-get install dillo ... and a minute later it's done.

But I do understand -- if tentatively -- the whole philosophy behind ports, and while the whole thing looks complicated, it worked perfectly.

I ran dillo from an xterm window and had a working Web browser.

I'm sure someone will enlighten me as to why this doesn't work:

# ping google.com

I imagine it has something to do with the firewall, but at any rate, I did install FreeBSD 7, I do have Internet working, I've got a browser running, and ACPI fan management and automatic configuration of X were perfect without any intervention from me.

Truth be told, it's more than most Linux installs can do.

While I couldn't imagine sticking with Fvwm in OpenBSD, I've grown quite fond of it -- I pretty much like it better than Fluxbox at this point. I'd hazard to say that I won't stick with Twm in FreeBSD, but it could grow on me in much the same way -- especially since, if I'm correct, Fvwm is based on Twm).

Final note: Why didn't I just install DesktopBSD or PC-BSD, you ask? Here's my answer: While I'm OK with running KDE, I'm not exactly comfortable with it. I really wanted to experience FreeBSD in a more, shall we say, "organic" way. After having such a good experience with OpenBSD, I see the value in building your own desktop, adding the apps you want and keeping everything a bit lighter.

If, as in the world of Linux, there was a FreeBSD-based project that allowed for an easy install with a full desktop based on Fluxbox, Fvwm, Xfce, JWM ... or even GNOME, I would be all over it. But the choices in DesktopBSD and FreeBSD (KDE and KDE, although I remember somebody telling me that DesktopBSD does install Fluxbox) don't exactly move me.

And since, like in OpenBSD, the basic FreeBSD install goes so well, I'm happy to start at the beginning.

Absolutely final word: Every time I write about a BSD project, I feel the need to praise the extensive, high-quality documentation that goes with it. The OpenBSD FAQ and man pages, the FreeBSD Handbook and man pages -- both have been and continue to be invaluable resources worth much more than their cost (which just happens to be "free"). It's one area in which the BSD projects are well ahead of their Linux counterparts, which generally feature documentation that is smaller in quantity, often out of date and lesser in quality. I wish it weren't so, but that's what I've seen.

OK, just one more thing: The fact that OpenBSD automatically configured the sound card in the $15 Laptop (the Compaq Armada 7770dmt), something no Linux distribution has ever done, coupled with FreeBSD's instantaneous management of the CPU fan in the $0 Laptop (Gateway Solo 1450), something done as well only by Linux kernel 2.6.18 (and with a little fiddling in subsequent kernels) is nothing short of astounding -- and a sign, in my little world at least, that Linux needs to watch its back.

Yes, competition, even for the hearts and minds of geeks, is a very good thing, indeed.

We go through this every six months: Ubuntu brings out a new release, and by the time release day comes around, it's murder to get enough bandwidth to grab the damn thing and make a new disc out of it.

And no, I don't have any recent Ubuntu installs that I can upgrade, so I need the full ISO.

Hence, I'm downloading a Ubuntu 8.04 beta right now.

I'm excited about this Ubuntu release for a number of reasons:

1) Even though I had problems with 7.10 on my Gateway laptop, that version of Ubuntu allowed me control of my Alps touchpad that is hard to come by in other Linux distributions. OK, so PCLinuxOS 2007 was able to do it, but otherwise I've either got tap-to-click or not ... and I'd like to have a choice in the matter.

2) I'm not a huge fan of upgrading every install on a six-month schedule. Some things I'm happy to upgrade twice a year. Some not. My problems with Ubuntus 7.04 and 7.10 put me off of the very popular distro for awhile. I went back to 6.06 LTS on one install and enjoyed it immensely. But why even think about staying with an install for up to three years? I'll tell you:

3) From the Firefox 3 beta to a bleeding-edge GNOME implementation ... OK, I can't find much else, but the point is that Ubuntu is front-loading this release with the latest of everything. Normally, I'm the kind of person who gravitates to stable, not experimental, but in this case -- with a long-term support release -- there should be plenty of time to shake out the bugs, so to speak. I imagine it'll be like running a less-broken Debian Sid (and hopefully not a more-broken one) that will cycle its way through Lenny-ness, on to a stable Etch-like state. Or at least that's what I'm hoping for.

It's a funny thing -- Ubuntu. I think this 8.04 release -- given its LTS status, and the general maturation of the Linux desktop over the past couple of years -- is more make-or-break and less just-another-in-the-cycle for the Ubuntu community. I'm hopeful that vendors like Dell will latch onto 8.04 and boost its profile by preinstalling it wherever and whenever they can.

Like I said, while I did abandon Ubuntu 7.10 pretty quickly, I saw a great deal of progress in terms of desktop usability. While I thought I needed Ubuntu to easily run the apps my 4-year-old has grown extremely attached too -- namely Gcompris, TuxPaint and Childsplay -- I've since installed them in Debian Lenny, and then even OpenBSD, and they worked just as well. Yeah, my 4-year-old is using OpenBSD (in 64 MB of RAM and 233 MHz of CPU, no less -- and no more).

So Ubuntu is great and all -- I do recommend it, but with the right administrative help and a little training, the "average" user can find his or her way in just about any Linux distribution -- and even in OpenBSD or FreeBSD.

Oh, and here's the fast mirror I found.

And here's the ubiquitous "this many days until Ubuntu Hardy" graphic:

But first ... FreeBSD 7 will fight for supremacy on my Gateway Solo 1450 laptop. I'm starting the install now, and things look very, very good at this point: ACPI fan management is working, and I'm barely past the boot prompt. that's very encouraging. Along with this install, I will be using and reviewing Dru Lavigne's book, "The Best of FreeBSD Basics," which so far has proven to be a very useful book to have around. A full review of the book is forthcoming.

If you guessed OpenBSD, you'd be right. I'm as surprised as anybody. So when it comes to hardware detection of the sound card in a Compaq Armada 7770dmt laptop (circa 1999), so far OpenBSD 4.2 is the only operating system (except for Windows 2000) to automatically set up the sound. The rest required some command-line and configuration-file voodoo.

I've been on vacation for the past week and a bit, and I've been through some of the unpublished comments, 99.9 percent of which are usually spam. But everything's still sitting on the Movable Type server, and I'll comb through it by the end of this coming week.

I'm sure we'll be changing the comments programming at some point in the near future, but if you want your comments to appear immediately, sign up for a Typekey account and leave a comment while signed in to Typekey. Where last I left the most recent insidesocal.com blog redesign, the sign-in was broken, so you pretty much have to sign in through the Typekey site, after which the Insidesocal server will recognize your sign-in. I do plan to fix the lack of a sign-in when I return and figure out how to do it.

Anyway ... if you do get a Typekey account and sign-in and subsequently leave a comment on this blog, I will register you as a "trusted" commenter, after which your comments will publish immediately.

For those who want to know: I get maybe 500 spam comments a day, none of which are automatically published. Unfortunately, the spam filter in Movable Type 4 is pretty awful, and it pretty much marks everything as spam ... or not. I wonder how some of these spam comments get through (although I have nothing but trusted Typekey comments set to publish automatically), since I can't seem to write a comment in this system that gets past the spam filter. In other words, the thing is pretty well broken.

But again, for the time being, sign up for Typekey, log in from there (and eventually from here), post a comment and I'll set you to publish automatically.

Thanks for playing.

I really need the new "Apache Cookbook" and "Linux System Administration," both from O'Reilly. The Apache book because it's new and covers Apache 2.2 in great detail, and the server book just because it looks pretty good and focuses on Debian.

To get a better idea of what's in these two books, go to the O'Reilly site's tables of contents for both:

"Apache Cookbook"
"Linux System Administration"

I decided to start from scratch with my Debian server project. Last time I was too hasty in adding the open-source version of Movable Type to my installation and intermingling files before I was ready.

This time I'm going to be a lot more methodical and make sure that Apache and MySQL are working properly -- meaning I can run CGI scripts and have a directory dedicated to same -- before I start with Movable Type.

I could've removed Apache, done some cleanup and gone from there, but since I didn't have much "invested" in the install, I wiped the drive and started over.

I did want to change a few things:

Last time I used encrypted LVM. Since I don't have any grasp about how to work with LVM partitions after the fact, and since I'm not confident enough to have an encrypted drive that I can't get to from a live CD rescue disc, I went with a standard partitioning scheme. I initially was going to roll out separate partitions for everything, but since I don't know how extensively I'm going to use /var -- and since the automatic partitioning in Debian tends to make the root partition too small for my taste (and with a 14.5 GB hard drive, I don't have a whole lot of space to waste), I went with a separate /home partition and one big partition for everything else. That way, even if I'm using /var for my Web files, I can always rsync them to the /home partition and then rebuild the whole damn thing if I need to, yet still have all the files right there.

Another thing I learned: When you check off "SQL server" during a Debian Etch install, you get PostgreSQL, not MySQL. I'll write more about this in an upcoming post, but I'm at such an early stage in my interaction with databases (i.e. smack dab at the very beginning) that I'm going to use MySQL just because of its sheer ubiquity (and because that's what Movable Type recommendseven though Movable Type supports PostgreSQL just fine -- and also allows use of SQLite).

I'm not ruling out using PostgreSQL in the future, but since this is my very first installation of a SQL database -- hell, it's the first time I've even used a SQL database and actually knew I was using it, so I'm going with the flow as much as possible.

In the last install, I also selected "file server," and ended up with a lot of stuff loading at boot that I don't need. What I really do need is an ftp server (and preferably a secure one) as well as the OpenSSH server, both of which are easy enough to install and configure (easy since I've successfully done it before).

And while I considered not installing the "Desktop environment," which brings GNOME and everything that goes with it, I didn't want to leave all that GUI goodness behind just yet; I'd rather have Synaptic, especially, at my disposal.

So right now I have the stock Debian Etch install with the desktop environment and Web server options.

And I need to add:

• Anything I'm missing to make Apache work with PHP and CGI/Perl scripts (that was my big stopper in last week's install)
• MySQL and the phpMyAdmin program to help me configure the database
• The ftp and OpenSSH server packages
• Movable Type

At this point, everything is on the local network, not right out there on the Internet, and I just want to see how hard it is to roll one's own blogging-equipped Web server. Would I rather use Drupal, WordPress ... or anything else? Sure, but since our shop makes extensive use of Movable Type, that's where I'm putting my energy.

I'm getting some help setting up Apache2 from this Debian Admin page. And Carla Schroder's "Linux Cookbook" has some good tips on rolling out Apache (look in Chapter 22 -- and if you don't have this book, you really do need it).

One thing that's screwing me up is the presence of multiple configuration files in Apache2 (apache2.conf and httpd.conf), the placement of those and other files in different directories on different systems, and general confusion of what the proper commands are between Apache 1.3, 2.0 and 2.2.

But since I'm being more deliberate this time, I won't move to the next step in the process until everything works with the previous step. That means I need to get CGI working in Apache, then add MySQL, create the database, and then add MovableType. ... and in between I'll get the FTP and SSH servers going.

Update: I installed a bunch of MySQL and PHP stuff that I saw in Synaptic. I also installed phpMyAdmin, which I already confirmed is working. I also added the proftpd ftp server, which has a MySQL-specific version (not sure what I'm getting myself into there). I also put openssh-server on the box, which worked perfectly in my last Debian Etch install.

A very good tip: This is true for most configuration files, as well as for those in Apache2, especially because there are a whole lot of them: SAVE copies of everything before you mess with it. Look at ALL of the configuration files and attempt to understand them before you mess with them.

By looking, I learned that the default Apache2 installation in Debian is already set up to use /usr/lib/cgi-bin as the CGI directory. This information wasn't in /etc/apache2.conf or /etc/httpd.conf (which is empty, with the implication -- for me at least -- being that this configuration file is no longer necessary in Apache 2.2 ... but don't quote me because I could be totally and completely wrong).

I found out about the CGI situation in /etc/apache2/sites-available/default and /etc/apache2/sites-enabled/000-default.

OK, I realize that Apache is a huge deal. It's production-ready, hugely scalable, time-tested, and all that other good stuff that makes for a bullet-hardened app. Did I throw in enough cliches?

But holy crap -- I've got FOUR configuration files in front of me.

I somehow in my previous installation was able to get the "home" of my Web server out of /apache2-default/, and now that I know where the cgi-bin area is (and presumably how to move it) ... I just might get this thing off the ground.

All I do know is that the online Apache docs led me astray (and were extremely vague about where exactly to put the various configuration lines I needed).

Here's what I'm going to do now: NOTHING. I'm going to sit on this for a day or so and think about how to proceed without screwing the whole thing up.

I'm doing considerable work in Movable Type with our big-time installation that serves up hundreds of blogs, many of which actually have more than a few readers.

So I figure I should be able to set up my own server on a local network with the open-source version of Movable Type. That way I'll have a better feel for what's going on at the server level. I've already fooled around a bit with Apache in OpenBSD and Debian. I had no problem getting a static Web site up and running.

To run Movable Type, besides Apache, you need MySQL ... and you need to configure everything. Apache must be set up to run CGI scripts. A MySQL database needs to be created. Everything has to be in a certain place, with certain permissions and certain users.

I'll just put it right out there: Movable Type doesn't have anything even remotely approaching the amount of documentation needed to get an installation up and running. The fact that they dump you off to the Apache Web site for that part of the install, then send you to MySQL for that part, and to the PHP site for that part of the installation.

I guess the implication is that you need to get your shit together as far as the server goes, then you can layer Movable Type on top of it.

And just what is Movable Type, anyway? Yes, it's a blogging application, but it's not a monolithic executable file. You don't download a different version for Linux, Unix or Windows. What?

It looks like Movable Type is a whole bunch of HTML coding and other various scripts that draw their real power from the Web server, database and other scripting languages on the system.

This isn't much of a revelation for those of you who know what you're doing, but the whole point of this blog, for me anyway, is to actually try to learn something. Lots of somethings, really.

For some reason I thought that Movable Type would be able to walk me through all the various tasks I would have to do to go from nothing to a full blogging platform. Not so much.

So how did I do? I already had Apache 2.2 on a fresh Debian Etch install. I used Synaptic to get MySQL. I downloaded the Movable Type files.

Here's my problem. I just don't know enough about Apache. And I'm not all that crazy about the documentation on the Apache site. I needed to move the DocumentRoot. I'd already done so once before, and I finally was able to do it again.

As far as setting up CGI, I had all the scripts ready to execute with chmod 755, and I tried to get Apache to let me run them. I just couldn't make it happen. I had a cgi-bin directory, and I pointed to it with ScriptAlias ... but I just couldn't get a script to run.

Part of the confusion, for me anyway, is that I don't know why there's both apache2.conf and httpd.conf. And with httpd.conf being pretty much empty, I'm wondering why both of these files exist and which one should contain which configuration information. I swapped stuff between them, starting and stopping Apache in the interim to test the cgi scripts. (I did apache2ctl stop and apache2ctl start).

I had already created a database. I barely know how I did it. I'll use phpMyAdmin next time to make it all easier.

What I really need is a good LAMP server book to walk me through all this.

I'm not giving up. I will start from scratch next week, starting with a fresh Linux install and doing things in a somewhat more methodical manner: install Apache, get CGI working, install MySQL, create database (hopefully I'll get that right), install PHP, install Movable Type files. Hopefully with CGI working I'll be able to actually set the damn thing up.

Clearly I need a book that covers Apache 2.2, PHP and MySQL.

I'm starting with the sensorsd.conf and sensorsd man pages. And this page from Calomel.org has some tips on what /etc/sensorsd.conf does, how to start the sensorsd daemon.

I'm not holding my breath, but if I could run OpenBSD (or FreeBSD or NetBSD) on my Gateway Solo 1450 laptop with the fan properly managed, I'd love to be dual-booting it with Debian.

Debian Lenny note: While many bugs seemingly got fixed in the Epiphany Web browser in Lenny, one new bug unfortunately has crept in.

Whenever you start the Epiphany browser, the check box to "work offline" is automatically checked. And the result is that you get versions of Web pages that you looked at the last time you were working "online." It's like a freaky time machine. Right now, you have to go under the file menu and uncheck the "work offiline" box to get Epiphany to pull up real live Web pages. I did see a bug report for this, sort of, but it doesn't seem current, and it seems to say that the problem is with the network manager (gconf??) rather than with Epiphany itself. This Ubuntu report is exactly what is happening. Whatever's causing the problem, I hope it gets resolved soon; I'm partial to Epiphany when using GNOME, but I've switched over to Iceweasel (aka Firefox) just to be rid of this bug.

I've wondered before why WordPress limited users to 50 MB of space in their blogs. I guess they were wondering, too, because they've increased that limit to a whopping 3 GB:

... everyone’s free upload space has been increased 60x from 50mb to 3,000mb. To get the same amount of space at our nearest competitor, Typepad, you’d pay at least $300 a year. Blogger only gives you 1GB. We’re doing the same thing for free.

Our hope is that much in the same way Gmail transformed the way people think about email, we’ll give people the freedom to blog rich media without having to worry about how many kilobytes are left in their upload space.

How are we able to do this? Over the past year we’ve developed our file infrastructure, replication, backup, caching, and S3-backed storage to the point where we don’t feel like we need to artificially limit what you folks are able to upload just to keep up with growth. We’re ready for you. :)

What about the space upgrades? They’re still important. You still need a space upgrade to upload certain file types, like movies, and we’re also increasing the limits of the paid upgrades, so if you bought a 1GB upgrade before it now adds 5GB for no additional charge.

First of all, I'd like to find out what they mean by "certain file types." Second, I think we can count the days until the Google-owned Blogger matches this. (Blogger stores your uploaded images in Picasa, and the limit for a free account remains 1 GB.)

And you thought all Microsoft ever did was roll out endless iterations of Windows and Office in between buying some competitors and threatening to sue the rest -- but there's something going on up in Redmond, Wash., that looks like genuine innovation.

Yep, Microsoft has been working on a new operating system -- one they say is unencumbered by four decades of computing history -- called Singularity. They've been hacking away at the thing since 2003, but this week saw the first public release of the code. I can barely understand what they're talking about, and it looks as if installing the thing gives you a very Unix-like command line.

Mary Jo Foley of ZDNet on Singularity.
Larry Dignan of ZDNet on Singularity.
Singularity on Wikipedia.

And in what looks like a very un-Microsoft move, the company is actually inviting academics and others to download what they've got so far and play around with it.

The whole point here is that Windows, based on the MS-DOS of the '80s and a whole bunch of earlier Windows releases after that, and even all the Unix derivatives (including Linux and the BSDs), which go back to the Multics days of the '60s, have at their core a whole lot of ideas that might not be the best for today and tomorrow's hardware and the uses we make of it.

And who has deeper pockets than Microsoft to fund just such a project?

If the Singularity project does move forward, it could give Microsoft an advantage in the server room, where Windows isn't exactly breaking any records. And Singularity -- or something else totally new and not encumbered by legacy code -- could even become the basis for a new desktop operating system.

I bag on Microsoft a lot -- many of us do -- but it's nice to know that even a few people up there in Redmond are trying to innovate instead of litigate, give something potentially worthwhile to the world of computing, and give people who will never try Linux a reason not to suffer with Windows any longer.

Another desktop-focused OS of note: Haiku is buiit on the now-defunct BeOS operating system and is designed from the ground up to excel on the desktop. I saw a demo at SCALE 6x, and while I was impressed, I'll be more impressed when the project is further along. Besides being tuned to do the things that desktop users want to do quickly and well (with a heavy emphasis on multimedia), Haiku's filesystem-as-database approach is certainly novel.

And when you see how hard it is to get a nascent OS off the ground -- look at how long Microsoft takes -- the progress made since the '90s in Linux, as well as OpenBSD, FreeBSD and NetBSD, is pretty amazing. It just shows you the value and power of the open-source development model.

Can Microsoft match it?

Totally unrelated: So I'm Googling to find an answer to something, and all I get, pretty much, are my own articles on the topic. But I found out that this Estonian (yes, Estonian) Web site, FreeSoftNews, links to just about everything I write. Thanks!

The $5 iPod (which isn't an iPod, because Apple sells nothing for $5) is coming to a Third World country near you. It's now being called the Talking Book. And did I forget to say it's supposed to cost $5?

From the Linux Devices story:

A Seattle-based nonprofit organization called Literacy Bridge hopes to create a low-cost audio player for the developing world. The $5 "Talking Book" is an iPod-sized flash-based mp3 player that juices up on health, educational, and other audio programming at Linux-based content distribution kiosks.

The plan is for individuals to purchase the Talking Books device for a partially subsidized cost of $5. The more expensive kiosk laptops will be acquired by entrepreneurs via micro-loan programs. The entrepreneurs will sell access to content, as well as the Talking Book devices themselves.

Or should I say, "How Canonical wants to be more like Red Hat," because the profit-seeking company behind Ubuntu, which wants to compete not just on the desktop but in the server room as well, has a new product called Landscape, which for $150 per node (unsupported), will allow for the full administration of any number of remote Ubuntu-equipped boxes:

Landscape provides users with a hosted web interface on which all machines are registered. From this single interface, packages and security updates are deployed to the entire network of servers and/or desktops with a single click. Additionally a wealth of monitoring data is provided graphically to the administrator showing process and resource use as well as flagging any available security fixes for the system.

If "$150 per node" means $150 per box, that can add up pretty quick. But such remote management of a plethora of boxes is something that a lot of people might want, I figure.

By the way, how much does Canonical charge for support? A lot. It makes Red Hat look like a bargain.

I've heard of quite a few people still running Debian Sarge -- the stable version of Debian before Etch went stable in April 2007. As per Debian policy, support for what is referred to as "old stable," in this case Sarge, is slated to last for a year after the next Debian release is declared "stable" (Etch).

So now we're bumping up on March 31, 2008, and Debian is telling users about the end of updates for Sarge:

One year after the release of Debian GNU/Linux 4.0 alias 'etch' and nearly three years after the release of Debian GNU/Linux 3.1 alias 'sarge' the security support for the old distribution (3.1 alias 'sarge') is coming to an end next month. The Debian project is proud to be able to support its old distribution for such a long time and even for one year after a new version has been released.

The Debian project released Debian GNU/Linux 4.0 alias 'etch' on the 8th of April 2007. Users and Distributors have been given a one-year timeframe to upgrade their old installations to the current stable release. Hence, the security support for the old release of 3.1 is going to end in March 2008 as previously announced.

I've heard incredible stories about people running servers with Sarge and having incredible uptimes stretching into full years and beyond. And I'm as loathe to upgrade something that "just works" as much as the next lazy guy, so I understand. Three years seems like a long time ... and if you want more than three years, there's always Red Hat/CentOS/Scientific Linux and Novell's Suse (really just Red Hat Enterprise Linux clones CentOS and Scientific Linux, because what kind of cheap person like myself is going to pay year after year for updates?).

But going three years without needing to do a reinstall is a pretty great thing. And if you start with a Debian release before it goes stable -- like Debian Lenny, which is still in Testing but appears pretty darn reliable to me -- you'll probably get more than three years. At this point, I imagine that most Debian users think of Etch -- the current Stable -- as too old. That's true for desktop users, but if your hardware likes Etch, I really see no reason to move to Lenny unless you want newer versions of all of the packages.

For me, Lenny is working pretty well on the $0 Laptop (Gateway Solo 1450), and Etch is doing great on the $15 Laptop (Compaq Armada 7770dmt). And this desktop/server I just set up? I used Etch just because I know it works. And I know that getting Lenny to perform well on the Gateway means I'll be able to stick with it for what could be four years (but actually might be less because the wait between Etch and Lenny becoming stable is probably going to be much shorter than the wait between Sarge and Etch ... or at least that's what I think is going to happen).

Yeah, I probably won't be running Lenny three years from now ... but you never know. As I said recently, Lenny is looking very, very good.

I've blogged before about how much I like ZDNet, with its emphasis on blogs as purveyors of tech news, with a page that no longer exists (but does redirect you) that until a few days ago would display the last five or so posts for each and every blog. Now the whole thing looks as boring as every other enterprise-aimed news site, and I think we all know what I'm talking about. The redesigned ZDNet site is missing all the blog names, all the photos of the bloggers ... all of their entries ...

The worst thing: I can't easily see what all of my favorite bloggers are doing -- and I do have quite a few ZDNet favorites.

I know I often hate things that are new, but am I wrong here?

To see the brouhaha for yourself, go to Larry Dignan's post announcing the change and the voluminous comments that follow. At least they made it easier to see all the comments at once. (Ed Burnette tipped me on how to do this in the old style, and it's just easier to see in the new design, a sign that the ZDNet people did a few things right ... but overall I'm astounded).

I did a Debian Etch install on one of my test machine drives recently, and today I added the openssh-server package so I could play around with PuTTY and Xming.

Once I installed openssh-server (I used Synaptic, in case you were wondering), using PuTTY to start the connection, I was asked whether or not I expected the encryption key to change (I was, since this is the Debian install, not OpenBSD, which I've been using until now).

One bonus of using this Debian Etch install: The OpenBSD drive is noisy, which probably means it's gonna go. The drive on which I installed Etch is much quieter. I probably need to get some newer, bigger drives ... or a whole new test box, but that's another story for another time.

Quirks in Debian Etch with openssh-server: I can run X apps, no problem. When I run:

$ nautilus &

... I get a huge window with the entire GNOME desktop, minus the toolbars. And I can't close that window -- Xming won't let me, I think. X-ing it out doesn't work. I had to kill the process in my PuTTY terminal. (Note: $ startx & does not work ...)

Speaking of security: OpenBSD is known for its security above all else. Here's how using openssl openssh (which was created by the OpenBSD team) differs -- at my lowly level, anyway -- between OpenBSD and Debian Etch:

In OpenBSD: The sshd server is included in the standard install. But it can't be used until rootly powers are used to implement it. Running X over ssh is not allowed until the appropriate configuration changes are made. But root logins are allowed over ssh by default; the administrator, however, can choose to block root login (which I did).

In Debian: Debian installs without the ssh server installed. So without the administrator specifically installing openssh-server, nobody can ssh into the box. But once that package is installed, Debian automatically allows ssh logins -- and X logins as well. As with OpenBSD in its default state, root logins are permitted over ssh until that feature is turned off in /etc/sshd_config.

I don't understand all the lines in sshd_config, but I probably should get better acquainted with each and every one of them.

Speed? It could be the fact that this Debian Etch box has the GNOME desktop, and I've been running OpenBSD either from the console or the default Fvwm window manager, but everything happens a lot faster with the OpenBSD install (hardware is the same for both). I could modify Debian to boot to a console instead of GDM, and that might speed it up a bit (memory is 256 MB), but whatever the reason, thus far OpenBSD is a bit smoother. (Later, things seemed to run a bit better when I didn't log in on the Debian box and hence didn't have GNOME running).

More on security: If this box wasn't just something for me to play with on the local network, the stakes would be a lot higher. I suppose not having sshd is pretty good security when compared to having sshd installed but not enabled. And I also suppose that installing sshd (openssh-server) means that you want to actually use it. But in the case of both OpenBSD and Debian, I wonder why root logins over SSH are enabled by default. If anything, I'd expect OpenBSD to disallow them until the administrator of the box decides to turn that feature on.

And since you can always use su or sudo (Ubuntu has conditioned me to like sudo, and I always add myself to the sudoers list with visudo, there's really no reason for a root login over ssh.

Side note: Debian doesn't automatically add the primary user to the sudoers list, something I always do because on many occasions I'd rather use sudo than su.

Ubuntu, by default, disables root logins entirely and only offers sudo. It makes setting root's crontab a pain in the ass. I use sudo -i crontab -e to get into root's crontab in Ubuntu.

Side note to a side note: While I can fake my way around vi, I like it when nano is the default editor and crontab -e brings up nano instead of vi. The one thing I don't like about nano is that when you wrap text, actually linefeeds are inserted. At least in vi you can have the text break in the middle of a word without turning word wrap on (although you are able to do so if you want wrapped text). The one thing I like in X editors is the ability for text to look wrapped without actually being wrapped.

Quick notes because I've got time for no more:

Debian Lenny: I hadn't updated Debian Lenny in about a week. Bugs are getting fixed all over the place. The latest wave of upgrades includes a couple of fixes for the Epiphany browser, which as a result is running better than ever. Most of what I noticed was cosmetic, but it just adds to the excellent functionality that Lenny already offers users. If you've been worried about running Lenny instead of Etch, I think the time is right to move to Lenny as it makes its way from Testing to Stable.

Preload in Debian: After reading about preload in Linux Journal, I finally installed it. Preload is supposed to monitor what apps you use most and automatically load them into memory, adjusting if your application habits change. Since I tend to run the same apps a lot, and since I have plenty of memory, I'm anxious to see how well preload works.

FreeBSD and the need for speed: FreeBSD 7 is now beginning its life as a stable OS. It's supposed to be up 15 percent faster than the fastest Linux kernels, up to 350 percent faster than FreeBSD 6x under normal loads, and up to 1,500 percent faster under heavy loads. I'm anxious to see how the hardware recognition performs. So far, I've had quite a bit of luck with DesktopBSD 1.6, which is based on FreeBSD 6, and I can only hope for better things with FreeBSD 7, which I plan to test soon.

OpenBSD update: I've been having a lot of fun -- and learning quite a bit -- with OpenBSD. I have the box on the local network, and I've been playing around with the ftp server, Apache Web server and with SSH. First I installed the PuTTY ssh client on my Windows XP box so I could connect from the XP box to the OpenBSD box. I could run any console program I wanted, and while it may not be a huge deal to the more experienced of you out there, it's a huge deal for me.

I wanted to run X over SSH, so I made the appropriate changes in OpenBSD to allow X11 forwarding over SSH. Ahd with the help of my friends over at LXer, I found out about Xming, an X client for Windows.

It took me awhile to figure out that I had to enable X in PuTTY to make it work. Xming runs in the background on the Windows box, and when I open an X program from the PuTTY console:

$ rox &

... A window opens on my XP desktop with the OpenBSD X program in it (which, in the case of the line above, is the Rox-filer). Pretty slick. (The & after the app name makes the process run in the background. I had one snag: I couldn't run the Dillo browser over SSH until I installed all the X fonts for Xming. There's a way to just use Xming to enable the SSH session, but that hasn't worked for me thus far. But since the PuTTY/Xming combination is working, that's what I'm going with.

I'd like to run a full X session with a full window manager running in a window on my XP box, but besides being slower than running single apps, I get the feeling that such a thing isn't exactly looked upon lovingly by the hard-core Unix geeks out there.

But being able to run any OpenBSD (or Linux) app on a network-connected box from a Windows-only PC is so totally cool that I should be sated in my dose of geekdom for the next week at least.

The $0 Laptop and its CPU fan discontents: I've been working with controlling my Gateway Solo 1450's CPU fan for months now. In Linux, I've had it controlled pretty well with a cron job, and in the case of Puppy a few added kernel modules.

But since then, I've come to realize that the cron job, which checked the CPU temperature every five minutes and turned the fan on or off depending on that temperature, is unnecessary.

All you need to do is turn the fan off at boot, and then ACPI will manage it just fine. This revelation comes after considerable work in the console, checking the temperature, running commands, running scripts and generally seeing what happens during the course of a computing session.

So I turned off my cron jobs, and now all I need to do is add the following line to /etc/rc.local:

echo 3 > /proc/acpi/fan/FAN0/state

That turns the fan off. I initially thought that only this line -- echo 0 > /proc/acpi/fan/FAN0/state -- would turn the CPU fan back on, but that is most definitely not the case. Once the fan is turned off with the "echo 3" command (which you can run from the console, just as you can the "echo 0" line), when the CPU gets warm, the fan turns on and then turns off when the CPU cools down.

So that one line added to /etc/rc.local is enough to get ACPI management of the fan working, at least in the Gateway Solo 1450.

Now there's the matter of OpenBSD, FreeBSD and NetBSD and this same CPU fan. So far nothing has worked, but I will keep trying.