Three and half years have passed since my first attempts to install Oracle 10g on an unsupported Debian GNU/Linux distribution. Seeing that Oracle 11g is out, and exclusively for Linux at this time, I decided to download it among the first and see and share with you what it's installation looks like.
The distribution can be downloaded from the Oracle Database Software Downloads page, but let me warn you upfront that the archive is 1.7GB in size, so you'll need quite a big pipe to successfully download it. What makes it even harder is that Oracle insists that you download it from browser window (Wget and similar utilities won't work out of the box, although there are some tricks that can be deployed), so be prepared to have that browser window open for a long time and prey that download doesn't break along the way.
Exactly 10 years ago, on 15th August 1997, Miguel de Icaza started his first announcement about GNOME Desktop project with this words:
We want to develop a free and complete set of user friendly applications and desktop tools, similar to CDE and KDE but based entirely on free software:
- We want the applications to have a common look and feel, and to share as many visual elements and UI concepts as possible.
- We want to use the GTK toolkit as our toolkit for writing the applications.
- We want to encourage people to contribute code and to test the code, so that the software will compile out of the box by using GNU's tools for automatic source configuration.
Both runs have been done on a single 120GB 7200rpm IDE disk. Command used: iostat -x 5 (extended statistics, sample every 5 seconds).
All screenshots were taken on my home workstation (Dual PIII 1GHz, 768MB RAM). Brown color represents kernel memory usage (miscellaneous caches), red is for active memory (page/buffer cache in use and mapped pages - applications), yellow is inactive page/buffer cache, green is free memory and finally orange color represents swap usage.
On the first picture you can see what happens when cron runs updatedb process, refreshing file name database (used by locate command). Rather quickly memory gets consumed by various kernel caches as updatedb traverses filesystems. Those are mostly inode & dentry caches, used by the kernel to find and access a file. Obviously, I have lots of files as more than half of my memory gets used by the caches. If you had enough memory so that you can cache and keep all this valuable information in memory, second updatedb run would finish almost instantly, instead of few minutes of disk crunching.