In-Reply-To: <4pe71m$i0c@news-e2b.gnn.com>
Message-ID: 
References: <4pe71m$i0c@news-e2b.gnn.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



	Rex Ballard - Director of Electronic Distribution
	Standard & Poor's/McGraw-Hill
	Opinions expressed do not necessarily reflect
	the Management of the McGraw-Hill Companies.
	http://cnj.digex.net/~rballard


On Sun, 9 Jun 1996, William Chow wrote:

> 	Hmmm..., is it just me or does it appear that Linux takes up a lot less 
> memory and disk space?

Actually, there are two factors there.  Linux DOES take up much less
memory and disk space, but it also makes more efficient use of the space
it has.

> I've been running a dual system on a divided hard 
> drive for the past month,
This is a very common practice.  Most people start using Linux under a
"dual boot" environment.

> and admittedly, I've installed a couple major 
> packages for Windows, like the Office Suite, Photoshop, and Corel, which eats 
> up a lot of diskspace. Supposedly these commercial packages are supposed to 
> have a lot of useful features, most of which I use only rarely.

Remember, under Linux, there are a full set of shared libraries for which
SOURCE CODE IS AVAILABLE.  When an application developer wants to test a
new application, he often needs to step into "Infrastructure Code" such as
library routines to verify proper handling of resources.  APIs and
Resource Files are great as far as they go, but it's a high risk venture
to blindly trust some other vendor's binary library to function properly.

MFC Programmers often have to deal with memory leaks and General
Protection Faults which cannot be diagnosed because there is no source to
step into.  Usually there is some class that has forgotten to call the
destructor method of it's base classes (particularly nasty when using
multiple inheritance).

The net result is that each application vendor must implement man
infrastructure features as their own DLLs or VXDs.  Sometimes it is
necessary to even write a "scheduler" to keep Windows 95 or Windows NT
from thrashing the applications.

Finally, we have OLE applications which require rather large disk and
memory buffers which cannot be swapped.  Also, many of the Windows
Resources and buffers cannot be swapped because they are needed by the GDI
in "real memory".

