schow@bnr-public.uucp (Stanley Chow) (02/16/89)
Hit 'n' now to skip another LONG Unix-is-good; no-it-it-not battle. Willaim B. Pace claims in <1170@spectra.COM> that AOS code is much cleaner than Unix code. Karl lehenbauer replies in <31010ficc.uu.net> saying so what? Given that Unix runs on just about every machine ever made, and a large third party software market, Karl continues: > >The writing is on the wall, gentlepeople. You can sit in your corner with >technology that's incompatible from what almost everyone else has, and >maybe do wonderful things. Your technology may even be superior in some >ways. But you take a big hit in that there aren't a lot of other people >generating software for your machine -- you'll have to do a lot of it >yourselves, meaning a lot of stuff you'd like won't get written, plus >economies of scale may be such that a database package costs $100K instead >of $1K. Savvy customers, especially those burned by the high cost of >converting software from one incompatible software and hardware architecture >to another are find, are going to Unix in droves, and while everyone has >their pet peeves about Unix (including me), I think it is a reasonable >platform for future development and do not see any architecture-independent >operating system capable of challenging it at this time. This is one of the few times (if not the first) that I have agreed with the Unix proponents. The reality of economics is such that no operating system will chanllenge Unix for sometime to come. However, are all you other Unix proponents out there going to let Karl get away with putting Unix into the same catagory with OS/360, MS/DOS? I would have thought that a major insult! (Please add as many smilies as you like). **** on the one hand **** There are many points in favor of Unix: - Portability (of people, not code) - Connectivity - Flexibility - Standard By people portability, I mean you can take some random computer science grad and expect reasonable productive quickly. This is a great asset for large companies. By connectivity, I mean things like rlogin, TCP, etc. I am composing this note on the HP 9000 on my desk rlogin to a Sun connected via ethernet. The seamless connection and convienent file transfer that can be achiverd is very impressive (and useful). By flexibility, I mean that people can take any device and hook it up, write a couple of filter and do everything with pipes. You can do anything you want. By standard, I mean that most Unix boxes look pretty much the same, the commands work pretty much the same, etc. (This is of course the key factor allowing people portability and also accounts for the successes). *** And on the other hand **** There are lots of other points againist Unix: - Non-protable code. I know the truism "Unix & C are the most portable system & language". I have no knowledge about the portabiity of Unix itself (the many versions of it) but the horror stories I have heard (and read about in the net) makes me think twice. (I am not saying it is impossible to produce an implementation of Unix that is nicely protable or that all C programs are inherantly non-portable, just that current practice does not). - The worst ergonometric design for a human interface I have ever seen. How many horror stories have you heard about people wiping out systems at a single keystrok? How many of you have tried to explain to non-hackers how (and why) to pipe things through filters? - No concept of full screen graphics. Unix seems to be still firmly tied to the day of 75 baud teletypes. (I know about X-windows and such, in fact I am using it right now). All the commands seem to be designed to minimize typing or half-duplex echo time. - I am sitting here typing this note in "vi" - the so called full screen editior of choice (see the man pages). I have used editors a decade ago that were better. (I use Micro-Emacs at home on my Amiga, but even that still reeks of teletype). For text editing, I will take a locally attached IBM 3278-4 anytime (since I can then use XEDIT and REXX). - Totally incomprehensiable magical incantations to do almost anything. Yes, I know, the Unix way is to set up aliases. If that doesn't work, write a shell script. If that doesn't work, write a filter. When all else fail, write your own shell. Consider the poor J. Doe user who forgets the location of a file (i.e., the parent directory). Do you really expect the non-hacker to connect filters and pipes ending up at grep with a bunch of funny characters? By their every nature, filters are most useful for people who understand how the system works. Add in the fact of three standard shells, the secretaries are going to be lost. - You have to know everything to do anything. This used to be the complaint people leveled at OS/360 since for everything you want to do, IBM provides about a zillion options on how to do it. Well, I think Unix has OS/360 beat in spades. To set up my nice HP-Sun connection, (after the physical connection is done and FTP, TELNET already work), I had to look at over a hundred pages of documentation: set, setenv, env, stty, tset, csh, termcap, and many other truely strange and wonderful beasts. Just so that I can get the right size window? How would you explain to a typist that you want to set some environment variables? Or that there are two kinds of variables set in three different ways depending on the shell? What about the escape characters that you sometimes need? How about resize not working as a command but has to be aliased so that the shell can do the setting of the variables? Should I go on? - Totally non-standard ways of doing things. I counted roughly a dozen ways to achive reverse vider on a xterm console. There are probable just as many ways to specify any other option. Guess how many programs handle all possible combinations of parameters and options? How many manuals assume all parameters are at the default settings? How many versions and clones of Unix are there? Are there any two that are 100% compatible (in the 100% PC clone sense)? How many levels of #ifdef is it for 'rn' to achive portibility? - Unix is a pig for CPU cycles and memory. How many workstation do you know that will support a single live user on less than a fast 68020 with 4 Meg of real memory and 50 meg of harddisk? I have an Amiga at home with a 7 MHz plain 68K with 2 meg of memory and a ST-225 that out performs many workstations for supporting a couple of edit sessions, a compile or two and a game while you are waiting (plus the half dozen obligatory monitoring gadgets). To sum it up, Unix achived a major breakthrough in creation of "deparmental computers". It will continue to succeed in the technical market place. However, there is a lot of evolving to be done if Unix is ever going to make it in the office market (competing with fast MS/DOC machines). Technological baggage from a by-gone era is not a good reason for poor human interface. (The observant readers will note that I did not discuss the internals of Unix. This is because it does not mattter in the real world. People care about functionality, researchers care about algorithms, only implemenators care about implementation). Stanley Chow ..!utgpu!bnr-vpa!bnr-fos!show%bnr-public (613) 763-2831 Discalimer: Since my employer is putting in Unix workstations by the hundreds, they would probably not listen to me even if they knew I had any opinion.
bnick@aucis.UUCP (Bill Nickless) (02/17/89)
In article <285@bnr-fos.UUCP>, schow@bnr-public.uucp (Stanley Chow) writes: > There are lots of other points againist Unix: > > - Non-portable code. I know the truism "Unix & C are the most > portable system & language". I have no knowledge about the portabiity > of Unix itself (the many versions of it) but the horror stories I > have heard (and read about in the net) makes me think twice. > (I am not saying it is impossible to produce an implementation of > Unix that is nicely protable or that all C programs are inherantly > non-portable, just that current practice does not). At least with UNIX you have a CHANCE at writing semi-portable code! The netnews software, for instance, written on one machine is installable on the many variants of machines, even running *nix's from different vendors. For all the "horror stories" you hear of, there are many more instances of a clean, well done operation. How many people complain and post to the net because their system came up right on the second (or first?) try? Besides, what might constitute a "horror story" for one person might be a five minute "oh, yeah, right" for someone else--depending on what the first impressions were (C compiler bug vs. renamed header file) and on what you try to do to fix it. -- Bill Nickless Andrews University Computer Science Department ...!sharkey!aucis!bnick or bnick@aucis.UUCP Unix Support Group "Help! I'm locked up in this .signature factory!"
jack@cwi.nl (Jack Jansen) (02/17/89)
Although I come to hate unix more and more (current unices, that is, let nobody insult V7:-), there are a few things in Stanley's posting that I would like to comment on: In article <285@bnr-fos.UUCP> schow@bnr-public.UUCP (Stanley Chow) writes: > - Non-protable code. I know the truism "Unix & C are the most > portable system & language". I have no knowledge about the portabiity > of Unix itself (the many versions of it) but the horror stories I > have heard (and read about in the net) makes me think twice. > (I am not saying it is impossible to produce an implementation of > Unix that is nicely protable or that all C programs are inherantly > non-portable, just that current practice does not). The real-world issue is not portability of the kernel but portability of user programs. Unix is still the only OS in the world that will allow *reasonably* easy porting of *many* programs to *some* wildly different machines. Note the emphasised words: porting is not trivial, it will not work for all programs, and not for all machines. Compare porting a program between Amdahl UTS, Dec VMS and XENIX to porting it between OS/360, VMS and MS/DOS. > > - The worst ergonometric design for a human interface I have ever > seen. Absolutely true. Playing devils advocate again, though: have you ever worked on OS/360? NOS/BE? Or, more in the same class of OS'es as unix, VMS or MS/DOS? The *only* reason novices can manage to learn MS/DOS is because there are only 5 commands to learn. MSDOS < UNIX <<<<<<< Macintosh. -- -- Fight war, not wars | Jack Jansen, jack@cwi.nl Destroy power, not people! -- Crass | (or mcvax!jack)
pwd@mdt.UUCP (Phil Dalrymple) (02/17/89)
In article <285@bnr-fos.UUCP>, schow@bnr-public.uucp (Stanley Chow) writes: > There are lots of other points againist Unix: > > - Non-portable code. I know the truism "Unix & C are the most > portable system & language". I have no knowledge about the portabiity > of Unix itself (the many versions of it) but the horror stories I > have heard (and read about in the net) makes me think twice. > (I am not saying it is impossible to produce an implementation of > Unix that is nicely protable or that all C programs are inherantly > non-portable, just that current practice does not). In fact we have about 250K lines of code that runs under Unix on five differnet system (both SYSV and 4.2) and the ONLY changes that need to be made (including ifdefs) are for byte order and the handling of the rs232 handshake lines for a very non standard device that we must connect to. Most ot those horror stories that I have traced down are cases of 1) Hardware (like our rs232 or byte order) but worst. 2) The people do not know what they are doing. 3) An attemp is being made to port to another OS as well as Unix. Item 3 above is the one I notice most often but I can not explan it. It may be that the fact that a large amount of changes are needed to port the code to say VMS or MS/DOS makes those doing the ports to a number of unix systems accecpt a lower standard of portabilty (sp?) in the code. -- Philip W. Dalrymple III mdt!pwd 404/587-2653
new@udel.EDU (Darren New) (02/18/89)
In article <4122@mdt.UUCP> you write: >In article <285@bnr-fos.UUCP>, schow@bnr-public.uucp (Stanley Chow) writes: >Most ot those horror stories that I have traced down are cases of >3) An attemp is being made to port to another OS as well as Unix. >Item 3 above is the one I notice most often but I can not explan it. >It may be that the fact that a large amount of changes are needed to port >the code to say VMS or MS/DOS makes those doing the ports to a number of >unix systems accecpt a lower standard of portabilty (sp?) in the code. >-- >Philip W. Dalrymple III >mdt!pwd >404/587-2653 Speaking as one who managed a project to make all the company's code run without change on MS-DOS, UNIX, AOS, and maybe others later, I think I can shed some light on this. As background, we had a number of programs for many clients that were very similar. The home office people wanted to run the programs on minis or mainframes, while the agents in the field had to run these on PCs. Nothing especially hardware-esk was going on (these were insurance programs and such) but the users were nieve about computers and had to be menued to death. Therefore, we needed help files that would rename keys to match what the user had, programs to present menus of other programs to run, backups and restores, sohpisticated form entry stuff, strange file formats, background printing, access through networks, ability to run from either floppies or fixed disks without recompiling/linkng/etc, and so on. Basically, lots of stuff that would be easier to do if only one operating system was involved. The solution I used (which worked quite well, if I do say so myself) was to identify the appropriate level of abstraction for the operations to be performed. For example, colors on the screen were not "red", "green" and so on, but rather "error", "field", "prompt", and so on. Files were either text or binary (unix-style streams), and never the twain shall meet, which allowed transparent handling of newline garbage and so on. Screen calls were not things like "what string do I send to position the cursor" but rather "position the cursor". Directory operations did not read the directory files one at a time but rather returned a list of all files matching a certain file type (spooled output, data file, rate tables, configuration file, ...). Literal file names never showed up in the code, nor did any information about where files were stored ever need to be known by the application. Not only did this allow for nice portability, but it allowed backup and installation programs to use the same configuration files that the application's libraries used to find, for example, where on the hard drive each floppy program file belonged; and it was guaranteed to be correct (previously a big problem there). Anyway, I think the problem of porting to other OSes is due to not abstracting to the proper level. I have had success with writing a "portability library" that defines what I want to do in terms of what the OS provides. Had parsing information (like '/' separates directory components) shown up in the application code, moving things to VMS would have been a nightmare, because VMS has a totally different file naming convention. As it was, redoing most of the code for directory and file manipulations allowed things like the interactive installer and the backup/restore programs to run after simple recompilations. I would suspect that most of the "horror stories" about moving to other OSes were due to the original code never being segmented into OS-dependent and OS-independent portions because the author never considered moving it to a new OS. On the other hand, since the above project, I have never failed to segment a program into such portions, and I have never had problems moving my own programs to other OSes with relatively trivial effort. - Darren New
edvax@skybridge.CWRU.EDU (Ed Reznichenko) (02/18/89)
In article <285@bnr-fos.UUCP> schow@bnr-public.UUCP (Stanley Chow) writes: > > Hit 'n' now to skip another LONG Unix-is-good; no-it-it-not battle. > > >Willaim B. Pace claims in <1170@spectra.COM> that AOS code is much >cleaner than Unix code. > >Karl lehenbauer replies in <31010ficc.uu.net> saying so what? Given > > - No concept of full screen graphics. Unix seems to be still firmly > tied to the day of 75 baud teletypes. (I know about X-windows > and such, in fact I am using it right now). All the commands > seem to be designed to minimize typing or half-duplex echo time. > > - I am sitting here typing this note in "vi" - the so called > full screen editior of choice (see the man pages). I have used > editors a decade ago that were better. (I use Micro-Emacs at home > on my Amiga, but even that still reeks of teletype). > For text editing, I will take a locally attached IBM 3278-4 anytime > (since I can then use XEDIT and REXX). ------------------------------------ This poster is asking for it. <BEGIN World War III> <ICBM's launched> Are you totally lobotomized? Why do you post this crap? Xedit makes edlin look heavensent. XEDIT? No concept of scrolling. To do simple things you have to go to the margin and type tons of stupid commands. What OS do you like? DOS/VSE? VM/CMS? IBM writing an OS that's useable for anything but controlling my bank account, surely you jest? I don't want to see that ugly thing again in my life or I will seriously start considering murder. What? you don't like grep? Do regexp like ^[A-Z0-9]\/ scare you? If so why don't you tune in to another channel and program in VS COBOL or whatever that crap is called these days. Can you even imagine INTERACTIVE operating systems? Do you miss batch cards? Thank you for starting a religious war. <END World War III> <Peace treaty signed> edvax@skybridge.scl.cwru.edu { "follow-ups" > /dev/null (void)unlink("/dev/null"); halt(); } Time travel is so dangerous it makes H-bombs seem like perfectly safe gifts for children and imbeciles.
R_Tim_Coslet@cup.portal.com (02/19/89)
I thought this was comp/os/misc not comp/os/unix_is_the_best_OS_ever... :-)
I am really getting tired of reading these STUPID arguments!
If I wanted to read about the "wonders" of UNIX I would be reading
comp/os/unix
R. Tim Coslet
Usenet: R_Tim_Coslet@cup.portal.com
BIX: r.tim_coslet martillo@cpoint.UUCP (Joacim Martillo) (02/21/89)
In article <497@cwjcc.CWRU.Edu> edvax@skybridge.UUCP (Ed Reznichenko) writes: :In article <285@bnr-fos.UUCP> schow@bnr-public.UUCP (Stanley Chow) writes: ::Willaim B. Pace claims in <1170@spectra.COM> that AOS code is much ::cleaner than Unix code. ::Karl lehenbauer replies in <31010ficc.uu.net: saying so what? Given :: - No concept of full screen graphics. Unix seems to be still firmly :: tied to the day of 75 baud teletypes. (I know about X-windows :: and such, in fact I am using it right now). All the commands :: seem to be designed to minimize typing or half-duplex echo time. :: - I am sitting here typing this note in "vi" - the so called :: full screen editior of choice (see the man pages). I have used :: editors a decade ago that were better. (I use Micro-Emacs at home :: on my Amiga, but even that still reeks of teletype). :: For text editing, I will take a locally attached IBM 3278-4 anytime :: (since I can then use XEDIT and REXX). :------------------------------------ :This poster is asking for it. :<BEGIN World War III: <ICBM's launched: :Are you totally lobotomized? Why do you post this crap? Xedit makes :edlin look heavensent. XEDIT? No concept of scrolling. To do simple :things you have to go to the margin and type tons of stupid commands. :What OS do you like? DOS/VSE? VM/CMS? IBM writing an OS that's useable :for anything but controlling my bank account, surely you jest? I don't :want to see that ugly thing again in my life or I will seriously start :considering murder. What? you don't like grep? Do regexp like ^[A-Z0-9]\/ :scare you? If so why don't you tune in to another channel and program :in VS COBOL or whatever that crap is called these days. Can you even :imagine INTERACTIVE operating systems? Do you miss batch cards? :Thank you for starting a religious war. :<END World War III: <Peace treaty signed: :edvax@skybridge.scl.cwru.edu :{ :"follow-ups" : /dev/null :(void)unlink("/dev/null"); :halt(); :} :Time travel is so dangerous it makes H-bombs seem like perfectly :safe gifts for children and imbeciles. Personally, I could vomit when I see someone arguing that Unix sucks because he or she does not like the command interpreter which in a correctly designed operating system is not part of the operating system and should be easily replaceable. Now, I see people totally devoid of any understanding of OS theory arguing Unix is bad because Unix does not know anything about screen graphics !!!???!!! Give me one good reason why an operating system should know anything about screen graphics! Clearly a lot of people known nothing about how to partition problems.
schow@bnr-public.uucp (Stanley Chow) (02/21/89)
In my original article <2850@bnr-fos.UUCP>, I complained about several problems of Unix. Several people have commented on my point on Portability and only one person commented on Ugly User Interface. Does this mean all my other points have universal agreement? (I know, I am asking for it, but as long as I am trying to "stimulate" discussion -- :-) :-) The first problem I listed was Portability: > > - Non-portable code. I know the truism "Unix & C are the most > portable system & language". I have no knowledge about the portabiity > of Unix itself (the many versions of it) but the horror stories I > have heard (and read about in the net) makes me think twice. > (I am not saying it is impossible to produce an implementation of > Unix that is nicely protable or that all C programs are inherantly > non-portable, just that current practice does not). In article <140@aucis.UUCP> bnick@aucis.UUCP (Bill Nickless) writes: > > At least with UNIX you have a CHANCE at writing semi-portable code! The > netnews software, for instance, written on one machine is installable on > the many variants of machines, even running *nix's from different vendors. [Bill then talks about the silent success stories and different concepts of what a horror is.] I am really trying to point out that yes, Unix (& C) does allow people to write code that is very portable, but it does not follow that all C programs written for Unix are automatically portable. As other people point out (see replies below), writing portable Unix/C program takes major effort. To take your example, I am told 'rn' has #ifdef nested up to 6 deep to allow for the difference of systems and machines. Given the same amount of effort, there are langauges like Fortran (oh no, did I just say another bad word?) that can be more portable, even if the application is restricted to a narrow domain. In article <4122@mdt.UUCP> pwd@mdt.UUCP (Phil Dalrymple) writes: > > In fact we have about 250K lines of code that runs under Unix on five > differnet system (both SYSV and 4.2) and the ONLY changes that need to be > made (including ifdefs) are for byte order and the handling of the rs232 > handshake lines for a very non standard device that we must connect to. > Most ot those horror stories that I have traced down are cases of > > 1) Hardware (like our rs232 or byte order) but worst. > > 2) The people do not know what they are doing. > > 3) An attemp is being made to port to another OS as well as Unix. > > Item 3 above is the one I notice most often but I can not explan it. > It may be that the fact that a large amount of changes are needed to port > the code to say VMS or MS/DOS makes those doing the ports to a number of > unix systems accecpt a lower standard of portabilty (sp?) in the code. > Again, I only wish to point out that many (if not most) of current existing programs do not port easily to diverse systems. I would suggest that you have done well if your 250K lines can be ported just by looking after byte orders. (By the way, do you handle 9 bit bytes? Nil pointer that is not 0? Segmented architecture that does not allow addresses before or after an allocated object? Different precision floating point?) In article <9031@louie.udel.EDU> new@udel.EDU (Darren New) writes: [Darren comments on Phil's article and relates his experience in a project and describes the solution he used - Abstraction. SC] > > Anyway, I think the problem of porting to other OSes is due to > not abstracting to the proper level. I have had success with writing > a "portability library" that defines what I want to do in terms of > what the OS provides. Had parsing information (like '/' separates > directory components) shown up in the application code, moving > things to VMS would have been a nightmare, because VMS has a > totally different file naming convention. As it was, redoing most > of the code for directory and file manipulations allowed things > like the interactive installer and the backup/restore programs to > run after simple recompilations. I would suspect that most of the > "horror stories" about moving to other OSes were due to the original > code never being segmented into OS-dependent and OS-independent > portions because the author never considered moving it to a new OS. > On the other hand, since the above project, I have never failed to > segment a program into such portions, and I have never had problems > moving my own programs to other OSes with relatively trivial effort. > - Darren New My point exactly. It is the methodology and style of coding that makes code portable, not the system for which it is written and not the language in which it is written. In article <7911@boring.cwi.nl> jack@cwi.nl (Jack Jansen) writes: > > The real-world issue is not portability of the kernel but portability > of user programs. Unix is still the only OS in the world that will > allow *reasonably* easy porting of *many* programs to *some* > wildly different machines. Note the emphasised words: porting is not > trivial, it will not work for all programs, and not for all machines. I quite agree. I take exception only with people who make your statement WITHOUT the highlighted words. > Compare porting a program between Amdahl UTS, Dec VMS and XENIX > to porting it between OS/360, VMS and MS/DOS. I have had occasion to move Fortran (that dreaded word again) programs between some systems, in the intended domain (that is, a lot of number crunching), I suggest Fortran is at least as easy to port. In fact, I think I will go whole hog and suggest that on large projects (> 1 million lines), the language and the O/S is irrelevent since it will be cheap to retarget the compiler and O/S to the new harware. In the same vain, have you tried to port Sun tools to X-windows (I know, this is not strictly Unix) or just between Sys V and BSD? :-) [Jack then comments on my complain about the Unix user interface. SC] > Absolutely true. Playing devils advocate again, though: have you > ever worked on OS/360? NOS/BE? Or, more in the same class of OS'es > as unix, VMS or MS/DOS? > The *only* reason novices can manage to learn MS/DOS is because there > are only 5 commands to learn. MSDOS < UNIX <<<<<<< Macintosh. As a matter of fact, I have used OS/360. I have no problem in hating it but I would not say it is worse than Unix, just bad in different ways. Also, no one seriousely suggests OS/360 (MVS, ...) as a real interactive system, for batch systems, it has a certain perverted appeal. There is one major point in favor of OS/360: you can always find the information in the obvious manual AND you can trust the information. Would you say that about Unix? :-) As to MS/DOS, would you really put Unix in the same class as MS/OOS? It isn't really fair to compare an 8088 on floppy to an 68030 with a fast 60 MB drive and ethernet. :-) :-) MS/DOS can get by with so few commands is that users (like me) use it to get into an application and forget about MS/DOS. (That shows you what I think about MS/DOS.) Have you looked that Amiga? It has a well thought out (comparatively) kernal interface that accomadates graphics, windows, multi-tasking, etc.. Many Unix hackers like it because of the flexibility and power like Unix but a very efficent system and clean interface. Stanley Chow ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public (613) 763-2831 Disclaimer: What? Me? Have an opinion? Surely you jest. Represent any one? Ha, I don't even represent myself.
dph@lanl.gov (David Huelsbeck) (02/21/89)
From article <299@bnr-fos.UUCP>, by schow@bnr-public.uucp (Stanley Chow): > [...a lot of standard Unix-commands-are-ugly complaints ...] > In article <7911@boring.cwi.nl> jack@cwi.nl (Jack Jansen) writes: >> [...agrees, then goes on to tacitly boast about how long he's been computing by talking about how bad OS/360 was/is ...] >> MSDOS < UNIX <<<<<<< Macintosh. > > As a matter of fact, I have used OS/360. I have no problem in hating it > but I would not say it is worse than Unix, just bad in different ways. > Also, no one seriousely suggests OS/360 (MVS, ...) as a real interactive > system, for batch systems, it has a certain perverted appeal. > > There is one major point in favor of OS/360: you can always find the > information in the obvious manual AND you can trust the information. > Would you say that about Unix? :-) > > As to MS/DOS, would you really put Unix in the same class as MS/OOS? > It isn't really fair to compare an 8088 on floppy to an 68030 > with a fast 60 MB drive and ethernet. :-) :-) > > MS/DOS can get by with so few commands is that users (like me) use it > to get into an application and forget about MS/DOS. (That shows you > what I think about MS/DOS.) > > > Have you looked that Amiga? It has a well thought out (comparatively) > kernal interface that accomadates graphics, windows, multi-tasking, > etc.. Many Unix hackers like it because of the flexibility and power > like Unix but a very efficent system and clean interface. > > > > Stanley Chow ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public > (613) 763-2831 > > > Disclaimer: What? Me? Have an opinion? Surely you jest. > Represent any one? Ha, I don't even represent myself. Well I may be a young, upstart, punk (I think I was born post-OS/360) but I think a lot of you old guys are full of barnyard animal excrement. The first system I used (not counting C64 BASIC) was VM/CMS I then learned MS-DOS (not much different from C64 BASIC), Unix, CTSS (Cray Time Sharing System) and most recently VMS. I logged in to a NOS machine twice to read some tapes. I have also spent a fair amount of time using Mac's. These experiences have led me to the conclusion that any system that lets you have a command line is better than any that doesn't. I hear there's a pseudo-csh for the Mac now. If the icons are so great why was this written? Unlike social systems I think OSs are best measured by how well they treat the best users not the worst. Sure any three year old can learn to use a Mac in a few minutes but the experienced user is stuck with that preschool interface for the rest of his life. Unix commands are no harder to remember than any other. Even if commands are supposedly plain English which English word do you use? Is it "delete", "remove", "purge", "kill" or what? I've seen all of these for the same task. Seems like "rm" ought to be as easy to remember as clover-key whatever, and unless you have three hands "rm foo<ret>" is a hell of a lot less effort than reaching for the mouse. Have you ever remotely logged into a Mac from a vt100? How would you go about doing that? What about an Amiga? (I suspect the later is possible.) Many people still have vt100's and similar equipment. With "screen" and GNU Emacs a vt100 is a very livable environment. If you actually use "vi" day to day you're getting what you deserve. Then again if you really like XEDIT Emacs might be too much for you. However, as has been pointed out before, none of X-Windows, SunView, NeWS, screen, Emacs, or vi is Unix. Neither is XEDIT VM/CMS or MVS. There are definitely problems with Unix (and C) but I don't believe either of you has addressed any of them. As people here are being forced to look seriously at something supposedly similar to Unix as a production environment for supercomputers the difference between deficiencies with substance and the sort of syntactic fluff you're complaining about are becoming more obvious. My personal belief is that Unix has been too successful for it's own good. I think people are trying to make it do things that it was never intended to do and it's straining under the load. It has been pointed out by other posters that this situation has a simple solution. One of you guys that knows why Unix stinks and how an OS ought to be can write one. Then you can either port it to a few hundred different platforms yourself or you can convince enough other people that it's so keen that they'll port it for you. Seriously, I think that this will eventually happen with some OS that comes out of a research environment. It stands to reason that Unix will not be around forever. However I think the chance that this will happen with one of it's current vendor specific competitors is zero. As for portablity, what would a numbers-in-numbers-out code do to be non-portable? There are reasons to use FORTRAN instead of C but I don't see that portability is one of them. Clearly doing funky things with pointers can make a C code non-portable but there's no law or reason that says you have to do that. Just stick to staticly allocated arrays of scalars (your only choice in *STANDARD* FORTRAN) and I think C will be just a portable as FORTRAN. Perhaps more so. I'm having problems right now with some "portable", standard FORTRAN 77 because the standard does not define a stdin/stdout, argv/argc type convention. Quick name a command language that runs on more different machines than sh does? Also, if OS/360 docs are anything like VM/CMS docs I'd rather have man pages thank you. The US Govt., DOE, UC and LANL have people that are paid to let you know what their official opinions are; I am not one of those people. -dph
raveling@vaxb.isi.edu (Paul Raveling) (02/22/89)
In article <7911@boring.cwi.nl> jack@cwi.nl (Jack Jansen) writes: > >The real-world issue is not portability of the kernel but portability >of user programs. Amen. However, the easiest way to assure portability of user programs is to have a portable kernel. In the case of UNIX, also a portable hierachy of things in /etc, /dev, /usr/adm, /bin, /usr/bin, /usr/local/bin, /usr/contrib/bin, /lib, /usr/lib, /man, /usr/local/man, etc. ad nauseum. ... And don't forget whether your setup is for sh, csh, ksh, tcsh, ... UNIX's architecture fosters incompatibility by migrating a lot of functions out of the kernel to levels where users have to deal with them. ---------------- Paul Raveling Raveling@isi.edu
peter@ficc.uu.net (Peter da Silva) (02/22/89)
In article <299@bnr-fos.UUCP>, schow@bnr-public.uucp (Stanley Chow) writes: > As to MS/DOS, would you really put Unix in the same class as MS/OOS? Yes. > It isn't really fair to compare an 8088 on floppy to an 68030 > with a fast 60 MB drive and ethernet. :-) :-) But it is fair to compare MS-DOS on a PC/XT and UNIX on the same machine. I had opportunity, a few years ago, to compare these two systems. Apart from the obvious advantages, I was mildly surprised to discover that on this 8088-based machine with 640K and a 10 meg drive, UNIX (Xenix, actually) was *faster*, both in disk I/O and (for well behaved MS-DOS programs) screen I/O. > MS/DOS can get by with so few commands is that users (like me) use it > to get into an application and forget about MS/DOS. (That shows you > what I think about MS/DOS.) This is a good point. I, on the other hand, had to do software development on the beast. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` People have opinions. Companies have policy. And typos are my own business.
schow@bnr-public.uucp (Stanley Chow) (02/22/89)
After reading this article again, I realized it is very long and pretty tongue in cheek. [Must be the vacation coming up.] Hope no one takes offense. As summarized in the Summary above, this will probably be my last word on this topic so feel free to flame away. I will probably miss it all when I use catchup. I am giving you a last chance to skip it. In article <9579@lanl.gov> dph@lanl.gov (David Huelsbeck) writes: >From article <299@bnr-fos.UUCP>, by schow@bnr-public.uucp (Stanley Chow): >> > > [...a lot of standard Unix-commands-are-ugly complaints ...] > >> In article <7911@boring.cwi.nl> jack@cwi.nl (Jack Jansen) writes: >>> > > [...agrees, then goes on to tacitly boast about how long > he's been computing by talking about how bad OS/360 was/is ...] > At last, I have a come back to people who have used CTSS :-) >>> MSDOS < UNIX <<<<<<< Macintosh. >> >> As a matter of fact, I have used OS/360. I have no problem in hating it >> but I would not say it is worse than Unix, just bad in different ways. >> Also, no one seriousely suggests OS/360 (MVS, ...) as a real interactive >> system, for batch systems, it has a certain perverted appeal. >> >> There is one major point in favor of OS/360: you can always find the >> information in the obvious manual AND you can trust the information. >> Would you say that about Unix? :-) >> >> As to MS/DOS, would you really put Unix in the same class as MS/OOS? >> It isn't really fair to compare an 8088 on floppy to an 68030 >> with a fast 60 MB drive and ethernet. :-) :-) >> >> MS/DOS can get by with so few commands is that users (like me) use it >> to get into an application and forget about MS/DOS. (That shows you >> what I think about MS/DOS.) >> >> >> Have you looked that Amiga? It has a well thought out (comparatively) >> kernal interface that accomadates graphics, windows, multi-tasking, >> etc.. Many Unix hackers like it because of the flexibility and power >> like Unix but a very efficent system and clean interface. >> >> >> >> Stanley Chow ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public >> (613) 763-2831 >> >> >> Disclaimer: What? Me? Have an opinion? Surely you jest. >> Represent any one? Ha, I don't even represent myself. > > >Well I may be a young, upstart, punk (I think I was born post-OS/360) >but I think a lot of you old guys are full of barnyard animal excrement. Ah, finally, someone recognises my great sagely wisdom! I will now pontificate at the ripe old age of 35. Yes, my child, the follies of youth are many and in time, you too, will gain wisdom. >The first system I used (not counting C64 BASIC) was VM/CMS I then >learned MS-DOS (not much different from C64 BASIC), Unix, CTSS (Cray >Time Sharing System) and most recently VMS. I logged in to a NOS machine >twice to read some tapes. I have also spent a fair amount of time using >Mac's. These experiences have led me to the conclusion that any system that >lets you have a command line is better than any that doesn't. > Instead of putting my record on the record (so to speak), I think I will beg off and rely on my great wisdom gained through the ages. Suffice to say that I have been on the computers of IBM and the BUNCH (that sounded so nice, I didn't mind bending the truth). I have also played with (putting it mildly) with Apple II's, throught PC's, to Amigas at home and more than a few minis and mainframes at work. Strangely enough, these experiences lead me to conclude that command lines are independent of "goodness" of system. >I hear there's a pseudo-csh for the Mac now. If the icons are so great >why was this written? Interesting question. Along the same lines, I hear GM is building a small car. If the Cadallics are so good, why is GM building a small car? > >Unlike social systems I think OSs are best measured by how well they treat >the best users not the worst. Sure any three year old can learn to use a >Mac in a few minutes but the experienced user is stuck with that preschool >interface for the rest of his life. Have you ever consider that what a user can learn in a few minutes is all that they *need*? Once, in the distant past in a strange land, I actually met a person who only wanted to get the work done instead of playing with the great toys that were sitting at his desk. He did not play with the kernal, not with the shell, not *even* with startrack!! You know, it's amazing, but there are actually people who don't want to know about computers (hardware of software). Hardware designers have a hard enough time designing hardware that they want a system to *work*. Clerks have enough trouble doing their jobs that want the system to *work*. These people don't want to hack the kernal, they don't even want to be power users, they just want to do their job! >Unix commands are no harder to remember than any other. Even if commands >are supposedly plain English which English word do you use? Is it >"delete", "remove", "purge", "kill" or what? I've seen all of these for >the same task. Seems like "rm" ought to be as easy to remember as >clover-key whatever, and unless you have three hands "rm foo<ret>" is a >hell of a lot less effort than reaching for the mouse. Why is it that when I talk about secrataries and clerks, everyone assumes they want to remember *any* commands? For a hacker, by definition, nothing is difficult. Would you consider "mv" to be the natural way to rename a file? Do you consider draging an icon to the trashcan to be a major problem? Come now, for a man who can remember all those commands, this can't be too hard. Last time I looked, most people use one hand for the mouse. Oh, you mean timesharing your hands between the keyboard and the mouse, why didn't you say so. Most people manage to timeshare their hands between cutlery during deals and keyboard during typing, adding the mouse during Mac-Draw is probably not a major problem. Just a note, one of the reason Mac's are nice is that just about all commands are accessable from both the mouse menu and the keyboard. People decide which suits them better and use that; mostly people use the mouse in Mac-Draw and keyboard during Mac-Write. But then, there are always those nit-wits who only use the computer once a month and will use the mouse menu for everything! >Have you ever remotely logged into a Mac from a vt100? How would you >go about doing that? What about an Amiga? (I suspect the later is possible.) > Why would anyone want to? Just take the Mac with you :-) I regularly login to IBM and Unix boxes from home. I have several friends who run BBS on Amiga's so I assume that's possible. I seemed to recall that PC's, wait, even older machines, Appli II, can handle that. Does that make the Apple II a real nice system? Like I said in my posting, the Amiga OS is Unix like and has built-in graphics, windows, multi-tasking, etc. (This is a sutle remainder that you sould read the posting before you flame). Different machines are designed for different purposes. I don't expect anyone to use a Zenith laptop as their simulation engine and I don't expect anyone to take a Cray onto a plane. Why should you want to dial into a Mac? >Many people still have vt100's and similar equipment. With "screen" and >GNU Emacs a vt100 is a very livable environment. If you actually use "vi" >day to day you're getting what you deserve. Then again if you really like >XEDIT Emacs might be too much for you. > Watch them insults. I might stop pontificating, then who will you flame? As I said in my posting [another sutle hint], I use Micro-Emacs on my Amiga. Also like I said in my posting, technological baggage [from history] ought not to hold up development. Just because I have a PDP-8 (which is sitting in my living room as a coffee table), you are going to make all your programs compatible with 4K memory? Another thing that comes with age [there I go boasting about my 35 years again] is the realization that different people want different things. I may be happy with a vt-100 since all I do is write reports and software. I doubt very much the VLSI designer next to me will be too happy with it. How about the editors [the people editing papers, not the programs editing files] who want to see the page proof on the screen? I expect your pals doing plasma simulation might be a tad upset if you restrict them to vt100 (or even vt220). Livability is in the eye of the beholder. >However, as has been pointed out before, none of X-Windows, SunView, NeWS, >screen, Emacs, or vi is Unix. Neither is XEDIT VM/CMS or MVS. There are >definitely problems with Unix (and C) but I don't believe either of you >has addressed any of them. As people here are being forced to look seriously >at something supposedly similar to Unix as a production environment for >supercomputers the difference between deficiencies with substance and the >sort of syntactic fluff you're complaining about are becoming more obvious. > Some people want MIPS, you probably want MFLOPS, I want ease of use, others may want 2Kx2K 60 bit color graphics. Just because it's not important to you; don't assume it't not important to me. >My personal belief is that Unix has been too successful for it's own good. >I think people are trying to make it do things that it was never intended >to do and it's straining under the load. It has been pointed out by other >posters that this situation has a simple solution. One of you guys that >knows why Unix stinks and how an OS ought to be can write one. Then you >can either port it to a few hundred different platforms yourself or you can >convince enough other people that it's so keen that they'll port it for you. > I agree with you on the too successful part. I don't quite understand your other part. Just becase I don't like Unix, I have to write a repacement or shutup? Is that the deal? Why do you think I want to? The OS that I managed is doing quite well [total system sales is in the billions of dollars], thank you very much. [Help, there is a terrible echo here, I keep saying the same thing.] At the risk of delabouring my point, different people judge OS by different standards. As I said in my posting, "People care about functionality, researcher care about algorithms, only implementor care about implemenation." Having done my share of implementations, I have now retired to user status with an occasional foray into the domain of philosophy and theory. Please note that these priviledges come only with age and you must wait for your turn. Otherwide, who will work to pay for my pension? >Seriously, I think that this will eventually happen with some OS that comes >out of a research environment. It stands to reason that Unix will not be >around forever. However I think the chance that this will happen with one >of it's current vendor specific competitors is zero. > Strange that we should disagree on this point also. I think Unix will be around forever (or what passes for forever in this business). For example, COBOL and FORTRAN are going strong. I do agree that something else will come and supplement it. >As for portablity, what would a numbers-in-numbers-out code do to be >non-portable? There are reasons to use FORTRAN instead of C but I don't >see that portability is one of them. For a good religous war, see back issues of comp.lang.c & comp.lang.fortran on this very issue. There are many things that make numbers go funny. I image if you stand up and shout this question, you ought to hear some replies from people in your building. If you really want to get into this, talk to me after my vacation. > Clearly doing funky things with >pointers can make a C code non-portable but there's no law or reason that >says you have to do that. Just stick to staticly allocated arrays of >scalars (your only choice in *STANDARD* FORTRAN) and I think C will be >just a portable as FORTRAN. Perhaps more so. I'm having problems right >now with some "portable", standard FORTRAN 77 because the standard does >not define a stdin/stdout, argv/argc type convention. Count yourself lucky if that is all your problems. How many C programers do you know? How many of them will/can write code without pointers? There aren't that many library/system calls you can make without using pointers. On the otherhand, how many Fortran programers do you know who can get into trobule with pointers? >Quick name a command language that runs on more different machines than >sh does? Quick, name the junior senator from Chicago. (Caught you, Chicago is a city). I bet you a lot more machine run kermit than run sh. So? My Amiga runs sh (and uudecode and zoo and uucp and ...) on its native DOS. What is the point? >Also, if OS/360 docs are anything like VM/CMS docs I'd rather have man >pages thank you. Taking the example in my posting, How many manuals do you need to set up your terminal (say to 132 char/line) in VM/SP? How many man pages do you have to read in Unix? Okay, you know it all and wrote the book on it, how about some rank novice? Stanley Chow ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public (613) 763-2831 Disclaimer: When I am jolly like this, I don't even let me represent myself. No person or organization would let me represent them anytime.
schow@bnr-public.uucp (Stanley Chow) (02/23/89)
In article <3151@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <299@bnr-fos.UUCP>, schow@bnr-public.uucp (Stanley Chow) writes: >> As to MS/DOS, would you really put Unix in the same class as MS/OOS? > >Yes. Be careful, I sense some hostility towards Unix on your part. This could get you flamed royally. [If I misinterpret your yes, sorry] > >> It isn't really fair to compare an 8088 on floppy to an 68030 >> with a fast 60 MB drive and ethernet. :-) :-) > >But it is fair to compare MS-DOS on a PC/XT and UNIX on the same machine. > >I had opportunity, a few years ago, to compare these two systems. Apart >from the obvious advantages, I was mildly surprised to discover that >on this 8088-based machine with 640K and a 10 meg drive, UNIX (Xenix, >actually) was *faster*, both in disk I/O and (for well behaved MS-DOS >programs) screen I/O. > Interesting. How about speed of OS operations? Like the famous wildcard expansion in the shell? E.g., DIR vs ls, TYPE vs more, mkdir vs mkdir, RENAME *.o *.oo vs mv ??, file creation speed, ... >> MS/DOS can get by with so few commands is that users (like me) use it >> to get into an application and forget about MS/DOS. (That shows you >> what I think about MS/DOS.) > >This is a good point. I, on the other hand, had to do software development >on the beast. I hope you only had to port to it as opposed to actually editing and compiling on it. If you actually had to use an XT as a development platform, you have my deepest sympthies and much admiration. >-- >Peter da Silva, Xenix Support, Ferranti International Controls Corporation. >Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' >Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` >People have opinions. Companies have policy. And typos are my own business. Stanley Chow ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public (613) 763-2831 I expressed no opinions here, mere extension of sympathy is not enough to get me into trouble. [Famous last words] Newsgroups: comp.os.misc Subject: Re: Why Unix is good (was Re: Unix bigotry) LONG Summary: Expires: References: <117@spectra.COM> <692@cvbnet2.UUCP> <3101@ficc.uu.net> <299@bnr-fos.UUCP> <3151@ficc.uu.net> Sender: Reply-To: schow@bnr-public.UUCP (Stanley Chow) Followup-To: Distribution: Organization: Bell-Northern Research, Ottawa, Canada Keywords:
marc@hpfcdc.HP.COM (Marc 'Sphere' Sabatella) (02/23/89)
/ hpfcdc:comp.os.misc / schow@bnr-public.uucp (Stanley Chow) / 9:56 pm Feb 20, 1989 / >Given the same amount of effort, there are langauges like Fortran >(oh no, did I just say another bad word?) that can be more portable, even >if the application is restricted to a narrow domain. Any particular Fortran restricts the domain of the applications written in it. The intersection of different vendors' Fortran's yields a language that is probably not even functionally complete; certainly it would not make an effective general purpose programming language. >(By the way, do you handle 9 bit bytes? Nil pointer that >is not 0? Segmented architecture that does not allow addresses before or >after an allocated object? Different precision floating point?) A minor nit: ANSI defines NULL to be 0, so one needn't worry about that. Your point about C programmers relying on implicit assumptions such as byte size, etc. is well taken, although I don't see floating point precision as an issue because C programmers are no worse here than Fortran programmers. However, picking on such obsurities as 9-bit bytes emphasizes the portability of C: with careful (but not excessively difficult) programming, your C program will run on the majority of architectures; and if you are a real zealot, you can even #ifdef away dependency on byte sizes. >> [ someone else's description of abstraction ] >My point exactly. It is the methodology and style of coding that >makes code portable, not the system for which it is written and not >the language in which it is written. The system independence of good code is true in principle, but sidesteps the issue that the systems themselves (except Unix) are non-portable. All but the most trivial of program will have some system dependence. If you abstract carefully, as the previous poster did, you can localize the system dependence, but you will still need separate system-dependent sections for each system. With Unix, you can structure that section so that it may be Unix specific, but is not machine dependent. With VMS, (or NOS, etc) the system dependent code will run only on Dec, (or CDC, etc). As for the language, this is simply untrue. With most other languages, the system dependent part must be extended to include "language implementation" specific code (for example, Pascal string handling packages); the common code must be written for the least common denominator (a misnomer, but I digress) of the feature sets of the various different Fortrans or Pascals provided by different vendors. With C, you have some assurance that this least common denominator will be some semblance of what is described in K&R, which is a language with enough power to allow you to write reasonable programs. You also know you will have the ability (via #ifdef) to isolate any dependcies; you have no way to (portably) do that in most other languages. >I have had occasion to move Fortran (that dreaded word again) programs >between some systems, in the intended domain (that is, a lot of number >crunching), I suggest Fortran is at least as easy to port. You cannot be serious. Vendor X does not support recursion, Vendor Y does not support records. Vendor Z does not allow calls to "C" library routines. Vendor Q doesn't even allow separate compilation. You want to port between these? This is a nightmare. Perhaps "in the intended domain" is the key: programs which use only a bare bones subset of the language will be easy to port. But then the program could probably have been written just as portably in C. >In fact, I >think I will go whole hog and suggest that on large projects (> 1 million >lines), the language and the O/S is irrelevent since it will be cheap >to retarget the compiler and O/S to the new harware. This just begs the question. If we accept that OS's and compilers may just be retargeted, then of course all systems and languages promote portability equally. The point is, Unix and C make this a necessity less often than any other OS/language combination. -------------- Marc Sabatella HP Colorado Language Lab marc%hpfcrt@hplabs.hp.com
peter@ficc.uu.net (Peter da Silva) (02/24/89)
In article <306@bnr-fos.UUCP>, schow@bnr-public.uucp (Stanley Chow) writes: > Be careful, I sense some hostility towards Unix on your part. This > could get you flamed royally. [If I misinterpret your yes, sorry] The only hostility you may be sensing is towards the bozos who put hundreds of K of junk in the UNIX kernel that better belongs outside, or at least should be optional. Once upon a time UNIX was small enough that it could compete with DOS. Never forget that. Let's hope Mach does better against OS/2. > Interesting. How about speed of OS operations? Like the famous wildcard > expansion in the shell? E.g., DIR vs ls, TYPE vs more, mkdir vs mkdir, > RENAME *.o *.oo vs mv ??, file creation speed, ... Anything that required going to the inodes, but not much more, seemed to be marginally slower for small directories. Things like 'ls -l' versus 'dir', as opposed to 'ls -C' vs 'dir /w'. For large directories it was always faster, probably because the cache was being more effectively used, and normal wildcard expansion didn't seem to slow it down any. > I hope you only had to port to it as opposed to actually editing and > compiling on it. Develop and compile. And it was an advance over the 8080-based intel blue boxes we had been using. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` People have opinions. Companies have policy. And typos are my own business.
gph@hpsemc.HP.COM (Paul Houtz) (03/03/89)
dph@lanl.gov (David Huelsbeck) writes: >Mac's. These experiences have led me to the conclusion that any system that >lets you have a command line is better than any that doesn't. >I hear there's a pseudo-csh for the Mac now. If the icons are so great >why was this written? >Unlike social systems I think OSs are best measured by how well they treat >the best users not the worst. Sure any three year old can learn to use a >Mac in a few minutes but the experienced user is stuck with that preschool >interface for the rest of his life. You make some very good points, David. I agree with you for my own use. I can type 60 wpm, and I MUCH prefer a command line to an icon. However, you MUST not prescribe what works for you as being best for everyone else. Icons have their place. If I have to log onto a machine I have never seen before (and may never see again) and gain some information from it (like "How much money is in my checking account"), I prefer a menu. There are times when I have been happy with icons and pull down windows in environments where I either had no documentation or had no time to read the documentation. Please, remember that computers can be of tremendous help to ALL of society, not just hackers. Many different user interfaces are necessary to allow different people to access the machine. Would you prefer a command line on the processor that controls the electronic fuel injection and timing in your automobile?