error: attempt to use poisoned "realloc"

Today I tried to compile ITK 2.2 on my machine again and ran into the "poisoned" error. A quick research on the internet recovered that this is caused by the gcc people having replaced realloc with something like xrealloc(the same applies to malloc).

Naively I tried to just replace both words in all the .c files:

find . -name "*.c*" | xargs perl -pi -e 's/realloc/xrealloc/g'
find . -name "*.c*" | xargs perl -pi -e 's/malloc/xmalloc/g'

But that didn't work at all and caused even more errors. I ended up with downloading a new version of CableSwig from the net and because I am still compiling keep your fingers crossed...

Storage Networking World 2006

I had the chance to attend the Storage Networking World 2006 this week for free. The most important message is: Virtualization is real! Virtualization in the storage world essentially means you can hide all your storage arrays (that's how they call big cabinets of hard drives) from different vendors behind one mount point (in case of NFS) - and even better add more arrays without changing anything on the server. Also you can make the application believe it has 64 TByte without actually providing it. So the next time the storage guys come to you and tell you you can't have all that storage -- you know they are full of crap;-)

And best of all the virtualization thing let's you do backups, migrations (data to a faster, better array) without any downtime. In addition to that I have see vendors selling big boxes which take care of everything - even swap rarley used files out to tape and the load them again in case you would need them. This stuff all comes in a big rack, with a service contract, and all we need to do is to mount it on our developer machines and we will never loose data again.

Another interesting tidbit was Geoffrey Moore's keynote "Dealing with Darwin": Geoffrey explained how to slice your "business" into core and non-core activities. In the core you want to innovate in the non-core area you want to drive down costs. Unfortunately there is also another dimension "mission critical". You really can't scrap resources from a mission critical non-core activity - that really let's the lights go out in your shop. So you have to carefully manage that so it becomes non-mission critical and can be outsourced. The most important thing for us programmers is that we probably should watch out when we find ourself in a project / support function for a product which gets managed to become non-mission-critical and finally being outsourced. To understand this stuff better you should read Geoffry's book: