Back in the bad old days I use a PDP11 w/ 48KB of core memory, which at times ran AT&T Unix, the C compiler and back then "hello world" program was a few KB. Here for example;
Quote:
[stevea@luchs tmp]$ cat > hello.c <<EOF
> int main() { printf("Yellow world!\n"); }
> EOF
[stevea@luchs tmp]$ gcc -o hello hello.c
hello.c: In function ‘main’:
hello.c:1: warning: incompatible implicit declaration of built-in function ‘printf’
[stevea@luchs tmp]$ ./hello
Yellow world!
[stevea@luchs tmp]$ size hello
text data bss dec hex filename
1037 252 8 1297 511 hello
|
Wow - see it's even smaller (1297 bytes). Except that tiny little program uses some massive shared libraries these days.
Code:
[stevea@luchs tmp]$ ldd hello
linux-gate.so.1 => (0x00e3d000)
libc.so.6 => /lib/libc.so.6 (0x0040a000)
/lib/ld-linux.so.2 (0x003e8000)
[stevea@luchs tmp]$ size /lib/libc.so.6
text data bss dec hex filename
1591998 10148 12320 1614466 18a282 /lib/libc.so.6
[stevea@luchs tmp]$ size /lib/ld-linux.so.2
text data bss dec hex filename
120931 3020 192 124143 1e4ef /lib/ld-linux.so.2
So about 1.74MB of shared libraries are involved. In this case those same shared libraries are used by every (userspace) process. In the bad old days you linked to a STATIC library but only the modules you used got linked in ... printf, eprintf, dprintd, _putchar, ... , not the entire library. OF course in the bad old days we had perhaps 16 processes MAX running by swapping to horid slow disk. Let's compare ...
Code:
[stevea@luchs tmp]$ ps -aefl | wc -l
183
[stevea@luchs tmp]$ free -m
total used free shared buffers cached
Mem: 993 792 200 0 86 243
-/+ buffers/cache: 462 530
Swap: 2047 187 1859
So I've got 12 times as many processes on an older laptop using a little over 20,000 times the amount of memory.
In the bad old days we spent a lot of time trying to minimize the use of memory. Pipelining operations from disk->memory->disk and then re-reading the results in between. I recall working on some some FFT & signal processing routines on a much bigger system (mainframe w/ perhaps 4MB of RAM, virtual memory system) and if you designed the software assuming that you had a lot of memory and allowed the virtual memory system to manage the problem - then performance was horrible. You could get a lot of performance by managing the use of memory in the application, but that puts a horrible burden on the software app to understand the memory environment. and act variably.
As computers evolved memory (and disk space) became bigger, faster cheaper at an amazing pace along with CPU performance. But we have used up all those features with added software burden. The old PDP-11 terminal (80x24) held 2KB of characters and was fed data at about 38.4kbit/sec. You are probably sitting in front of a screen with (~1Mill 24bit pixels) 3MB on display and fed over a backplane at ~50Gbit/sec.
The bottom line is that if you really want to go back and "camp out" in the stone age you still can. A few years ago I used to develop a lot of embedded systems - some with Linux 2.4 kernels and busybox running in as little as 16MB, with no GUI. There is a thread on this forum where I stripped down Fedora to be almost that small. Stripping the kernel would have been the next step. It's not that hard to do. Some of the BSD clan are still almost small enough (but most only run on x86). I think you'll find the experience shockingly primitive. But to be fair I find RHEL5 kind primitive too.
If your argument is that we use all these big new resources frivolously - we'll it's hard to claim that's wrong. My immediate (~3MB) desktop a LOAD of fancy memory and graphics frames and graphical icons and such - all attached to complex interactive callbacks, but I am primarily pushing ~1KB of characters around a complex terminal frame. Of course I'm listening to streaming audio and pulled up a news feed video a few minutes ago - hard to do that on a PDP-11.
Back in the early workstation era the argument was that having a graphical interface was going to allow for a much better interface and allow people to see/learn from graphical content (picture worth 1000 words concept). In fact the big/new interface is the desktop and it's network based clone, the browser. Aside from some simplistic icons and buttons most of the REAL info is presented as text. Yes there are pictures, but most things simply aren't presented graphically and the tools for graphical presentation require a lot of work. What I mean is that if you go to bea.gov you'll find loads of very interesting data in spreadsheet form, but it's a headache and a half to get the same data into a properbar chart or ... Same problem repeated endlessly across the net. It shouldn't be that hard.
I'm NOT impressed with the argument that you can teach mathematics of science graphically. These require abstract concepts that are only relatable used arefully crafted language. Sure you can get a kid to learn the multiplication table or understand some example cases to motivate physics ideas - but you don't learn the concepts hat way.
--
So I think until we get an interface pretty close to the Star Trek's holodeck - we'll continue to eat up all the computer resources we can throw at the problem of MMI. Of course the computer/network will continue to be the premiere porn delivery system on the planet, perhaps expanding to the less visually oriented half of the population as it progresses.
Rant on Gigabytes
Linear Mode
