The arrow of time

Ubuntu story: I carried the gadget to work in order to upgrade it over the network but soon found out I left the charger in my apartment. It's not like I don't know that I'm looking for trouble by starting a system upgrade without an AC supply and going to a meeting, but I thought it had plenty on time on battery to perform the upgrade so it will most likely sit there waiting at a "Reboot now or later to finish the upgrade?" prompt when I return (or, at worst, the batteries will die at this prompt). Unfortunately the meeting got long and the batteries did die - but not in the way I expected. Apparently the computer just turned off for the lack of juice instead of a clean shutdown. Whan I connected it to AC later, some kind of startup utility died, X11 couldn't start and the root file system was left mounted read-only. The system (at the console login prompt) identified itself like 8.10 but it booted the old kernel and apparently the packages were all over the map. Doesn't seem good, right? Apparently, no. After mounting the file system properly, the first package maintainance utility I tried instructed me to run "dpkg --configure -a" so this is the magic incantation I did. After some churning, new packages were up, new kernel was up, boot loader configuration was up (I dual boot the machine with Windows but it simply added the new kernel to the list, which is I think the optimal thing to do) and after rebooting it was like nothing bad has happened - I have a shiny new Ubuntu 8.10. I still need to check about some packages but so far everything I tried seems to work. Color me impressed - this aspect of the system really looks robust and reliable. If I tried to pull this on portupgrade (i.e. stop it after it was only half done), it would be next to impossible to track which packages (+dependencies) were processed and which weren't.

RHEL story: One of the things I do is deploy and maintain a complex PHP web application developed at our University and used at other departments and commercial clients. The application was developed on FreeBSD and we took great advantage of the abundance of PHP libraries available in the ports system to enhance the features of our application. A client insisted on RHEL and that's what we, in cooperation with his sysadmin, deployed. Because RedHat has blessed only a very basic number of PHP libraries for official support and deployment, we had to find and use packages from God knows where, compiled by unknowns in an unknown way. Another thing is that RHEL apparently only supports Apache in prefork mode, and we've been deploying FastCGI for years now, for better performance and reliability. It soon become apparent that the conglomerate of packages doesn't play in perfect harmony and causes problems. I had it with problems and decided to build a parallel infrastructure with pkgsrc that would be used instead of the RHEL-botched one. I found out it was really similar to FreeBSD ports and has all the packages I need. Additionally I could simply use FastCGI with Apache and mod_fcgid (going from fifty 100 MB Apache processes to 5 multi-threaded Apache processes and 10 fat PHP processes). Great! If I can always do that, I won't be afraid to deploy on RHEL in the future