Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Officially changing my most-hated UNIX flavor.



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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org