2 posts tagged “ubuntu”

Thanksgiving weekend has been an interesting few days. We headed down to my parent's house for a family Thanksgiving. After the eating, my wife and I headed back to my parent's house from my aunt's since Logan was extremely worn out. He went to sleep, and I pulled out my laptop.

I knew something was wrong as soon as I hit the power button and the hard drive started clicking like mad. The laptop then decided to tell me that there were no bootable devices and to run the diagnostic tools. I did, and then it told me there was no hard drive detected. Not a good thing. I pull the drive out, reseat it, and the same thing. Horrible clicking followed by the same error.

I had a copy of Spinrite (which I highly recommend for anyone) in my laptop bag from work and booted off of that. I tried to select the drive, which it recognized, and it said that there appeared to be a problem. When I tried to actually start the Sprinrite process, it refused. My drive was in such bad shape that Sprinrite actually told me it wouldn't run. Not good at all.

This is the one machine I have that doesn't get backed up.

I grab my dad's laptop and head to Dell's website. I log on with the chat, give him the service tag. I explain my problem and what I've done. Without any other questions, he asks for my address and says that a drive will be at work by Monday. No hassle, no going through their magical checklist to reaffirm that my drive is dead. The chat lasted less than 10 minutes, most of it confirming address and contact information.

That still left me without a laptop to use until Monday. I had my external hard drive, an Ubuntu 7.10 CD, and a laptop that boots off of USB. Plugged in the first, stuck in the second, and told the laptop to boot from the third.

After a few moments, Ubuntu booted and recognized my external drive. I started the installer, told it to wipe my external drive clean, and after about 20 minutes it was finished. I rebooted... and had a desktop! Ubuntu had detected all my hardware just like it had the last time it was installed, and even playing OpenArena I can't tell that I'm running off of a USB drive.

Most of today has been installing little bits of software, but at least I have a laptop. The battery even lasts about two hours even with having to power the external drive. Tragedy averted? Not really, I lost a demo I had set up in VMWare and will get to figure out how to set it up and see how dead the internal drive is Monday, but at least I have a fully functional laptop.

At least it's working.

One of the things that plagues any OS is an availability of software, and the ability to install said software. On Windows, it comes easily, and on MacOS X it's even easier to install. But those are primarily binary-based operating systems, so there isn't any need to compile. Everything is already there in nice, neat packages.

On *nix, the story is a lot different most of the time. Sure, there are binary installers like Google Earth or Java, but for the most part if you want to install something, that means downloading the source, './configure'ing, 'make'ing it, and 'make install'ing it. That's assuming you have all the dependencies, and the only way to know that is assuming that the package tells you what exact dependencies you need. In response to all this, RPM and .deb packages evolved.

RPMs and .deb packages do not clear up this dependency hell. You need some sort of manager. Thus comes 'yum' and 'apt'. These programs are supposed to find out what dependencies you want, install them, and then install the software that you want. yum is, unfortunately, incredibly slow for my tastes. apt is very quick and efficient, and handles .deb and RPM packages just fine. The downside is that these two tools rely on a source for their information, generally internet sites called 'repos.' These repos have all the dependencies that one would need to install software, and almost always have a ton of software for you to choose from.

What happens when you want to install, say, OpenXchange? Well, the paid version includes a script to install itself and download all the packages that one might need... assuming that you are running RHEL 4 or SUSE Enterprise Server 9. Say you don't want to put down money for RHEL to try out software you don't want, but at this point SUSE Server is at version 10. What do you do? Not install it on 10, that's for sure.

Invariably, on any RPM-based distro that I attempt to use, I quickly run into dependency hell. In the case of OpenXchange, the packages needed are not on the install DVD for SUSE 10. So I went looking around the internet. You download the RPM package you need (package 123), try to install it. ERROR - This package needs XYZ package before it can be installed. Search for package XYZ, download, install, ERROR - You need package ABC for this package to install.

Search, download, install ABC, then XYZ, then 123. Try to install 456, search for DEF, install DEF, then 456. Install 789... see where this is going? The best part about this is that you have to find RPM packages for SUSE. You want this specific package? Oh, I'm sorry, the newest one is only built for RHEL. There is an older one for SUSE 9.x if you want to try that.

With the knowledge that OpenXchange is near impossible to install on SUSE 10, I'm forced to an outdated server edition of 9. Download all 6 CDs for 9, install 9, install OpenXchange, and everything works fine. Why? SUSE Enterprise Server 9 contains all of the packages you need right on the CDs. No external repos or downloads needed.

What happened to all those packages that I needed between SUSE 9 and SUSE 10? They were never built, and by the looks of it no one wants to take the time to update the packages.

Why must this be such a pain, you might ask? Because even though RPM follows a specific format on how the package itself is created, each distro that uses RPM needs files in different places. That package that you downloaded for SUSE 9 may not work right on SUSE 10, and even may not work right on RHEL. Each distro may have files in different locations, and SUSE might expect something in /etc/program, but on RHEL it might actually be in /opt/program, or /usr/local/program.

RPM suffers from a splintering of the distros that support it. By contrast, I haven't run into an issue on Ubuntu wherein I download the Debian-only package. Why? Most Debian offshoots stay fairly close to their roots, so that means an Ubunutu package has a fairly high chance of working fine on Debian itself, or SimplyMepis, or any another Debian offshoot.

Hopefully RPMs will one day be less distro specific so that it makes life easier. Until then, if I can't find it in yum, I'm hesitant to try to download an RPM I install off of the internet.