Speeding up Safari

I recently got sick of the Safari spinning ball, and decided to conduct some research to speed up my favorite web browser. After reading numerous posts on the Apple discussion board, I made the following changes to significantly boost page rendering time:

1. Add Mike’s Ad Blocking Hosts file to /etc/hosts and restart lookupd

2. Purge the Safari cache from Safari -> Clear Cache

3. Remove old RSS articles by clicking Preferences -> RSS -> Remove Now

Once these three actions were complete, Safari was back to post install speeds! Nice!

What happened to customer service?

I just had another awful experience with a large corporation’s customer service, and this got me thinking about how crappy customer service has gotten. There seems to be a complete lack of problem ownership, representatives are paid to get you off the phone, and in most cases the problem is pawned off on the individual who is trying to get help. When I was a wee lad, I remember customer support representatives being friendly and trying to assist with actual problem resolution regardless of the circumstances. Has capitolism truly eroded the desire to care about people when assisting them over the phone?

I attached myself to myself

I came across my new favorite error message last night while debugging some issues with the Solaris printstack() function:

$ gdb -q /var/tmp/apache2/bin/httpd

(gdb) shell ps -ef | grep gdb
matty 9216 8963 1 20:30:34 pts/1 0:00 gdb -q /var/tmp/apache2/bin/httpd
matty 9217 9216 0 20:30:41 pts/1 0:00 bash -c ps -ef | grep gdb

(gdb) attach 9216
Attaching GDB to itself is not a good idea…

You gotta love some geek humor. :)

Making sense of libfoo.so.2.6 on Linux systems

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.

Getting Emulex adaptors working with Solaris

This past week I wanted to use the Solaris cfgadm utility to unconfigure a few LUNs. When I ran ‘cfgadm -al’, I noticed that the FC adaptors were not visible in the cfgadm output:

$ cfgadm -al

Ap_Id                          Type         Receptacle   Occupant     Condition
c2                             scsi-bus     connected    configured   unknown
c2::dsk/c2t0d0                 CD-ROM       connected    configured   unknown
usb0/1                         unknown      empty        unconfigured ok
usb0/2                         unknown      empty        unconfigured ok

This seemed odd, since I could see the controllers in the vxdmpadm output:

$ vxdmpadm listctlr all

CTLR-NAME       ENCLR-TYPE      STATE      ENCLR-NAME
=====================================================
c1              Disk            ENABLED      Disk
c0              Disk            ENABLED      Disk
c4              EMC             ENABLED      EMC0
c3              EMC             ENABLED      EMC0
c4              EMC_CLARiiON    DISABLED     EMC_CLARiiON0
c3              EMC_CLARiiON    DISABLED     EMC_CLARiiON0

Since the controllers in question were Emulex adaptors, I read through the Emulex admin guide and found that the platform and FC adaptor had to be DR aware to support configure/unconfigure operations. Since I couldn’t locate a “DR aware” label in our vendors documentation, I decided to open a ticket to see if the servers supported cfgadm. After a week or two of chatting with support, our vendor indicated that we would need to use the Sun Leadville drivers to configure and unconfigure LUNs with Emulex adaptors in Solaris systems. This was awesome news, and I am super happy that the lpfc driver will now be installed in /kernel/drv by default! Niiiiiiice.