johnl@iecc.cambridge.ma.us (John R. Levine) (01/02/91)
In article <37459@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >What does wrongness have to do with width of use? Look at MS-DOS, >for example, to see that wide use does not indicate lack of wrongness. Note to comp.arch purists: this article is about software architecture. I'd be the last to argue that MS-DOS is the world's best operating system, but it has its redeeming points. Remember that when the IBM PC first came out, there were three competing operating systems, DOS, CP/M, and the UCSD P-System, and since then there were lots of other competitors ranging from QNX to PC/IX. None have come anywhere near displacing DOS. DOS also scaled up reasonably well from its original extremely cramped memory environment, 16K or 64K, to its current 640K or 1MB. (IBM's OS/360 also had to work in 64K originally, and even on current 3090 systems with upwards of 128MB of RAM, some of the design compromises to squeeze OS into 64K are still evident in MVS.) I cheerfully admit that DOS completely fails to handle more than 1MB of RAM. It's not perfect. DOS mostly does two things, but it does them quite competently. It provides a program loader and a file system. The program loader is not as obvious as it looks, the CP/M loader didn't handle relocation entries and hence only handled executable images up to 64K. The DOS loader can load and relocate any amount up to the full available memory. The file system, as of DOS 2.x and later, is a little clunky but quite usable. It provides tree-structured directories containing files of arbitrary contents and length, with the ability to seek to any place in a file and read or write arbitrary length data. On floppy disks, it provides good performance since it tends to make files contiguous. There are strange limitations, e.g. the fixed size root directory and the 8+3 upper case only file names, but no worse than and in many cases better than a lot of other file systems. For a long time DOS couldn't handle a disk volume of more than 32MB, though that has been remedied in recent versions. In 1984 when I lashed up a 600MB Fujitsu Eagle disk to a PC AT, it appeared as disks D: through O:, but it did work reliably as the main disk on a network server. The best thing about DOS is its extreme extensibility. The fact that it uses software interrupts to communicate upwards with applications and downwards with the BIOS, combined with the ability of programs to load themselves permanently at runtime (so-called TSRs) and to intercept the software interrupts meant that user programs could make arbitrary extensions to DOS so long as they preserved the semantics of the calls. As a small example, there are many command history programs that intercept the "keyboard read line" system call and replace it with a version that provides history and intra-line editing. This approach provides history to any program that uses the keyboard read line call (of which there are admittedly not a whole lot) as opposed to the Unix approach in which csh and ksh have swell command history which is unavailable to any other program. As a much larger example, all PC networks before Microsoft provided the redirector interface worked by intercepting all of the file system calls such as open, close, read, write, seek, and read directory and passing references to remote files off to network code. There were compatibility problems when e.g. early versions of Novell network code provided a file name syntax more general than and hence incompatible with DOS's, but in most cases that network program interface is quite effective. I hear many voices crying out "but it's all a gross hack." Well, yes, it is. There are certainly bad things about DOS: the interfaces it didn't implement, particularly that to the screen, that force every new PC screen controller to have a hundred hardware modes that emulate every previous model of controller, and the single non-overlayed address space that is so filled up by TSRs that there's precious little space left for applications. But DOS provided extensible operating system interfaces ten years ago, something most versions of systems such as Unix have yet to offer. There are useful lessons to be learned figuring out what DOS does well and doing those things in a context that avoids DOS's mistakes. -- John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl "Typically supercomputers use a single microprocessor." -Boston Globe
sef@kithrup.COM (Sean Eric Fagan) (01/02/91)
(I've crossposted this to comp.os.misc, and directed followup's there. Anyone who objects is free to change that, but it's the closest I could think of for the groups I read 8-).) In article <1991Jan02.035501.9457@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes: >I'd be the last to argue that MS-DOS is the world's best operating system, but >it has its redeeming points. Agreed, and you point out some of them. My problem with DOS is that I think its time has passed. Users want/need *more*. OS/2 comes close, I guess, but I don't think it's quite right (it feels too much like DOS still 8-)). For managing the small machine that was the 8088-based IBM PC, DOS is fine. For handling the not-so-small machine that kithrup is (25MHz '386, 8Mb RAM), it is not good enough for what I want to do. My objections to DOS start at that point. There are lots of "DOS Extenders" available; I don't think any of them work as well as DOS-under-UNIX would (although they eat up a lot fewer resources, I will admit). They don't fit smoothly into it, and trying to keep up with the changing hardware and software demands is next to impossible. An example of how an OS grows to handle new hardware: '286 xenix vs. '386 xenix. The latter runs all the software from the former, plus has extensions of its own. It just ... *feels* better. Anyway: yes, DOS has its uses. If my needs were a bit smaller, DOS would probably suffice for what I want/need. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
muyanja@hpdmd48.boi.hp.com (bill muyanja) (01/03/91)
> ... I cheerfully admit that DOS completely fails to handle more than 1MB of > RAM. It's not perfect. Not so! Windows 3.0, a *DOS* product, can allocate a 64MB glob of memory in 386-enhanced mode. - bill
jap@convex.cl.msu.edu (Joe Porkka) (01/07/91)
D*mn, I couldn't resist. If anybody wants to claim that MSDOS is good, especially considering *when* it came into existance, and the hardware it had to work on, I tell them to take a look at OS/9 on the RadioShack TRS-80 ColorComputer. Preemptive multitasking, resource tracking, MultiUser, etc. etc. all in 64K of RAM on a 6809 processor. (No additional ROM either). Although the PC existed before OS/9 on the CoCo, OS/9 did exist before the CoCo, though I don't know exactly when or where or on what hardware previous to the CoCo.
jackv@turnkey.tcc.com (Jack F. Vogel) (01/07/91)
In article <1991Jan6.183213.27136@msuinfo.cl.msu.edu> jap@convex.cl.msu.edu (Joe Porkka) writes: >Although the PC existed before OS/9 on the CoCo, OS/9 did exist >before the CoCo, though I don't know exactly when or where or >on what hardware previous to the CoCo. Gosh, a stroll down memory lane :-}!! Not that anybody really cares, but OS/9 ran on a 6809 based system made by a company in Chicago called Gimix. I worked for them briefly in the early 80's. Their system was SS50 bus based, hardware task switching with multiple 64K cmos memory boards. Supported realistically around 16 users as I recall. Don't know if they're still around these days or not. Thanks for the memory :-} :-}. -- Jack F. Vogel jackv@locus.com AIX370 Technical Support - or - Locus Computing Corp. jackv@turnkey.TCC.COM
myhui@bnr.ca (Michael Hui) (01/07/91)
In article <1991Jan06.204401.21579@turnkey.tcc.com> jackv@turnkey.TCC.COM (Jack F. Vogel) writes: >Gosh, a stroll down memory lane :-}!! Not that anybody really cares, but >OS/9 ran on a 6809 based system made by a company in Chicago called Gimix. Gimix computers were in turn closely related to the world's first hobbyist's 6800 based microcomputer manufacturer, Southwest Technical, who devised the SS50 bus, and, among other things, once sold a line of audio components as well, advertised in the same catalog as the computers.
dkessner@isis.cs.du.edu (David D. Kessner) (01/07/91)
There is an important thing to remember here. MS-DOS is just about obsolete. obsolete (adj): when a tool fails to perform to the expectations of it's user. - The David Kessner Dictionary of Whatnot. No matter how good MS-DOS was back in 79-80, it just isnt right now. Sure, it'll work for some people. But there are the others, those who want real multi-tasking, large drives, 32-bit native support, >640K RAM, Virtual memory, etc, etc. I've been programming since 1982, on everything from a TRS-80 model 1 CLONE (does anyone remember the Genie?), Commodore 64, IBM's, Apples, and many UNIX boxes. I am at the point where the operating system greatly affects how I program. At times I come up with a great new algorithm, but it cannot be done under MS-DOS without jumping through hoops. I usually end up using MS-DOS more as an overglorified program loader than anything else. Now, I cannot live without my UUCP, multi-user multi-tasking, etc, etc. In that respect, MS-DOS is obsolete (and can loosely be called WRONG). I wonder what would happen is MS-DOS would be more like UNIX. With all those MS-DOS programmers who could better spend their time programming rather than compensating for the OS. David Kessner kessner!david@csn.org
andras@alzabo.uucp (Andras Kovacs) (01/08/91)
In article <14900021@hpdmd48.boi.hp.com> muyanja@hpdmd48.boi.hp.com (bill muyanja) writes: >> ... I cheerfully admit that DOS completely fails to handle more than 1MB of >> RAM. It's not perfect. > >Not so! Windows 3.0, a *DOS* product, can allocate a 64MB glob of memory in >386-enhanced mode. > >- bill Does it cost extra money or someone ships it bundled with DOS x.xx?! (When someone talks about DOS then the subject isn't Windows 3.0.) -- Andras Kovacs "Could somebody tell me what kind of a world we live in andras@alzabo.UUCP where a man dressed as a BAT gets all of my press..." Nepean, Ont. The Joker
feustel@netcom.UUCP (David Feustel) (01/08/91)
Does Unix support scanners, real-time A/D & D/A? How much does it cost? -- David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631 EMAIL: netcom.uucp
longc@cs.fau.edu (Courtney Long) (01/08/91)
In article <1991Jan6.232549.2764@isis.cs.du.edu> dkessner@isis.UUCP (David D. Kessner) writes: >There is an important thing to remember here. MS-DOS is just about obsolete. > Sorry about a operating system discussion on an ARCHITECHTURE (HARDWARE) forum, but I can't let this one go by. MS-DOS is NOT anywhere near obsolete and I can't believe someone would say this! There are just too many PC's with too little memory and tiny little 808x processors for this to be true. And, if MS-DOS were about to become obsolete, there would not be any future versions of DOS. >.............. At times I come up with a great new algorithm, but it cannot >be done under MS-DOS without jumping through hoops. I usually end up using >MS-DOS more as an overglorified program loader than anything else. Now, I >cannot live without my UUCP, multi-user multi-tasking, etc, etc. In that >respect, MS-DOS is obsolete (and can loosely be called WRONG). > I'm certain that your algorithms are quite good. Keep in mind that: 1. You don't use a garden hoe to grade for an interstate highway. 2. Tubes aren't often found in digital computing systems. >I wonder what would happen is MS-DOS would be more like UNIX. With all those >MS-DOS programmers who could better spend their time programming rather than >compensating for the OS. You'll probably see a wider base of UNIX operating systems in the future. Yes, UNIX is a "professional" operating system (although you won't hear that from MVS users) and offers a rich programming environment. Enjoy UNIX, but remember that you're really in the minority for small systems (as far as operating systems are concerned) ! > >David Kessner >kessner!david@csn.org Courtney
bill@mwca.UUCP (Bill Sheppard) (01/09/91)
In article <1991Jan6.183213.27136@msuinfo.cl.msu.edu> jap@convex.cl.msu.edu (Joe Porkka) writes: >D*mn, I couldn't resist. > >If anybody wants to claim that MSDOS is good, especially considering >*when* it came into existance, and the hardware it had to work on, >I tell them to take a look at OS/9 on the RadioShack TRS-80 >ColorComputer. > >Preemptive multitasking, resource tracking, MultiUser, etc. etc. >all in 64K of RAM on a 6809 processor. (No additional ROM either). > >Although the PC existed before OS/9 on the CoCo, OS/9 did exist >before the CoCo, though I don't know exactly when or where or >on what hardware previous to the CoCo. OS-9 is still very much around - the 6809 version is (obviously) not finding too many design wins, but OS-9/680x0 is a very widely used real-time OS. OS-9/6809 was originally released in 1979, based on a 6800 kernel developed in 1977. OS-9/68000 was released in 1983. Code size is still small (especially compared to Unix), with a ~27K kernel, a complete diskless embedded system would require ~40K of system code, ~60K for a disk-based system, <256K for TCP/IP system. OS-9 is Unix-like, shares many identical or similar system calls, but doesn't support virtual memory (in keeping with real-time constraints). OS-9 has more OEM licensees than Unix, and is embedded in hundreds of thousands of products and in use in tens of thousands of PC's (including Mac's, ST's, Amiga's, Coco's, and PC's with 680x0 add-in cards). The story as I've been told is that IBM was highly interested in the 6809 for the PC, but Motorola couldn't produce them in the quantity needed by IBM. Had IBM chosen the 6809 then OS-9 would most probably have become what MS-DOS is today (let me rephrase that - OS-9 would have become the standard PC operating system, and probably made for much happier programmers and more powerful applications given its multi-tasking, memory efficient design). On the other hand, OS-9 has been chosen as the basis for Compact Disk Interactive, the new CD standard about to be released to the consumer market by Philips, Sony, and Matsushita, and may yet become as common in the home as MS-DOS is. (Parts of this thread belong more suitably in alt.folklore, comp.realtime, and other various newsgroups, so take your pick!) -- ################################################################################ # Bill Sheppard -- bills@microware.com -- {uunet,sun}!mcrware!mwca!bill # # Microware Systems Corporation --- OS-9: Seven generations beyond __/_!! # #######Opinions expressed are my own, though you'd be wise to adopt them!#######
mike@bria.UUCP (PUT YOUR NAME HERE) (01/09/91)
In article <1991Jan6.183213.27136@msuinfo.cl.msu.edu> convex.cl.msu.edu!jap (Joe Porkka) writes: >If anybody wants to claim that MSDOS is good, especially considering >*when* it came into existance, and the hardware it had to work on, >I tell them to take a look at OS/9 on the RadioShack TRS-80 >ColorComputer. > >Preemptive multitasking, resource tracking, MultiUser, etc. etc. >all in 64K of RAM on a 6809 processor. (No additional ROM either). Gee, I almost forgot about good ol OS/9 on the CoCo ... but you have to be fair. MS-DOS was designed to be CP/M compatable (initially) and therefore had the "program loader limitation" graven in stone. Add to that the fact that Intel's 8088 is a dog, voila, you have MS-DOS. -- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike -- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (01/09/91)
I'd like to butt in and suggest that this discussion about merits
of PC operating systems is on completely the wrong track.
First I should make it clear that my interest is specifically in
*personal computer* operating systems--that is, ones oriented
towards a single-user environment. You can have as many tasks/
threads/processes as you want, running on as many processors as
you want, connected as loosely or as tightly as you want, but the
whole mess is still cooperating on solving the problems of a single
user. That's my scenario.
[Note from Poster's Conscience: the rest of this message is
pretty long, and more than a little rambling, so if you don't feel
as strongly about the importance of single-user systems as I do,
you may as well skip the rest of it.]
As soon as you accept this, it becomes obvious that MS-DOS was
badly designed from day 1. Microsoft *should* have done a
better job, even allowing for the fact that they couldn't have
foreseen most of the technical developments that have happened
in the last ten years.
Consider what an operating system is supposed to do. Different
people have lots of different ideas on this, but among the most
important design principles that I can think of are:
1) Shield the application program from hardware dependencies,
and variations in system configurations.
2) Provide a standard interface to services that allow
transfer of information between applications.
3) Implement other useful services that application programmers
find themselves reinventing.
Principle 1 leads to such ideas as "device drivers" to hide the
differences between floppy disks, SCSI hard disks, disks on
network servers etc (broadly speaking). Principle 2 leads to the
conclusion that, if two or more applications are going to be able to
access common data on those same disks, then you must have a common format
for storing that data, and hence (to guarantee consistency) the
operating system must provide the interface for accessing the
data. This leads to the concept of file systems, and their
extension into ISAM managers, database servers and the like.
Note the important difference between Principles 2 and 3: a certain
feature may be needed in a lot of programs, so it would be handy
if it were a standard part of the OS, but as soon as that feature
becomes a basis for communication *between* programs, its inclusion
in the OS becomes pretty much mandatory. Another example of this is
networking protocols (a combination of Principles 1 and 2).
Just for fun, consider the problem of conversion of dates and times:
formatting them in a human-readable text representation, as well as
converting such a text representation into an internal form more suited
to calculations. You might think that a package to do this falls under
Principle 3: useful to a lot of programs, but not an *essential* part
of the OS. But in today's increasingly international software market,
you may be selling your application in countries where they speak
different languages, even use different calendars. You could either
say that a) every application will need to have support for every
country's conventions (language, alphabet, calendar etc) built into it, and
the user will have to make the appropriate choice when installing
the application, or b) the operating system should worry about it,
so that the choice is made once when installing the OS (and may
even be changed later while the OS is running), and all the applications
automatically adapt.
So really, date/time conversion (and other issues of text manipulation
and formatting) fall under Principle 1, not 3, and they are
an important part of the functionality of the OS after all.
I really brought that up as an example of how consideration of
the principles of OS design can lead you to conclusions which obviously
don't agree with those that have been reached yet by the designers of
most current OSes. So who's wrong...?
Getting back to MS-DOS, my assertion is that its design was based
more on how contemporary OSes did things, rather than on *why* they
did them. It was an adaptation of features to be found in multi-user
minicomputer operating systems, without regard for the fact that those
systems ran in a rather different environment, under different constraints,
from a PC.
"Hindsight!" I hear you cry. Nobody could have foreseen the directions
that the PC industry took, or the sorts of applications that PCs would
be put to. Almost entirely true. Almost.
At the time the first version of MS-DOS was being developed, there
was already at least one wildly successful PC application, which was
obviously a pointer as to what many future applications would be like.
I'm talking about Visicalc.
If MS-DOS had been designed to make applications like Visicalc easier
to implement, it would have been a much better PC operating system.
What made Visicalc different from anything that had been seen in
the multiuser mini/mainframe world? It was _interactive_. It responded
instantly to every keystroke, and it achieved this by writing directly
to video RAM.
"Horrors!" cried the OS Designers of the Old School: "So much for
hardware independence (Principle 1)." It's true, Visicalc could never
have run on a paper-printing teletype. But then, no one would have
wanted to use it on one, anyway.
The downside to the way Visicalc worked, is that it needed to be
specially ported to every different hardware platform, since each
brand of PC mapped its video RAM in a different way.
Eventually Visicalc made it onto the IBM PC, and was joined by a
flood of new applications that all made assumptions about the way
the video system worked. And IBM came out with new video systems,
and the _entire_ history of these, from MDA and CGA thru EGA, PGC,
VGA, 8514/A, XGA and beyond, has been one of adding new kludges,
while making sure that the old kludges keep working.
Imagine how different things would have been if MS-DOS had provided
display-handling routines (even text-only ones--never mind graphics!) of
a decent quality to begin with: there would have been very little
need to maintain compatibility at the hardware register level, and
applications could interrogate the system to discover the dimensions
of the screen (number of lines and columns) and other such information.
Who knows, one could have had a word-processing application written
in 1981, working on a 25-line CGA display, and started it up on a
1990-vintage super VGA system to watch it automatically adapt to a
50-line display with zillions of colours!
The point is that hardware and configuration independence is still
important, but you have to interpret the concept (and all the other
principles of good OS design) in terms of the needs of contemporary
real-world applications, not the way things worked on systems dating
from 20 years ago.
Lawrence D'Oliveiro fone: +64-71-562-889
Computer Services Dept fax: +64-71-384-066
University of Waikato electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
Climber Rob Hall on why he climbed the seven highest mountains on
seven continents in seven months: "No one would give me a good
office job."mike@bria.UUCP (Michael Stefanik) (01/09/91)
In article <1991Jan08.040128.22819@cs.fau.edu> cs.fau.edu!longc (Courtney Long) writes: >Sorry about a operating system discussion on an ARCHITECHTURE (HARDWARE) >forum, but I can't let this one go by. MS-DOS is NOT anywhere near obsolete >and I can't believe someone would say this! There are just too many PC's >with too little memory and tiny little 808x processors for this to be true. >And, if MS-DOS were about to become obsolete, there would not be any future >versions of DOS. The fact that there are many small machines capable of only running this glorified program loader doesn't mean that DOS ain't obsolete. Shall we find out what "obsolete" means? obsolete, adj. [L. obsoletus, fr. pp. of obsolescere to grow old, become disused](1579) 1 a: no longer in use or no longer useful b: of a kind or style no longer current, oldfashioned syn. see OLD Well, DOS is certainly still in use, and it could be called a matter of taste on the subject of if it's useful, BUT, it certainly is no longer current and is definately oldfashioned. I vote for DOS being obsolete. >I'm certain that your algorithms are quite good. Keep in mind that: > > 1. You don't use a garden hoe to grade for an interstate highway. > 2. Tubes aren't often found in digital computing systems. If you're talking toolwise, DOS doesn't even get garden hoe status. I think of DOS more along the lines of a rusted trowel sans handle. >You'll probably see a wider base of UNIX operating systems in the future. >Yes, UNIX is a "professional" operating system (although you won't hear that >from MVS users) and offers a rich programming environment. Enjoy UNIX, but >remember that you're really in the minority for small systems (as far as >operating systems are concerned) ! So was DOS in 1981. Because DOS is the status quo, that doesn't mean you accept it. The point is *move forward* - convenience has no place with progression. If MS-DOS users were representative of Mankind, we'd be living in caves waiting for it to lightning so we could get some fire ... -- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike -- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
sef@kithrup.COM (Sean Eric Fagan) (01/09/91)
In article <1991Jan08.040128.22819@cs.fau.edu> longc@cs.fau.edu (Courtney Long) writes: >Sorry about a operating system discussion on an ARCHITECHTURE (HARDWARE) >forum, but I can't let this one go by. MS-DOS is NOT anywhere near obsolete >and I can't believe someone would say this! There are just too many PC's >with too little memory and tiny little 808x processors for this to be true. >And, if MS-DOS were about to become obsolete, there would not be any future >versions of DOS. Uhm... hate to break it to you, but those machines with 8086's and 8086's are obsolete. (Well, not entirely; the new pen PC's are still a bit too small for a '286, but give them a year or so.) If the hardware is obsolete, I would not be surprised to find an obsolete "OS" running on it. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
don@zl2tnm.gp.co.nz (Don Stokes) (01/09/91)
ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >I'd like to butt in and suggest that this discussion about merits >of PC operating systems is on completely the wrong track. >As soon as you accept this, it becomes obvious that MS-DOS was >badly designed from day 1. Microsoft *should* have done a >better job, even allowing for the fact that they couldn't have >foreseen most of the technical developments that have happened >in the last ten years. Agreed, although it appears the MS-DOS was created in rather a hurry, and as a bit of an afterthought. I don't think it's really fair to say MS-DOS was "designed", rather "evolved" from existing operating systems. >Consider what an operating system is supposed to do. Different >people have lots of different ideas on this, but among the most >important design principles that I can think of are: > 1) Shield the application program from hardware dependencies, > and variations in system configurations. > 2) Provide a standard interface to services that allow > transfer of information between applications. > 3) Implement other useful services that application programmers > find themselves reinventing. >Principle 1 leads to such ideas as "device drivers" to hide the >differences between floppy disks, SCSI hard disks, disks on >network servers etc (broadly speaking). Principle 2 leads to the >conclusion that, if two or more applications are going to be able to >access common data on those same disks, then you must have a common format >for storing that data, and hence (to guarantee consistency) the >operating system must provide the interface for accessing the >data. This leads to the concept of file systems, and their >extension into ISAM managers, database servers and the like. There are two opposed views here -- some say applications should be free to do what they like, and the OS should butt out and stick to Principle 1, and others (like me) say that any kind of standardisation effort has to centre around the OS, or at least standard (ie provided with the OS) software, providing a path of least resistance towards applications that talk to each other properly. This is the stuff of VMS vs Unix flame wars.... >Getting back to MS-DOS, my assertion is that its design was based >more on how contemporary OSes did things, rather than on *why* they >did them. It was an adaptation of features to be found in multi-user >minicomputer operating systems, without regard for the fact that those >systems ran in a rather different environment, under different constraints, >from a PC. >"Hindsight!" I hear you cry. Nobody could have foreseen the directions >that the PC industry took, or the sorts of applications that PCs would >be put to. Almost entirely true. Almost. >At the time the first version of MS-DOS was being developed, there >was already at least one wildly successful PC application, which was >obviously a pointer as to what many future applications would be like. >I'm talking about Visicalc. >If MS-DOS had been designed to make applications like Visicalc easier >to implement, it would have been a much better PC operating system. >What made Visicalc different from anything that had been seen in >the multiuser mini/mainframe world? It was _interactive_. It responded >instantly to every keystroke, and it achieved this by writing directly >to video RAM. Well, it was done that way because the apple ][ suffered exactly the same problem as MS-DOS -- the standard keyboard/screen I/O routines forced you to resort to talking to screen memory/hardware registers directly. Visicalc lookalikes were implemented successfully on CP/M machines, without using such tricks (but they did need to know what you were using for a terminal). One could say that the "designers" of MS-DOS failed to learn from mistakes that had already been made. Don Stokes, ZL2TNM / / don@zl2tnm.gp.co.nz (home) Systems Programmer /GP/ GP PRINT LIMITED Wellington, don@gp.co.nz (work) __________________/ / ---------------- New_Zealand__________________________
bill@mwca.UUCP (Bill Sheppard) (01/10/91)
In article <1675@inews.intel.com> dlau@mipos2.UUCP (Dan Lau) writes: >In article <1779@mwca.UUCP> bill@mwca.UUCP (Bill Sheppard) writes: (discussion of OS-9 deleted) >And for those interested, OS-9/386 (for all those 386 and 486 >PC's out there) was released in 1988 or 1989. Microware implemented >their own compilers and assembler and libraries for the 386, from >scratch. Then they ported the OS-9 kernel and utilities to the 386. Actually, the product you refer to is known as OS-9000. OS-9 was written in assembly language for the 680x0 and 683xx families; we re-coded the kernel and file managers in C so that we can more easily port OS-9000 to other platforms, which today include 68020/30 and 80386SX/386/486, and will include RISC implementations later this year. Of course, certain critical parts of the kernel still need to be done in assembly language of the host processor. Thanks for the plug! -- ################################################################################ # Bill Sheppard -- bills@microware.com -- {uunet,sun}!mcrware!mwca!bill # # Microware Systems Corporation --- OS-9: Seven generations beyond __/_!! # #######Opinions expressed are my own, though you'd be wise to adopt them!#######
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (01/10/91)
In article <so6iV1w163w@zl2tnm.gp.co.nz> don@zl2tnm.gp.co.nz (Don Stokes) writes: | Agreed, although it appears the MS-DOS was created in rather a hurry, | and as a bit of an afterthought. I don't think it's really fair to say | MS-DOS was "designed", rather "evolved" from existing operating systems. Microsoft didn't write MS-DOS, it was written at Seattle Computer as QDOS (Quick and Dirty OS) as a 16 bit clone of CP/M. After that it grew, with many unix-like parts in the filesystem. "Software tends to grow like a snowman built by a small child. It starts as a simple initial design in smooth layers, then grows by slapping some stuff on here and there and later smoothing over whatever sticks." (I said that in 1985 about another program entirely, but it fits.) -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) VMS is a text-only adventure game. If you win you can use unix.
jlg@lanl.gov (Jim Giles) (01/10/91)
I realize this is probably not the proper newsgroup for this discussion, but there is no comp.sys.misc and this is where the issue came up. If anyone can think of a better venue, let me know. ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > [...] > Consider what an operating system is supposed to do. Different > people have lots of different ideas on this, but among the most > important design principles that I can think of are: > > 1) Shield the application program from hardware dependencies, > and variations in system configurations. > 2) Provide a standard interface to services that allow > transfer of information between applications. > [...] The most important operating system features are these: A) Intercept and authenticate all requests for resources. This is a security issue and should be _the_ primary concern of an operating system (even a single user system - after all, how can someone protect himself from viruses if there is no security mechanism in the system?). MS-DOS has no capability in this respect _at_all_. UNIX is little better. Having said this about UNIX, I expect a flurry of UNIX cultists to flame about how UNIX really is secure after all. That is one of the flaws about UNIX - it _pretends_ to have security and many people believe the pretense. B) For all resource requests that have been authenticated, schedule the resource to satisfy the request. Again, MS-DOS doesn't have multi-processing so scheduling isn't done at all. UNIX (and most other operating systems) have an advantage here. But, the versions of UNIX that I've seen are pretty poor at scheduling. The things you mention are important, but are less so than the two just given. In particular, most of the features you mention should probably not even be in the system kernel itself. Device drivers, for example should be thought of as server processes that can be swapped out of memory entirely if the device has no active requests against it. > [...] > 3) Implement other useful services that application programmers > find themselves reinventing. I delayed this discussion because, of all the things on your list, this is the one I'm not sure should be done by the operating system _at_all_. There are, for example, many systems in which all I/O is (normally) done through a feature-rich "record manager". This provides many file and record types which are very useful to database type applications, etc.. Unfortunately, they are so feature-rich that they slow I/O down considerably when you use them. But, since it's usually _very_ hard to get around the record manager, you're stuck with it. Personally, I think the operating system should provide simple, fast, low-level functionality and the "useful services" that you are talking about should be done as servers and/or utilities and libraries. In other words, the user who doesn't need or use these features shouldn't give up system performance because of their presence. J. Giles
khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (01/10/91)
...
be fair. MS-DOS was designed to be CP/M compatable (initially) and
...
MSDOS wasn't designed to be CP/M compatible, it was CP/M derived.
Recall...
a) cp/m 1.4 ships and becomes mature (ready to become 2.x)
b) seattle computer co. builds an 8086 board, needs OS
buys 1.4 sources (and rights) and ports to x86
c) microsoft buys the port and rights
There was a dispute a couple of years back if (c) included rights to
8088, 80286, etc. and was settled out of court.
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043jlg@lanl.gov (Jim Giles) (01/10/91)
From article <10813@lanl.gov>, by jlg@lanl.gov (Jim Giles): > I realize this is probably not the proper newsgroup for this > discussion, but there is no comp.sys.misc and this is where > the issue came up. If anyone can think of a better venue, > let me know. Whoops. I was wrong. The _IS_ a comp.sys.misc. Please send followup of this discussion there. (Gee, some days it doesn't pay to get up.) J. Giles
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (01/10/91)
In article <339@bria> mike@bria.UUCP (Michael Stefanik) writes: | So was DOS in 1981. Because DOS is the status quo, that doesn't mean | you accept it. The point is *move forward* - convenience has no place | with progression. If MS-DOS users were representative of Mankind, | we'd be living in caves waiting for it to lightning so we could get some | fire ... No, we'd have colonies on the moon and Mars. DOS users are the ones who use the computer as a tool, not a way of life. They can edit some files, produce a few spreadsheets, do their taxes, and maybe play a game or two. They go on to solve useful (read as money making) problems with their little computers, and don't think about upgrading until they have a problem they can't solve with the existing resources. The people who are content with DOS don't see as anything but a way to do a job. They solve problems with existing resources instead of worrying about new ones. They are the people who put Skylab up several decades ago. The scientists who now say that we can't put up a space station because it will need constant repairs don't use DOS. They never get anything done because they are always sharpening their tools. | technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly | found to be saying things like "Well, it works on my DOS machine ..." As opposed to people who write income tax programs in Emacs macros, and keep saying things like "I don't need support, I have the source. Given a few days I can add the feature." DOS doesn't fit my usage, but for typical business applications it works just fine. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) VMS is a text-only adventure game. If you win you can use unix.
feustel@netcom.UUCP (David Feustel) (01/10/91)
How about a pointer to Microware? -- David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631 EMAIL: netcom.uucp
dkessner@isis.cs.du.edu (David D. Kessner) (01/10/91)
In article <20235@netcom.UUCP> feustel@netcom.UUCP (David Feustel) writes: >Does Unix support scanners, real-time A/D & D/A? How much does it >cost? > >-- >David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631 >EMAIL: netcom.uucp I think UNIX does support scanners, but I forgot there I saw this. There is no real reason why it coulden't. There are UNIX FAX's, why not a scanner? A friend of mine once described UNIX as a non-real-time system, "Your computer is running in a hospital monitoring a heart rate. The heart fails so it sends mail to the doctor..." I never said that UNIX was perfect. But there are other OS's that will do real-time things in a multi-tasking sort of way. Take the Amiga, for example. This is a $600 machine that will multi-task and sample audio at the same time. Then there is always the Silicon Graphics machines... UNIX costs no more than a similarly configured PC. A two user licence of ESIX (SysV for the 386), the development version, costs $500. The unlimited user, development version, with manuals runs $1000. SCO UNIX runs no more than $2500 with all the bells and whistles. NOVELL NETWARE 386 v3.1 runs no less than $5000! $7000 is closer (We are a dealer for NOVELL, but I forgot our price). UNIX is more expensive, when compared to a single user MS-DOS 386 system running something like Desqview, but you get what you pay for! There are some things that MS-DOS just CAN'T do, like multi-user! David Kessner kessner!david@csn.org
ric@mcrware.UUCP (Ric Yeates) (01/11/91)
In article <20469@netcom.UUCP> feustel@netcom.UUCP (David Feustel) writes: >How about a pointer to Microware? \ Microware Systems Corp. ---------------\ 1900 NW 114th St. > Des Moines, IA 50325 ---------------/ (515) 224-1929 / Ask for the FREE OS-9 or OS-9000 Catalog! >-- >David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631 >EMAIL: netcom.uucp -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ric Yeates Microware Systems Corp. "I found these opinions on the floor, so I don't think they belong to Microware." 1. Grease Generously 2. Wax Philosophically -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
mike@bria.UUCP (Michael Stefanik) (01/11/91)
In article <3111@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: > The people who are content with DOS don't see as anything but a way to >do a job. They solve problems with existing resources instead of >worrying about new ones. They are the people who put Skylab up several >decades ago. The scientists who now say that we can't put up a space >station because it will need constant repairs don't use DOS. They never >get anything done because they are always sharpening their tools. I disagree with this generalization that DOS users are productive computer users, and UNIX users are not productive becuase they're too busy building better mousetraps; if this were truly the case, Ken would still be working on the PDP-11 cranking out the "mousetraps" that we all take for granted. Certainly I would agree that UNIX users are more "tools" oriented than DOS users, but would a likely reason be that UNIX tools are considerably more powerful (and, yes, *fun* to use) than the meager portions doled out by Microsoft? UNIX users *do* see their machines as tools, and use them as such. The point I'm trying to make is why not try something better, even if your needs are met? By way of analogy (a true one at that), consider the telephone. When the phone first came out, messenger boys were common. The people said, "Why would we use a phone? We use our messenger boys, and all of the businesses we deal with are close by." This is the same mentality of many DOS users: "Why should I upgrade? My AaackBlatz package does what I need." All the while they are shutting their eyes to something that could increase their productivity ... True, not *everyone* needs the latest and greatest. However, I have found that DOS users are on the order of contented cows, happy with the pasture in which they graze, and not interested in anything else but chewing their mediocre cud ..." -- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike -- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
sdawalt@valhalla.wright.edu (Shane Dawalt) (01/11/91)
From article <14900021@hpdmd48.boi.hp.com>, by muyanja@hpdmd48.boi.hp.com (bill muyanja): >> ... I cheerfully admit that DOS completely fails to handle more than 1MB of >> RAM. It's not perfect. > > Not so! Windows 3.0, a *DOS* product, can allocate a 64MB glob of memory in > 386-enhanced mode. > But Windows is a DOS *product* and is not DOS. Note there are many 286 machines "out there" too, so it is not a 386-only issue. My machine is a 286 beast and I would enjoy having 16 Megs of RAM with 32Megs swap. (Oh yes, swapping would be a pain, but it could be done if one thinks a bit.) Until I find a money tree (or rich uncle), my 286 will have to do. Shane(); -------------------------------------------------------------------------- From the keyboard of: email: sdawalt@cs.wright.edu Shane A. Dawalt --------------------------------------------------------------------------
jlg@lanl.gov (Jim Giles) (01/12/91)
From article <3120@crdos1.crd.ge.COM>, by davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr): > In article <11123@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >> [... grep is trivial ...] > > So your job doesn't involve data analysis, or you have other tools. Other tools. As I said, the problem with grep is that what it does is too trivial to deserve to be a separate tool. I needs to be a built-in capability of editors, database managers, etc.. > Anyone who has tried to learn how regular expressions really work knows > it isn't trivial. If you use grep for matching "abc" that's fine, but it > has a lot more power than that. Regular expressions are usually covered in the first week of any good compiler course. Once you know the basics, a brute force grep should only require a few hours to write from scratch. The tool isn't useful often enough to lavish lots of optimizations on it. Save that kind of effort for a regular expression search tool that's callable as a library function - that's where you need it - built-in to other tools. > [...] > | In view of this fact, 'grep' also falls into the next category. > | > | 2) Useless. These tools (and there are a lot of them) don't do > | anything I ever need to do. > > That sounds like a bad argument to me. My spreadsheet was last > accessed in October of 1988, does that make it useless? UNIX gives you > lots of tools and you can use what's useful to you. [...] Which, as I said, verges on the empty set. If you don't need a spreadsheet, you shouldn't have bought one. The problem with UNIX is that it comes with a whole host of software which is useless to _me_, but I have to retain it because it's all needed for system maintenance. > [...] DOS gives you next > to nothing, and now that even BASIC is an extra cost item gives you no > programmable capacity standard. So, it breaks even with the _useful_ part of the UNIX distribution. But, let's do a comparison. MS-DOS (mail order discount) runs between $70 and $140 (depending on which version you buy). The cheapest UNIX that I've seen (not MINIX, real UNIX) runs about $900. I can buy a considerable amount of MS-DOS software for that extra $760. And, it will all be stuff I actually _USE_ (or I wouldn't buy it). Note: I've heard that there's a new UNIX for PC's which just contains a pcc-type compiler, a bourne shell clone, a half dozen utilities, and UNIX itself of course - for $99. For this kind of price, I may buy a copy, just to play with. At $900, you can forget it. > [... spell vs. tools available on DOS ...] > [...] and finally > several commercial products which have the same functionality as the DOS > products (different user interface, though). Really? I've been looking all over for such things. The only ones I've found are migrants _from_ MS-DOS. Usually they run slower than their PC counterparts. The problem was, in order to port to UNIX they rewrote in C. > [...] > But UNIX runs on an XT. And like DOS it runs slowly, but many things > run faster than DOS for the same effect. Well, MINIX et. al. will run on XT's. They aren't _really_ UNIX. I looked into that stuff before. At the time, my XT didn't have sufficient space to install UNIX (DOS occupies almost no space). Now, I have a much bigger system, but even so, UNIX would consume a significant portion of my disk/memory. By the way, I've never seen _any_ PC-UNIX benchmarks which compared favorably to the same appli- cation on DOS. > [... integrated environments et. al. ...] > > I bet you will hear from Sabre and a few other people who sell things > like this. I hope so. In any case, commercial UNIX software is usually more costly (something about volume bringing the price down). They'd have to have a good price to lure me into a UNIX environment at home (I'm already _stuck_ with UNIX at work). > [...] > VMS is a text-only adventure game. If you win you can use unix. Oh, I hope I lose then. Better yet (since this is VMS you're talking about), I think I'd rather not play at all. By the way, don't get me wrong here. I'm not an MS-DOS fanatic. A number of your complaints against DOS are quite valid. A lot needs to be done to make it more palatable. But, UNIX would be, at best, a step sideways: not forward. J. Giles
akira@atson.asahi-np.co.jp (Akira Takiguchi) (01/12/91)
I know I have less experience than most particepants... In article <11143@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >In <3120@crdos1.crd.ge.COM>, by davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr): >> In article <11123@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >>> [... grep is trivial ...] >> So your job doesn't involve data analysis, or you have other tools. >Other tools. As I said, the problem with grep is that what it does >is too trivial to deserve to be a separate tool. I needs to be a >built-in capability of editors, database managers, etc.. `Integrated' DOS softwares tends to be too complicated with `catalog' features that most people never use (and sometimes lack important features). Mr. Giles complains about editors and database managers not built in, but in fact they ARE built in the operating system in UNIX's way. Think UNIX as one `integrated DOS software'. Not much difference. And UNIX provides more :-) features. Mr. Giles doesn't like THE WAY they are integrated, and I won't say anything about it; that's a personal taste. -- Akira Takiguchi at ATSON, Inc. A subsidiary of the Asahi Shimbun Phone +81 3 3289 7051 Fax +81 3 3289 7066 SORRY, EMAIL NOT AVAILABLE
plinio@turing.seas.ucla.edu (Plinio Barbeito/;093091;allsites) (01/12/91)
Warning: This article is fairly long. In article <11123@lanl.gov> jlg@lanl.gov (Jim Giles) writes: [...stuff deleted...] >The tools on UNIX tend to be clustered into a few categories: > > 1) Trivial. These tools ('grep' is an example) perform functions > that are so simple that there is hardly an excuse for separate > tools to do them. I do a 'grep' perhaps once a month (and then, > only because 'ls' doesn't have a filter for file ownership in it). > In view of this fact, 'grep' also falls into the next category. One of the things that makes unix programs so powerful is the extent to which they can be used together to provide a result that would require custom development under DOS. No doubt, the specifically developed program would probably be missing a feature you want/need, and then you have to hunt for another slightly different program. Then you have to decide a (non-standard?) place for both programs on your disk, and remember what names they had and the (probably different) interfaces they use. In contrast, the unix csh interface allows you to hide details pertaining to the interface of its programs. For your case, you could learn how to use grep ONCE, then write an alias that pipes grep's output to ls, call the result 'lso' or whatever you insist on, put the line in your .cshrc, and never deal with grep again. Do the same with the other features of ls that you use (e.g. alias lsa ls -a), and then forget that ls and grep ever existed. This way you don't have to remember how to use all of the functions of the programs you need to use, or even see them as available, unless you want to. > 2) Useless. These tools (and there are a lot of them) don't do > [...a reference regarding how spell was useless] A lot of commands seem to be useless, but keep in mind that some of these programs' raison d'etre does not become apparent until you use them in combination with others. For example, I once marveled at what possible use a program doing nothing else but printing a bunch of y's on the screen could have. The program 'yes' turns out to be a way (I didn't say a good way) to force an interactive program requiring 'y' inputs back into a program you can run from a batch file or an alias. It's those seemingly useless programs that (when used in combination with others), turn out to be the invaluable lifesavers when you have some obscure thing you need to automate. Power and automation go hand in hand. > 3) Backward. These are UNIX tools which are behind those available > on other systems, and UNIX implementations are playing catch-up. > Graphical user interfaces (popularized by Apple, often just as > good on MS-DOS machines as on UNIX workstations), and word > processing/desktop publishing (UNIX may have had a _lead_ here > a decade ago, they blew it - they are now _behind_). In addition, > there are things like spreadsheets, etc. which UNIX doesn't have > at all as far as I can determine (there are bound to be some, I > just haven't seen any). (Note: graphical interfaces benefit > _slightly_ on UNIX from the following category.) What you have said is akin to "If I can put the Y operating system on top of DOS, then DOS has a better interface than unix running X". Windows or Deskview are nothing short of what many people consider an operating system. X is a Unix *application*, for instance. It doesn't handle memory allocation, I/O or other things for the machine. If you can claim Windows as a DOS application, then with a freer conscience, people that use NeXTs are bound to mention their excellent interface and DTP software. People using A/UX will mention (but please don't, it threatens my argument :-) ) the mac DTP software, Xerox users might mention GlobalView (which runs on top of SunOS) with ITS associated set of word processor/DTP/spreadsheet software, and the list goes on. [4...] > on MS-DOS, you only pay for the software/hardware for TCP/IP if > you really _need_ the functionality. I agree with your general argument to a certain degree. However, how do you know that you won't need the functionality in the future, and be forced to buy a complete new system because of it? You are able to reliably predict your needs, but this does not apply to everyone. I know people that have to buy a new clone every 2 years. If they used Unix, they could wait 3 years :-) > 5) Mundane. This category includes such things as compilers, [...] > Some MS-DOS compilers have 'integrated environments' of their > own, with built-in editors, debuggers, etc.. This is a slight > advantage for MS-DOS if you like that sort of thing, you can > turn it all off if you don't. Are you sure that in ALL cases you can "turn it all off"? It may be true of Turbo, or another compiler you use, but can you decouple dbase (etc, for the sake of argument) from its interface if you need to run it unattended? If you can't get rid of the (typically non-standard) interface, this becomes a net disadvantage if you have information that programs must share, IMO. You may be able to find the program with the kitchen sink in it, that has enough features to make everyone happy (except for the person learning to use it), and that doesn't need to communicate with other programs, but you may pay a price waiting for all that stuff to be loaded into the typically very limited physical memory from the typically slower, non-concurrently accessed, DMA incapable, either (limited small) or (large and inefficient) filesystem. [By this point your argument no longer centers on DOS' relative power, just general Unix bashing, but, let's keep going...] >Part of the problem with UNIX is that it tends to be monolithic and >obscure. That's why so much is typically 'bundled' with it: there's ^^^ you've just described a lot of MS/DOS programs. :-) >so many things needed just to get the system working and keep it >working. Unix may be too complex for the average joe. But (back to the original premise) don't say that its programs aren't powerful. IMHO, its beauty is that by putting 0010 and 0010 together, on the whole, it makes it possible to automate the heck out of your tasks. >[...] For example, a lot of people think that >Zork-like games are fun to play. Personally, I think such games are >deadly dull - carry every object you find to every room you find and... You're right, one person's idea of fun may be another's exercise in boredom. But there are other "tools" which you might not have known about, whose excitement value is not necessarily derived from the interface. If fun can be traced to ego satisfaction, then there can be nothing more fun than ruining someones day :-). Unix provides plenty of opportunity to do this (without lawsuits from the victims) by playing multi-user games like xtrex or empire. Complex human interaction is what makes it more than just issuing commands. If the amount of fun is proportional to the amount of ego, then empire must be the funnest game of all time (just read rec.empire and you'll see what I mean). But this is also subjective. And if I don't seem fanatical about it, there's a chance you or someone else might not even be intrigued. [...some talk about Unix user interface deleted...] >to be useful and which don't, it's just a matter of memorization. The Memorization, IMHO, is learning which of the 30 non-mnemonic function keys does what in each different DOS program I have to use, and where and in which fashion the result will be shown on the screen. [...] >Note: in order to disarm the usual ad hominem flame from UNIX proponents >I must tell you that I have used UNIX every working day for about a decade >now. I know it reasonably well. So don't hit me with the usual "he's >obviously never used UNIX and doesn't know what he's talking about" >routine. It won't wash. I've tried to be lighthearted throughout this post, so don't take it too personally when I say that for washing purposes, soap is in the eye of the beholder :-) But I'm not necessarily a Unix proponent, and I don't consider this a flame. The old O/S that is Unix (early 1970's) has many drawbacks; your argument about its user interface being hard to learn is convincing and you make some other valid points, but I think that for the most part you are barking up the wrong trees, especially in the area of power, and especially if the thing you are comparing it with is an operating system with an architecture that provides very little that the applications don't want to do themselves. >J. Giles plini b --- Disclaimer: No disclaimers.
avg@hq.demos.su (Vadim Antonov) (01/12/91)
What are you talking about? If your data is worthless to you,
MS-DOS is your choice for sure. Numerous viruses, *real* (ha, ha!)
mode of operation, TSRs and rather cretinistic file system make
this DOS pretty unuseable for any serious job. Moreover I cannot say
I always dreamed to spend my life playing Big Brother's toys.
I cannot say either I'm a Unix fanatic (having nine years spent with it
I *may* say it) but I'm quite sure the next one will not have the name
"OS/2" or "MS Windows". Of course these beasts will be still popular
between suits preferring to think lesser. It's not a matter of technology,
it's rather a matter of mental orientation - Unix provides an environment
suggesting users to think, Messy-Dossy creatures assume that user do not
think at all. That's the difference.
Vadim Antonov
DEMOS, Moscow, USSR
PS. Being a general in F-19 simulator I cannot say I don't like MS-DOS :-)
I like this toybox, babe!ppessi@niksula.hut.fi (Pekka Pessi) (01/13/91)
In article <11143@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >Regular expressions are usually covered in the first week of any good >compiler course. Once you know the basics, a brute force grep should >only require a few hours to write from scratch. The tool isn't useful >often enough to lavish lots of optimizations on it. Save that kind >of effort for a regular expression search tool that's callable as a >library function - that's where you need it - built-in to other tools. See regex(3). So you are not ignorant about Unix? -- Pekka Pessi / ppessi@niksula.hut.fi
jlg@lanl.gov (Jim Giles) (01/13/91)
From article <PPESSI.91Jan12222745@spiderman.hut.fi>, by ppessi@niksula.hut.fi (Pekka Pessi): > [...] > See regex(3). So you are not ignorant about Unix? No, I'm not. The existence of regex(3) _supports_ my prosition on grep. That is: grep is a trivial tool that doesn't have any business being a separate utility. In nearly every context where people recommend the use of grep, regex() is a _better_ solution. For one thing, it saves the overhead of using pipes - passing the strings as procedure arguments is a lot more efficient (in this case, the pipe overhead is probably _bigger_ than the execution time of the whole pattern search). Or, is my mention of the preference for library routines without mention of a specific name to be taken as significant ignorance. I didn't mention the specific routine because the discussion of grep is intended as an example of a general class of trivial utilities on UNIX - _all_ of which would be better done by library routines. Fortunately, there _are_ public domain libraries which perform these functions (and are available _free_ in source - so even MS-DOS users can use them). Come to think of it - there are free public domain versions of the utilities themselves available for MS-DOS users. Most MS-DOS users don't bother to get copies because they aren't worth the disk space they take up. The library routines, on the other hand, are a different matter. J. Giles
longc@cs.fau.edu (Courtney Long) (01/13/91)
In article <339@bria> mike@bria.UUCP (Michael Stefanik) writes: > >................... Because DOS is the status quo, that doesn't mean >you accept it. The point is *move forward* - convenience has no place >with progression. If MS-DOS users were representative of Mankind, >we'd be living in caves waiting for it to lightning so we could get some >fire ... >-- >Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation >UUCP: ...!uunet!bria!mike I agree that MS-DOS is not the last word in PC operating systems. My personal preference is OS/2, but I'm cautious in admitting that because most people haven't used is and don't know much about it other than what they've read. I don't agree that DOS has outlived it's usefulness or that there is a readily available, affordable alternative which has a respectable applications base. Some people say Windows. What about you? >-- >technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly >found to be saying things like "Well, it works on my DOS machine ..." elitism (i-le'tiz'em) a sense of being part of a superior or privileged group
jxf@altair.cis.ksu.edu (Jerry Frain) (01/13/91)
jlg@lanl.gov (Jim Giles) writes: >From article <PPESSI.91Jan12222745@spiderman.hut.fi>, by ppessi@niksula.hut.fi (Pekka Pessi): >> [...] >> See regex(3). So you are not ignorant about Unix? >No, I'm not. The existence of regex(3) _supports_ my prosition on grep. >That is: grep is a trivial tool that doesn't have any business being a >separate utility. In nearly every context where people recommend the >use of grep, regex() is a _better_ solution. This discussion is becoming absurd. I fail to see any logic in this argument. Perhaps someone would be kind enough to tell me what *exactly* justifies whether a tool has "any business being a separate utility?" Grep(1) is no more trivial than ls(1). Yet I doubt that you would question the existence of ls as a separate utility. I probably invoke grep from the shell at least twenty times daily. I do not wish to invoke a similar function from within any program (for those particular twenty invocations). I invoke grep from the shell because that serves my purpose best. Perhaps this is due to the nature of my job. I doubt it, since I know many people who also use grep from the shell quite often. Regex() would only be a better solution if one desired to create a built-in shell command which had the same features as grep. This, however, is impractical. Every shell (or other program which might find grep useful) would require its built-in grep utility, some possibly with different features than another. Why should I use ten different implementations of grep, when I can use the very same grep utility whenever I need? --Jerry -- Jerry Frain -- Systems Programmer Kansas State University Department of Computing & Info Sciences Internet : jxf@cis.ksu.edu Manhattan, Kansas UUCP : ...!rutgers!ksuvax1!jxf
egdorf@zaphod.lanl.gov (Skip Egdorf) (01/13/91)
In article <11143@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > > From article <3120@crdos1.crd.ge.COM>, by davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr): > > In article <11123@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > >> [... grep is trivial ...] > > > > So your job doesn't involve data analysis, or you have other tools. > > Other tools. As I said, the problem with grep is that what it does > is too trivial to deserve to be a separate tool. I needs to be a > built-in capability of editors, database managers, etc.. > Ummm... But, Jim, weren't you just saying that the problem was the "muscle" required to run all the Unix stuff? doesnt wrapping a grep into EVERY program just make the problem worse? The point being missed is that Unix was, and still IS (in a practical sense, just to avoid OS/2 arrows) the only system that provides the USER with a multitasking facility that is Easy to use: the pipe. Generally, grep as a stand-alone command is indeed a toy. The beauty of the interface is that grep is ALREADY connected to all that other software by Unix via the pipe. The point of the Unix interface is (and was in 1975) that tools like grep are supposed to be seperate in order to avoid the "muscle" required when all those 'modes' are in EVERY program. > > [...] > > | In view of this fact, 'grep' also falls into the next category. > > | > > | 2) Useless. These tools (and there are a lot of them) don't do > > | anything I ever need to do. > > > > That sounds like a bad argument to me. My spreadsheet was last > > accessed in October of 1988, does that make it useless? UNIX gives you > > lots of tools and you can use what's useful to you. [...] > > Which, as I said, verges on the empty set. If you don't need a > spreadsheet, you shouldn't have bought one. The problem with UNIX > is that it comes with a whole host of software which is useless > to _me_, but I have to retain it because it's all needed for > system maintenance. Grep, USELESS???? Once you begin to (yes, I agree) MEMORIZE what all those little tools do, and then start to use them together, you find that there are a lot of useful ones after all. The problem (my opinion) stems from lots of users moving to Unix from systems that do not provide multitasking ("Why would I ever need to run more than one thing on my single-user suystem?" shows up all over the net a lot ...) and then try to use the tools one at a time and are disapointed. > ... > > [...] > > But UNIX runs on an XT. And like DOS it runs slowly, but many things > > run faster than DOS for the same effect. > > Well, MINIX et. al. will run on XT's. They aren't _really_ UNIX. > I looked into that stuff before. At the time, my XT didn't have > sufficient space to install UNIX (DOS occupies almost no space). > Now, I have a much bigger system, but even so, UNIX would consume a > significant portion of my disk/memory. By the way, I've never seen > _any_ PC-UNIX benchmarks which compared favorably to the same appli- > cation on DOS. I use two classes of tools. Gnu emacs and Common Lisp form one, A few windows on the Sun for access to all the very useful Unix utilities form the other. The Unix tools I use (with grep as one of the more common) run with little or no change as they did on my 11/40 with 128KB in 1976. The fact that I like power tools when appropriate (you DO use a Cray once in a while??) does not mean that I do not also use the simple tools when they are appropriate. The trick is to realize that both are needed at times. I don't use a power floor sander to do the final smoothing on a picture frame, and I don't use a piece of 1x2 with 320 grit wrapped around it to finish an Oak floor. > ... > (I'm already _stuck_ with UNIX at work). > ... But, UNIX would be, at best, a step sideways: > not forward. I'm sorry to hear the word "_stuck_" there. The primary responsibility of a computer professional is to know enough about the range of tools available so that the correct tool can be chosen for the job. I find CTSS on a Cray a useful tool for some jobs. I find Unix on a workstation to be a useful tool for some jobs. I expect to find Unicos on our Crays to be useful for some Jobs. I find VMS useful for some jobs (though the jobs for which is is useful is a rather limited set). I find MS-DOS useful for some jobs (again, a limited set). I have chosen a field where I am working on projects that use the tools I like BEST (Lisp on large workstations in my case), but I realize that there is a difference between what I like best to do, and what I must use professionally as the need arises. If you are in a position where you are being _stuck_ using some tool you dislike, either your management is forcing an inappropriate tool on you, or the tool is appropriate but you dislike it. In either case, you might consider moving to someplace where the projects worked upon require the tools you like. If your current job is best served by Unix tools, but you dislike those tools, you will neither be productive, nor happy. > J. Giles Skip Egdorf hwe@lanl.gov
johnl@iecc.cambridge.ma.us (John R. Levine) (01/13/91)
Gee, when I started this thread on why DOS is useful, I didn't expect it to
evolve in this direction.
There's no doubt that grep is a trivial tool. What makes it useful is the
ease with which it can be included in useful non-trivial shell scripts. Until
there's a language that lets you build programs with regexp() as easily as
sh lets you built them with grep, I expect to use grep about 100 times as
often as regexp.
The usual DOS application builders are either batch files, using a language
slightly less powerful than the 5th edition Mashey shell, or else Turbo C.
No thanks.
Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnljpk@ingres.com (Jon Krueger) (01/13/91)
From article <11123@lanl.gov>, by jlg@lanl.gov (Jim Giles):
> the individual tools on MS-DOS tend to be more _powerful_.
For example?
-- Jon
--
Jon Krueger, jpk@ingres.com jlg@lanl.gov (Jim Giles) (01/13/91)
From article <EGDORF.91Jan12184630@zaphod.lanl.gov>, by egdorf@zaphod.lanl.gov (Skip Egdorf): > In article <11143@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >> [...] > Ummm... But, Jim, weren't you just saying that the problem was the "muscle" > required to run all the Unix stuff? doesnt wrapping a grep into EVERY program > just make the problem worse? No. Piping things together is about the _least_ efficient way of incorporating a functionality into a tool. Almost _anything_ is an improvement. The additional muscle required to support UNIX is due in large part to preferential use of this least efficient technique. > [...] The point of the Unix interface is (and was in 1975) that > tools like grep are supposed to be seperate in order to avoid the "muscle" > required when all those 'modes' are in EVERY program. The paradigm you are describing was recommended to as a way of perfomrming what we would today call "rapid prototyping". It was a way of getting a quick-and-dirty version of a new tool so you could play around with the functionality before building a production quality version as a single utility. > [...] The problem (my opinion) stems from lots of users moving to Unix > from systems that do not provide multitasking ("Why would I ever need to run > more than one thing on my single-user suystem?" shows up all over the net a > lot ...) and then try to use the tools one at a time and are disapointed. In the modern sense of the term, UNIX doesn't provide multitasking either. It provides multiprocessing. Pipes are a weak subset of the general concept of interprocess communication. For the benefit of those that don't have a multitasking system, I will describe the difference. Multiprocessing is the use of timesharing or other techniques to do (or at least simulate) several independent processes simultaneously. Such processes _may_ communicate with each other through the operating system. The standard model for this is to treat interprocess communication as a type of I/O. Multitasking is the use of several CPUs on an individual process in order to speed the turnaround of that process. Differrent tasks communicate with each other without having to pass the information through the system. The usual method here depends upon the mutual exclusion instructions and general archetecture of the hardware in use. The Cray, for example, provides shared memory access between CPUs, shared registers, and hardware semaphores. To be sure, before the wide availability of multiple CPU machines, the two terms were used interchangably. > [...] > I don't use a power floor sander to do the final smoothing on a picture > frame, and I don't use a piece of 1x2 with 320 grit wrapped around it > to finish an Oak floor. Then why insist that a single tool (grep) is appropriate for all pattern matching functionality? It's as if the _only_ size sandpaper was the 1x2 and if you needed to do floor finishing you'd have to glue dozens of sheets of such paper to the power sander. It's possible, but the appropriate size paper for each job is better. The appropriate level of interaction between the components of a software environment is very rarely a pipe. The appropriate level of interaction is _much_ more often a procedure call. J. Giles
spot@CS.CMU.EDU (Scott Draves) (01/13/91)
In article <11255@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
The paradigm you are describing was recommended to as a way of perfomrming
what we would today call "rapid prototyping". It was a way of getting
a quick-and-dirty version of a new tool so you could play around with
the functionality before building a production quality version as a
single utility.
...
The appropriate level of interaction between the components of a
software environment is very rarely a pipe. The appropriate level
of interaction is _much_ more often a procedure call.
Your use of UNIX must be very different from mine (and others'), or
you are talking about programming and not interactive use.
I do *not* want to write a program every time I want to search a file
for a word. The stuff I write with shell (pipes and all those funny
utilities) are mostly one-shot hacks. Something I need done now and
probably not ever again in the future. So "rapid prototyping" is
*exactly* what I want.
If you are saying you would never write production code in csh using
all those utilities, then I agree. And so will (nearly?) everyone
else. That would be slow and gross.
But my day to day use of the computer demands a flexible set of tools
which I can combine in useful ways to accomplish all sorts of crazy
things. csh + unix utilities + elisp works quite well.
--
IBM
Scott Draves Intel
spot@cs.cmu.edu Microsoftquale@picard.cs.wisc.edu (Douglas E. Quale) (01/13/91)
In article <11234@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <PPESSI.91Jan12222745@spiderman.hut.fi>, by ppessi@niksula.hut.fi (Pekka Pessi): >> [...] >> See regex(3). So you are not ignorant about Unix? > >No, I'm not. The existence of regex(3) _supports_ my prosition on grep. >That is: grep is a trivial tool that doesn't have any business being a >separate utility. In nearly every context where people recommend the >use of grep, regex() is a _better_ solution. For one thing, it saves >the overhead of using pipes - passing the strings as procedure arguments >is a lot more efficient (in this case, the pipe overhead is probably >_bigger_ than the execution time of the whole pattern search). Or, is That's right. Every time I want to do a one time only search for a pattern I write, compile and debug a program to do it, because it saves a few milliseconds of the *computer's* time. User's time isn't important. -- Doug Quale quale@picard.cs.wisc.edu
sef@kithrup.COM (Sean Eric Fagan) (01/13/91)
In article <11255@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >No. Piping things together is about the _least_ efficient way of >incorporating a functionality into a tool. Almost _anything_ is >an improvement. Actually, pipes can be an improvement for sequential processing, since, while the one process is waiting on I/O, the other process can be processing. Throughput is increased as a result. >In the modern sense of the term, UNIX doesn't provide multitasking >either. It provides multiprocessing. Pipes are a weak subset of >the general concept of interprocess communication. Uhm, Jim, you've got your terms reversed. Multiprocessing is generaly used to mean multiple processors; multitasking means just that: multiple tasks. Now, it's true, unix is not *really* multitasking, as, in most implementations, only one task runs at a time (but not necessarily; for example, in a PC, with a smart serial card, the serial card can run in parallel with the CPU). Note, however, that, if you want to say that unix isn't multitasking, you have to say it's not multiuser, either (since only one user is using the machine at a time). This is true of most machines, however. Now, about unix and multiprocessing: every major unix vendor these days has a multiprocessing version of unix available, if a multiprocessor version of the hardware is available. Crays, for example, under unicos; AT&T, with the 3b6000 (is that the number? I really forget); SCO, with MPX and something like 5 or 6 different hardware vendors; Sequent, Encore, ETA, Elxsi, MIPS, DEC, etc. Note that, with multiple processors, you get the advantage in speed, if you use pipes, without having to change code in any way, as different parts of your "program" can run in parallel. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
jlg@lanl.gov (Jim Giles) (01/13/91)
From article <1991Jan13.010437.7212@maverick.ksu.ksu.edu>, by jxf@altair.cis.ksu.edu (Jerry Frain): > [...] > Why should I use ten different implementations of grep, when I can use the > very same grep utility whenever I need? Ask any mechanic whether he'd rather use the correct size socket wrench from a complete set or always have to use the monkey wrench. Work is always more productive when the correct tool is used - not the one-size- fits-all tool. Besides, in this case I'm not recommending 'ten different implementations'. I'm recommending that the one implementation which is usually much more appropriate is a library routine and not a piped utility. J. Giles
spot@CS.CMU.EDU (Scott Draves) (01/13/91)
The paradigm you are describing was recommended to as a way of perfomrming what we would today call "rapid prototyping". It was a way of getting a quick-and-dirty version of a new tool so you could play around with the functionality before building a production quality version as a single utility. ... The appropriate level of interaction between the components of a software environment is very rarely a pipe. The appropriate level of interaction is _much_ more often a procedure call. Your use of UNIX must be very different from mine (and others'), or you are talking about programming and not interactive use. I do *not* want to write a program every time I want to search a file for a word. The stuff I write with shell (pipes and all those funny utilities) are mostly one-shot hacks. Something I need done now and probably not ever again in the future. So "rapid prototyping" is *exactly* what I want. If you are saying you would never write production code in csh using all those utilities, then I agree. And so will (nearly?) everyone else. That would be slow and gross. But for day to day work I use csh + grep et al + elisp quickly and effectively to solve my problems. -- IBM Scott Draves Intel spot@cs.cmu.edu Microsoft
jpenne@ee.ualberta.ca (Jerry Penner) (01/13/91)
In article <11261@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <1991Jan13.010437.7212@maverick.ksu.ksu.edu>, by jxf@altair.cis.ksu.edu (Jerry Frain): >> [...] >> Why should I use ten different implementations of grep, when I can use the >> very same grep utility whenever I need? > >Ask any mechanic whether he'd rather use the correct size socket wrench >from a complete set or always have to use the monkey wrench. Work is >always more productive when the correct tool is used - not the one-size- >fits-all tool. > >Besides, in this case I'm not recommending 'ten different implementations'. >I'm recommending that the one implementation which is usually much more >appropriate is a library routine and not a piped utility. > >J. Giles This is not a good comparison. The unix grep is more like a magic wrench that sizes to the correct nut, bolt autmatically. You may well have picked grep as the wrong example. I say this because all of the MSDOS programs I have used that do pattern matching never fully implement regular expressions. Maybe because the authors only use MSDOS and don't use a grep that has more powerful features. Or maybe they didn't feel it was worth the time to code. I don't know. But I'd much rather have a real grep that might be a fair bit slower if at least it works. IT is the right tool because it DOES the job. Like others have said. The power is in the shell implementation because you can use it quickly without writing and debugging a C program to do it. You get your task done in a couple of minutes or maybe even seconds rather than half an hour or more. -- ------------- Jerry Penner alberta!bode!jpenne Edmonton, Alberta, Canada
pavlov@canisius.UUCP (Greg Pavlov) (01/13/91)
In article <11123@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > > ..... I do a 'grep' perhaps once a month (and then, > only because 'ls' doesn't have a filter for file ownership in it). > In view of this fact, 'grep' also falls into the next category. > I use grep, awk, sed, etc constantly - both on my own pc and the UNIX systems I work on. These, for me, long ago became "necessities". Also true of my programming staff and a lot of our user base. > My spelling checker on MS-DOS suggests alternatives so that > I can correct my error. It also has a built-in thesaurus, .... > Funny, but none of the MS-DOS machines we have here came with anything that looks like what you describe. Didn't even come with anything as useless as "ispell", in fact.... > ...... Of course, TCP/IP is a DARPA > standard and is available on many systems - including MS-DOS. But, > on MS-DOS, you only pay for the software/hardware for TCP/IP if > you really _need_ the functionality. You also pay in time and lack of integration. It takes a heck of a lot less effort for us to get a new UNIX box up and on a network than an MS-DOS box. > .... The prices (considering the > heavy hardware cost of a UNIX system) is competitive though. This is only true if you insist on the comparison DOS people love to make: cheapest Taiwanese clone one can dig up vs. list price for a SUN/DEC/HP/ IBM box. But most of the major mail-order vendors here now sell UNIX on their 386/486 platforms. Granted, you can run MS-DOS on much less (just as you can run UNIX on much less). But those "features" you attributed to DOS- graphics-based interfaces, complex compilation packages, etc, literally drag on the lesser INTEL breeds. > Part of the problem with UNIX is that it tends to be monolithic and > obscure. That's why so much is typically 'bundled' with it: there's > so many things needed just to get the system working and keep it > working. > Not quite sure what you mean by "monolithic" (2001 Monolith ??). But your second sentence rather accurately applies to most software packages avail- able for MS-DOS machines: lots of facilities have to be built in and/or bundled in with them to make them functional in MS-DOS. And every package handles these in its own way. Like talking to a printer, for example: /ppr[select range]ag in 1-2-3, <shift-F7>[specify page range] in WordPer- fect, etc (this AFTER you've gone thru each package's unique gobbledy- gook to identify/initialize the printer in the first place). > Finally, you make the claim that UNIX tools are fun to use. Now, this > may be a personality thing. > How about that !!! > As someone pointed out years ago (I wish I could find the reference), > the word 'arcane' and the phrase 'user friendly' are mutually exclusive. > UNIX is arcane. > ... and MS-DOS is 'user friendly' ???? > Note: in order to disarm the usual ad hominem flame from UNIX proponents > I must tell you that I have used UNIX every working day for about a decade > now. I know it reasonably well. So don't hit me with the usual "he's > obviously never used UNIX and doesn't know what he's talking about" > routine. It won't wash. > No, I don't question whether you know UNIX but whether you have been dis- cussing MS-DOS or a wraith that changes characteristics, shape, and size in response to each one of your arguments' needs. greg pavlov, fstrf, amherst, ny pavlov@stewart.fstrf.org
jxf@altair.cis.ksu.edu (Jerry Frain) (01/13/91)
[ Temptation to change the subject line stifled, as many readers have probably gone to the trouble of placing the current subject in their kill files ] jlg@lanl.gov (Jim Giles) writes: >In the modern sense of the term, UNIX doesn't provide multitasking >either. It provides multiprocessing. Pipes are a weak subset of >the general concept of interprocess communication. >For the benefit of those that don't have a multitasking system, I will >describe the difference. Multiprocessing is the use of timesharing >or other techniques to do (or at least simulate) several independent >processes simultaneously. Such processes _may_ communicate with each >other through the operating system. The standard model for this is to >treat interprocess communication as a type of I/O. Multitasking is >the use of several CPUs on an individual process in order to speed >the turnaround of that process. The above definitions of the terms "multiprocessing," "multitasking," and "time-sharing" are not consistent with current graduate-level operating systems teachings. Nor are they consistent with most operating system text-book definitions which I have seen. Multiprogramming is when several instances or programs (processes) reside in (main, or primary) memory (storage), and the processor switches between programs. Time-sharing is essentially multiprogramming, except now users have on-line terminals. The CPU provides interactive service to terminal users while larger batch-type jobs are executed in the background. Multiprocessing is when more than one processor cooperate together to execute programs (processes). Multitasking is typically described in the context of a programming language. Multitasking languages, like Ada and Concurrent C, allow the programmer to specify separate threads of execution (tasks). Given these definitions, we can see that most forms of Unix provide (a) multiprogramming, and (b) time-sharing. Whether or not Unix supports multiprocessing is dependent upon your particular implementation (there of course versions that _do_ support multiple processors). Lastly, if you have a compiler for a multitasking language on your Unix system (we have both Concurrent C and Ada), then it supports multitasking. > Differrent tasks communicate with each >other without having to pass the information through the system. The >usual method here depends upon the mutual exclusion instructions and >general archetecture of the hardware in use. The Cray, for example, >provides shared memory access between CPUs, shared registers, and >hardware semaphores. To be sure, before the wide availability >of multiple CPU machines, the two terms were used interchangably. These are fine and very appropriate IPC mechanisms for shared-memory model operating systems. However, the general trend today is to move away from mutual exclusion mechanisms which are dependent on shared-memory, due to the rapidly increasing popularity of distributed systems. Regards, --Jerry -- Jerry Frain -- Systems Programmer Kansas State University Department of Computing & Info Sciences Internet : jxf@cis.ksu.edu Manhattan, Kansas UUCP : ...!rutgers!ksuvax1!jxf
crispin@csd.uwo.ca (Crispin Cowan) (01/13/91)
In article <11234@lanl.gov> jlg@lanl.gov (Jim Giles) writes: [people should use a reg. ex. library call instead of a utility] Why? How are we to invoke this function? Is it to be mandated that every application provide access to every available sys-call in the OS? Ugh, extreme software bloat; a different interface to grep for every different application. >Come to think of it - there are free public domain versions of the >utilities themselves available for MS-DOS users. Most MS-DOS users >don't bother to get copies because they aren't worth the disk space they >take up. Hardly. The tools being discussed are not general; they are SOFTWARE DEVELOPMENT tools, and anyone doing software development in DOS should have them on their DOS box. Accountants, on the otherhand, have no more need for software tools than I do of an accounting package. Crispin ----- Crispin Cowan, CS grad student, University of Western Ontario Work: MC28-C, x3342 crispin@csd.uwo.ca 890 Elias St., London, Ontario, N5W 3P2, ---> Support the GST: Canada's first fair tax <---
sef@kithrup.COM (Sean Eric Fagan) (01/13/91)
In article <SPOT.91Jan13002434@WOOZLE.GRAPHICS.CS.CMU.EDU> spot@CS.CMU.EDU (Scott Draves) writes: >If you are saying you would never write production code in csh using >all those utilities, then I agree. And so will (nearly?) everyone >else. That would be slow and gross. I wouldn't be so quick with that, if I were you. Large portions of C News (most of it?) are written as shell scripts, and C News is considerably faster than B News (where larger portions were written in C). Use the right tool for the job; with UNIX, there's a good chance that "the right tool" will involve a combination of an already supplied program, and some of your own code (be it ksh, sh, csh, C, f77, whatever). Also, this is no longer an architectural issue; comp.unix.misc is where it belongs. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
jlg@lanl.gov (Jim Giles) (01/14/91)
From article <1991Jan13.070039.12473@maverick.ksu.ksu.edu>, by jxf@altair.cis.ksu.edu (Jerry Frain): > [...] > The above definitions of the terms "multiprocessing," "multitasking," > and "time-sharing" are not consistent with current graduate-level > operating systems teachings. Nor are they consistent with most operating > system text-book definitions which I have seen. > > [... more stuff about the textbook definitions of the terms ...] This only goes to show that the people who _use_ the features and the people who train the implementors of the technology are using the terms differently. I deal mostly with the former while you obviously study the later. That kind of problem is pandemic in computing. Unfortunately, this sort of miscommunication leads to the situation that implementors want to support features that the users don't want or need while the users ask for features only to be told by the implementors that no one should want such things. Bad deal for everyone if you ask me. In any event, by _both_ of our definitions, the functionality offered by standard UNIX is not multitasking. J. Giles
jlg@lanl.gov (Jim Giles) (01/14/91)
From article <3130@canisius.UUCP>, by pavlov@canisius.UUCP (Greg Pavlov): >> [... spell, etc. vs. an integrated text editor ...] > Funny, but none of the MS-DOS machines we have here came with anything that > looks like what you describe. Didn't even come with anything as useless as > "ispell", in fact.... Thank goodness. The price of MS-DOS is much lower, in part, because of the lack of all this bundled software. Bundled software is _not_ free (as people keep telling me over email). I think it's much better to pay $60 for MS-DOS and $200 for good wordprocessing software than to pay $500 for UNIX and get vi, eqn, tbl, ..., and troff bundled in. The UNIX purchase still leaves me with the need to buy some good word processing software - none of the bundled stuff qualifies in this category. J. Giles
jxf@altair.cis.ksu.edu (Jerry Frain) (01/14/91)
jlg@lanl.gov (Jim Giles) writes: >From article <1991Jan13.070039.12473@maverick.ksu.ksu.edu>, by jxf@altair.cis.ksu.edu (Jerry Frain): [ definitions of OS terms and previous discussion deleted for brevity ] >This only goes to show that the people who _use_ the features and the >people who train the implementors of the technology are using the terms >differently. I deal mostly with the former while you obviously study >the later. That kind of problem is pandemic in computing. Truly. The recognition of this fact was the purpose of my article. >In any event, by _both_ of our definitions, the functionality offered >by standard UNIX is not multitasking. Again, this depends on your personal view "multitasking." By the definition I presented, multitasking is typically considered to be the feature of a language (Ada, Concurrent C, et. al.) which enables the programmer to establish separate threads (tasks) of execution. Taking this concept in the context of operating systems, it would follow that a "multitasking operating system" is one which may establish separate threads of execution, hence a multi-threaded OS. A popular example would be the MACH kernel. However, I do not believe that I have seen the term "multitasking" used this way. In any event, If you accept this view of "multitasking operating systems," then multitasking/multi-threaded versions of Unix _have_ been developed. If you choose not to accept this view, then I do not know how the term "multitasking" may be applied as a characteristic of operating systems. Regards, --Jerry -- Jerry Frain -- Systems Programmer Kansas State University Department of Computing & Info Sciences Internet : jxf@cis.ksu.edu Manhattan, Kansas UUCP : ...!rutgers!ksuvax1!jxf
greg@tcnz2.tcnz.co.nz (Greg Calkin) (01/14/91)
In article <11234@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <PPESSI.91Jan12222745@spiderman.hut.fi>, by ppessi@niksula.hut.fi (Pekka Pessi): >> [...] >> See regex(3). So you are not ignorant about Unix? > >No, I'm not. The existence of regex(3) _supports_ my prosition on grep. >That is: grep is a trivial tool that doesn't have any business being a >separate utility. In nearly every context where people recommend the >use of grep, regex() is a _better_ solution. There are many situations where a one off grep is incredibly useful, e.g searching 20 files for a string or 2 or stripping a few names out of a pipe where slapping together something to use the library would be ridiculously time consuming. I would imagine the first thing many people with only a library routine would do is cobble together something to use on pipes for ad hoc situations. The same holds true for many Unix utilities - their functions are trivial, they may be more effectively processed through libraries, etc, but they are incredibly USEFUL for ad hoc work, so their existence is justified. -- Greg Calkin, Systems Engineer and Dreamer (greg@tcnz.co.nz) Thomas Cook N.Z. Limited, PO Box 24, Auckland CPO, New Zealand, Ph (09)-793920 Disclaimer : Would you buy a used car from someone with these opinions ?
boyd@necisa.ho.necisa.oz.au (Boyd Roberts) (01/14/91)
In article <11255@lanl.gov> jlg@lanl.gov (Jim Giles) writes: |From article <EGDORF.91Jan12184630@zaphod.lanl.gov>, by egdorf@zaphod.lanl.gov (Skip Egdorf): | |> [...] The point of the Unix interface is (and was in 1975) that |> tools like grep are supposed to be seperate in order to avoid the "muscle" |> required when all those 'modes' are in EVERY program. | |The paradigm you are describing was recommended to as a way of perfomrming |what we would today call "rapid prototyping". It was a way of getting |a quick-and-dirty version of a new tool so you could play around with |the functionality before building a production quality version as a |single utility. | You wouldn't be a Emacs user would you now? The whole point of the tools approach is to do one thing well and _not_ to re-invent the wheel. How would you design a hammer? Would it start out like a hammer and the wind up being a Swiss Army Knife? Anyway, what's this got to do with computer architecture? I've set the followup to alt.religion.computers. Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
pavlov@canisius.UUCP (Greg Pavlov) (01/14/91)
In article <11255@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > > No. Piping things together is about the _least_ efficient way of > incorporating a functionality into a tool. Almost _anything_ is > an improvement. The additional muscle required to support UNIX > is due in large part to preferential use of this least efficient > technique. > The reality that we see at DOS-based sites (and we work with a lot of them) are the ubiquitous "bat files", which are built to perform almost any possible computer-based function one could possibly dream of. Misuse of tools and resources ? Yes. But people will tend to do things the easiest way that they can find. I find the "_least_efficient" piping much more efficient - people and resource-wise. > > The paradigm you are describing was recommended to as a way of perfomrming > what we would today call "rapid prototyping". It was a way of getting > a quick-and-dirty version of a new tool ..... ... and as a quick-and-dirty way of getting one-time jobs done. 5-15 minutes of people time to put together a shell script plus 1-10 minutes to execute it is a heck of a lot more cost-efficient from my budgeting point of view than 15 minutes to 1 day of programmer time plus 10 seconds to 2 minutes' computer execution time. And in the former case, the programming staff often isn't involved. pavlov@stewart.fstrf.org
mike (Michael Stefanik) (01/14/91)
In article <11123@lanl.gov> lanl.gov!jlg (Jim Giles) writes: >I disagree with the premise of the above. UNIX certainly has _more_ >tools, but the individual tools on MS-DOS tend to be more _powerful_. >The tools on UNIX tend to be clustered into a few categories: [ Continues on about how grep is trivial, UNIX tools are backwards, etc. ] Jim, if UNIX tools are *so* trivial, weak, mundane, and useless, why in the hell are people porting them to MS-DOS? Why is there a vi, emacs, grep, ls, chmod, etc? Heck, there is even a company (forget the name off the top of my head ... Mortice Kern something?) that's has a whole business devoted to providing a UNIX environment in DOS (at least tool-wise). This is a *lot* of energy thats being devoted to such trivial, weak, mundane, and useless programs. Oh, and I found it charming how you lumped compilers in with "mundane" tools. I don't know about you buddy, but that is how I earn my daily bread. >Part of the problem with UNIX is that it tends to be monolithic and >obscure. That's why so much is typically 'bundled' with it: there's >so many things needed just to get the system working and keep it >working. Let's not generalize now. Ever hear of Mach? I am a strong believer in the concept of "kernel as a message passer", but what has this got to to with DOS? Are you trying to say that DOS is less monolithic than UNIX? Give me a break. >Finally, you make the claim that UNIX tools are fun to use. Now, this >may be a personality thing. [ some tripe about how tools are like an adventure game ...] >try every utility you hear about in every manner you can think of until >something useful happens; then memorize what you did to get that useful >functionality - because it doesn't make any sense which things turn out >to be useful and which don't, it's just a matter of memorization. Is this how you went about learning UNIX? Ever hear of manual pages? Ever hear of apropos? There is a right tool for the job, and dammit, it isn't that hard to find it. >Note: in order to disarm the usual ad hominem flame from UNIX proponents >I must tell you that I have used UNIX every working day for about a decade >now. I know it reasonably well. So don't hit me with the usual "he's >obviously never used UNIX and doesn't know what he's talking about" >routine. It won't wash. In what context were you using UNIX? As an administrator? An applications programmer? A systems programmer? It seems as though you have completely misunderstood the *philosophy* behind UNIX, and yes, there certainly is one. UNIX is tools-oriented, which simply stated is: it is better to write one small program which does one thing *very* well, rather than one large program that does everything in a mediocre fashion. The DOS mentality does not encompass the tools philosophy because, by and large, it is unworkable on DOS. The philosophy has the concepts of multitasking (or whatever you prefer to call it) inherent in it's infra- structure; since DOS cannot multitask, and the best it can do is a enormously weak impersonation of anonymous pipes, DOS is not a good environment for the tools approach to problem solving. So, you see, grep is not meant to be a program used all by itself; it's use is for interaction with other tools. I find the pipe to be a simple and elegant solution to communication between processes; the anonymous pipe preserves the interchangability of tools, which is extremely important. In music, any one note is just a vibration at a certain frequency; when they are put *together*, they make a symphony. Don't expect to write symphonies with a single note ... it's not realistic. To be happy with the UNIX environment, you have to understand and accept it's philosophy of tools. I don't think you do. If UNIX truly makes you that uncomfortable, then why use it? Just so you understand where I'm coming from, for me, the implementation of a particular UNIX is far less important than the philosophy that it is built upon. Although various flavors of UNIX have good and bad in them, the idea which created them is a great one, and will continue on. -- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike -- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
mike (Michael Stefanik) (01/14/91)
In article <1991Jan12.233347.21388@cs.fau.edu> cs.fau.edu!longc (Courtney Long) writes: >I agree that MS-DOS is not the last word in PC operating systems. My >personal preference is OS/2, but I'm cautious in admitting that because >most people haven't used is and don't know much about it other than what >they've read. I don't agree that DOS has outlived it's usefulness or >that there is a readily available, affordable alternative which has a >respectable applications base. Some people say Windows. What about you? Some time ago, I read the book by the principal author of OS/2 and his explanation of the OS/2 religion. I found myself agreeing with many of the fundamental concepts which, of course, has it's origins in UNIX. My big problem with OS/2 is the following: 1. It continues a trend of proprietary operating systems, which I think should die a quick, terrible death. 2. It assumes it's users are stupid. Example: don't use lower case letters in filenames because users can't tell the difference. 3. It bends over backwards to be compatable with MS-DOS, and thus bloats itself unreasonably. 4. The kernel is monolithic and unsophisticated. The ideas held up to be "new and innovative" in OS/2 have been around for over 20 years. If the argument is that these ideas are new and innovative on machines that small, then think about QNX (circa 1986). 5. OS/2 is not multiuser. The current trend these days in the PC world is to say "well, yeah, I guess we do need multitasking, but what do we need multiuser capability for?" However, wouldn't it be alot easier to simply plug in a terminal than buy another machine or hook up an expensive network? As far as an alternative to DOS, there are inexpensive (performace vs. cost) flavors of UNIX. And since the larger applications like WordPerfect, Lotus 1-2-3, and dBase have migrated (or are in the process thereof), DOS users don't have to give up those programs they have grown to love. -- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike -- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
mike (Michael Stefanik) (01/14/91)
In article <1991Jan13.202218.3093@maverick.ksu.ksu.edu> altair.cis.ksu.edu!jxf (Jerry Frain) writes: >jlg@lanl.gov (Jim Giles) writes: >>From article <1991Jan13.070039.12473@maverick.ksu.ksu.edu>, by jxf@altair.cis.ksu.edu (Jerry Frain): > [ trivial squabble about various and sundry things by Jim Giles deleted ] > >Taking this concept in the context of operating systems, it would follow >that a "multitasking operating system" is one which may establish separate >threads of execution, hence a multi-threaded OS. A popular example would >be the MACH kernel. So, you are saying that for an operating system to be multitasking, it would have to have multiple threads of execution within the context of the kernel itself? I always took "multitasking" to mean that the kernel provided the capability of context switches between user processes. By your definitions, since a process cannot be switched out in kernel mode, this would mean that UNIX is not multitasking -- but it is! (He says stubbornly, stamping his foot on the ground ... :-) Oh, the joys of semantics and the common tongue ... -- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike -- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
herrickd@iccgcc.decnet.ab.com (daniel lance herrick) (01/14/91)
In article <SPOT.91Jan13005322@WOOZLE.GRAPHICS.CS.CMU.EDU>, spot@CS.CMU.EDU (Scott Draves) writes: > > I do *not* want to write a program every time I want to search a file > for a word. The stuff I write with shell (pipes and all those funny > utilities) are mostly one-shot hacks. Something I need done now and > probably not ever again in the future. So "rapid prototyping" is > *exactly* what I want. > > If you are saying you would never write production code in csh using > all those utilities, then I agree. And so will (nearly?) everyone > else. That would be slow and gross. > I was amazed when I first started poking around a UNIX system how much of the Operating System was written in sh (not csh) using those trivialities like grep. Maybe csh is slow and gross, but things like the disk sweeper that searches the disk for files that can be thrown away, the line printer interface program that takes a file and cats it with some other things to the printer device,..... They are production code. They are within the reach of the system manager to customize easily. They run at suitable performance levels. And they are all over the system! dan herrick herrickd@iccgcc.decnet.ab.com
hp@vmars.tuwien.ac.at (Peter Holzer) (01/15/91)
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: >In article <339@bria> mike@bria.UUCP (Michael Stefanik) writes: >| So was DOS in 1981. Because DOS is the status quo, that doesn't mean >| you accept it. The point is *move forward* - convenience has no place >| with progression. If MS-DOS users were representative of Mankind, >| we'd be living in caves waiting for it to lightning so we could get some >| fire ... > No, we'd have colonies on the moon and Mars. DOS users are the ones >who use the computer as a tool, not a way of life. They can edit some >files, produce a few spreadsheets, do their taxes, and maybe play a game DOS users also are the people who are constantly amazed what their computer can do if you have the right tools and know how to use them. Lots of them don't even know the /S option of xcopy. >or two. They go on to solve useful (read as money making) problems with >their little computers, and don't think about upgrading until they have >a problem they can't solve with the existing resources. They don't think about upgrading? A DOS-User: "Now I have MS-DOS 5.0" Me: "Interesting. What has been improved since 4.0?" DOS-User: "I don't know, but it is 5.0!" Conversations like the above are constantly going on. DOS-Users constantly want the newest version of each program they use (even if they use PC-Tools only to format their floppies). Admittedly I am talking about Users who don't buy their programs, but the story stays the same. > The people who are content with DOS don't see as anything but a way to >do a job. They solve problems with existing resources instead of >worrying about new ones. They are the people who put Skylab up several >decades ago. The scientists who now say that we can't put up a space >station because it will need constant repairs don't use DOS. They never >get anything done because they are always sharpening their tools. >| technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly >| found to be saying things like "Well, it works on my DOS machine ..." > As opposed to people who write income tax programs in Emacs macros, >and keep saying things like "I don't need support, I have the source. >Given a few days I can add the feature." More often DOS-Programmers (not general Users) say: "I don't have support, I just have to wait for the next release or find someone to write a program that does this." Even if you have support, nobody is going to add those features that aren't there over the phone. I am living in a dorm and of the 15 people owning a computer 3 are CS students (including me). The other people are constantly asking me to fix bugs in, add features to, etc. DOS-programs, what I just can't do without source (Ok, I can patch checks for DOS version or computer type or some hard-coded filenames, but anything beyond that is damned hard with only an EXE-File and sdb). If I had the source, however I could fix it (The only question is if the problem is serious enough to dig into 11MB source of emacs :-) > DOS doesn't fit my usage, but for typical business applications it >works just fine. Agreed. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |
sysmgr@KING.ENG.UMD.EDU (Doug Mohney) (01/15/91)
In article <1991Jan12.090835.3783@hq.demos.su>, avg@hq.demos.su (Vadim Antonov) writes: > >Vadim Antonov >DEMOS, Moscow, USSR > >PS. Being a general in F-19 simulator I cannot say I don't like MS-DOS :-) > I like this toybox, babe! I thought F-19 was on the restricted list of software? How'd someone in Moscow get it? ..... :-) Doug Mohney, Operations Manager, CAD Lab/ME, Univ. of Maryland College Park * Ray Kaplan was right *
chip@tct.uucp (Chip Salzenberg) (01/16/91)
According to jlg@lanl.gov (Jim Giles): >Piping things together is about the _least_ efficient way of >incorporating a functionality into a tool. Don't confuse the UNIX pipe service with its implementation. Poor pipe implememtations abound. So do poor implementations of every OS feature ever devised. That fact proves nothing. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "If Usenet exists, then what is its mailing address?" -- me "c/o The Daily Planet, Metropolis." -- Jeff Daiell
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (01/16/91)
In article <1991Jan13.085556.1332@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: | I wouldn't be so quick with that, if I were you. Large portions of C News | (most of it?) are written as shell scripts, and C News is considerably | faster than B News (where larger portions were written in C). This brings up an optimizing problem which occurs widely. If someone (experienced) is going to optimize a program, at some point they will usually profile it. At the least it will get an eyeball analysis to see where the CPU is likely to spend time. However, people often tend to think of the shell scripts as "slow" to the exclusion of measurement. Many scripts have been rewritten as C programs, possibly with grep functionality folded in via a regcmp or similar library, *without profileing*. Since it is easy to determine the shell overhead, either by looking at an acocunting record or using time (time sh script args), it is easy to determine if any appreciable portion of the resources are in the shell. My experience is that normally there is 1-5% CPU in the shell, leaving very little room for actual improvement. Ditto replacing grep. Rarely does a program perform a grep function significantly faster than grep itself. This is harder to profile, since I have no way of predicting how much I will gain with a dedicated program. I realize that most readers of this group know this, but the intemperate remarks about not writing production code in shell brought this on. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) VMS is a text-only adventure game. If you win you can use unix.
phil@brahms.amd.com (Phil Ngai) (01/16/91)
In article <11143@lanl.gov> jlg@lanl.gov (Jim Giles) writes: |I've heard that there's a new UNIX for PC's which just contains a |pcc-type compiler, a bourne shell clone, a half dozen utilities, and |UNIX itself of course - for $99. For this kind of price, I may buy |a copy, just to play with. This product is definitely worth what you pay for it, and not a penny more. All code is limited to 64 Kbytes. A toy, does even less than Minix. Unix continues to be much, much more expensive than DOS. -- militia: 1.a. A citizen army, as distinct from a body of professional soldiers. b. The armed citzenry, as distinct from the regular army.
dana@locus.com (Dana H. Myers) (01/16/91)
In article <11123@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >UNIX certainly has _more_ >tools, but the individual tools on MS-DOS tend to be more _powerful_. An assertion which can not be supported, but Jim tries anyway. >The tools on UNIX tend to be clustered into a few categories: > > 1) Trivial. These tools ('grep' is an example) perform functions > that are so simple that there is hardly an excuse for separate > tools to do them. I do a 'grep' perhaps once a month (and then, > only because 'ls' doesn't have a filter for file ownership in it). > In view of this fact, 'grep' also falls into the next category. Ok, so grep is trivial. I use it maybe 100 times as often as you do. Is it possible you aren't a typical Unix user? I guess 'more' or 'pg' are really trivial, too. What are you suggesting; one big tool, a massive, difficult to maintain behemoth, that implements all the functions which are currently broken into discrete, individually maintainable modules? Imagine the documentation on the 'Giles Shell'; goodness, it would be like taking 10 or 15 or lesser man pages and making them into one big page.... hmmm... is this supposed to be progress? > 2) Useless. These tools (and there are a lot of them) don't do > anything I ever need to do. A prime example is 'spell'. If > I _knew_ how to spell a word, I wouldn't have mispelled it. If you _knew_ how to use Unix, you wouldn't be saying all this absurdity. > My spelling checker on MS-DOS suggests alternatives so that > I can correct my error. It also has a built-in thesaurus, so > that I can find words (correctly spelled) that are better that > what I tried originally. Spelling checkers also fit into the > next category. There is absolutely nothing preventing anyone from providing an enhanced spelling checker for Unix. Your DOS spelling checker probably did not come with DOS; instead, it is a commercial product you bought (or maybe made a copy of) or a shareware product. > 4) Muscle. Since UNIX _requires_ a more powerful hardware base to > even get it running _at_all_, there are usually some things that > UNIX throws in that something like an XT _can't_ do. To be sure, > this is a bonus for UNIX. But, it's also costly. Things in this > category are exemplified by TCP/IP. Of course, TCP/IP is a DARPA > standard and is available on many systems - including MS-DOS. But, > on MS-DOS, you only pay for the software/hardware for TCP/IP if > you really _need_ the functionality. What are you saying? Most users don't by XT clones anymore. 286 and 386 machines are quite popular, even to DOS users. Certainly most Unix ports for the 386 platforms run nicely in what many DOS users consider a typical configuration for running DOS.... >Note: in order to disarm the usual ad hominem flame from UNIX proponents >I must tell you that I have used UNIX every working day for about a decade >now. I know it reasonably well. So don't hit me with the usual "he's >obviously never used UNIX and doesn't know what he's talking about" >routine. It won't wash. It would wash better than most of your "logical" arguments. I wonder what you call 'using Unix'. I won't say that you 'obviously never used UNIX' but I will say that you don't appear to really know what you are talking about. -- * Dana H. Myers KK6JQ | Views expressed here are * * (213) 337-5136 | mine and do not necessarily * * dana@locus.com | reflect those of my employer *
phil@brahms.amd.com (Phil Ngai) (01/17/91)
I don't know what this is doing in comp.arch, but what the heck. Is
there anything available under "unix" comparable to Microsoft
Powerpoint for Windows, for a comparable price?
(I've used unix since 1981, PCs since 1988. Used to run a few systems.)
--
The Am386s are coming!sysmgr@KING.ENG.UMD.EDU (Doug Mohney) (01/17/91)
In article <1991Jan16.183130.12291@amd.com>, phil@brahms.amd.com (Phil Ngai) writes: >-- > The Am386s are coming! Ok. When? Where? What machines? Can you really call it a '386 without legal trouble? ;-) Doug Mohney, Operations Manager, CAD Lab/ME, Univ. of Maryland College Park * Ray Kaplan was right *
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (01/17/91)
In <3111@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: >The people who are content with DOS don't see as anything but a way to >do a job. They solve problems with existing resources instead of >worrying about new ones. There's a little bit of irony here, though. Cirrus Logic, the company where I work, uses Sun workstations to design chips...and these chips are used as disk controllers and VGA display controllers in MS-DOS machines, which are then used by people who would rather solve problems using MS-DOS than switch to Suns. Small world! :-) -- History never | Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> becomes obsolete. | UUCP: oliveb!cirrusl!dhesi
phil@brahms.amd.com (Phil Ngai) (01/17/91)
In article <00942CCE.68B737A0@KING.ENG.UMD.EDU> sysmgr@KING.ENG.UMD.EDU (Doug Mohney) writes: |> The Am386s are coming! | |Ok. When? Where? What machines? I suspect that I wouldn't be able to answer your questions without disclosing proprietary information. Consider yourself teased. :-) |Can you really call it a '386 without legal trouble? ;-) I'm not a spokesman for the company but my understanding is that Intel's request for a temporary injunction was denied, however, the matter has not come to trial so we are currently not prohibited from using 386 but the judge could decide against us after hearing both sides' arguments. I guess people who want to file as "a friend of the court" could also get their voice heard... -- The Am386s are coming!
wg@opal.cs.tu-berlin.de (Wolfgang Grieskamp) (01/17/91)
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: > My experience is that normally there is 1-5% CPU in the shell, leaving >very little room for actual improvement. This is nosense, unless you measured process spawns and other system services invoced by the shell. Did you? -- Wolfgang Grieskamp wg@opal.cs.tu-berlin.de tub!tubopal!wg wg%opal@DB0TUI11.BITNET
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (01/17/91)
In article <2472@opal.cs.tu-berlin.de> wg@opal.cs.tu-berlin.de writes: | davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: | | > My experience is that normally there is 1-5% CPU in the shell, leaving | >very little room for actual improvement. | | This is nosense, unless you measured process spawns and other system | services invoced by the shell. Did you? I pulled a section of the accounting file, and added up all the user and system cpu for all processes including the sh process. I called this the total. I then added the user and system cpu for the sh and called that the shell cpu. For three such jobs selected at random from scripts run from cron the shell cpu was from 1-5% of the total. Since then I did this for a few interractive shell scripts, and saw all numbers less than 10% for cpu used in shell. I'm not sure I undestand your question. I'm making a simple measurement, using the most easily available numbers. You are free to measure this any way you want and draw any conclusions you want. Obviously you can measure anything you want based on the cpu use of the processes started by the shell. In all cases the shell cpu was 1-3 sec, which gives some set of bounds on how much you could save by replacing the shell with a program. Pipe time is harder to eliminate, since each pipe means replacing two complete programs with one merged program. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) A system without MS-DOS compatibility is like a rock without mayonnaise
peterb@ptlcamb.UUCP (01/19/91)
>From article <PPESSI.91Jan12222745@spiderman.hut.fi>, by ppessi@niksula.hut.fi (Pekka Pessi): >> [...] >> See regex(3). So you are not ignorant about Unix? > >No, I'm not. The existence of regex(3) _supports_ my prosition on grep. >That is: grep is a trivial tool that doesn't have any business being a >separate utility. In nearly every context where people recommend the >use of grep, regex() is a _better_ solution. For one thing, it saves >the overhead of using pipes - passing the strings as procedure arguments >is a lot more efficient (in this case, the pipe overhead is probably >_bigger_ than the execution time of the whole pattern search). Or, is Right, a pipe only costs for the amount of data being passed through it. I sure hope you don't think to cat the file and pipe the output into grep like this: cat file | grep string If you are, get a clue. You can redirect input into grep which doesn;t use a pipe, Or you can even pass the file name to grep. Or even file names to grep. RTFM first. Flame second, Duck third. -- Peter Barada / ...!{harvard|bu.edu|think|uunet}!ima!ptlcamb!peterb Phoenix Technologies Ltd. / Peripherals Group / 617-551-5000 (USA) Clone the Bone!!! / Opinions are mine; Phoenix cloned them from me...