Path: utzoo!bnr-vpa!bnr-fos!bnr-public!schow From: schow@bnr-public.uucp (Stanley Chow) Newsgroups: comp.sys.amiga.tech Subject: Why do you need metaphor? (Re: What should be learned from Unix Summary: Use the real thing instead Message-ID: <1417@bnr-fos.UUCP> Date: 10 Aug 89 17:11:36 GMT References: <7570@cbmvax.UUCP> <440@xdos.UUCP> Sender: news@bnr-fos.UUCP Reply-To: schow%BNR.CA.bitnet@relay.cs.net (Stanley Chow) Organization: Bell-Northern Research, Ottawa, Canada Lines: 74 Followup-To: Keywords: In article <440@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: > [discussion of how ps works on Unix.] In almost >all other ways, Unix very consistently treats everything like a file. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It is not clear (at least to me) that this is a good thing. Why do you want everything to look like a file? A file has a very limiting structure. Why would you want to force complicated data structure into a file? I think appropiate use of linked data structure is entirely correct. > >And even with ps, Unix is nominally within the boundaries of that >consistency, for it reads a symbol table from a file (/unix or /vmunix) >to find the offsets in files of what it wants (/dev/mem and /dev/kmem). >There is no poking directly around in memory. I agree that this is a >grey area and that it is inelegant on an absolute scale, but it is >relatively elegant compared with the AmigaDOS method of directly accessing >device/task data structures in your address space without any benefit >of any consistency metaphor. ^^^^^^^^ This is perhaps the key. I look on metaphor as an aid to learning something. Once I know the subject, *it* becomes the metaphor for learning something else. Why is it good to tie everything forever to a bad metaphor (files)? > >Both Unix and AmigaDOS would benefit from extensions that put the >list of tasks (apparently) into a directory where they could be listed >(and perhaps deleted, etc) using standard utilities. Unlike AmigaDOS, this >ability *is* about to appear in a mainstream Unix: V5.4. Again, my question: why should deleting a task be the same as deleting an entry from a directory? The code gets more complicated since the delete command now must know to call the delete-task routine. The user still has to know that a task is involved so there is no hope of 'undo'. Perhaps what you want is a 'consistant' interface where command names and syntax for different commands follow a consistant convention. This is very differnt from having the 'same' command do it in the same way. > [...] But the lesson from history (of Unix) that >is most important, yet most widely disregarded, is that it *is* consistent, >and the user *can* do all that stuff from the command line, and that >all those utilities *do* behave well e.g. with piped input/output. Not meaning to start another Unix flame war, but I think you mean that *you* have found *a set* of utilities that fit well together with *your* style of computer usage. The default set(s) of utilities from the variouse vendors are by no means 'consistant'. Including all the freebies and bought S/W in any description of 'consistant' is at best inconsistant. > >Unix has, compared with everything but the Smalltalk kernel, the greatest >degree of consistency of application of its underlying metaphor, and that >*inherently* makes it more powerful *overall* than any system with a >lesser consistency. Don't even bother to criticize it until you've got >a system that beats it in this respect. If you can set up message passing >ports between tasks purely via the CLI in AmigaDOS, and if all standard >utilities support this, then you've got something that might start making >Unix look like a toy. But meanwhile, pretending that e.g. AmigaDos is >*already* far better than Unix simply prevents learning from history. > I know almost nothing about any Unix-type kernal, so I cannot comment on the kernal internals. I do, however have strong views about the consistancy as seen by the *user*. In my view, Mac is more consistant than Amiga and Amiga is more consistant than Unix. Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow (613) 763-2831 ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public Me? Represent other people? Don't make them laugh so hard.