RAM disk.

[Barry Shein]

>When I hear `ram disk' I reach for my revolver.  Now, repeat after me...

I agree Boyd.

The "problem" Unix is experiencing right now is that it has become
standard in the industry and all these folks from other O/S cultures
are having it thrown in their laps.

Those with some system experience and an opinion immediately begin
shouting for all these jargon items they were sold on from their
former system (systems which, I may add, are now becoming rapidly
obsolete.)

We had a good rash of this when TOPS-20 died a few years ago and lots
of TOPS-20 types who had been switched to Unix suddenly began shouting
for a rework of their favorite features.

Here's several features that keep coming up. Not all are without
merit, but some are already there (like RAM disk) and others are
questionably portable or, well, without merit.

1. RAM Disk

Unix already has most of the advantages of a RAM disk, so this is just
mostly a "jargon" check-off item. Had we called the buffer-cache ram
disk most of these people would not be asking for this today.

2. Caseless file system

This is stupid. The ability to insert and distinguish almost all 256
character codes is used in other languages to great advantage (e.g.
Kanji.)

The point being, a good way to view this is that file names are not
stored in ASCII under unix, they're stored as a string of 8-bit bytes,
so case is only in the eyes of the beholder.

There are a few byte values (such as slash) which are hard to encode,
but so what, you can't give your computer an IP address of all ones or
all zeros either, hardly damning. Out of band values has a long
history in computing and engineering.

3. Asynchronous I/O for "performance" reasons

All Unix block I/O is asynchronous (well, driver dependant of course,
but disks and tapes and so forth.)

The recent addition to Unix has been *synchronous* I/O (FSYNC bit.)
The one major exception is directory updates, but that's never the
issue when this comes up.

Systems like VMS have synchronous I/O as the default so asynch had to
be engineered in as the exception. It's important to understand all
this before shouting for a particular style of programming interface
that probably won't change the performance of your application one bit
(actually, will probably slow it down as now you've added all sorts of
exception handling baggage to a formerly low overhead feature.)

Another related feature is being able to get an interrupt when an I/O
has really gone to disk (et al). This has merit and for many
applications would be vastly superior to the FSYNC bit. I'm not sure
why this hasn't been done universally as the SIGIO signal could just
be used for this and it probably only entails marking a bit in the
buffer and having the kernel issue a psignal() or whatever when the
right completes and the buffer is being freed. Perhaps I'm missing
something.

4. Command names which resemble english words.

Certainly more popular among those who speak english.

Bell Labs commissioned independant studies early in Unix's history to
see if this was important or not. I've tried to locate these, others
have claimed to have been involved and seen the reports. It's possible
they were "internal use only", perhaps the work should be repeated.

The basic conclusion was that you can make commands english, wierd,
mnemonic, and even counter-intuitive (e.g. "delete" means edit a file,
"edit" means delete etc.) and it simply doesn't seem to make all that
much difference to learning curves.

This may seem horribly counter-intuitive and against all conventional
wisdom (some people get quite apoplectic when this is asserted, sort
of like telling them that there is no Santa Claus.)

Consider, for a moment, that the company which produced Unix has had
some moderate success getting the general public to enter long strings
of digits as part of their daily activity. And it is even successful
among children and other idiots, etc.

Motivation to use the thing appears to be more important than what you
call the commands. In the end, the remarkable thing about computers
are the people who use them.

5. TSR's

The MS/DOS community developed these out of utter desparation due to
their single-tasking O/S and the way memory management was
brain-damaged from the start. See "job control". Of no merit.

----------

There are many other things that can go on this list. It might be
interesting to generate such a list and post it monthly along with the
frequently asked questions lists. Something like "Why Doesn't Unix..."
-- 
        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs at world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD