Xref: utzoo comp.unix.internals:556 alt.religion.computers:1887 Path: utzoo!attcan!uunet!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.unix.internals,alt.religion.computers Subject: Re: RAM disk. Message-ID: Date: 9 Oct 90 18:49:59 GMT References: <18560@rpp386.cactus.org> <143359@sun.Eng.Sun.COM> <18574@rpp386.cactus.org> <1850@necisa.ho.necisa.oz> Sender: bzs@world.std.com (Barry Shein) Followup-To: alt.religion.computers Organization: The World Lines: 111 In-Reply-To: boyd@necisa.ho.necisa.oz's message of 9 Oct 90 04:45:00 GMT >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@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD