Skip navigation
Steve Carl

A Good Failed Testing Plan

Posted by Steve Carl Employee Sep 28, 2007
Testing assumptions about Evolutions stability issues.


Last time I posted about running Evolution 2.10.3 under PCLinuxOS, and the stability issues I was starting to see after about three days of Evolutions Exchange Connector use against MS Exchange 2003. I said in that post that I thought it probably was not a PCLOS issue, but an Evolution 2.10.3 issue. In the same post I talked about the other oddities I was seeing with PCLOS on the Dell D620 laptop: ACPI reporting insane fan speeds, and occasional system going to sleep right as I am typing away at emails. Neither problems were serious, but the going to sleep thing was disconcerting. Talk about having train of though derailed! Was my computer making value judgments on the quality of the email I was writing?


A comment that was posted to that entry told me I needed to try a newer kernel by updating the apt repositories and enabling "testing". That seemed very reasonable, so I did, and installed and booted the 2.6.22 kernel (Same as Fedora 7's more or less).


Not one thing changed. Nothing. 2.6.18 and 2.6.22 ran on the D620 from my point of view the exact same way. ACPI was still whacky, and the system still went away for sleepytime from time to time while I was using it.


"What if this is a hardware issue?" I started to wonder. Mint 3.0 had never done any of this on this exact same computer, but this could be something new. Maybe someone spilled a drink into the laptop while I was not looking. I needed another data point. First I installed bug-buddy and the available symbol files for Evolution on PCLOS, and submitted the next Evolution Connector failure.


Having done what I could there, my thinking was that I would collect the same data from a different distro. Late last Friday, I installed Fedora 7 with the 2.6.22 kernel, to see what changed.


Everything changed.


Well, duh. I suppose. I think it is somewhat reasonable to assume that a 2.6.22 kernel from PCLOS and a 2.6.22 kernel from Fedora would have some passing resemblance, and they do. But the things that are different are just not what I was expecting.


First of all, now I can not even see the fan speed in ACPI. I was using KDE with PCLOS, and now Gnome with Fedora 7, so that is not totally apples to apples. I'll need to fire up KDE in a spare moment to see how that might be different.


The system does not go off to sleep randomly anymore. That could again be KDE I suppose. It has power management awareness. Maybe it was confused.


Suspend worked way better on PCLOS. So did Beryl.


The default fonts of KDE on PCLOS are much easier to read than the default fonts of Gnome of F7. Again, not apples to apples.


And.... Evolution has stopped failing now that I am on F7. I didn't even erase the .evolution file when I converted from PCLOS to F7. F7 has worked now for one solid week without one single failure. And the package levels look to be the same. These are the ones I have on F7:


rpm -qa | grep -i evolution


This was not at all scientific. I changed way way too many variables. But it is kind of interesting. It also changes my plans. I was thinking this weekend I'd be putting Mint 3.1 (now GA) onto the D620. Not any more.


I did put Mint 3.1 on my Acer 5610, and other than the new artwork, it runs and acts in every significant way like Mint 3.0 did. That is to say, terrific. Mint 3.0 was having Evolution stability issues the same as PCLOS. Mint 3.1 ships the exact same packages. The biggest advantage of Mint 3.0 or 3.1 to my diagnostic way of thinking was that Ubuntu 7.04 (which Mint is 100% compatible with) has a fairly complete set if .debs for Evolution debugging: Symbols included in everything but the part I care about: Connector.


If Evolution under F7 is going to be stable though then I am staying here for a while. I can live with crummy suspend if Evolution works! If it crashes and looks the same, I'll submit against my open bug report. If it doesn't, I'll have to come up with the new theory, and a new way to test it.

A week of using PCLinuxOS as the main office desktop and the office "Killer App"


After about a week of using PCLinuxOS (PCLOS) as my primary Linux desktop at the office, I have an update to my last post.



If you are a Linux person, and you are living with MS created infrastructure, then one of the things you have to deal with is how to cross-calendar and email with the MS Windows users around you. MS has of course made it all "easy" as long as you do not stray from their application stack. I say “easy”, because actually MS has to work very hard to maintain that. They have a pile of RPC's and undocumented-to-the-world programming interfaces that all the applications have to know about and use or at least tolerate correctly in order to make something like MS Outlook work with MS Exchange. Put a sniffer on the line and watch the conversation MS Outlook has with MS Exchange sometime. It is amazing. What *are* they talking about? :)


There is hope on the horizon: With IBM's announcement the other day about Lotus Symphony, plus things like Yahoo buying Zimbra, and Google's apps stuff (especially now that Google Apps has added collaborative presentations), it seems like the possibility will arise the MS will have to respond to all of this, and hopefully in ways that enable Linux, OS.X, and other platforms users easier access to their infrastructure without issuing messages of second class citizenship.


What I mean by "second class citizenship" is that I often see messages like "You are not running IE: this function will not work. Use IE for a fully featured experience." when I am accessing something on MS Sharepoint. It is true as far as it goes: I am in fact not running IE. Might be because I am not running MS Windows either?


In this day and age there is no technical reason to *have* to run any particular browser. Any standard compliant modern browser should get it done. There are plenty of proof points out there. Gmail works fine from Firefox or Opera, and has every bit the dynamic screen content the stuff in Sharepoint does. From a feature / function point of view, everything that Sharepoint or the like does *should* be available to Linux or OS.X users on an equal basis. All it would take is being Open: using standards and coding tools that were inclusive rather than exclusive. The humorous thing (to me anyway) that something like Sharepoint, a supposed collaboration tool, is that its functionality is exclusive. Its hidden message: “You can collaborate with us, but only if you are one of us.” But as usual I digress.


Evolution Not Evolving


Until something good happens here, we Linuxii must interact with the tools at our disposal. And for MS Exchange, that is Evolution.


Evolution is an optional install on PCLOS, and is packaged up especially for the Distro by the PCLOS packaging team. Here are my current relevant packages:

rpm -qa | grep -i evolution


The first thing I noticed about using Evolution under PCLOS is that the packager appears to have fixed a long standing Evolution-under-KDE issue. Perhaps it was fixed in Mandrake or some other KDE place and adopted by PCLOS: I am not sure. PCLOS is very inclusive when it comes to where they get their fixes according to the interview with Texstar in the current issue of the PCLinuxOS magazine, posted on their website in HTML format. The fixed problem is the "Where is the password?" screen prompt behavior / bug / loss of focus. On Ubuntu or Mint or Fedora running KDE, bring up Evolution with the MS Exchange connector, and the password prompt disappears behind the main Evolution screen. Unless you know it is there, you will just sit there waiting for something to happen. With the PCLOS packaged version of Evolution, the password prompt appears, and the main Evolution prompt then opens up *behind* the password prompt dialog. The prompt dialog loses focus but stays on top where you can see it. That is the way the Evolution works under Gnome, so this is goodness.


Evolution looks nice: the fonts are well done and match the rest of the KDE desktop. Anti-aliasing works well on the Dell D620's LCD panel. Stability was good for the first two days. I did not even start with a clean .evolution file in my home directory, but used the one Mint had created.


Evolution started crashing on day three. Well, not Evo, but the back-end "Connector" process. Same difference effectively as I had to restart Evolution to get things back. I put up with that for a couple of days, and then I tried deleting the Evolution information in .gconf and .evolution, and redefining the connection, and went all of about an hour before connector crashed again. This is exactly the same thing as was happening with Mint 3.0 before when it on this same computer, so I am inclined to say it is that Evolution Exchange Connector is still not as fault tolerant as it needs to be. Or maybe it is not as "Microsoft Tolerant" as it needs to be. Or both. Recall that Evolution is not talking to MS Exchange via MAPI and the mish-mash of various RPC's that MS uses to make Outlook connect. Instead, Evolution's Connector talks to Outlook Web Access, or OWA. WebDAV, the Open Standard transport that underlies the current Connector-to-OWA code may be a standard, but that does not mean the OWA is 100% WebDAV standards compliant, or even that the WebDAV standard was not written with some wiggle room in a couple places that allows vendors to create incompatible versions of WebDAV.


Attention Deficit Syndrome



I don't know which of the many possibilities is the root of the problem. What is clear is that the Exchange Connector does not get the same development attention from the Open Source community that other MS interop software like Samba does. Samba being a complete re-implementation of one of the most complicated, most historical baggage protocols ever (SMB) works like a champ. It in fact can out-perform the same protocol in its supposed native OS, or at least it did last time I benchmarked it. This is an example of what is possible when a great deal of time, energy, intelligence, passion, and Open Source community collaboration are focused on a problem.


Connector continues to suffer by comparison. I do not know why. It would seem that the need to do this would be strong. MS Exchange has a huge chunk of the mail server market. Law of averages would seem to indicate that critical mass had been reached ages ago, so that there would be plenty of people needing MS Exchange interoperability from Linux.


Email is easy enough of course. If all I needed was email against MS Exchange, I'd just load up Sylpheed or Thunderbird or Mulberry or any of a bunch of other POP / IMAP capable email clients, and I would be done with it. But part of the MS Exchange exclusion factor is calendaring. For some reason folks like the integrated email / calendar functions, and POP and IMAP know nothing about calendaring.


At the same time, MS Exchange 2003 doesn't work with WebCAL enabled Open Clients. If you want to accept a meeting that an MS Windows user created, you either have to load up the calendar in your web browser, or use the Evolution Connector. In another subtle message of exclusion, OWA will look to see if you are running IE or not. If you are running anything other than IE, you can see and interact with MS Exchange still, but in a flatter, less dynamic way. At least you don't get any messages about being a second class citizen from OWA.


OWA makes a great deal of effort to look a lot like the MS Windows native MS Outlook application. I suppose that is a comfort to some, but I dislike the extra time it takes to load the look and feel stuff. Gmail runs rings around OWA in look, feel, functionality, inclusion... too bad there is not a Google appliance that translates OWA into Gmail. That would be sweet.


Whats up Doc?



So... why the relative lack of attention to a seemingly critical piece of technology like the Exchange Connector? Why the abends? How come we are years and years into this, and still dealing with stability issues like this? it is clearly not a PCLOS issue. I have the same sets of issues on Fedora, Ubuntu, Mint, FreeSpire... you name it.


What I have not tried it something like Novell Desktop 10. Right or wrong, I assume that since Open Source is what it is, that Novell will not have implemented anything differently here. In fact, since Novell sells Groupwise, I have assumed that Exchange Connector will be something that the packagers of that distro will not have focused on. If they had, and if they had done anything to make it work better there, why would that not have made it back out to the community?


One possible explanation (and I am totally guessing here) might be that the Open Source community isn't spending enough time of this because they are focused instead on other mail servers. Hula or Bongo perhaps? Open Xchange? Citadel, Kolab, Scalix, or Zimbra? Another I didn't recall? Something where the work of building something as complex as this is simplified by being able to use openly defined protocols. Where the difficulties of testing and integrating are not complicated by also having to figure out the on-the-wire protocols by trial and error. Read the early Samba story and see what craziness they went through to get things working.


Here is an area where I usually try to help by loading up Bug-Buddy and the debugging versions of things so that I can send the diagnostic data back to the people that know the products enough to fix the problems. That might be a problem with PCLOS. In Synaptic, running against the default PCLOS repositories, I did not see the debugging, symbols included, versions of Evolution and Connector. Without those, Bug Buddy's submissions are pretty information free.





That might be the death of PCLOS on my office desktop. I think the time has come to do some research and find out which distros have what I need so I can submit some Evolution bug reports.


If this gets fixed: If Evolution Connector can stabilize, that should help the Linux adoption rate in ways that little else can. If Linux is to make inroads on the corporate desktop, it has to do so knowing the realities of the data center software lifecycle. Companies have huge investments in things for MS Exchange: backup programs, server farms, virus scanning, spam blocking, email re-directors for email satellite devices like Blackberries. Linux desktops have to live in the current world until time and technological movement take their toll and make these issues moot.





There are other reasons I might soon be done with PCLOS. There are many many things I like about the Distro, but there are a few things that are starting to drive me nuts. One is that over the last week at least four different times, while I was right in the middle of typing an email the Dell D620 laptop just went to sleep. It was plugged it. the battery fully charged. There were no power interruptions or other external state changes. I press the power button and it comes right back, but why in the heck did it do it in the first place?


The year old kernel might be part of the problem. The D620 has already been replaced by Dell with a new model, but a year ago it was a brand new laptop. Perhaps it has some new hardware in the guts of the laptop case someplace that the 2.6.18 kernel did not yet include stable support for in September of 2006 when the kernel was new.. ACPI is obviously whacked. My internal fan is just not turning at 8000 RPM.


In the good news column are CrossOver and VMware. Both installed easily, and in fact VMware Player 2.0.1 compiled with via with no error messages. That might be a first. The older Kernel operating in its favor probably. The guest seems crisper under PCLOS than Mint too, but that is utterly subjective. Might just be that “newly washed car” phenomena in action.

Steve Carl


Posted by Steve Carl Employee Sep 16, 2007

Looking at PCLinuxOS as a Corporate Desktop


In a post I made a while back, the Linux distro  PCLinuxOS showed up in the comments. When I stuck my foot into it in a reply, the creator of the distro, Texstar jumped in to set me straight. My mistake was to say the PCLinuxOS was now based on Debian. Another poster pointed out I needed to do my research better. Too true. I had two data points.


  1. I had read someplace on the Internet of a forum that PCLinuxOS was now Debian based, and
  2. I had looked at PCLinuxOS briefly when I was trying to decide what Distro to use for my last LinuxWorld lab, saw that it used Synaptic, forget that there was an RPM version of that tool, and moved on.

It is even worse than that though: The article I read that gave me this idea in the first place is lost to history, but I saw a post at Desktop Linux that reinforced it:


Once installed, more than 5,000 additional packages are available through PCLinuxOS's Synaptic software manager and file repositories. This works essentially in the same way as Debian and Ubuntu's update system. “


I stopped reading there. Had I just finished the paragraph, the very next sentence was:


However, instead of using deb packages, it uses RPM. Thus, PCLinuxOS users must use their distribution's own repository -- it is not interchangeable with the Debian or Ubuntu program libraries.


Well fine. Just fine. IRNIdjut. I normally do actually research stuff better than that. Really. I should have know better: A few years back, I used an early release of PCLinuxOS in the Linuxworld lab as the class boot-able LiveCD. I only stopped using it because a newer version of PCLinuxOS dropped Evolution for space on the LiveCD disk reasons. I needed Evolution for the lab.


Even worse: I used to be a [RPM based] Mandrake user! I used Mandrake for years. Texstar used to package up all sorts of things to make Mandrake better, and was one of the, if not the most popular packagers for Mandrake “back in the day.” [Mandrake is called Mandriva now] Worse: Texstar even lives in the same city I work! I should know his stuff better that this. Argg!!! This is just embarrassing, to say the least.


I Have No Choice. I Must Do Research.


Having stepped into this royally, the only way to be able to look in the mirror is to test PCLinuxOS 2007. One of the comments to my post about PCLinuxOS asserted that PCLinuxOS is 100 times better than Mint. I am surrounded by Mint systems. Mint is based off of Ubuntu, and there is an article in the PCLinuxOS Magazine September 2007 Issue 13 is titled "Ubuntu's Hype is Misleading".


I am always open to change. Starting back in the post "Most Popular Linux Desktop?" post, I wondered what the hype around Ubuntu was all about and set about testing it. I ended up using Mint as my primary Linux desktop ever since.


I decided to use the Dell D620 that I posted about in "". Mint had been on the unit for about a month. Everything was working more or less in a well known way. Evolution was the main pain point, since it crashed fairly often, at least until I figured out a new way to set it up (I pointed it at the OWA web server rather than the MS Exchange server for the WebDAV connection. That made it run much better. No idea why yet.). The other, slight lessor issue was that the wiggle stick and the track pad used different mouse acceleration profiles. I could not get them synced to save my life. The wiggle stick fast. The trackpad slow and therefore mostly useless. The computer itself is speedy fast, what with its T7200 Core 2 Duo.


Mint on the D620 grabbed the CD image from a mirror on the net, burned it, and then moved out of the way on the hard drive to make room for PCLOS (PCLinuxOS's official abbreviation). Aside: Interesting that there is no LiveDVD version of PCLOS. There is clearly a large number of packages in the repository that they could put on by default if they had a LiveDVD version. From my last LinuxWorld lab I learned most everyone was able to boot a DVD these days. That would be nice, because then they could put Evolution back on the install media, and I would have another option of the lab!


LiveCDs are the Best-est


Any Linux Distro that does not have a LiveCD/LiveDVD version is missing the boat. It is so nice to be able to test the distro *from* the CD, to be sure there are not major issues before you roll the Distro down.  As easy as Linux is to install these days, I still spend a fair amount of my after-hours life doing these types of things, and the LiveCD is just too nice to not use. Even Fedora 7 is on board with a LiveCD you can install from! PCLinuxOS booted, asked a few questions about the network, and I was up.


The LiveCD gives you the option of "root" or "guest" to log in as. I go in as 'guest', password 'guest', and a normal looking KDE desktop with some distro specific artwork appears. There is an icon on the task bar to start downloading updates (Synaptic, but labeled "package manager")... which is odd in a way. I'm running off a LiveCD. My read/write space is limited by the ramdisk. No way I could put new packages on this while it is running LiveCD. Next to Synaptic icon on the taskbar is something that anyone that has ever used Mandrake knows: the DrakConf utility. I'll need to use both of these once I am running PCLOS installed off the hard drive, so I note their presence and move on.


The trackpad and wiggle stick are accelerated the same. Nice.


Finding no issues running PCLinuxOS from the LiveCD, I clicked on the installer icon, reworked the disk layout to preserve my /home, and watched the D620 CD drain the LiveCD onto the harddrive in short order. Screaming fast install. Here's the disk layout:




Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes



   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        1824    14651248+   7  HPFS/NTFS
/dev/sda2            1825        3040     9767520   83  Linux
/dev/sda3            3041        3283     1951897+  82  Linux swap / Solaris
/dev/sda4            3284        9729    51777495   83  Linux

On the Dell D620, sda1 is the BMC corporate MS WinXP image. sda2 is "/". sda4 is "/home". I formatted sda2 and sda3 (swap). As a first challenge to PCLOS, I was going to leave all my files from Mint laying about my home directory. Mint was set up with both Gnome and KDE, so all the config files from a months use were there. There was no issue at all with anything. KDE (the default GUI of PCLOS) fired up, went in, and everything was great. Well. Mostly.


Intel Graphics Chip


Like Ubuntu, but not like Fedora or Mint, PCLOS did *not* set up the Intel graphics chip correctly at first. Worse, the Drakconf utility that lets you fix this was nowhere to be found on the desktop anymore. It was there on the taskbat when it was booted on the LiveCD: now it was gone. It actually took me a few moments to dig up what the config utility is called (been a while since I used Mandrake), and fire it up from command line. *Now* it noticed I needed to install the "915Resolution" package to deal with the hardware. I said it could. Download. Install.


  • Logged out, restarted X, back in. Still 1024x768. Another trip into Drakconf, and I reset the panel type from 1024x768 to 1280x800.
  • Log out. Restart X. Still whacked. Back into Drakconf. Go into "Screen Resolution". 1280x800 not an option. 1280x960 is. At the bottom are the words "Other". I pick that, and now it redraws the menu with all sorts of resolutions, including the one I need.
  • Exit, out. In. Now the fonts look like crud. KDE control center can fix that: Turn on anti-aliasing, force the DPI to 96, save, exit.
  • Come back in, and now it looks right.

This is not better than Mint so far. But after this it gets better...


Building the Perfect Corporate Linux


Launching Synaptic, running update installing north of 200 updates (about the same ball park in terms of number of packages as the first time I fired up Mint), rebooting, going into Synaptic again, start tweaking this out as a corporate desktop. I noted along the way that the Synaptic update has Firefox moved from to that is goodness. I was afraid I was going to have to override the default browser install.


The PCLOS kernel is oddly old, at 2.6.18. That kernel version was released last September, 2006. Mint on my Acer is at kernel 2.6.20, Fedora on my Dell C400 is at 2.6.22, and is at 2.6.22 as well. This only matters of course if I turn out to need one of the new features of the later kernels. So far, on the D620, that does not appear to be the case, other than possibly ACPI.


If you have to work with MS Exchange mail servers and do cross calendaring with MS Windows users , then you have pretty much only one choice for email client: Evolution. Two, if you count Outlook Web Access and your favorite browser.


Evolution is not installed by default. PCLOS dropped it in favor of Thunderbird a while back. But it is still in the PCLOS apt repositories, and Synaptic can pull it down. Even though the kernel is "backlevel", the Evolution groupware suite is the same release (more or less) as Mint's: 2.10. Normally when I change out the OS level on Linux, I move all the Evolution dot files into backups, and create all new, since Evolution has a history of not dealing well with upgrades. I took a flyer, brought Evolution up as is, and it happily accessed the .evolution, and other .gnomeish files and worked like a champ. Out of the box. No issues so far. That might be a first.


I need other things: Avahi, HFS+, Quanta, Bluefish, NVU (yes... I know. I like to mess around with different HTML generation utilities, even though I almost always just fall back to Google Docs in the end.). I need Planner, and it is available.


At this point, I am noticing another thing. The package repositories are actually pretty fast. One of the reasons I stopped using Mandrake was that their repositories seemed to get slower and more painful to use every release. In fact, the Mandrake package manager was no great shakes back then (No idea now: I put up Mandriva 2006 last year, but on hardware so slow that I could not evaluate how fast anything was), so I can see why Texstar opted to use Synaptic instead when he forked Mandrake/Mandriva to create PCLinuxOS. These PCLOS repositories are on par with Mints in terms of download times. Mint, being on top of Ubuntu, which is on top of Debian means that there are well over 20,000 packages available. PCLOS has less than that, at 6882.  Does that matter? Not so far. Everything I have looked for was out there as an installable. Whatever is not there, it is so far not something I use.


Office Sweet


OpenOffice is nice and current at 2.2.1. Even better, on the KDE menu, I can invoke the "Web Writer" mode separately from the "Writer" mode. This is the way it should be IMHO: OpenOffice acts differently in those two modes, and the Web Writer not only lets me edit the HTML directly, it tends to generate far cleaner HTML than OpenOffice Writer, doing a "Save as HTML". That latter mode puts in all sorts of extra text layout directives that try and make the doc look exactly the same on the web as it does on the printed page. That means the HTML pretty much sucks rocks. It may be 100% standards compliant, but it is a mess to work with. Better than MS Word doing a "Save as HTML", I will give you that. That really is not saying much though, as MS Word is well known for creating bad HTML. Not sure about the new 2007 version. Never seen it. I suppose it is possible it got better there: the new version of Frontpage was supposed to be getting fixed in terms of its standards compliance. Maybe the same HTML engine? I digress....


On Screen Mr Sulu.


When I press the tiny, dedicated volume up, down, or mute buttons on the D620 (special keys above the keyboard) when it was running Mint, an on screen display popped up, showing me what I was doing, and thye keys worked. PCLOS does not appear to know how to deal with those keys. I don't really care that much. Kmix is easy to click on and tweak, but on the other hand, it is another thing Mint does that PCLOS doesn't. I poked around in Synaptic looking for a package that might not be installed, but nothing was apparent. Keywords like 'laptop' and 'Acer' and 'Dell' turned up nothing when searching in Synaptic. I was looking for Acer because there is a new project to make Acers special keys work, similar to the IBM laptop package like "tpb".


Install as Root


I do not like to log into root. Its a security thing. I do it when I have to: Single user mode, FSCK, etc. But mostly I like to work from my userid and leverage sudo to power me through the additional software package installs from my userid. Perhaps the missing DrakConf is not installed in my pedestrian accounts taskbar by default but available on Roots.. Maybe it is buried on a menu someplace. I tried to "switch user" over to root, but the screen flashes brightly and I can't get in to look. I did not try logging out and then back in as root. The key point was that Drakconf was hiding, not that I might be able to find it on an extended search.


/etc/sudoers is not pre-configured by the install to include my account, so I fixed that, and I also added an icon button for Drakconf to the KDE task bar. I think it is pretty elegant the Ubuntu / Mint add the first user defined *automatically* to /etc/sudoers.


I supposed this is a schism point for Linux: how separate do you keep root? How powerful do you make the default user account? On one end, some distros just let you into root and are done with it. Ubuntu/Mint hides root altogether, but sets up sudo cleverly so that by entering your password you can install things. PCLOS is more on the "Use two accounts to do separate things" end of the spectrum.


I don't really know which one is better. In PCLOS, I made my userid able to do rootish things via sudo authentication. On Mint, I set roots password, and configure so I can log into it *if I want to*. These are all personal preference things, and as long as the distro lets me set it up how I like, I guess it does not matter much.


ACPI out to lunch


There is a little KDE app called Kima the PCLOS includes. Kima reads stuff out of ACPI and displays it on the task bar. Actually, I set up a second task bar. I moved the KDE default one to the top of the screen, added a new panel, and put Kima and the active tasks on the new bottom bar.


Kima or ACPI or both have lost their minds. Where Mint displayed sane fan speeds, cpu frequencies, and whatnot with its gnome apps for such things, Kima says that the CPU's never drop off 2 Ghz, and that the fan is running at 7974 - 8016 rpm. If the fan was running that fast, it would be a banshee of supersonic screaming, and the D620 laptop would be hovering. In fact, something is lying, because when I put hand at the back, left hand side of the computer where the Core 2 Duo heat sink is, there is only a tiny whisper of a breeze coming out of it. I assume that this is an effect of the back-level kernel. It is not serious, but it is annoying.


That being said, here is another subjective observation to place into the pipe and smoke a bit: PCLOS seems faster than Mint. I have not measured anything, but it just feels crisper. That is not something I would have expected from a 2.6.18 kernel, since for one thing a number of the enhancements up the road have to do with laptops, ACPI, and the scheduler.


Suspend is a real hit or miss affair. This also worked better on Mint. I am thinking it is the new kernel again.




IMHO Beryl is fun if not utterly useful. Ubuntu has announced that Beryl's soul-mate Compiz will be enabled by default in their next release [7.10, or "Gutsy Gibbon"]. PCLOS ships Beryl and Compiz installed, and either can be enabled from the KDE Control Center. This is a very nicely integrated bit of work. I wish all the DrakConf functionality was in the KDE control center too. Or KDE Control center was tossed and all it's functions put into DrakConf. Having two apps for system config is really not intuitively obvious. I digress: Beryl / Compiz is the point here.... I enabled Beryl.


Beryl runs well, is fast, is stable, and all the effects do not seem to slow the computer in the slightest. Mint was/is good in this regard as well.




When I installed PCLOS, I defined the wired interface. It was late at night, I was at the office still. No wireless. Just Cat5. When I took it home to continue the testing, PCLOS did not automatically decide that it should switch to the wireless interface instead. Mint does. Ubuntu does. DrakConf brings up the interface easily, sees the access point, and connects to it no problem. The Intel wifi hardware is no issue (unlike Fedora).


I do not know if I had started by defining the wireless interface first if PCLOS would do better here. Clearly all the parts are in place. The hardware is located, defined to the OS. There just is not a process that looks to see which interface has a valid connection available. My iPhone can do that, switching between Edge and Wifi, and preferring Wifi when it is available.




This whole test has given me an idea for my next post over at I'll start on that as soon as I finish this. [Update from the future: Schism>/a> now posted ]


It might have occurred that this is hardly a great comparison: Mint versus PCLOS is a Gnome interfaced Distro (by default: KDE can be installed, and like Ubuntu, there is a KDE version of Mint ) versus a KDE default interfaced version (and while I did not do it, it looked like I could install Gnome onto PCLOS with Synaptic). If someone says that PCLOS is better than Mint, what I can not tell is whether they are at least in part saying that KDE is better than Gnome. This is part of why I mostly focused on things that underlie the GUI. I have no GUI axes to grind. I can use KDE or Gnome. I like them both. I know most folks have a strong preference for one over the other. My only statement of opinion in this regard is that I think people with MS Windows backgrounds will be more comfortable with KDE to start.


I am also not sure looking at PCLOS as a corporate desktop is a valid thing to do, any more than when I looked at Fedora for the same thing. The home page of PCLOS contains a history of PCLinuxOS, and that has the following line in it: "Since Mandrake was a trademarked name myself and others decided to name the livecd after our news site and forum pclinuxonline thus PCLinuxOS". The news site and forum has no history, mission statement, why we are here kind of thing that I can find, so I am going to make a supposition. The PC of PCLinuxOS is from the same machine most people use to run OS's, I.E. PC = Personal Computer. There is no server edition. There no paid-for support option (The home page link "About Us" in fact says :


Customer Support:




If you need customer support, please visit our friendly forums .


Nothing about central management tools (although plenty third party stuff is out there for Linux that would probably work with PCLOS).


Mint has a helpdesk support option, and Ubuntu has Canonical support.


My point is I just wrote an article about using a community supported personal computing Linux version running KDE and compared it to a completely different kind of version of Linux. They both have that chewy Linux goodness inside, but they are not really valid comparisons in any other meaningful way. My one constraint: That I was looking at it as a Corporate Desktop should have set alarms bells ringing.


Oddly, that initial criteria worked in PCLOS's favor here. Not having wireless at the office, the way wireless must be manually set up every time is no big deal most of the time. For me.


Go back through "Adventures", and in posts too numerous to link here you will probably get the idea of why my thinking is on what the killer application is for a Linux corporate desktop. Well, two of them: OpenOffice is a given. The other is Evolution. If you are an MS Exchange shop, and you don't want to live with a web browser interface to email and calendar, then Evolution is a must. PCLOS's version of Evolution (even though it was not on the default install) has so far been more stable than Mints, and that means I'll keep PCLOS on the Dell D620 for now.


At least until Mint 3.1 ships.


A batch up updates about various issues raised by last weeks post. The news is all good too!


Last week I posted about some things we were up to in the Network Attached Storage area, and this post was new in that it was not about what we had already done, but what we were actively doing. I don't usually let it get out there that I don't know everything, but this seemed like a good time to get the truth out :)


Part of the idea of posting this way was to get some information out there as soon as possible, and to get feedback from any others that might be in the same boat as us. This week I have a batch of updates to various things in that post. I will not spend as much time doing background as I usually do: You are either going to care about this and already know about it, or have no idea what I am talking about and go see if I posted something more interesting over at I haven't.... For one thing I have been traveling all week, and have not had time.


This post would have been up sooner, but I was waiting to hear back on permission to post some things that were mailed to me, and also to see how an experiment turned out. The experiment is probably of more interest to the general Linux folks, so I'll cover that first:


In the aforementioned post, I pointed at a Bugzilla link... actually Dan Goetzman, Chief NAS Officer (CNO: Like CFO, only different) pointed at the link. Dan looked to see what the patch was about, and saw that it was "only" a deletion of three lines: the code was checking for:

GFS(s) expects NFS fh_type and fh_len would have the same value

that would apparently never be true, and that was causing a problem for NFS when it was accessing GFS-provided file systems. Here is Dan's news:



I found the simple patch instructions for that Bugzilla report (OK: I won't make you dig that out of the last post: 229346 : Ed.) that I thought was the root cause of the NFSV2 over GFS problem I discovered on the CentOS cluster. The good news, it is indeed the problem! I applied the patch and rebuilt the gfs kernel module on all 3 nodes and that problem is gone!


I guess when it rolls out in a future CentOS update I can remove this specific patch.

I have restarted my testing, back from square one. So far, so good...

I still have the "other" problem (same as with Red Hat 5). Older Solaris clients (7-8) are not able to mount NFSV2, but the default NFSV3 works fine. So, for now I will assume we can live with that limitation.


I was thinking about gen'ing a custom kernel with NFS_ACL support off to see if that would prevent this problem. Apparently there is no command line or modules.conf way to turn that off. The NFSD module is compiled to make calls into the NFS_ACL module.


For now, I will forge ahead assume we don't need NFSV2 on the older Solaris clients.


That is terrific news, because if this works, that means the GFS layer will prevent us from having to do all sorts of customer failover code for the NFS and CIFS servers in the cluster! Well, that is the theory anyway. Warning: Law of Unintended Consequences in full effect here!

Tru64, TruCluster, and READDIRPLUS with some NFS Clients.


The other problem we have been having has to do with Tru64 and some NFS clients that do not deal well with each other. The CentOS cluster above is meant to replace the Tru64 TruCluster as soon as we can qualify it, but in the meantime various clients that are being 100% protocol complaint are failing because Tru64 does not do the right thing with READDIRPLUS calls. Graham Allan, IT Manager in the School of Physics and Astronomy at University of Minnesota, Dan, and I have been emailing about this at some length over the last week.


The good news is that the problem has been fixed in the Tru64 community: Here is the news from Graham:


One of our students here also found a reference to the issue in the
Redhat bugzilla database, which alludes to some possible fixes at the
Tru64 end:

In particular:

     Comment #11 From Ahmon Dancy        on 2007-03-08 15:35 EST             

     (In reply to comment #8)
     > > Just curious... is there a way to turn off READDIRPLUS
     > > support on Tru64 servers?

     Yes!  The following worked for me.  There is probably some better way to
     do this
     so that it remains permanent across boots, but I haven't figured it out yet:

     ladebug -k
     assign doreaddirplus=0


     Comment #12 From Ahmon Dancy      on 2007-03-08 19:47 EST           

     If anyone is interested, I have hacked up a new nfs_server.mod kernel
     module for
     Tru64 which fixes the bug.  I have it deployed on a local system and it
     fine.   I built it against a host that identifies itself as Tru64 V5.1B
     2650).  It can probably be adjusted for other versions as well.


     Comment #14 From Ole Holm Nielsen        on 2007-04-17 16:48 EST             
     Regarding Comment #11 I have some further advice:  You may not have
     installed on your Tru64 server, but probably you have /usr/bin/dbx. 
     You may then modify the "doreaddirplus" variable until the next reboot by:

     # dbx -k /vmunix
     (dbx) assign doreaddirplus=0
     (dbx) quit

     If you want the change to be persistent across reboots do:

     # dbx -k /vmunix
     (dbx) patch doreaddirplus=0
     (dbx) quit

     If you upgrade the kernel this will have to be repeated.

     We have verified that this workaround solves the NFS problem
     with a Tru64 NFS server and a RHEL5 Linux NFS client.


     Comment #15 From Steve Dickson        on 2007-05-15 11:00 EST             
     Fixed in nfs-utils-1.0.10-10.fc6 by added the -o nordirplus mount option
     which will have the kernel support in the next kernel update.


I (Graham: E
d) had an interesting reply as well from Ahmon Dancy who had 
mentioned his "hacked" nfs server kernel module in the bugzilla discussion.
I will paste his reply for you:

   There are two approaches available now, and mine is the more
   complicated of the two.

   Approach #1:

   See post 11 on that bug, followed by post 14.  This disables
   readdirplus support altogether in the NFS module.  Then, when linux
   makes a readdirplus call, it will return a not-supported code, in
   which case linux will revert to standard readdir, which works.

   Approach #2 (mine):

   My approach was to spend a (bunch) of time disassembling the nfs
   kernel module and patching it w/ a fix so that readdirplus works


Impressive bit of reverse engineering! I use Ahmon's name here because it is in a public forum on this issue already. Graham said I could mention him...

Even better, HP *appears* to be working on a formal patch for this, so Tru64 is still being supported inside the company!


That is all this time. I hope this information helps others fighting one of these two problems!

Filter Blog

By date:
By tag: