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!
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 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. :)
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
will be a link to
in which N is the highest major version number found on the system. For every major version number supported,
will be a link in turn to
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.
I installed Spam Karma 2 a few weeks back, and am amazed at how well it works! Not only has it captured every piece of SPAM posted to my BLOG, it automatically purges them so I don’t have to do anything myself (the “purging” feature is a configuration option). Thanks Dr. Dave!
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.