While catching up with some posts on the CentOS mailing list, I came across a post from a person who had managed to hose up his system by forcefully installing several RPMs. The user was using Oracle’s unbreakable Linux, and installing the RPMs had really done a number on his package repositories. I laughed silly when I read Jim Perrin’s response to the users plea for help:

Original poster> Hi, everyone, I have one conflict problem when I try to install Centos YUM
Original poster>on RHEL 4_X 86_64.

Original poster> Uname -a shows:

Original poster> Linux PT3 2.6.9-42.0.0.0.1.ELsmp #1 SMP Sun Oct 15 15:13:57 PDT 2006 x86_64
Original poster> x86_64 x86_64 GNU/Linux

Jim’s reply> This isn’t a RHEL kernel. This is the Oracle Unbreakable Linux kernel.
Jim’s reply> Congrats, you broke it.

Ahhhhhh — the humor we geeks find in the little things. :)

Posted by matty, filed under Linux Misc. Date: December 4, 2006, 7:54 pm | No Comments »

If you have ever done a long listing of /usr/lib on a Linux system, you probably choked and asked yourself what the f$%^ is this mess? After reading through Peter Seebach’s article Dissecting Shared Libraries, things don’t seem so bad, and the large number of files actually starts to make sense. Step one in sorting out the library madness requires making sense of the digits (the major and minor revision numbers) that appear in the shared library file name. Peter’s article clarifies this with the following description:

“One of the potential advantages of dynamic linking, however, is in fixing bugs. It’d be nice if you could fix a bug in the library and not have to recompile a thousand programs to take advantage of that fix. So sometimes, you want to link to a newer version. Unfortunately, that creates some cases where you want to link to the newer version and some cases where you’d rather stick with an older version. There is a solution, though — two kinds of version numbers:

  • A major number indicates a potential incompatibility between library versions.
  • A minor number indicates only bug fixes.

So under most circumstances, it is safe to load a library with the same major number and a higher minor number; consider it an unsafe practice to load a library with a higher major number.”

This makes sense, and seems like a good thing for systems that don’t want to break applications. Now what about all those links in /usr/lib? Peter provides the following description:

To prevent users (and programmers) from needing to track library numbers and updates, the system comes with a large number of symbolic links. In general, the pattern is that

libexample.so

will be a link to

libexample.so.N

in which N is the highest major version number found on the system. For every major version number supported,

libexample.so.N

will be a link in turn to

libexample.so.N.M

in which M is the largest minor version number.

If you haven’t checked out IBM’s redbook or Linux developerworks sites, I highly recommend doing so. There are numerous awesome pieces of documentation spanning numerous technologies.

Posted by matty, filed under Linux Misc. Date: December 28, 2005, 1:11 pm | No Comments »

While reading an article on MacDevCenter, I came across a link to the world famous Torvalds / Tanenbaum micro-kernel debate. The debate doesn’t actually address the merits of micro-kernels and monolithic kernels, but provides for an interesting read.

Posted by matty, filed under Linux Misc. Date: October 6, 2005, 12:29 am | No Comments »