(LinuxWorld) — I just spent the last few days rediscovering why I like Mandrake Linux and why I don't use it anymore. I downloaded the iso images for Mandrake 9.0 and burned a couple of CDs. About a half-hour later, I had Mandrake 9.0 up and running on my 1-GHz Athlon, based on the Asus A7M266 motherboard. The machine has an NVidia GeForce 3, Intel Ethernet Express Pro 100, Sound Blaster Live!, ATA100 disk drives and 512 MB of DDR RAM.
Joe Barr was right to rave about the Mandrake 9.0 install. Mandrake did just about everything right from start to finish, which was a welcome relief after some of the bonehead problems I found in Mandrake the last time I used it (I'm guessing that was back around version 8.0, if memory serves, although it rarely does).
There are two things I really like about this version. First, there is a "What to do" menu item in GNOME and KDE (and probably the other window managers, too, but I didn't try them to find out). Click on this item, and it gives you a number of common tasks for users, such as "Administer your system," "Enjoy music and video," "Read documentation" and others. It's not perfect. When you select an option such as "Browse the Web", it won't necessarily bring up your favorite browser. Even more mysterious is that in KDE, the option brings up Konqueror in file-manager mode, not Web-browser mode. If you're familiar with Konqueror, you already know that doesn't really matter, but it's just not the action I would have expected.
Mandrake configured the menus to launch what it thought were the obvious actions for the given environment. For example, if you're using KDE, it will launch Konqueror, as I pointed out. If you're using GNOME, the same option will launch Galeon. If these choices aren't intuitive for your users, you can customize what Mandrake does when users click on these simplified menu selections. It isn't immediately obvious how to do this, but if you spend some time deciphering the files in /etc/menu-methods, you can probably figure out a few ways. The easiest thing to do is to change some of the symbolic links you'll find in the /etc/alternatives directory.
The other thing I like about Mandrake is the Mandrake Control Center. You can use it to do everything from selecting NFS mount points to configuring your monitor's resolution. Best of all, the configuration modules are often (but not always) user-friendly enough that you don't have to be an experienced system administrator to use them.
I'll have a little whine with that
I ran into problems, however, when I began to write this column. OpenOffice suffered from a cursor problem I recalled from my distant past. As I moved the edit cursor around, it left trails. I thought I could recall having solved that problem by updating to the accelerated NVidia GeForce drivers, so I downloaded the latest files from the NVidia site, and installed them. Sure enough, the cursor trails disappeared.
My next disappointment was finding that the fonts in Mozilla did not appear to be anti-aliased. A quick glance at the files in the /etc/X11 directory told me that the system was set up to do anti-aliased fonts, so I wasn't sure what was missing. I set some Mozilla configuration files to turn anti-aliasing on, but nothing seemed to make the fonts — especially small fonts — look better. It wasn't all that bad, so I gave up after a while.
Then I noticed that GNOME runs like molasses below zero. It was so slow that I thought I had trashed something in the system until I fired up KDE again. KDE screams with exactly the same configuration of X11. Being a fan of KDE, this didn't bother me too much, but I really liked the way Mandrake configured the GNOME defaults, so I wanted to use GNOME. The only thing I wanted to change about GNOME was the theme.
I happen to like the new Keramik style that is becoming standard with KDE 3.x. There's a Keramik theme clone for GNOME called Geramik. It works like a charm on my Debian system, so I figured it would work fine on Mandrake. I downloaded the source, compiled it and installed it. It didn't like the fact that Mandrake was using GTK 2.0, so it didn't work.
I wondered if there was a pre-compiled Geramik package available, searched a few Internet sites and found a Geramik RPM file especially for Mandrake 9.0. I downloaded it and ran RPM to install it. It complained about two missing dependencies, libXft.so.2, and libfontconfig.so.1.
One of the highlights of the Mandrake Control Center is the software-installation and update system, so this was an ideal opportunity to exercise it on more than just the packages that come on the CDs. I launched the handy-dandy Mandrake graphical installer that automatically resolves dependencies, configured it to recognize the new Geramik package and told it to install the package. It complained about the same unresolved dependencies. Fine. I pointed the installer to some sites that might have the extra libraries. It wouldn't update its database based on thoses sites. So I used the powerful search functions in the installer to see if I could find any packages containing these files in the repository of files it knew about. Nothing came up.
Afer an hour or two of trying various alternatives, I finally remembered that this is the sort of thing that drove me to Debian. One advantage of Debian is the "apt" package installer. Part of it is the fact that even if you need to point apt to a non-standard Debian repository to get the package you want, the people who maintain the site generally provide all the dependencies. Because the apt system retrieves a list of everything available, it is able to find and get whatever it needs without user intervention.
The Mandrake installer is a big improvement over the way things used to be, and the graphical interface is better than even the best Debian graphical front-ends to apt that I've seen. However, until it catches up with Debian in terms of how package repositories are managed, it's not good enough. Granted, I found Debian difficult to get used to at first, so perhaps I'm suffering from Debianitis now and will eventually figure out how easy it is to solve these problems in Mandrake. Until then, I give Mandrake's fancy package-management a thumbs-down.
I still like Mandrake 9.0, though, and I intend to keep using it for a while to see how long the romance lasts. I'll let you know if there are any surprises, positive or negative.
Xoops me baby one more time
I received some interesting reactions to my column on Xoops and E-Xoops, along with a few questions. Allow me to settle some issues:
Q. Are you a Britney Spears fan?
A. The short answer: No, I'm not a fan.
The long answer: The parody expressions "Xoops I did it again" and "Xoops me baby one more time" represent my complete knowledge of Britney Spears and her work, and I would willingly gouge those bits out of my brain with a cocktail fork if I thought I could purge the information that way.
Q. You wrote about E-Xoops in your last column, but VarLinux.org seems to be running Xoops. Was that an error?
A. No. I did everything I described in the column based on E-Xoops. Shortly after I wrote the column, I decided to see how easy or difficult it would be to port my changes over to Xoops. It was pretty easy. I've kept the site based on Xoops ever since.
Q. Which do you prefer now, E-Xoops or Xoops?
A. I like them both very much. I'm told that Xoops has more modules available, but E-Xoops modules sometimes seem to have more features. Some of these additional features are very attractive, but it's not that difficult to port E-Xoops modules to Xoops. Therefore, one does not have to pick one over the other due to module availability. I ported the shoutbox module, which was designed for E-Xoops, to Xoops with little effort. (The ported module is available on VarLinux.org and Xoops.org.)
I'm also told that while Xoops is the work of a team of programmers, E-Xoops is pretty much a one-guy deal. I tend to prefer the work of a team, because contrasting views usually produce better results. But that's not why I chose Xoops. If E-Xoops is better, it makes no difference to me if it's a one-guy deal or not. In this case, however, I prefer some of the Xoops design over E-Xoops, so the better of the two (at least for me) is Xoops. These are my personal preferences on how PHP code should be handled, so that doesn't make Xoops objectively better than E-Xoops. I just like the Xoops approach a little better because it avoids globals and tries to use more abstraction to object-oriented programming.
Both projects could use a lot of improvement. I'm sure the maintainer of E-Xoops is a wonderful fellow, but I got more of an impression from the Xoops guys that they aren't at all sensitive to criticism and are extremely receptive to suggestions. This healthy attitude increases my motivation to use and support Xoops.
Q. Have you looked at (fill in your favorite content-management or blog system here)?
A. Maybe. I can't review them all in one month.One factor of which you may not be aware is that my host only supports PHP and Perl. I hate Perl, and I can't use Python, Zope or many other alternatives (Clarification: I have a tremendous respect for Perl; it just hurts my brain to write code in Perl).
Even though I prefer Python to PHP, I can't implement VarLinux.org in Python at this time. Regardless, if enough readers want a review of this blog or that CMS, I'll be more than happy to look at it.
Q. You could have used the PHP "strtotime" function instead of your lengthy process of converting dates.
A. D'oh. I have an exceptional talent for missing the obvious, and I was in top form here. Yes, "strtotime" is the ideal way of converting a date like "May 10, 2001" into a unix_timestamp, and it would have saved me a lot of useless string-manipulation. Indeed, "strtotime" will adapt to just about anything that resembles a string-representation of a date, which should tell you something about how clever PHP programmers can be.
After pondering at considerable length why I missed such an obvious function in the PHP documentation, it occurred to me that I missed it because that's not where I looked. I only looked at the MySQL functions that were available for converting dates. This isn't quite as moronic as it may seem; I failed to tell readers in my article on Xoops that I experimented with all the date conversions by hand at the MySQL prompt to make sure I'd end up with the correct results. It wasn't until later that I created the PHP file to automate the process, so I was thinking in terms of what MySQL had to offer instead of what PHP could do.
In retrospect, it was still a pretty dopey oversight. I knew I'd eventually move the conversion into a PHP program, so I could have anticipated that and looked to see if PHP could make the process easier. What can I say? At least you got a glimpse of what MySQL can do in terms of date-conversions and string-manipulation. MySQL is actually pretty powerful in that respect. Have a look at the link to string functions in our resources selection.
Q. Does she or doesn't she?
A. Only her hairdresser knows for sure.
Subscribe to Linux Email News Alerts
Subscribe via RSS