Windows 286 to Windows 3.1 were originally based on a minimalist
architecture where individual applications could randomly go out and
manipulate absolute memory locations, hardware registers, and operating
system variables.  This was necessary for legacy applications such as
Lotus 1-2-3 which needed to do it's own window management on a 4 Mhz 8088
with only 256k of RAM (or less).  Each application implemented features
such as overlays, memory management, and interrupt handling independently.
This was appropriate based on the minimalist design of MS-DOS.  Remember,
IBM wanted to sell Hardware, and thus encouraged applications developers
to exploit the hardware of the PC (making them completely dependent on
"Absolute IBM Compatiblity".  It was only when IBM came out with the
MicroChannel bus that Applications Developers began to question the wisdom
of this dependency.

UNIX on the other hand, has a completely different legacy.  Many early
Unix systems were thrown together from a hodgepodge of "Spare Parts"
donated by corporations upgrading from PDPs to Vax.  Unix systems often
had a variety of different terminals attached, and even a simple function
like clearing the screen became an adventure in compatibility.  People
like Bill Joy (No of Sun), worked very hard to integrate tranparency into
the operating systems, libraries, and applications, literally from the
bottom up.   Unix touted device independence through the use of streams,
curses (which could interpret an ascii stream an translate it into display
commands hundreds of different terminals), and pipelines.  Library
routines such as "stdio" successfully hid not only the date source and
destination, but also the memory management, queuing, disk caching,
defragmentation, and all of those other wonderful chores that are done
manually or with "add-ons" under MS-DOS and Windows.

Even the interrupts were captured by the operating system,
handled by drivers linked into the kernel, and flagged by semaphores which
the scheduler would check before starting an application.  This made it
possible to optimize functions like context switching, memory management,
paging, and faulting.

Windows NT is a good comprimise between the two approaches.  It creates
"virtual machines" which can look and act like software, hardware, and
interrupts which are actually virtual memory, memory faults, and
semaphores handled by the operating system.  The cost of this comprimise
was that each process had to be treated like an independent machine.  An
application might wait on a memory semaphore that was supposed to be set
by a trap handler.  Since the operating system could not distinguish
between driver DLL code and application DLL code, it was necessary to
relinquish control to the application which would determine if it was
ready to run, often called "Busy/Wait" scheduling.  Windows 3.X uses
exclusively busy/wait scheduling, while Windows NT allows a real-time
clock or other interrupt to preempt the running task whether it wants to
wait or not.  The scheduler can than switch to a new task.  This is a
relatively simple model, until you realize that the Pentium also has a
multilayer Cache, memory management units, and several other "protections"
which must be reconfigured for each machine.

Since each machine can be a virtual machine, it may have it's own copies
of disk drive buffers, video buffers, communication buffers.  This further
complicates the management of the infrastructure.

UNIX/Linux is designed around a common kernel and libraries which provide
the interfaces to delegate the management to the kernel.  As a result, the
kernel manages all disk drive, communications, and system buffers as well
as all system memory.  Transferring memory from one task to another
(piplines) can be as simple as mapping the memory of the receiving task
into the buffer created and filled by the sending task.  Only 3-5 bytes
need to be modified to "transfer" a 4kbyte "buffer".  Many times, the
pipeline can be implemented in the on-chip cache.  I have just cut my
memory requirements by half and increased my speed substantially.

Unix also takes advantage of another old theory which states that - in any
given period, 90% of the processing is done by 10% of the code.  For
functions such as X11 initialization, every variable is going to be
checked or modified, which is why there is that delay between when you
start an X11 application and when you actually see a display.  Once this
initialization is complete, the system knows where to go the get help
files, include files, or fonts, but the core application can sit and loop
on the tiny little pipeline queue.  When the core of one application is
piped to the core of another application, the result is that a very small
amount of memory is required to search a file, modify lines of input as
they pass through, and create a pleasing format.  Within a few thousand
instructions (1 or 2 milliseconds) the system has "optimized itself" into
a high performance dataflow engine.

> 	However, these are just three large packages, with some other WIndows 
> garbage thrown in, it's eaten up almost all of its partition space.

Simply put, each application is carrying around it's own implementation of
the Linux operating system, the part that is missing or suboptimal in
Windows-95/NT.

> 	With Linux, I basically installed everything that came with the 
> distribution,

Which distribution is this?  I loaded the entire Slackware 2.2
distribution in less than 300 Meg.  The ELF distributions are a bit
larger, partly because they have more "toys" (web servers and browsers,
X11R6...)

> then added in Xemacs (which is awfully slow on startup, much 
> slower than Emacs 19.30),
I pointed out the X11 initialization routine before.  You can get more
speed with a 7200rpm SCSI disk drive.  It also helps to put your swap
drive and Windows partition on one drive and but your root and user
partitions on the other drive.  You will think you have more RAM (it's
actually just better caching).


> an X-windows manager,

Here is another little piece of magic.  The Xserver and X window manager
couple to take a great deal of the load off of each application.  In the
Windows environment, the VDI/GDI interface is similar, but the GDI must
force the VDI (hence the entire application) to "wait" if the application
forces the GDI to "scroll" or "clear".  Linux users quickly learn to use
"more" instead of "cat" (like "type") because a Pentium 90 with an S3 64
bit video chip and SCSI Adapter/drive can scroll so quickly quickly that
"War and Peace" can be pushed through the display before the user even
sees the vertical retrace. (Yes this is a slight exxageration it's really
only about 2 megabytes/second with a fast SCSI/2 drive).  Evelyn Wood, eat
your heart out :-).

> a couple of X-windows utilities,
Remember, you are using the same memory for the "Read Only" portion of
each of these applications, and you are using shared images of memory
until either application modifies the content of that memory.  In effect,
you are only allocated the 2% of the memory you actually modify.  Because
of this, more of the entire system can be installed into the library, more
of the defaults can be initialized using the app-defaults files, and more
of the disk drives is available to you - the user.  You can even keep a
"resource database" in the X-Server to speed up initializations.  Try
running "xrdb app-defaults/Xterm" before actually starting xterm.  The
same is true with any application.


> and I've still got over half of the Linux partition open. (And 
> this is on a smaller partition than the Windows part...)

Remember, fonts, documentation, and other resources are stored on the disk
drive in compressed (gzip) format and uncompressed when you access them.
You can decompress strategic fonts, help files, and resource files to
reduce "start-up" time.


> 	Do others have a similar experience?

If they don't, they probably have something wierd going on in
configuration.  I will admit, doing an "Install Everything" with a Red-Hat
CD-ROM gets more exciting.  It puts "everything including the kitchen sink
(emacs icon)" onto the hard drive, sucking up 500 Meg.  Of course to get
the equivalent functionality in MS-Windows 95, it would take about 20 Gig.

> It just appears as if Linux 
> programs seem to be a lot more compact overall, and gzip really zips well. 

