Sparc Classic as a Web Server

After 512MB had been put aside for the swap partition, the remaining space had to be filled with carefully selected software packages, so the system has enough space left for applications. Disk space also was an issue when I installed additional software such as the GNU C compiler gcc. The standard gcc package now includes a lot more then just the plain C and C++ compilers. It's 92MB size decompressed to 400MB on disk, to much to handle for the Classic. Luckily there was still a smaller package available.

Also, modern operating systems start an enormous number of processes and daemons for caching, device control and system management that run fine on modern systems (at least nobody cares much or even notices about the often wasted CPU cycles) but they would kill the Classic while competing about its limited resources.

SUN's Sparc Classic as a Web Server or running modern day software on a 10 year old computer - Page 2
After 512MB had been put aside for the swap partition, the remaining space had to be filled with carefully selected software packages, so the system has enough space left for applications. Disk space also was an issue when I installed additional software such as the GNU C compiler gcc. The standard gcc package now includes a lot more then just the plain C and C++ compilers. It's 92MB size decompressed to 400MB on disk, to much to handle for the Classic. Luckily there was still a smaller package available. Also, modern operating systems start an enormous number of processes and daemons for caching, device control and system management that run fine on modern systems (at least nobody cares much or even notices about the often wasted CPU cycles) but they would kill the Classic while competing about its limited resources.	Sparc Classic: "df - k" on a 2GB harddisk with Solaris 9 Sparc Classic: "top" on a 50MHz system with 96MB RAM
Finally, the age shows when running some modern applications that had not been available during the haydays of the Classic. For example, file transfer with scp is awfully slow because the processor is so busy crunching numbers for the encryption. Or, just reading a longer man page resulted in half-a-minute wait due to the formatting process. For the manpages, I decided to use some precious diskspace and created the preformatted versions with catman. For the local file transfer, I fall back to good old ftp. Compiling modern software is also a process requiring a lot of patience, a full day went by when I compiled the latest Nmap and Nessus packages. But what really caused me headache was the issue I encountered after bringing up the Apache webserver.	While serving static pages just fine, I had a unbelievable 7 second delay once I tried my first .cgi that was written in Perl. Unacceptable! I was ready to give up.
	But then I accepted the challenge and I searched for alternatives: mod_perl, mod_jserv and CGI programming in 'C'. While mod_perl showed no improvement at all, mod_jserv was a big surprise to me. I did not expect Java to be an option at all. But once the JVM was running, pages were delivered fast. I thought hard about it and decided against. First, the JVM is another process takes permanently 40MB of memory. Although not all of it is resident, running it would only make sense if I expect to be under constant web load, <page 3>