Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Fri, 10 Sep 2004 nmeyers at javalinux.net wrote: > On Fri, Sep 10, 2004 at 02:33:51PM -0400, David Kramer wrote: > > Up until recently it was HP-UX, because I had some messy issues porting > > an app from HP-UX 10 to a more modern version. They changed every object > > size under the sun in preparation for 64-bitness and a newer curses > > standard and IPv6, even though that newer HP-UX didn't itself have the > > 64-bitness or IPv6. > > As a former HP guy, I thank you :-). No problem. AIX was already a close second anyway. It was on AIX that I faced my most hard-to-trace, poorly-documented UNIX strangeness to date. While working at Pegasystems, I was supporting this client whose installation of our application was taking up three or four times the memory it should. We couldn't figure out why. They even sent us tar files of their installation, and we would get the sysadmin to install it, and it would run fine. We even brought in an AIX expert for a few days. The problem turned out to be this: On AIX, if a shared library file (which, by the way, has to be named *.a, not *.so) is writable, the code segment is duplicated in memory for each application using it, and if the file is read-only, then all of the applications share one copy of the code. That's right: the file permissions determine how the library gets loaded into memory. Of course the sysadmins were changing the file permissions when they untarred the files here, so we never saw the problems until we asked them to do a "find . -ls" and send us the output. We noticed the permissions difference, and tried it on a lark. We susequently called IBM, and *they* had trouble finding where that was documented.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |