Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!wb3ffv!ka3ovk!raysnec!shwake From: shwake@raysnec.UUCP (Ray Shwake) Newsgroups: comp.unix.sysv386 Subject: Re: Since Most Everythings's right with SCO Can we make it smaller? Message-ID: <305@raysnec.UUCP> Date: 25 Apr 91 16:38:50 GMT References: <7395@spdcc.SPDCC.COM> Organization: IRS/CI - Technical Solutions Branch Lines: 33 rbraun@spdcc.COM (Rich Braun) writes: >Reading this thread, I can't help but to wonder: why worry about >kernel size, these days? I've long been one to complain about the fact >that software seems to get larger in direct proportion to the decrease >in memory costs, and often slower due to its increasing complexity, but >in the case of a reasonably well-performing O/S with lots of features, >why worry so much about kernel size? Recent history proves this assumed correlation false. The radical increase in memory demands (roughly 1987-90) resulted from the move to RISC, windowing environments (MS and X Windows), heavy networking, etc. That same period also witnessed *increased* memory prices partly resulting from the move to 1 MB chips (and general shortages of same) and the foolish memory floor price agreement with Japan. >Add another megabyte to the system and the problem will go away. Seems >a fairly simple and economical solution. Even at 1-2Mb, kernels remain >significantly smaller than most applications. (As compared to ten >years ago on mainframe computers, when a kernel was typically many >times larger than an application.) This line of thought assumes, at minimum, that the system architecture supports minimal, and inexpensive, memory increases. That's not always the case. Examples: Try to take a NEC Powermate from 2 MB to 3, 4 MB to 6, or 8 MB to 12. Can't do it. Another example. To increase a NeXT workstation from 8 MB, one must take it all the way to *20* MB (16 if one gets rid of surplus 1 MB SIMMS). Inexpensive it won't be. In summary? End the bloat. Bring on the UN!X Lite. ----------- uunet!media!ka3ovk!raysnec!shwake shwake@rsxtech