Remember too, that Linux, like other Unix systems is designed to exploit
the features of efficient interprocess communication.  Rather than a
"swiss army knife editor" like MS-Word that does formats, tables,
graphics, spreadsheets, and has all the methods for formatting to display,
printer, and disk drive (each a different custom format), and expects the
user to use only that application and methods (Read your Microsoft License
very carefully) to view the data, Linux/Unix has about 8000 little
applications and about 200 framework languages which allow you to edit,
format, sort, print, and display in a variety of different ways.

If you want a nice little WYSIWYG editor, try Doc, or Andrew.  You can get
postscript (from Doc) or SGML (or subset HTML).  You can take easily
browsed documents such those generated by the system or those filled by
Mail, News, and Web Server programs, and format them into pretty
documents, "databases", or other statistical summaries.

Because of the "data-flow model", the traditional "SQL Search" is replace
with Perl which can dynamically scan, search, sort, and format multiple
content streams in real-time.

> Also, it oftentimes appears as if X-Windows runs faster than Windows 95. 

This has largely to do with the way X-Windows handles it's "stream of
bytes" from the applications (which can be queued, scheduled, and
delegated to hardware drivers) vs. the "Event queue" which requires that
the queuing event sleep until the event is handled (callback).

> There are a lot less disk reads/writes in X (I have enough memory to run 
> without a swapdisk), and in terms of graphics processing speed, it really can 
> fly. (although Windows is no slouch either...)

A good 64 bit graphics coprocessor such as the S3/864 can produce
extremely high speeds.  The advantage of Linux is that several different
tasks can update the screen at the same time.  There are other subtle
forms of streamlining which are based on the assumption that the
bottleneck will not be the scheduling CPU. 

> 	The X-windows environment, however, is a bit tougher to use without 
> adding in a considerable amount of time and effort to configure it to one's 
> tastes,

Slackware is a bit tricky to configure initially.  Red Hat is much easier
to set up.   If you use the "Xview" window manager, there is a utility to
configure the system using "point and click" interfaces.  Like most of the
Unix/Linux operating system, the layout and configuration is configured
from a human readable text file.  If you really want a mouse interface,
you can probably get a TCL/TK script that lets you "fill in the menu".
Ask around on the other linux newsgroups.  If you don't get a response,
take it on yourself and add it to the repository.  You can get your name
on the Linux "Credits" bar too.  Unix contributions are a major notch in
the Resume, especially for someone with a degree and less than 5 years of
experience.

> although the pager is very nice (something that Windows, I believe, 
> can only do rather clunkily with third party software),

Theoretically, windows could use a "pager".  Unfortunately, since most
Windows files are proprietary binary files and the copyright/license
restrictions forbid any form of reverse engineering, you could only make a
"pager" by creating a "shell" program that calls the appropriate OLE
server module (which will load the blood and guts of it's entire
application).  If your OLE server is not implemented as a DLL or a VXD,
each will likely have it's own memory.  Many Windows applications do not
allow multiple instances of the application due to lack of support for
reentrancy (the ability to share the code without corrupting static or
global variables).  Most Windows applications rely on the Multiple
Document Interface (MDI) to keep multiple instances running as threads of
the same parent task.

> and Motif looks very 
> nice...

Even if it isn't real Motif, it looks nice.  Personally, I like the Xview
look and feel.  When I'm in a big hurry or I want really fast
initializations, I use twm.  The ICCCM standards make sure that I can run
almost any X application with any X window manager.  They also make sure
that an application doesn't lock up the system by grabbing exclusive focus
of the Mouse and Keyboard.  I have little trouble going over a month
without ever rebooting the system.  I know some ISPs who never reboot the
system.  They clean up system files with cron jobs.

> Will

You have come up with some great observations of the advantages of Linux
over MS-Windows.  I have tried to explain some of the thinking and
technology behind the "Magic".  The bottom line though is that, for any
given piece of hardware, Linux will seem substantially faster than
Windows-NT or Windows-95.


	Rex Ballard.



From rballard@cnj.digex.net Mon Jul  1 21:51:28 1996
Status: O
X-Status: 
Newsgroups: alt.binaries.warez.ibm-pc,alt.binaries.warez.ibm-pc.dos,alt.cracks,alt.binaries.mac,alt.binaries.misc,alt.mindcontrol,comp.sys.mac.advocacy,alt.folklore.computers,comp.os.linux.advocacy,comp.os.msdos.misc,comp.unix.advocacy,comp.sys.mac.advoca