bzs@bu-cs.BU.EDU (Barry Shein) (03/01/88)
>Hello Unix Wizards! > > Our campus is almost on the verge of being turned into a VMS >filled campus due to the lack of knowledge of the person in charage of >computing services here. The next couple of months will determine >what the campus computer scene will be like during the next decade. >This person has in mind buying Vaxes with VMS, and DECnet with lots of >money... The basic problem with VMS is that it locks you into a single hardware architecture and vendor. In this day and age that severely limits what you can purchase in computing power. Vaxes vary widely in price but not much in processing power. For example, a small uVax-II sells for around $30K and offers a little less than 1 MIP. An 8750 sells for perhaps $500K and offers a few MIPs. In the near future this range closes even further, the uVax-3 being around 1/2 the processing power of the top end with a price range of ten-fold. It's hard to buy worse price-performance. The Unix market ranges from PC based Unix systems which the average student can afford (and this area is expanding rapidly) to the Cray-2, a premiere super-computer, and just about everything in between. In the middle market (typical small-medium scale time-sharing) one can buy Unix systems from various vendors with upwards of ten times the price performance of VMS. Unix systems are relatively bundled, beyond mere hardware considerations most Unix systems right out of the box are completely useable. It can be supplemented in many significant ways with free or nearly free (eg. ~$100 for an entire campus) software. VMS is heavily unbundled, from day one if you want so much as a compiler you begin layering heavy costs. And you'll pay a separate price for acquiring and maintaining software on every CPU running VMS on campus. This will quickly lock you out of the workstation market, having to add $100K in basic software costs to 40 VMS workstations can put a real damper on a typical University's plans, no matter how good the intentions. Unix is the premiere system for compute intensive areas, such as the sciences using Fortran. The reason is the vast range of power a program written to run under Unix presents. As I said, a program developed on a small, affordable PC or workstation can be copied and re-run on huge compute engines. Although a lot of the sciences in the past used VMS they now generally realize that this was an error and the communities are rapidly switching to Unix, any argument that science is done on VMS is a false argument of the past. You should poll major science depts and research labs. If nothing else, the fact that the Cray and other super-computers run Unix has pushed the equation in this favor, a person using VMS is essentially locked out of the entire NSF super-computer initiative. Decnet would tend to reaffirm this retardation (TCP can be had on VMS but it's sort of like teaching a pig to dance, speak to VMS sites and they'll tell you what a general pain in the ass it is to deal with third party vendors, network software breaking on each O/S release etc etc.) The typical claim by the campus administrator is to point at all the myriad applications and big-name software that runs on VMS and doesn't run on Unix. In the first place, most of this now does run on Unix so that tends to be an anachronistic view. Another point is that such admins usually have DP-envy. No one on the campus has any need for any of the big-name applications the person is bragging about, you're running an academic environment, not a bank! Get a list of these applications and you'll see how ludicrous this consideration is. Unix tends to vastly dominate the academic community in software availability. These admins will sneer at things like X-windows, lisp (which doesn't cost $10K/node), AI systems etc in preference to their big-name commercial databases and spread-sheets as if what students and professors do is not to be taken seriously, then why are they on a campus? It's no accident that both Athena and Andrew have chosen Unix for their massive campus computing projects. Unix makes available the forefront of hardware technology, parallel processing from companies like Encore, Sequent, BBN (Butterfly), RISC and the so-called "super-workstations" like Sun/4, MIPS, HP etc. which can deliver nearly 1MIP/$1K of price. The parallel processor provide time-sharing systems extending into the hundreds of MIPs, again for about $1K/MIP. Anything new and innovative runs Unix, not VMS, it would be foolish to lock an entire academic community out of all this. I can understand why a bank is not particularly concerned, but why a (supposedly) active research community? Why lock yourself out of all this. The VMS salesthings will claim that they're going to do all this *in the future*, they've been saying that for years and years, and when they do come out with something it tends to be too little too late, in name only, like a dual processor 8800 which barely exploits what tiny parallelism it has. VMS itself is not an interesting operating system to learn or study. It is basically a re-work of RSX, an ancient real-time operating system from the PDP11 (Unix also ran on the PDP11 years ago, but it has grown in modern ways, as opposed to VMS's habit of just accreting whatever features were needed to meet the next big govt contract.) The claim that Unix is somehow less secure than VMS is a red herring. Unix offers sufficient security for campus systems, you're not the NSA (again the tactic of arguing that VMS is better for things you don't need.) More importantly, many Unix systems are available with full sources for a modest price, typically $1000/campus (it's simply a matter of your vendor choices, more than you can say for VMS where there is no choice.) Without the sources you are, at best, at the mercy of the vendor for security. A huge security hole which is bringing you to your knees (which happens regularly on VMS, and the news travels the networks like wildfire) leaves you helpless and at the vendor's whims as to whether or not they feel like closing the hole this week, or next month, or put it off for next release. In fact their concern with only commercial DP makes them *less* interested in your security problems. Banks don't have malicious students exploiting security holes and don't tend to notice such things or complain about them. With Unix and the sources you can at least plug up the hole by a code change and then call the vendor and wait for the real fix, at least you'll be up and running until then. Don't believe that VMS sources are available, it's a lie, demand to see prices for all items needed such as Decnet sources. Demand to be told what resources it would take to even manage such sources. Last I checked it required the dedication of a few hundred thousand dollars in hardware (basically, an entire larger Vax with large disks) to manage sources. Obviously the sources will also be of enormous benefit in answering user questions, such as tracking down example code using particular system calls. You can sort of do this with VMS's microfiche, if you consider searching through microfiche for a particular system call usage a good way to spend your time. You can't grep microfiche. Even then you'll usually find that the way the system application accomplishes what the user seems to want to do is by exploiting some privilege you won't want to give to a user (I'm not sure I want to go into the whole mess of the zillions of VMS "privilege" bits which you'll never fully understand the implications of and will almost surely end up giving away the store because some reasonable thing can only be accomplished by giving a user some dangerous privilege bit, Unix's single privilege scheme [root or not root] is much more secure, you just don't give out root privs and you know exactly what can and cannot be done by the two sets of users on your system, who wants to calculate the permutations of 30+ priv bits and what they might imply singly and in combination?.) The programming and system interfaces in VMS are arcane and just a hodgepodge of features, there's no particular underlying design philosophy, just whatever marketing wanted this week. Although VMS has some interesting software features it's nearly impossible for anyone but a very experienced programmer to take advantage of these. This is not really a damnation of VMS, VMS is a platform for delivering turnkey applications software, like databases in commercial environments for people who wouldn't think of programming in general, just data entry and report generation. I'm *sure* this is representative of your needs (hah!) In an academic community one merely has to go into a campus bookstore to see another argument. Look at all the Unix books! Where are the VMS books? There are none. A complete set of Unix manuals costs less than $100, a more than sufficient set costs perhaps $50. A complete set of VMS docs costs several hundred dollars, no student or even faculty member (except the few richest) can afford to own a documentation set for VMS. There's some on-line help in VMS but it's designed to sell manuals or supplement them, the details are always missing (purposely.) Most Unix systems come with on-line, complete manual sets with the exact same text used to produce the printed manuals. Thus, what's the cost to a student for Unix manuals? For $0 (zero) they can get everything, if they like manuals in their laps they can buy those for the cost of a couple of textbooks. To supplement that they can buy any of dozens of titles on Unix ranging from the structure of the operating system, systems programming, compiler construction, applications programming, AI, many programming languages, shell programming, text processing etc etc. For VMS you'll be lucky to find two titles (I can only think of one, the Internals book, and that's hardly a text, oh yeah, there's an assembler textbook, both of those are about five years old and don't even refer to the current VMS system so you won't be able to use their code etc.) So, running courses on VMS will mean foresaking textbooks. Very clever! Good plan for running an academic environment! It's no accident, the DEC/VMS crowd has no interest in academia, your sysadmin has DP-envy. Decnet nearly completely locks you out of wide-area networking, such as the arpanet. One need only look at the arpanet's University rolls to see who you are abandoning, merely the foremost schools and research labs in the country. About 95% of them use Unix systems to hook up to the arpanet. Decnet is completely useless in this regard. There are a couple of strange, semi-wide area networks based on DECNET (few people could name them.) Perhaps one or two of your faculty would like to be on them. You should buy them a microvax and get on with the rest of the campus' needs, don't let the tail wag the dog. And you can forget uucp and usenet entirely, which means no e-mail to vendors etc. In summary, buying into VMS for a campus is buying into the past in a pathetic, nearly necrophilic way for an academic community. It locks them out of the mainstream in Computer Science, Engineering, the Sciences and many of the humanities (all the multi-media projects of any interest are being done on either Unix or or Macintosh/PC systems.) It has very little to offer an academic community for either research or coursework. It is flying in the face of nearly all trends in computing today and doing so at such a high dollar price that it borders on irresponsible. This is not to say that there is no need for even one VMS system on your campus, there probably is. But using it as a campus standard is irresponsible and completely without merit or rational justification and will cripple academic computing for years to come. What other campuses do this? This is not a religious flame, I have presented myriad factual basis for my arguments. VMS people like to claim religious flame and "chocolate vs vanilla!" arguments. This is because they cannot deal with the real issues so making it a political war can only act to their advantage. Avoid the issues, get the opponents fired, scare a campus administrator with false promises of donations etc. Unfortunately you may be up against an insidious cancer you only barely understand which will manipulate your organization in ways you will regret. -Barry Shein, Boston University
trt@rti.UUCP (Thomas Truscott) (03/01/88)
In article <1636@tulum.UUCP>, hirai@swatsun.uucp (Eiji "A.G." Hirai) writes: > Is VMS as horrible as I suspect or am I alone an thinking this? VMS is a fine OS. Any campus should have a few VMS systems. But your campus should primarily run UN*X. This partly because UNIX is wonderful and partly because UNIX has become so widespread that it should be chosen even when clearly deficient. (E.g. people still choose FORTRAN.) 1. As a University, it is absolutely mandatory to make UNIX the major academic operating system. * undergraduates should use it because it is what they will use when they graduate. * graduate computer science/engineering students can study, and even modify the UNIX OS. Thousands of students have learned how to write operating systems by studying UNIX. Not true of VMS! Consider MIT (Project Athena), CMU (Mach OS, and Andrew), University of Califorina at Berkeley (3.0 BSD and so on). Consider the following major academic software projects: Sprite, Locus, TimeWarp, (forget this, consider *almost any* recent major academic software project!). UNIX had a major role in every one. * Look at the CS faculty recruiting ads in the back of the Communications of the ACM, and count how often UNIX is mentioned. Can you even *find* a mention of VMS? * What about the non-CS students and faculty? If they want innovative uses of computing they will find it on UNIX. Mostly they will want word processing, and that is on UNIX too. (But a SUN or Mac or PC clone is cheaper for that than a VAX. Whatever you pick can run UNIX. VMS only runs on a VAX.) 2. As a strategic computing decision, you must pick UNIX, because it is becoming a world-wide standard operating system. It can run on nearly every computer from the smallest home systems to the Cray 2. Virtually every newly designed computer has UNIX as the standard (if not the only) operating system. Older operating systems will persist, of course, but their vendors now provide UNIX alternatives. In particular there are vendor-supplied UNIX alternatives to IBM MVS, DEC VMS, Apollo Domain, Prime OS, DG AOS, Gould MPX, and Apple MacOS. Any "tactical" gain from chosing VAX VMS initially will quickly lose to (a) improvements in VAX UNIX (e.g. DEC's Ultrix) and (b) improvements in the UNIX computing world in general. 3. DECnet is a limited network, limited mainly to Vaxen. TCP/IP is currently the obvious choice for networked laser-printers, terminal concentrators, and so on. As other choices become obvious UNIX will have them, and will have them before any other operating system does. (UNIX already has several networking alternatives, such as XNS.) Ultrix has DECnet, but it should be used only to communicate with your VMS systems. ========== Some non-technical notes: Your computing services manager may already have committed to VMS, so this may be a pointless battle. Unless you have something to lose, though, you should have a long chat with "him" anyway as he should know what he will be up against later. Survey other colleges similar to yours (maybe just scan faculty recruiting ads as mentioned above) and see what they are doing about computing. Your manager probably has done so, make up your own list. Ever since VAX was built, the UNIX vs. VMS question has been asked. I have about 200 kilobytes of answers (mostly in favor of UNIX!) for everything from real time to office automation. As time goes by, the answers change. And it is mostly due to the tidal wave of UNIX engulfing the computing world, making the smaller technical details completely irrelevant. For example, past claims such as "FOO runs only on VMS" took time to answer, now it is simply "DEC shipped/will ship FOO on Ultrix last/next summer." From what I heard at the Ultrix BOF at the last Usenix conference, DEC is now committed to equal development/support of new products on both VMS and UNIX, which may benefit both systems by encouraging competition between the two porting teams. Tom Truscott
rcb@rti.UUCP (Random) (03/01/88)
In article <2235@bsu-cs.UUCP> bzs@bu-cs.BU.EDU (Barry Shein) writes: > >>Hello Unix Wizards! >> >> Our campus is almost on the verge of being turned into a VMS >>filled campus due to the lack of knowledge of the person in charage of >>computing services here. The next couple of months will determine >>what the campus computer scene will be like during the next decade. >>This person has in mind buying Vaxes with VMS, and DECnet with lots of >>money... > >Unix systems are relatively bundled, beyond mere hardware >considerations most Unix systems right out of the box are completely >useable. It can be supplemented in many significant ways with free or >nearly free (eg. ~$100 for an entire campus) software. VMS is heavily >unbundled, from day one if you want so much as a compiler you begin >layering heavy costs. And you'll pay a separate price for acquiring >and maintaining software on every CPU running VMS on campus. This will >quickly lock you out of the workstation market, having to add $100K in >basic software costs to 40 VMS workstations can put a real damper on a >typical University's plans, no matter how good the intentions. > I tried REAL HARD to let this one go by without response. I failed. 1. DEC's new software library makes the cost argument pointless. In the library, some group in your organization is designated as the keeper of the distribution and master manuals. They should be a group that can provide VMS support for the rest of the organization. Other people with vaxes can add their machine to the library for a small yearly cost (cost depends on what you have in the library). They are then licensed for ALL products in the library. The cost here for some 25 products is around $800. This product list also includes Ultrix and DEC's ultrix products (like VMS fortran for Ultrix) 2. Manuals. In the library, any manuals you need your own copy of can be purchased through the library at substantial discounts. (because that will become a single point of volume sales, they can afford it). 3. Support. ALL products in the library are backed up by DEC support. The library group has access to the Telephone Support Center for questions on any product (vms or ultrix). 4. Ease of upgrades. True using vms locks you into one architecture. That means that your nifty graphical product that you wrote on vms may not port to a cray very easily. However, I have been involved in product ports from unix to vms and am familiar with ports from one unix to another and the situation is not much better. I have just as many if not more problems moving software between different versions of unix as I have between unix and vms. The software in question was written in C on unix and had some serious I/O and memory requirements. Just look at all the notices in the sources groups about code that has a bug on machine xyz's unix. --------------- Anyway, enough of the preaching. The above leans a little heavily to the vms side, but only the counter the extreme unix leaning of the previous posting. In my opinion, both unix and vms have a place in a university. There is a LOT of companies out there that have never even heard of unix but have vaxes all over the place. (i hate to say this, but) there is a vastly greater number of companies out there that have nothing but IBM (boo, hiss) computers. If we want universities to prepare students for the real world, we should be teaching them IBM operating systems :-) However, now for the proposal. What you want for your university does not really matter. There is no reason for this either/or argument. Why not do the following. - Buy the vaxes (they run unix just fine) - Set up equal numbers running unix and vms - Allow students to try out both and work on which ever one they like. - Watch the load on the machines and buy more for which ever OS is the most heavily loaded. Simple no? After all, most of the religious flames in this argument I believe come from whatever system the person originally learned on. I learned on VMS, so that's what I use best. I am most efficient on VMS because I know it the best. Most of what I do could be done on either. The real beauty of the DEC software library is that you can switch a machine from one OS to the other easily. We have a lot of workstations around here and people work on both OS's at times. I would like to promote the opinion that that persons vaxstation can run whatever OS they are need for their current project and then change with the next project if need be. Oh well, this is getting too long. That's all for now. -- Randy Buckland (919)-541-7103 Research Triangle Institute rcb@rti.rti.org [128.109.139.2] {decvax,ihnp4}!mcnc!rti!rcb
klb@philabs.Philips.Com (Ken Bourque) (03/03/88)
*>In summary, buying into VMS for a campus is buying into the past in a
*>pathetic, nearly necrophilic way for an academic community.
*>
*>Using it as
*>a campus standard is irresponsible and completely without merit or
*>rational justification and will cripple academic computing for years
*>to come.
*>
*>Unfortunately you may be up against an insidious cancer
*>
*>This is not a religious flame
--
Ken Bourque klb@philabs.philips.com ...!{uunet,ihnp4,decvax}!philabs!klbbpdickson@trillium.waterloo.edu (Brian P. Dickson) (03/03/88)
I have caught the end of another skirmish in a battle that shouldn't exist. Why do I say that, you ask? Because VMS isn't UNIX and vice-versa, which is important in its own right. Because, in an academic environment, exposure to more than one *good* operating system is important. Because they both run on VAXen. There are companies, such as HCR in Toronto, who make UNIX emulations that run *on top of* VMS, making both OS's available simultaneously. This may be avoiding the issue, but for a small campus with only a few machines, this is one route. Pro-UNIX: most of these arguements have been heard. Many vendors, source, portability, the 'net, modifibility, etc. Pro-VMS: not many of these have been mentioned yet: in non-academic environments, DECnet is tremendously useful, because with a very large number of machines, you never worry about paths; however, machine names must be unique. If a large number of campuses connected via DECnet, information could be shared very easily, via DEC's CONFERENCES (basically a cross between UNIX news, and BBS's). Also, if someone makes a file (W:R) readable, you can SET DEFAULT to his *machine & directory*, and do stuff with the file. Security is a larger issue, normally controlled by the addition of machines to the network, and tyrranical managers on each machine. Another thing in favour of VMS is the HELP facility; it can be used to get a lot of useful information about languages as well as utilities; true, not all of the information is always available, but for most languages, syntax, usage, parameters for functions, and structure can be found; the tree structure of help is one of its best features. The main arguement for *how* VMS is intended to be used, most systems written under VMS are intended to be installed commands, which involves more than just putting it in the equivalent of /bin. It is meant for less-than-fully computer literate users. *This does not mean secretaries, as it does with IBM :-)*. This means you can set up an entire system for, say, a research scientist, and the fact that *you* wrote it is invisible to him. (When it breaks, you can blame DEC :-) :-) :-). This means parameter-passing, help, and lots of other things are handled mostly by VMS, not your own programs. Details on CONFERENCES: instead of sending the stuff all over the country, the article remains on the machine, until it is read (ie the contents are sent over via DECnet, but never stored). Each machine/site/cluster does not duplicate stuff; however no single machine has all of the news stuff on it. EG: watmath would have sci.math.*, another machine would have rec.arts.*, utzoo would have sci.space.*, and so on. Less usage of disk space, more usage of the network itself. Great for very specific, high signal/noise ratio, real-news stuff, ie the faculty & grad students on most campuses. ======== Recommendations: Get UNIX *and* VMS machines for undergrads, VMS for grads, faculty and administration, if you can afford it. If not, get VMS with a UNIX implementation running on top. You may need an ULTRIX between other UNIXes and the VMS machines for them to talk, but if most code is written in portable C code, not many problems will arise. -- Brian Dickson
jsloan@wright.EDU (John Sloan) (03/03/88)
in article <1636@tulum.UUCP>, hirai@swatsun.uucp (Eiji "A.G." Hirai) says: > Please help shed the light for us! Please tell us what you think would be > reasons why you wouldn't buy VMS! (or why you would). We need the help > of all you wizards out there. Any examples you can think of will help! I am not a wizard. I manage a laboratory with (as of last week) twenty Unix systems ranging in size from a SUN-3/280S (our principal timesharing system), a cluster (in the generic sense) of SUN-3 workstations with a 3/180S server, a VAX 785, a VAX 750, some NCR Tower 32/600s, and some smaller machines. Most of the engines are ethernetted together, and the VAXen and SUNs are all integrated using NFS and YP to provide a computing environment where CPUs are considered merely peripherals: if you need a bigger one, put it online on the net and use it, and don't worry too much what it is or where it came from. Our of four computer centers on campus (i.e. organizations which have some degree of centralized computing in terms of geographical location and management), we are the only Unix shop, the rest being VMS with one IBM mainframe for administrative work. I am fighting the same fight you are, arguing with the computer center Directors and a Vice President. I object to the term wizard, and if you're smart, you'll drop it too. I am not a wizard, and none of the 2.7 FTE people that work for me supporting our environment are wizards either. Unix _must_ shake the reputation of needing a wizard to maintain it if it is going to be accepted in organizations where skilled labor is expensive and hard to find. I am incredible fortunate, and I know that. I have highly skilled, motivated, educated (most with a M.S. in C.S.), and _experienced_ people working for me, but your typical campus computer center is usually not that fortunate. Our center tried to hire one of my people away (I think I would have gladly let him go, if only to improve conditions at center), and he was seriously considering it until they discovered that he would have to take a pay cut. So much for competitiveness in salary, even within the University, and I can't pay what the people just across the street will pay for the same person. Don't say wizard. Don't say guru. "Systems manager" might be okay. But don't give anyone the idea that you need a wizard to maintain a Unix system because [A] it just isn't true anymore, if it ever was, and [B] it will discourage any migration to Unix. Why Unix? I sit on a committee that reports to our VP for Computing (a CIO in corporate parlance) that is supposed to advise our Computer Center Directors on purchases, policy, procedure, etc. DEC has delivered a proposal for a 6MIPS VAX for $1.2M. Six months ago I purchased, received, and deployed our Sun-3/280S, a 4MIPS engine for under $100K. Question: which is the better deal? Answer: The $1.2M VAX. Because it runs VMS. Never mind that for CPU intensive applications (which is predominantly what we're talking about here) the VAX is _eight_ times more expensive (with comparable amounts of disk space and memory) than the Sun. The Sun doesn't run VMS. The time has come for us to realize the _true_ cost of proprietary technologies. When you run VMS you have _one_ name in your rolodex card file, and it says "Digital". It is no longer a question of getting the most for your money; it is a matter of finding out from your sales rep how many zeros to write on the check. There is another issue than capital investment: intellectual investment. Unix has a reputation as being user hostile or having a steep learning curve, and yet once that learning curve has been achieved, your intellectual investment is protected across an incredible number of machines and models for many many vendors. Sure, there are differences between the system calls or management from system to system, but at least I can sit down and immediately begin editing, manipulating files, using tools, helping me while I learn those differences. And for many users, there _is_ no difference. When we moved our faculty off our 750 onto the 3/280S, the only difference (besides vastly improved response time) that they noticed was that the role or "R" and "r" in the mail command was reversed... which lasted until we figured out how to change it. These two machines are from different vendors, and have different architectures, but they had one thing in common: both had common roots in Unix. There are financial considerations here too, in terms of productivity and training costs. I spent five years as a systems programmer in an IBM mainframe environment, and when I left I was the senior technical resource in my shop. I spend two years in a PDP-11 environment, two years in a VAX/VMS environment, and the past two years in our current Unix environment. I can say without reservation that Unix is the most useful, most productive, and most (dare I say it?) _friendly_ environment that I, as a professional programmer and manager, have ever had the pleasure of using. Subjective opinion? Hmmmmm.... perhaps. But I'm not so sure. In the end, you will have to find your own justification, your own strategy. On my end, I am confident that the University will continue to fritter away the taxpayers money on proprietary technologies, while I work hard on providing the best, most cost effective computing environment for the money. I apologize for the length of this. I know, few hard facts, mostly just soapboxing. Perhaps it will prompt some discussion. I wish you luck. -- John -- John Sloan Wright State University Research Center CSNET: jsloan@SPOTS.Wright.Edu 3171 Research Blvd., Kettering, OH 45420 UUCP: ...!cbosgd!wright!jsloan (513) 259-1384 (513) 873-2491 Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/03/88)
In article <284@wright.EDU> jsloan@wright.EDU (John Sloan) writes: >DEC has delivered a >proposal for a 6MIPS VAX for $1.2M. Six months ago I purchased, >received, and deployed our Sun-3/280S, a 4MIPS engine for under >$100K. I forwarded this and two previous articles on this theme from comp.unix.wizards to comp.os.vms because I thought they deserved wider circulation. The UNIX versus VMS battle was lost and won some years ago, around 1984, I think. It's all moot now. But if you still discuss it, it would be a good idea to let both comp.unix.wizards and comp.os.vms readers follow it. It will also add balance, since the real VMS defenders are all in comp.os.vms. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
ross@swan.ulowell.edu (Ross Miller) (03/03/88)
In article <2235@bsu-cs.UUCP} bzs@bu-cs.BU.EDU (Barry Shein) writes: }The basic problem with VMS is that it locks you into a single hardware }architecture and vendor. In this day and age that severely limits what }you can purchase in computing power. Vaxes vary widely in price but }not much in processing power. For example, a small uVax-II sells for }around $30K and offers a little less than 1 MIP. An 8750 sells for }perhaps $500K and offers a few MIPs. In the near future this range }closes even further, the uVax-3 being around 1/2 the processing power }of the top end with a price range of ten-fold. It's hard to buy worse }price-performance. Agreed that VMS locks you into a single hardware vendor. But the MIPS argument doesn't hold up. MIP =} Mythical instructions per second. IO throughput is not being recognized in this argument. An 8650 here easily handles 70 people in compile edit link mode with an HSC70 on it. It is rated at 6Mips or so. Try putting 70 people on 6 MicroVax IIs. Price performance on unix machines is generally better, but the DEC hardware and VMS software is real reliable. HSC's make things move right along also. People seem to think of a Vax and they think of a wimpy little 780. The high end 8000 series processors are great for academic applications be they running VMS or Ultrix. Let's not forget that DEC does sell a Unix product. Let's not forget that Unix started out specifically on DEC products and does tend to run very well on DEC machines because of this. ... stuff deleted to save space ... }Unix systems are relatively bundled, beyond mere hardware }considerations most Unix systems right out of the box are completely }useable. I agree. }It can be supplemented in many significant ways with free or }nearly free (eg. ~$100 for an entire campus) software. VMS is heavily }unbundled, from day one if you want so much as a compiler you begin }layering heavy costs. Yes, but DECUS certainly does have a great deal of stuff available. I still haven't gotten through all my tapes. }And you'll pay a separate price for acquiring }and maintaining software on every CPU running VMS on campus. This will }quickly lock you out of the workstation market, having to add $100K in }basic software costs to 40 VMS workstations can put a real damper on a }typical University's plans, no matter how good the intentions. Yup, I agree DEC has to fix this soon or they will lose. Again though you can run Ultrix on a DEC machine and this does alleviate many of these problems. But LAVC is nice. }Unix is the premiere system for compute intensive areas, such as the }sciences using Fortran. Huh, unix fortran is known to rot. Proprietary fortrans that may happen to run on a unix box are good, but milage will vary greatly. }The reason is the vast range of power a }program written to run under Unix presents. As I said, a program }developed on a small, affordable PC or workstation can be copied and }re-run on huge compute engines. Although a lot of the sciences in the }past used VMS they now generally realize that this was an error and }the communities are rapidly switching to Unix, any argument that }science is done on VMS is a false argument of the past. Science is done??? A scientist would explore all systems to look at the usefulness of each, otherwise the scientist is a close minded person and by definition not a scientist. } You should }poll major science depts and research labs. If nothing else, the fact }that the Cray and other super-computers run Unix has pushed the }equation in this favor, a person using VMS is essentially locked out }of the entire NSF super-computer initiative. Woha there, crays also run in Vax Clusters running VMS. Just think real IO speeds of 80Mbits per second achievable, instead of the 2 or 3 Mbits per second of an ethernet controller. }Decnet would tend to }reaffirm this retardation (TCP can be had on VMS but it's sort of like }teaching a pig to dance, speak to VMS sites and they'll tell you what }a general pain in the ass it is to deal with third party vendors, }network software breaking on each O/S release etc etc.) Most companies if kicked long and hard enough will try to resolve a problem like this. I think that in the in DEC will be forced to also. }These admins will sneer at things like X-windows, lisp }(which doesn't cost $10K/node), AI systems etc in preference to their }big-name commercial databases and spread-sheets as if what students }and professors do is not to be taken seriously, then why are they on a }campus? Ah, but remember that the purpose of a campus is to teach. To teach these big name data bases is useful since they are the most powerful and the most used when the student will go out into industry. But, on the other hand Ingres, one of the biggest and most powerful, has its roots in unix. Let's not forget that DEC did make Ada available at 1k per node, versus at the time all the 20k compilers. This was for academic institutions only I belive. So the horse is not black or white, it is grey. }It's no accident that both Athena and Andrew have chosen Unix }for their massive campus computing projects. Oh, Athena great sucker upper of money, that Athena. I am less than impressed with a 30Million dollar window package. }Unix makes available the forefront of hardware technology, parallel }processing from companies like Encore, Sequent, BBN (Butterfly), RISC }and the so-called "super-workstations" like Sun/4, MIPS, HP etc. which }can deliver nearly 1MIP/$1K of price. Unix was easy to port. Yea unix. }The parallel processor provide }time-sharing systems extending into the hundreds of MIPs, again for }about $1K/MIP. Anything new and innovative runs Unix, not VMS, it }would be foolish to lock an entire academic community out of all this. }I can understand why a bank is not particularly concerned, but why a }(supposedly) active research community? Why lock yourself out of all }this. The VMS salesthings will claim that they're going to do all this }*in the future*, they've been saying that for years and years, and }when they do come out with something it tends to be too little too }late, in name only, like a dual processor 8800 which barely exploits }what tiny parallelism it has. Yea, but unless you've been on Mars you know that VMS 5.0 will take advantage of the multiprocessor machines. Also the busses in question can support more than two cpus. A parallel machine with IO throughput? ... points raised about VMS not being modern, I sorta agree ... }The claim that Unix is somehow less secure than VMS is a red herring. }Unix offers sufficient security for campus systems, you're not the NSA }(again the tactic of arguing that VMS is better for things you don't }need.) Unix is easy to crack. I have never seen a gugu for VMS. I have seen people break into machines to shut them down because a known power outage was coming and the person with the root password was not around. Also unix varies greatly in integrity from machine to machine. }More importantly, many Unix systems are available with full }sources for a modest price, typically $1000/campus (it's simply a }matter of your vendor choices, more than you can say for VMS where }there is no choice.) Without the sources you are, at best, at the }mercy of the vendor for security. A huge security hole which is }bringing you to your knees (which happens regularly on VMS, and the }news travels the networks like wildfire) leaves you helpless and at }the vendor's whims as to whether or not they feel like closing the }hole this week, or next month, or put it off for next release. In all fairness you can get the sources via microfiche. When DEC does learn of a problem it seems that they do ship out the update within a month or two. It is a problem not having sources, at a reasonable price though. }In fact their concern with only commercial DP makes them *less* }interested in your security problems. Banks don't have malicious }students exploiting security holes and don't tend to notice such }things or complain about them. With Unix and the sources you can at }least plug up the hole by a code change and then call the vendor and }wait for the real fix, at least you'll be up and running until then. }Don't believe that VMS sources are available, it's a lie, demand to }see prices for all items needed such as Decnet sources. Demand to be }told what resources it would take to even manage such sources. Last I }checked it required the dedication of a few hundred thousand dollars }in hardware (basically, an entire larger Vax with large disks) to }manage sources. Yep, but they are available, but rediculous to get. Don't forget that you need a $8000 Bliss compiler, and they won't guaruntee that it will compile. }Obviously the sources will also be of enormous benefit in answering }user questions, such as tracking down example code using particular }system calls. You can sort of do this with VMS's microfiche, if you }consider searching through microfiche for a particular system call }usage a good way to spend your time. You can't grep microfiche. Even }then you'll usually find that the way the system application }accomplishes what the user seems to want to do is by exploiting some }privilege you won't want to give to a user (I'm not sure I want to go }into the whole mess of the zillions of VMS "privilege" bits which }you'll never fully understand the implications of and will almost }surely end up giving away the store because some reasonable thing can }only be accomplished by giving a user some dangerous privilege bit, }Unix's single privilege scheme [root or not root] is much more secure, }you just don't give out root privs and you know exactly what can and }cannot be done by the two sets of users on your system, who wants to }calculate the permutations of 30+ priv bits and what they might imply }singly and in combination?.) I disagree. It is nice to be able to give moderate level operator type students OPER, to do operator things but not everything. There are a lot of bits and they do get complicated, but then usually a more complicated system has more power. For example it is somewhat harder to get a root DCL on VMS because what is a root DCL. That DCL process will only have the priveleges it stole, not all of them. ... VMS is a hodepodge ... }In an academic community one merely has to go into a campus bookstore }to see another argument. Look at all the Unix books! Where are the VMS }books? They are in my bookstore, right next to the Unix books. That wall of orange is also unquestionably better and easier to read than the Unix Docs. But I would like to see the VMS Docs on line in a better format than help. }There are none. A complete set of Unix manuals costs less than $100, a }more than sufficient set costs perhaps $50. A complete set of VMS docs }costs several hundred dollars, no student or even faculty member }(except the few richest) can afford to own a documentation set for }VMS. There's some on-line help in VMS but it's designed to sell }manuals or supplement them, the details are always missing }(purposely.) You pay for what you get in this case. }Most Unix systems come with on-line, complete manual sets with the }exact same text used to produce the printed manuals. Thus, what's the }cost to a student for Unix manuals? For $0 (zero) they can get }everything, if they like manuals in their laps they can buy those for }the cost of a couple of textbooks. But there is a cost to the instituion of each student printing these out. I am not saying that is bad, but there is a cost. ... note enough academic texts for VMS, I agree ... }So, running courses on VMS will mean foresaking textbooks. Very clever! }Good plan for running an academic environment! It's no accident, the }DEC/VMS crowd has no interest in academia, your sysadmin has DP-envy. DEC got where it is from academia. I have seen them trying, but being very torn about which direction to go. ... Decnet does not connect with the Arpa net ... }And you can forget uucp and usenet entirely, which means no e-mail }to vendors etc. I believe there are implemenations of both. Tek tcp is also reasonably priced. }In summary, buying into VMS for a campus is buying into the past in a }pathetic, nearly necrophilic way for an academic community. It locks }them out of the mainstream in Computer Science, Engineering, the }Sciences and many of the humanities (all the multi-media projects of }any interest are being done on either Unix or or Macintosh/PC }systems.) Isn't the Machintosh guilty of many of your arguments. A much better argument would be Unix or a Commodore Amiga. The Amiga has supported TCP/IP, FTP, TELNET for at least a year and a half that I can remeber, and has had NFS for a while. Much more reasonable for people wanting to link in with Unix boxes at high speed. }It has very little to offer an academic community for either }research or coursework. It is flying in the face of nearly all trends }in computing today and doing so at such a high dollar price that it }borders on irresponsible. This is not to say that there is no need for }even one VMS system on your campus, there probably is. But using it as }a campus standard is irresponsible and completely without merit or }rational justification and will cripple academic computing for years }to come. What other campuses do this? Yes I would agree that as a campus standard it is not the way to go. There should be no campus standard. Students should have access to many things to explore. }This is not a religious flame, I have presented myriad factual basis }for my arguments. VMS people like to claim religious flame and }"chocolate vs vanilla!" arguments. This is because they cannot deal }with the real issues so making it a political war can only act to }their advantage. Avoid the issues, get the opponents fired, scare a }campus administrator with false promises of donations etc. }Unfortunately you may be up against an insidious cancer you only }barely understand which will manipulate your organization in ways you }will regret. } -Barry Shein, Boston University You forgot NFS. Let's not forget the Network File System of Unix. Clearly a great boon to the argument of unix over VMS. Ross -- csnet: ross@swan.ulowell.edu uucp: ross@swan.ulowell.edu || ...harvard!ulowell!ross Trust the computer. The computer is your friend.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/03/88)
In article <68@musky2.MUSKINGUM.EDU> terrell@musky2.UUCP (Roger Terrell) writes: > >VMS ADVANTAGES: > - VMS is much more secure, although this does not mean much in an >academic environment unless there is a lot of research and/or the >administrative people are paranoid. There is a widely-held belief that the less an environment allows people to do, the more secure it must be. By this strange definition, the ultimate in security is achieved by not letting anybody log in at all. VMS wins very easily, then, since each user's authorization record has a DISUSER field. In one fell swoop you can disuser all your users, since the relevant command will accept wildcards. However, I prefer to believe that the more you can let your users do without harming the system, the better your system's security is. The ideal secure system would put no restrictions at all on what users could do, yet it would not be maliciously crashable or allow privacy to be breached. (It would also unfortunately succomb to Russell's or a similar paradox and presumably vanish in a puff of logic.) UNIX does come pretty close, though. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
u8551087@ucsvc.dn.mu.oz (03/03/88)
In article <2235@bsu-cs.UUCP>, bzs@bu-cs.BU.EDU (Barry Shein) writes: > >>Hello Unix Wizards! >> >> Our campus is almost on the verge of being turned into a VMS >>filled campus due to the lack of knowledge of the person in charage of >>computing services here. The next couple of months will determine >>what the campus computer scene will be like during the next decade. >>This person has in mind buying Vaxes with VMS, and DECnet with lots of >>money... > > The basic problem with VMS is that it locks you into a single hardware > architecture and vendor. In this day and age that severely limits what > you can purchase in computing power. Vaxes vary widely in price but > not much in processing power. For example, a small uVax-II sells for > around $30K and offers a little less than 1 MIP. An 8750 sells for > perhaps $500K and offers a few MIPs. In the near future this range > closes even further, the uVax-3 being around 1/2 the processing power > of the top end with a price range of ten-fold. It's hard to buy worse > price-performance. > > The Unix market ranges from PC based Unix systems which the average > student can afford (and this area is expanding rapidly) to the Cray-2, > a premiere super-computer, and just about everything in between. In > the middle market (typical small-medium scale time-sharing) one can > buy Unix systems from various vendors with upwards of ten times the > price performance of VMS. > > Unix systems are relatively bundled, beyond mere hardware > considerations most Unix systems right out of the box are completely > useable. It can be supplemented in many significant ways with free or > nearly free (eg. ~$100 for an entire campus) software. VMS is heavily > unbundled, from day one if you want so much as a compiler you begin > layering heavy costs. And you'll pay a separate price for acquiring > and maintaining software on every CPU running VMS on campus. This will > quickly lock you out of the workstation market, having to add $100K in > basic software costs to 40 VMS workstations can put a real damper on a > typical University's plans, no matter how good the intentions. > > Unix is the premiere system for compute intensive areas, such as the > sciences using Fortran. The reason is the vast range of power a > program written to run under Unix presents. As I said, a program > developed on a small, affordable PC or workstation can be copied and > re-run on huge compute engines. Although a lot of the sciences in the > past used VMS they now generally realize that this was an error and > the communities are rapidly switching to Unix, any argument that > science is done on VMS is a false argument of the past. You should > poll major science depts and research labs. If nothing else, the fact > that the Cray and other super-computers run Unix has pushed the > equation in this favor, a person using VMS is essentially locked out > of the entire NSF super-computer initiative. Decnet would tend to > reaffirm this retardation (TCP can be had on VMS but it's sort of like > teaching a pig to dance, speak to VMS sites and they'll tell you what > a general pain in the ass it is to deal with third party vendors, > network software breaking on each O/S release etc etc.) > > The typical claim by the campus administrator is to point at all the > myriad applications and big-name software that runs on VMS and doesn't > run on Unix. In the first place, most of this now does run on Unix so > that tends to be an anachronistic view. Another point is that such > admins usually have DP-envy. No one on the campus has any need for any > of the big-name applications the person is bragging about, you're > running an academic environment, not a bank! Get a list of these > applications and you'll see how ludicrous this consideration is. Unix > tends to vastly dominate the academic community in software > availability. These admins will sneer at things like X-windows, lisp > (which doesn't cost $10K/node), AI systems etc in preference to their > big-name commercial databases and spread-sheets as if what students > and professors do is not to be taken seriously, then why are they on a > campus? It's no accident that both Athena and Andrew have chosen Unix > for their massive campus computing projects. > > Unix makes available the forefront of hardware technology, parallel > processing from companies like Encore, Sequent, BBN (Butterfly), RISC > and the so-called "super-workstations" like Sun/4, MIPS, HP etc. which > can deliver nearly 1MIP/$1K of price. The parallel processor provide > time-sharing systems extending into the hundreds of MIPs, again for > about $1K/MIP. Anything new and innovative runs Unix, not VMS, it > would be foolish to lock an entire academic community out of all this. > I can understand why a bank is not particularly concerned, but why a > (supposedly) active research community? Why lock yourself out of all > this. The VMS salesthings will claim that they're going to do all this > *in the future*, they've been saying that for years and years, and > when they do come out with something it tends to be too little too > late, in name only, like a dual processor 8800 which barely exploits > what tiny parallelism it has. > > VMS itself is not an interesting operating system to learn or study. > It is basically a re-work of RSX, an ancient real-time operating > system from the PDP11 (Unix also ran on the PDP11 years ago, but it > has grown in modern ways, as opposed to VMS's habit of just accreting > whatever features were needed to meet the next big govt contract.) > > The claim that Unix is somehow less secure than VMS is a red herring. > Unix offers sufficient security for campus systems, you're not the NSA > (again the tactic of arguing that VMS is better for things you don't > need.) More importantly, many Unix systems are available with full > sources for a modest price, typically $1000/campus (it's simply a > matter of your vendor choices, more than you can say for VMS where > there is no choice.) Without the sources you are, at best, at the > mercy of the vendor for security. A huge security hole which is > bringing you to your knees (which happens regularly on VMS, and the > news travels the networks like wildfire) leaves you helpless and at > the vendor's whims as to whether or not they feel like closing the > hole this week, or next month, or put it off for next release. > > In fact their concern with only commercial DP makes them *less* > interested in your security problems. Banks don't have malicious > students exploiting security holes and don't tend to notice such > things or complain about them. With Unix and the sources you can at > least plug up the hole by a code change and then call the vendor and > wait for the real fix, at least you'll be up and running until then. > Don't believe that VMS sources are available, it's a lie, demand to > see prices for all items needed such as Decnet sources. Demand to be > told what resources it would take to even manage such sources. Last I > checked it required the dedication of a few hundred thousand dollars > in hardware (basically, an entire larger Vax with large disks) to > manage sources. > > Obviously the sources will also be of enormous benefit in answering > user questions, such as tracking down example code using particular > system calls. You can sort of do this with VMS's microfiche, if you > consider searching through microfiche for a particular system call > usage a good way to spend your time. You can't grep microfiche. Even > then you'll usually find that the way the system application > accomplishes what the user seems to want to do is by exploiting some > privilege you won't want to give to a user (I'm not sure I want to go > into the whole mess of the zillions of VMS "privilege" bits which > you'll never fully understand the implications of and will almost > surely end up giving away the store because some reasonable thing can > only be accomplished by giving a user some dangerous privilege bit, > Unix's single privilege scheme [root or not root] is much more secure, > you just don't give out root privs and you know exactly what can and > cannot be done by the two sets of users on your system, who wants to > calculate the permutations of 30+ priv bits and what they might imply > singly and in combination?.) > > The programming and system interfaces in VMS are arcane and just a > hodgepodge of features, there's no particular underlying design > philosophy, just whatever marketing wanted this week. Although VMS has > some interesting software features it's nearly impossible for anyone > but a very experienced programmer to take advantage of these. This is > not really a damnation of VMS, VMS is a platform for delivering > turnkey applications software, like databases in commercial > environments for people who wouldn't think of programming in general, > just data entry and report generation. I'm *sure* this is > representative of your needs (hah!) > > In an academic community one merely has to go into a campus bookstore > to see another argument. Look at all the Unix books! Where are the VMS > books? > > There are none. A complete set of Unix manuals costs less than $100, a > more than sufficient set costs perhaps $50. A complete set of VMS docs > costs several hundred dollars, no student or even faculty member > (except the few richest) can afford to own a documentation set for > VMS. There's some on-line help in VMS but it's designed to sell > manuals or supplement them, the details are always missing > (purposely.) > > Most Unix systems come with on-line, complete manual sets with the > exact same text used to produce the printed manuals. Thus, what's the > cost to a student for Unix manuals? For $0 (zero) they can get > everything, if they like manuals in their laps they can buy those for > the cost of a couple of textbooks. To supplement that they can buy any > of dozens of titles on Unix ranging from the structure of the > operating system, systems programming, compiler construction, > applications programming, AI, many programming languages, shell > programming, text processing etc etc. For VMS you'll be lucky to find > two titles (I can only think of one, the Internals book, and that's > hardly a text, oh yeah, there's an assembler textbook, both of those > are about five years old and don't even refer to the current VMS > system so you won't be able to use their code etc.) > > So, running courses on VMS will mean foresaking textbooks. Very clever! > Good plan for running an academic environment! It's no accident, the > DEC/VMS crowd has no interest in academia, your sysadmin has DP-envy. > > Decnet nearly completely locks you out of wide-area networking, such > as the arpanet. One need only look at the arpanet's University rolls > to see who you are abandoning, merely the foremost schools and > research labs in the country. About 95% of them use Unix systems to > hook up to the arpanet. Decnet is completely useless in this regard. > There are a couple of strange, semi-wide area networks based on DECNET > (few people could name them.) Perhaps one or two of your faculty > would like to be on them. You should buy them a microvax and get on > with the rest of the campus' needs, don't let the tail wag the dog. > > And you can forget uucp and usenet entirely, which means no e-mail > to vendors etc. > > In summary, buying into VMS for a campus is buying into the past in a > pathetic, nearly necrophilic way for an academic community. It locks > them out of the mainstream in Computer Science, Engineering, the > Sciences and many of the humanities (all the multi-media projects of > any interest are being done on either Unix or or Macintosh/PC > systems.) It has very little to offer an academic community for either > research or coursework. It is flying in the face of nearly all trends > in computing today and doing so at such a high dollar price that it > borders on irresponsible. This is not to say that there is no need for > even one VMS system on your campus, there probably is. But using it as > a campus standard is irresponsible and completely without merit or > rational justification and will cripple academic computing for years > to come. What other campuses do this? > > This is not a religious flame, I have presented myriad factual basis > for my arguments. VMS people like to claim religious flame and > "chocolate vs vanilla!" arguments. This is because they cannot deal > with the real issues so making it a political war can only act to > their advantage. Avoid the issues, get the opponents fired, scare a > campus administrator with false promises of donations etc. > > Unfortunately you may be up against an insidious cancer you only > barely understand which will manipulate your organization in ways you > will regret. > > -Barry Shein, Boston University
mcpherso@msudoc.ee.mich-state.edu (Mike McPherson) (03/03/88)
Can we *please* stop the UNIX vs. VMS argument. We have both, we like both. <flame on> YOU PEOPLE ARE WASTING MY TIME!!! <flame off>
garry@batcomputer.tn.cornell.edu (Garry Wiegand) (03/04/88)
In a recent article mcpherso@msudoc.UUCP wrote: ><flame on> > > YOU PEOPLE ARE WASTING MY TIME!!! > ><flame off> Go away, please. We have both, we like both too. But, as professionals, it's always interesting to discuss what makes a good computer. The VMS vs Unix holy war is unusually fun and enlightening because people have such strong opinions and ideas about it. Most of what goes by on these newsgroups can be classified as "data" - people reporting random bits of technical info to each other. Topics that inspire people to *think*, on the other hand, are rare. I've gained a *lot* more enlightenment from "Unix vs VMS" than from all the usual grungy junk around here. Harrumph. garry wiegand (garry@oak.cadif.cornell.edu - ARPA) (garry@crnlthry - BITNET) PS - I'd like to publicly thank Barry Shein for a very good pro-Unix (or pro-both) posting. I'm generally pro-VMS (ie, DEC's "style" of doing things is closer to my own than the Unix authors' style is), but Barry's arguments were practical and carefully put.
landauer@morocco.Sun.COM (Doug Landauer) (03/04/88)
> As professionals, > it's always interesting to discuss what makes a good computer. The VMS > vs Unix holy war is unusually fun and enlightening because people > have such strong opinions and ideas about it. Besides, it's been at least six months since the last time this particular war erupted, so there's a whole new semester's worth of freshmen to be won! :-) Perhaps it's time to add this subject to the news.announce.newusers list of topics that have been rehashed so often that the net.vets are tired of it. (Or to add a new article to that suite, creating that list.)
ward@cfa.harvard.EDU (Steve Ward) (03/05/88)
The DEC Educational Software Library with DEC workstations scenario is
great, but has one very large problem:
When a MULTIUSER VMS LICENSE is needed beyond the basic 2-user VMS
license then the trouble begins. First, DEC will not under any
conditions sell a multiuser VMS license upgrade for a workstation,
period. Second, this means you must buy non-workstation machines with
multiuser VMS licenses for your multiuser needs. This sacrifices the
flexibility of upgrading a workstation, causing the purchase of extra
computers and software, and even worse, DEC workstations are available
for purchase by educational/research entities (by and large, your
mileage may vary) at excellent price discounts while the multiuser
system are not.{ VMS itself is priced outrageously high if it cannot
be purchased via the educational library, which is definitely the case
for VMS multiuser licenses.
If you have a scenario that will only call for workstations then these
concerns won't apply, otherwise, give it some thought.
Further concern is warranted in the area of network support costs. For
VMS DEC offers many network software support tools, but they tend to be
outrageously expensive and are not part of the educational library. In
my context "outrageous" means pricing that is radically higher than the
cost of any other software/hardware item available at the educational
library or workstation discount pricing. I consider ratios of greater
than 2/1 very significant. The encountered ratios of 5/1 to 25/1 are
easily outrageous.
I hope that DEC will someday offer such things as Remote System Manager
(software) at a price scaled to the economies they offer in other
elements of their educational/research sales programs. Sometimes it
seems that DEC is trying to "make up" some lost profit ground by letting
you buy in cheap and add-on expensive, especially with anything in the
VMS realm.ward@cfa.harvard.EDU (Steve Ward) (03/05/88)
I have many complaints about VMS and DEC educational/research sales
policies, but I have{ lots of positive comments, too.
Relax, I know Unix is a{ lifestyle and VMS is only an operating
system, but it isn't as bad as some (B. Shein) say.
VMS has an excellent Fortran compiler and any serious Fortran number
cruncher in research will cry its virtues. Unix only has one Fortran
compiler{ in the same league with the VMS compiler, and it is the DEC
Fortran-for-Ultrix compiler.
VMS manuals are very expensive.
VMS programming interfaces are overly complicated, often remaining
confusing even after wading through massive manuals, believe me, this
stuff is arcane. Go to a native IBM OS for a real taste of arcane.
VMS is fast and has fewer bugs and breakdowns than most OS's. There are
different levels at which you can program the file system and I/O, the
general areas of complication. This helps a little. Unix is no picnic
in the I/O area, either. It seems every Unix port has different I/O
system calls or the same names with different arguments -- how about all
those different IOCTL's? Of course, simple things are done fairly
easily in either Unix or VMS. Writing system-level code can be painful
in Unix or VMS, but give me Unix for system code anyday (90% less grief,
but the remaining 10% can be BIG).
Neither Unix or VMS makes an interesting OS design or theory study.
They are both old and both have good features and bad features.
Certainly these features should be studied in the learning process but
OS research lies in writing/simulating new OS's or features. Having
ready access and control of the entire computer hardware (for arbitrary
reboots, crash analysis, etc) is probably important here, along with
decent cross-asembler and cross-compiler support. Two of the same
machine is always nice for OS work, one for compiles and one as a guinea
pig. Allright, I admit it, I'd rather do this from Unix, but since I
use both OS's, I must say it matters little whether the compile engine
is running VMS or Unix.
We have researchers using the NSF supercomputer facilities from VMS and
Unix workstations via DECNET networks and the Internet, so this is a
wash.
Certainly VMS is no more "in the past" or "necrophilic" than Unix, Mr.
Shein. When all is said and done, Unix and VMS have many pluses and
minuses. The priorities of a given situation will apply weights to
these plusses and minuses and will result in a choice. In most cases a
fair evaluation will result in a tough decision. I prefer Unix because
VMS layered software products are so expensive. The other differences
are a wash for me because I am not interested in a single (or a few)
salient feature. As I said, the pros and cons of both OS's abound, but
largely balance out.
I prefer open architecture and hope that POSIX and IEEE standardized
Unix are realized in the marketplace.
The thrust of my comments are to offer some responsible balance to the
emotional anti-VMS rhetoric. This is not an attempt to "prove" anything
, just to give DEC and VMS a chance at a fair shake. Except for some
economic arguments I think that most of the VMS/Unix complaints and
praises balance out or can be reduced to personal preferences.
Now, to get to work on what will be the real "best" OS ..... (ha!)....
.exodus@uop.edu (G.Onufer) (03/05/88)
VMS --- Just say NO!
bzs@bu-cs.BU.EDU (Barry Shein) (03/05/88)
From Steve Ward: >VMS has an excellent Fortran compiler and any serious Fortran number >cruncher in research will cry its virtues. Unix only has one Fortran >compiler{ in the same league with the VMS compiler, and it is the DEC >Fortran-for-Ultrix compiler. Serious Fortran number crunchers in research use Vaxes? I think that's an oxymoron, even DEC's largest machine can't be considered a serious number cruncher's machine in this day and age, and that was my only point, VMS locks you into Vaxes and Vaxes can no longer be taken seriously by people with compute intensive needs. Whatever perceived niceties there are of programming Fortran under VMS (and I don't dispute them) are sort of lost when you lack the computational power to run that code, no? Let's not hash terms, we're talking number crunching (we both have used that term now), finite element analysis, matrix inversions etc. In fact, I think DEC has done an unfortunate disservice, more of a sociological phenomena, by plying to the scientific community and then leaving them out in the cold with incompatible fortran and no iron to grow into and remain competitive with their more nimble colleagues. Most of us noticed this problem during the huge gap between the 780 and the 8600 releases. -Barry Shein, Boston University
rrk@byuvax.bitnet (03/05/88)
How did this rot get here? I admit I have probably written similar inacruacies about unix (Eunuchs?) systems in my day, and will probably do more in the future, but this writer doesn't know much about VMS on the inside. Some of his points are based on correct facts, but are a very narrow view, while others are just plain wrong or ignorant. VMS is single hardware architecture and operating system. That is it's great strength. That is why it is not a mess of add-ons and doing things with an already out of shape architecture. Anyone who has followed DEC knows that if DEC takes a new direction, just about everything follows and it affects the system at all levels. Old things become "jacket" routines which call the new, and everything follows the new scheme. DEC has done many things with their architecture that UNIX will never do, because UNIX really wasn't designed. It just kind of happened. We can follow up with specific examples, if you like, but I noticed that the original article didn't bother in its many pages. VMS most definately does not lock you into an architecture or a hardware. I know of no OS that communicates with others like VMS. I would suspect that VMS communicates with Unix as well or better than many other unix's. There are many network configurations for bringing in DOS PC's and other strange animals that I've never heard of in the PC world. I run WordPerfect under VMS and DOS. I can use its file manager (last time I tried) to list files accross DECNET on a unix machine, or on the hard drive or floppy of my PC. I can make a VMS drive look like a hard drive on my PC's and I can save a document on my PC and then use a DCL command to send it directly to a print queue where VMS will pass control to WordPerfect routines which will translate the document for the destination queue it happens to print on--which may not be determined until long after the user logs off and may be on another node of the VAX cluster. Cerrtainly once you start using VMS you will become dependant on it for all the things that the other O/S's don't give you. If this is what you meant when you said you are locked into it, then I agree. But VMS doesn't lock you into one O/S, although I can see how you might have assumed this coming from the UNIX world where you are locked into one O/S. If you really want to, you can put UNIX on half of your machines until people voluntarily stop using it and defer to VMS. From what I have seen of UNIX running on a VAX, it consumes much more system overhead than VMS, so the higher VMS price is at least partially justified. If you spend half a million on new hardware, do you want to save a few thousand dollars on your O/S and have it eat half your investment? There would be no problem with running UNIX on your non-VAX equipment. Yes, the software for VMS is more expensive and unbundled, but if I were counting on something being supported and upgraded and improved, I would go for the one with the price tag every time. Sure, there are PD compilers out there for VMS as well, some of them quite good, but if you want the good one, development usually isn't done for free. I believe you will find the VMS fortran that you pay for compatible and fast. As far as the communities "rapidly switching to UNIX", as far as it goes on VAX's, the existing base of VAX's is (last time I checked) 60% VMS, 40% UNIX. The new VAX's being shipped are about 80% VMS, 20% UNIX. I suppose this could be reconciled if it could be shown that such communities were a relatively small segment of the market, or that they were steering away from VAX's in general. I'm not in a position to know that. I program heavily in assembly language, and know that the code produced by the "C" compilers is very inadequate--even under UNIX. I have helped optimize it for students on several occasions. It is the design of "C" that procludes lots of optimization that I consider important. Maybe that's why the O/S doesn't stack up next to VMS. I work on a major program which is being ported to most machines known to man, and the UNIX implementation will never be what the VMS one is, because the UNIX environment is not well defined. Yes, get a list of these applications that run on the VAX. Try the newest VMS software sourcebook for just a beginning. They are not useless. The only major thing is that they are sometimes expensive, but many cannot be had or can only be had in mutilated forms under UNIX, due to the great lack of hardware or O/S integrity under UNIX. DEC has realized the error of their ways. Xwindows will be an integral part of VMS 5.0 which will be released soon. It's funny, all the new and innovative things I've seen run only under VMS. The things usually requested from the UNIX world are utilities like MORE, for UNIX users who haven't learned how to get around under VMS. MORE is nice (although a bit cryptic from what I've seen) but is a long ways behind what I would call "new" or "innovative" watch this list for such requests. But why argue... for those who want UNIX, let there be UNIX, and for those who want the O/S to do all the mundane things for them and leave them free for more creative pursuits, so that they don't have to reinvent indexed files and other things like interfaces and specialized utilities every time they want to use them for something new, let there be VMS. They cryptic comments about a study of the O/S's are just an ignorant apology for the lack of the well-defined and implemented features which UNIX doesn't have and if it ever does, it will be because it copied DEC's O/S as in the past. True enough, the VMS sources are only available under a special license (about $30,000 last time I checked). Interesting, isn't it then, how all the best software is being written for the VAX. You don't have to modify, or even read the source code to be able to use the O/S. Do you ask the manufacturer of a spreadsheet for the sources so that you can run it? Or how about an editor, or other utilities. No. You want documentation. VMS documentation generally suffices. The VMS sources would fill many disks and be unmanageable. That's why documentation was written. Routines are supposed to have nice interfaces. The online VMS help on a normal VMS system (not tailored out of size considerations) gives fairly detailed information on every parameter to every common system service and run-time library routine. Using this information, someone familiar with VMS documentation conventions (yes, under VMS we have conventions) can call any of these system services or routines. You can extract system structure or constant information from system libraries. If the UNIX documentation were as large and complete as the complete VMS documentation, I doubt there would be room for it on disk eithe, althoough you can order complete documentation on-line, but you'd better order more disks. This is a real operating system and a thorough documentation. Any decent documentation will provide you with user-level examples, and not refer you to the sources for examples. Obviously UNIX documentation must require that. As for being able to modify VMS, the reason why DEC sat down before hand and designed VMS was so that there would only have to be one VMS which satisfies everyones needs. When you modify the basic UNIX to try to make up for its inadequacies, you just complicate things. When you use a nice hook to add to or customize VMS, you use something well defined which will work with future O/S releases, and will not hamper the use of the O/S functions by other programs not written with the modification in mind. VMS is more secure by far than UNIX. The reason that people get really excited about any discovered holes is that VMS, unlike UNIX (just ask the government why they can't use UNIX where they can use VMS because UNIX is insecure) is presumed to be totally secure. Thinking that banks are less worried about security than university campus's indicates, I believe, a loose screw, as do the suggestions that being able to granularly define exactly what a user may and may not do without giving away the store is less secure than only having one privilege bit -- all or nothing. The references to the programming interfaces just don't resemble fact in the slihtest. I really feel embarassed about having responded at all to such uninformed rantings. Yes, UNIX documetation is cheap, but you apparently can't even use it without the source-code. If your campus hasn't gone VMS, why would there be doc's in the bookstore? There are reference cards and beginners books for about every aspect of VMS, as well as on-line tutorials, the likes of which I've never seen under UNIX. The architecture manual on my desk was printed last year. It is obvious that old books would exist in a stagnant environment. Take a list at the digital press book list. I'm getting tired of this... I don't know how many more pages of stuff there is that I haven't directly addressed, but most of it is just bias and user preference. Yes, there are valid reasons for having archaic things like UNIX around. Is everyone suddenly going to throw aray their PC's? No. But I can think of a few UNIX machines they might abandon when there is enough VMS to go around and enough documentation, etc. All the UUCP and usenet I've ever seen has been on a VMS VAX. DECNET doesn't preclude these. I must have missed the "factual basis" in all of the "myriad" strewn throughout the original comments. UNIX is no standard. So we can choose from either DOS, or whatever the MAC runs or VMS.
dan@maccs.UUCP (Dan Trottier) (03/05/88)
In article <310@nancy.UUCP> mcpherso@msudoc.UUCP (=P^ZAZPPPYPYXU zQYhBYPYo^O) writes: >Can we *please* stop the UNIX vs. VMS argument. We have both, we like >both. > ><flame on> > > YOU PEOPLE ARE WASTING MY TIME!!! > ><flame off> Oh come on now. There are ways in most of the news reader programs to kill all the articles with a certain subject line. I find these articles both informative, if not a little biased, and refreshing. We too have both UNIX and VMS on the campus and many of the arguments on both sides are valid. Many sites are faced with the problem of which operating system is best for their application. I hope that these articles can help them make the best choice. Just because *we* are established and happy doesn't mean that others are. The discussion has gone on longer than necessary but it is dying out. I suggest that if you don't want YOUR time WASTED and you use rn try the "k" command. -- A.I. - is a three toed sloth! | ...!uunet!mnetor!maccs!dan -- Official scrabble players dictionary -- | dan@mcmaster.BITNET
dboyes@uoregon.UUCP (David Boyes) (03/06/88)
In article <20403@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > >From Steve Ward: >>VMS has an excellent Fortran compiler and any serious Fortran number >>cruncher in research will cry its virtues. Unix only has one Fortran >>compiler{ in the same league with the VMS compiler, and it is the DEC >>Fortran-for-Ultrix compiler. Steve has a good point here. VMS Fortran isn't bad -- it has a lot of useful extensions and in general could almost convince me to go back to writing Fortran code. DEC put a lot of time into making this onw work -- would that they had spent as much time on the rest of their language compilers (you aborters of VAX COBOL listening out there? -- get it right, you .... well, nevermind.). My major point of issue with VMS Fortran is that 1) it is non-standard in a lot of ways -- those useful extensions just don't move well, and 2) no machine that it runs on is fast enough to do serious number crunching. I've been processing matrixes of dimensions larger than 1,000,000 X 1,000,000 elements as part of an image processing system, and even an empty 8800 just doesn't cut the mustard to handle that kind of data manipulation. We're talking DAYS of compute time here, folks. > even DEC's largest machine can't be considered a serious >number cruncher's machine in this day and age, This is very true. DEC highly overrates the compute power of their hardware. I find it extremely interesting that an IBM 4341-II (about a 780-class machine) can manage to do a comparable job to the 8800 I mentioned above -- within 3-5 hours of compute time difference. DEC's got to be doing *something* wrong here. Someone once told me that 1 IBM MIP was roughly equivalent to 2.5 DEC MIPs. Anybody else heard this and want to confirm? >In fact, I think DEC has done an unfortunate disservice, more of a >sociological phenomena, by plying to the scientific community and then >leaving them out in the cold with incompatible fortran In all fairness to DEC, you don't have to use the extensions at all and things will port very well. I move programs from VMS Fortran to VS Fortran on our IBM box all the time. >and no iron to >grow into and remain competitive with their more nimble colleagues. True. I'd kill for a medium sized Masscomp or a Convex. Even a medium size IBM 9370 would be an improvement. > > -Barry Shein, Boston University -- David Boyes | ARPA: 556%OREGON1.BITNET@CUNYVM.CUNY.EDU Systems Division | BITNET: 556@OREGON1 UO Computing Center | UUCP: dboyes@uoregon.UUCP 'How long d'ya think it'll be before just us oldtimers remember WISCVM?'
jsloan@wright.EDU (John Sloan) (03/07/88)
in article <310@nancy.UUCP>, mcpherso@msudoc.ee.mich-state.edu (Mike McPherson) says: > Xref: wright comp.unix.wizards:5993 comp.os.vms:5749 > > Can we *please* stop the UNIX vs. VMS argument. We have both, we like > both. Perhaps I had better make my position clear, Mike. _We_ also have both Unix and VMS. I like both, and think each has its strengths and weaknesses, and areas of appropriate application. I happen to prefer Unix over anything I've ever used before since I started programming around 1970 (DOS/VS, OS/{MFT,MVT,SVS,MVS} on the IBM mainframe side, VMS since 2.x on the VAX side, INTERCOM/SCOPE on CDC Cybers, RSX and RT-11 on PDP-11s. CP/M in the Z80/S-100 days, CP/M-68K, MS/DOS, etc. as well as lots of Unixes), but that is a personal preference, as in politics, sex and religion, and arguments about any of these often generates more heat than light. I push Unix not for religious reasons but for purely economic ones. I am responsible for the deployment of systems and networks and for the management of what is arguably the largest computer center in our University (a matter of some dispute). I simply can not afford to deploy VAXen. I think VAXen are well designed, reliable machines. But I know, based on the numbers I see on the paperwork that crosses my desk, that I can provide more cost-effective computing by buying machines from Sun, Encore, NCR, H-P, what-have-you, than I can from DEC (or IBM for that matter). When I say "cost effective", I'm taking more than just the initial capital investment into account. It is my job to worry about retraining, reliability, power requirements, air conditioning requirements, compatibility, interoperability, maintenance, availability, expandability, preservation of existing investment, and a whole host of other "-ilities". Most of all, I worry about labor costs, because they are the highest of any of the costs I worry about: [1] the cost of my systems staff supporting a wide variety of machines in what is necessarily a multi-vendor environment, and [2] the cost of retraining users. "Users" includes graduate students who must be productive, because they're working on grant-funded projects with deadlines; and faculty researchers who we cannot afford to pay $40K-$70K a year to learn a new operating system and a new editor every time we deploy a new engine. When I look at capital costs, I see a whole lotta engines that are more cost effective than VAXen. And when I look at labor costs, I see an operating system that runs on a wide variety of machines, minimizing my costs for retraining my labor force. And when I look very very carefully, I notice to my delight that these cost effective machines just happen to all run this same operating system. Amazing! I have two VAXen, a 750 and a 785. I could not do with out them. But I could not have afforded to buy them, either. I inherited each, because, bless its heart, our industry provides absolutely no meaningful resale value on these machines, so usually they're cheaper to keep than to sell. Maintenance costs may shortly make that strategy invalid as well; I am on the verge of showing it's cheaper to replace our VAXen with Suns configured as timesharing engines, than to pay the maintenance costs over the expected remaining live cycle of these machines. It is not a matter of religion, Mike. It's a matter of money. And although if I am to believe what I read lately, that there is more than a tenuous connection between religion and money, at least here at my University in my Department, there is a clear cut strategy for providing adequate computing resources. -- John Sloan Wright State University Research Center CSNET: jsloan@SPOTS.Wright.Edu 3171 Research Blvd., Kettering, OH 45420 UUCP: ...!cbosgd!wright!jsloan (513) 259-1384 (513) 873-2491 Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.
ward@cfa.harvard.EDU (Steve Ward) (03/08/88)
In article <1648@uoregon.UUCP>, dboyes@uoregon.UUCP (David Boyes) writes: > In article <20403@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > > > >In fact, I think DEC has done an unfortunate disservice, more of a > >sociological phenomena, by plying to the scientific community and then > >leaving them out in the cold with incompatible fortran > > In all fairness to DEC, you don't have to use the extensions at all > and things will port very well. I move programs from VMS Fortran to VS > Fortran on our IBM box all the time. > > >and no iron to > >grow into and remain competitive with their more nimble colleagues. > > True. I'd kill for a medium sized Masscomp or a Convex. Even a medium > size IBM 9370 would be an improvement. > > > > > -Barry Shein, Boston University > > > -- > David Boyes | ARPA: 556%OREGON1.BITNET@CUNYVM.CUNY.ED Before anybody "kill for a MASSCOMP" they might do some serious FORTRAN benchmarking and general testing, but THAT is another story....(we have a couple of them here....) We also have a couple of CONVEX's and an IBM 4381, too. The comments from our researcher scientists and programmers about DEC Fortran are overwhelmingly positive, in favor of it, and the dozens of annually visiting scientists from around the globe EXPECT DEC FORTRAN to be up and running. Everybody loves a faster computer, one way in a multiuser environment to get more cpu is to give the same cpu to many few concurrent users. We do this with VAXes. VAXes are getting faster, but DEC lags behind some vendors in the fastest cpu race. On the other hand DEC offers VAX workstations at great prices (for us they start at about $3K each). We run many 1 scientist to the machine and run other larger configurations with 16 concurrent users or fewer. The cost per user is lowest for us with DEC VAXes of various MicroVAX and VAXstation models. As I said, we also have other machines, including Sun workstations, tooo. The only truly "fast" machines are the NSF supercomputers we access from our networked based VMS/Ultrix VAXes, Sun's, etc. Our approx. 150 PHD researcher scientists on staff in this research outfit seem to do well using a mixed machine environment, and DEC Fortran and DEC VAXes remain quite popular among them. I agree that you want to avoid any precooked mindset of "one machine, one operating system, one compiler" etc, but DEC does offer some useful and very economical options, at least to us through our DEC University Consortium contract. We will continue to take advantage of the depth and breadth of market offerings that make sense for us. I would think that while you don't want to be locked into a vendor, you certainly don't want to lock any vendors out, either. U
sommar@enea.se (Erland Sommarskog) (03/09/88)
Barry Schein goes along flaming against VMS and closes: >This is not a religious flame, I have presented myriad factual basis >for my arguments. VMS people like to claim religious flame and >"chocolate vs vanilla!" arguments. This is because they cannot deal Some of the "facts" are not just true, but Barry goes on as they were refutable. I shall comments some few points that I found wrong. (And, actually, I think Barry could make a good televangelist. :-) >Unix systems are relatively bundled, beyond mere hardware >considerations most Unix systems right out of the box are completely >useable. It can be supplemented in many significant ways with free or >nearly free (eg. ~$100 for an entire campus) software. VMS is heavily >unbundled, from day one if you want so much as a compiler you begin >layering heavy costs. And you'll pay a separate price for acquiring Now, watch it here. A Unix system comes with a bunch of compilers that's true. VMS does not. But what about the quality of the compilers? My experience of Unix compilers restricts to the Fortran and Pascal compiler that comes with 4.3 BSD on our VAX. The code they produce have a speed which hardly is acceptable for procduction. And if you want other languages, Ada for instance, you'll have to buy that separately also for Unix. >The claim that Unix is somehow less secure than VMS is a red herring. Ah, good televangelist preaching! >privilege you won't want to give to a user (I'm not sure I want to go >into the whole mess of the zillions of VMS "privilege" bits which >you'll never fully understand the implications of and will almost >surely end up giving away the store because some reasonable thing can >only be accomplished by giving a user some dangerous privilege bit, But, hey, you argue for Unix for that yuo can keep the security because you can have the source code. But with the same arguments you use against the VMS privilieges, can be used against the code: Will you ever fully understand it? Zillions of line of code. (Zillion seems to mean 30+ here.) >Unix's single privilege scheme [root or not root] is much more secure, >you just don't give out root privs and you know exactly what can and >cannot be done by the two sets of users on your system, who wants to >calculate the permutations of 30+ priv bits and what they might imply >singly and in combination?.) Sure. I also use one single screwdriver, no matter the size of the screws. Some of the screws get damaged, so what? It's much simpler that way. Seriuosly: The VMS privilieges makes it possible to just use those you need at the moment. And for giving away: Very few students ever need more than NETMBX and TMPMBX. They should have *very* good reasons for getting any other. >VMS. There's some on-line help in VMS but it's designed to sell >manuals or supplement them, the details are always missing >(purposely.) > >Most Unix systems come with on-line, complete manual sets with the >exact same text used to produce the printed manuals. Thus, what's the >cost to a student for Unix manuals? For $0 (zero) they can get This is a damned lie! If I look up the man-page for the Pascal compiler on our machine I learn about the compiler, but for the langauge as such I am referred to a separate document, which is not on the machine, at least the man- page gives me no reference. If you do HELP PASCAL on VAX machine you'll be able to get the most of the language definition. OK, the complete definition is in the orange binder, but you make it very good with the HELP facility. And for the Unix with the on-line help exactly as the printed ones: When you read from a terminal you're more likely to skim for certain information. Plunging through a long man-page is no fun. VMS' hierarical HELP is much better here. And this brings us on to another issue which Barry does not mention: Unix may have some clever tricks, but it's user interface is really arcane. One-letter options is certainly not state-of-the-art. I could continue, but I shall not. I think a campus should have some Unix systems since they are quite frequent in the real world. They should also have some non-Unix systems, since Unix systems are so frequent in the real world. The student should get more than one view. -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP "Souvent pour s'amuser les hommes d'equipages and it's like talking to a stranger" -- H&C.
dboyes@uoregon.UUCP (David Boyes) (03/09/88)
In article <910@cfa.cfa.harvard.EDU> ward@cfa.harvard.EDU (Steve Ward) writes: >> >> True. I'd kill for a medium sized Masscomp or a Convex. Even a medium >> size IBM 9370 would be an improvement. >> David Boyes | ARPA: 556%OREGON1.BITNET@CUNYVM.CUNY.ED >Before anybody "kill for a MASSCOMP" they might do some serious FORTRAN >benchmarking and general testing, but THAT is another story....(we have >a couple of them here....) I did. Our Masscomp (owned by the chem dept.) outperforms all the VAX equipment on campus except the 8800, and the 8800 doesn't beat it by much. They're zippy little boxes, and considering that I can buy one outright for the price of the license for VMS and FORTRAN for a year and get an OS license and compilers in the bargain, I'd rather let it sit there and munge.... In defense of DEC, the chem Masscomp does have their high-performance FPU, but still -- there's a lot of difference there. >Everybody loves a faster computer, one way in a multiuser environment to >get more cpu is to give the same cpu to many few concurrent users. We >do >this with VAXes. VAXes are getting faster, but DEC lags behind some >vendors in the fastest cpu race. On the other hand DEC offers VAX >workstations at great prices (for us they start at about $3K each). >We run many 1 scientist to the machine and run other larger >configurations with 16 concurrent users or fewer. The cost per user >is lowest for us with DEC VAXes of various MicroVAX and VAXstation >models. Well, this is all well and good, PROVIDED you can afford to do what you just described. Out here in reality, is simply NOT economically possible to buy 1 machine for every 16 or so researchers -- the money just isn't there. >DEC does offer some useful and very economical options, at least to us >through our DEC University Consortium contract. We will continue to >take advantage of the depth and breadth of market offerings that make >sense for us. I would think that while you don't want to be locked >into a vendor, you certainly don't want to lock any vendors out, either. Economical? Let's be serious here. Unless you are getting some TREMENDOUS knockoff, a uVax II or a Vaxstation still costs a pretty penny to get comparable performance to any of an arbitrarily large number of other machines. It's very much like IBM -- the technology may not be fast and flashy, but it'll be there tomorrow still plugging away -- kind of like the difference between a Porsche 944 turbo and a Ford Fairlane. Ack. -- David Boyes | ARPA: 556%OREGON1.BITNET@CUNYVM.CUNY.EDU Systems Division | BITNET: 556@OREGON1 UO Computing Center | UUCP: dboyes@uoregon.UUCP 'How long d'ya think it'll be before just us oldtimers remember WISCVM?'
davidli@umn-cs.cs.umn.edu (Dave Meile) (03/09/88)
I don't understand these OS wars here in comp.os.vms. I mean, the two major operating systems are both, for the most part, proprietary. If you don't believe this, try writing your own version of UNIX and marketing it without paying AT&T any money. You'll quickly experience the how "non proprietary" it really is! The DEC Educational Software Library is *not* just for workstations, at least as far as I've been able to tell from the literature we have here. MicroVAX II, MicroVAX 2000, VAXstation 2000 ... If you wish to pay for an unlimited VMS license, you can still get the Library. True, the VAXstation 2000 is limited to two users -- but that is its *function* ... workstations are one-two person computers folks. Now then, all we have to wait for is POSIX (not a tm of AT&T) and this silly argument will go away.
levy@ttrdc.UUCP (Daniel R. Levy) (03/10/88)
In article <4236@umn-cs.cs.umn.edu>, davidli@umn-cs.cs.umn.edu (Dave Meile) writes: > I don't understand these OS wars here in comp.os.vms. I mean, the two > major operating systems are both, for the most part, proprietary. If you > don't believe this, try writing your own version of UNIX and marketing it > without paying AT&T any money. You'll quickly experience the how "non > proprietary" it really is! There are some UNIX-like operating systems out there which were written without reference to so much as one line of AT&T code, and as such AT&T has not to my knowledge raised any challenge thereto. (MINIX is one such OS.) However, none of these systems may legally be called a UNIX operating system; they are typically billed as "UNIX-like" or "UNIX-compatible." I honestly don't know whether this is because of (strategic?) magnanimity on the part of AT&T (as was the release for public use without royalty of the "setuid bit" patent) or whether it is truly out of AT&T's legal reach. (I am, you note, covering my behind.) I also don't know whether implementors of VMS-like environments (there are some out there) must license the right from DEC. -- |------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, | an Engihacker @ | <most AT&T machines>}!ttrdc!ttrda!levy | AT&T Computer Systems Division | Disclaimer? Huh? What disclaimer??? |--------Skokie, Illinois--------|
ward@cfa.harvard.EDU (Steve Ward) (03/11/88)
In article <1663@uoregon.UUCP>, dboyes@uoregon.UUCP (David Boyes) writes: > In article <910@cfa.cfa.harvard.EDU> ward@cfa.harvard.EDU (Steve Ward) writes: > >> > >> True. I'd kill for a medium sized Masscomp or a Convex. Even a medium > >> size IBM 9370 would be an improvement. > >> David Boyes | ARPA: 556%OREGON1.BITNET@CUNYVM.CUNY.ED > >Before anybody "kill for a MASSCOMP" they might do some serious FORTRAN > >benchmarking and general testing, but THAT is another story....(we have > >a couple of them here....) > > I did. Our Masscomp (owned by the chem dept.) outperforms all the VAX > equipment on campus except the 8800, and the 8800 doesn't beat it by > much. They're zippy little boxes, and considering that I can buy one > outright for the price of the license for VMS and FORTRAN for a year > and get an OS license and compilers in the bargain, I'd rather let it > sit there and munge.... In defense of DEC, the chem Masscomp does > have their high-performance FPU, but still -- there's a lot of > difference there. > > >Everybody loves a faster computer, one way in a multiuser environment to > >get more cpu is to give the same cpu to many few concurrent users. We > >do > >this with VAXes. VAXes are getting faster, but DEC lags behind some > >vendors in the fastest cpu race. On the other hand DEC offers VAX > >workstations at great prices (for us they start at about $3K each). > >We run many 1 scientist to the machine and run other larger > >configurations with 16 concurrent users or fewer. The cost per user > >is lowest for us with DEC VAXes of various MicroVAX and VAXstation > >models. > > Well, this is all well and good, PROVIDED you can afford to do what > you just described. Out here in reality, is simply NOT economically > possible to buy 1 machine for every 16 or so researchers -- the money > just isn't there. > > >DEC does offer some useful and very economical options, at least to us > >through our DEC University Consortium contract. We will continue to > >take advantage of the depth and breadth of market offerings that make > >sense for us. I would think that while you don't want to be locked > >into a vendor, you certainly don't want to lock any vendors out, either. > > Economical? Let's be serious here. Unless you are getting some > TREMENDOUS knockoff, a uVax II or a Vaxstation still costs a pretty > penny to get comparable performance to any of an arbitrarily large > number of other machines. It's very much like IBM -- the technology > may not be fast and flashy, but it'll be there tomorrow still plugging > away -- kind of like the difference between a Porsche 944 turbo and a > Ford Fairlane. > > Ack. > > > > -- > David Boyes | ARPA: 556%OREGON1.BITNET@CUNYVM.CUNY.EDU Well, we do get good prices from DEC. As I said, a VS2000 with a one year onsite maint. warranty starts about $3300 and tops about $10K (color, 6MB, RD54,etc) with both VMS/Ultrix licenses and licenses for another dozen VMS software products, or so. Last year we configured some VAXStation II's with 16MB of memory, Ethernet, VMS/DECnet/Fortran, etc. and Excelan TCP/IP, 1.2 Gigabyte of MAXTOR disks for under $25K each. The machines included 16-user VMS licenses, which is my existing major complaint against DEC. DEC will not sell add-on multiuser VMS licenses for VAXStations anymore. I can buy VAXStation II's starting at $10K with all the software I mentioned for the VS2000's included, but no longer can get the VM<S multiuser licenses for them. We set up an LAVC of VSii's with the configuration I mentioned. For the average user disk capacity, central disk backup requirements, and other requirements we had, we found this approach to be by far and away the most economical on a cost per user basis. By the way, I just recently bought some MAXTOR 8760 (760MB) drives for $3300 each. Being willing to integrate a few third party peripherals does really help to bring the cost down. The cost of the disk capacity I added to the LAVC last year is now half of what was paid last year, meaning that now I can add 2.4 GB of disk space with appropriate controller, chassis, power supply, cables to a Q-bus MicroVAX/VAXStation for about $15K.
irf@kuling.UUCP (Bo Thide) (03/12/88)
In article <2258@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <284@wright.EDU> jsloan@wright.EDU (John Sloan) writes: >>DEC has delivered a >>proposal for a 6MIPS VAX for $1.2M. Six months ago I purchased, >>received, and deployed our Sun-3/280S, a 4MIPS engine for under >>$100K. Well, I just got my FPA installed in my HP9000/350 (multi-user HP-UX) turning this 4 MIPS machine (4.7 times VAX integer, they say) into a 3.5 MWhets number cruncher. This is an amazing speed at an amazingly low total price (less than the equivalent of $50k for the lot). I am just now installing an Ariel FFT processor (at $1,600) to improve the speed even further (1024 point complex FFT in 9 ms, 256 point real FFT in less tan 1 ms). Similar workstations are available from Sun, Apollo, Masscomp and others. This just shows that today's personal "super"-workstations have turned traditional minis (like the VAXen) obsolete. An added benefit is that all workstations use (some type of) UN*X. -Bo -- >>> Bo Thide', Swedish Institute of Space Physics, S-755 90 Uppsala, Sweden <<< Phone (+46) 18-300020. Telex: 76036 (IRFUPP S). UUCP: ..enea!kuling!irfu!bt
bzs@bu-cs.BU.EDU (Barry Shein) (03/13/88)
>I don't understand these OS wars here in comp.os.vms. I mean, the two >major operating systems are both, for the most part, proprietary. If you >don't believe this, try writing your own version of UNIX and marketing it >without paying AT&T any money. You'll quickly experience the how "non >proprietary" it really is! Several companies and organizations have done exactly this, among them are IDRIS from Whitesmith's, UNOS from Charles River Data Systems, Doug Comer's XINU, Andy Tannenbaum's MINIX, something called TRIX I don't honestly know much about. Richard Stallman's Free Software Foundation has committed to providing such a system in the near future and has many of the utilities needed already available, the kernel is in development. I suppose someone could do the same with VMS although that remains much more hypothetical. I guess in all fairness one can point to some of the VMS compatibility products available under Unix systems such as ELXSI's EMBOS (I think that's right) and others which include features like a VMS compatible Fortran, I assume some of the libraries for that tho probably a small subset, I think EMBOS even comes with a home-grown DCL, EMBOS is not unique, Sun and others are shipping similar products. Anyhow, the point's moot I believe, I don't think the ability to write a look-alike product (or not) is a test of proprietariness, at least not inasmuch as it has been discussed here. The real point was whether or not other companies could take the source code, modify it, put it on their own iron and market it simply by paying a royalty fee to the owners. In the case of Unix, yes, and many many companies owe their livelihood to this fact, in the case of VMS, no, not really, I suppose one could split hairs over the third-party repackagers (people who take vaxes and vms and do various repackaging under their own labels, VARs, OEMs, whatever) but it really would be just that, splitting hairs. However, you are right in one regard, there is no doubt that AT&T owns Unix (whatever that means exactly, certainly the trademark "Unix" and the specific source code they have covered with their licenses), that is not by any stretch of the imagination in the "public domain". Whether the look and feel or interface is proprietary is another issue that's really a legal one not completely up to the wishes of any vendor. The real point is, however, that AT&T has made their software quite available for use as a platform for commercial ventures of almost any type. Although $40,000 may seem like a lot of money for a commercial source license (the first thing you need) it really isn't, it's very cheap to someone planning on going into the software business (other than garage start-ups), probably less than you'll pay for any one employee's one year salary. The binary redistribution rights entail some flat fee (I forget what, but something like $20K one-time) and a royalty that varies, usually around $150 per system, enough to allow the current IBM/PC versions (typically around $500 retail.) Anyhow, I guess it's more of a semantic disagreement over exactly what "proprietary" means. -Barry Shein, Boston University
bzs@bu-cs.BU.EDU (Barry Shein) (03/13/88)
Well Steve, the prices you are getting Vaxes for certainly must be coloring your opinions a little. I suppose if I could get a VS2000 with one-year on-site for $3K I might think a little differently also. As it stands I believe the last thing DEC ever offered around here was 5% or some such if we promised to do volume business, or maybe it was 5% but a little more if we did volume, I forget, I guess the laughter was too loud in the room. Things like that can really change one's view of what competitive price performance really means, no? I think we're more typical and Harvard has some sort of sweetheart deal (hey, good for them) that can't really be factored into the rest of our decisions. -Barry Shein, Boston University
schwartz@psuvax1.psu.edu (Scott Schwartz) (03/13/88)
In article <4236@umn-cs.cs.umn.edu> davidli@umn-cs.UUCP (Dave Meile) writes: >I don't understand these OS wars here in comp.os.vms. I mean, the two >major operating systems are both, for the most part, proprietary. If you >don't believe this, try writing your own version of UNIX and marketing it >without paying AT&T any money. You'll quickly experience the how "non >proprietary" it really is! Ha ha ha. Ever heard of the Free Software Foundation? They are writing a unix compatable OS that will be free for all. Currently the FSF is negotiating with Berkeley to have the BSD utilities declared free (as many of them have already been) and with CMU for the ok to use MACH as the kernel. AT&T gets nothing. More to the point, AT&T has already source licenced UNIX to tons of other companies. Many companies have written unix look alikes, too. If you want unix, you are never chained to one vendor. #disclaimer <unix is a trademark of western electric co., but a rose by any other name... > :-) :-)
bzs@bu-cs.BU.EDU (Barry Shein) (03/14/88)
I always love when someone starts off all hell-in-blazes that they are about to rip someone to shreds and then manages to fire their blanks into the air... From: sommar@enea.se (Erland Sommarskog) >Some of the "facts" are not just true, but Barry goes on as they were >refutable. I shall comments some few points that I found wrong. (And, >actually, I think Barry could make a good televangelist. :-) Yeah, ok, we're waiting... >>Unix systems are relatively bundled, beyond mere hardware >Now, watch it here. A Unix system comes with a bunch of compilers >that's true. VMS does not. But what about the quality of the compilers? Are they bundled or not? I'm sorry you don't like the quality of the compilers, they seem to serve quite a number of people fairly well. Is this supposed to be a devastating refutation of my claim that Unix is more bundled? Can you spell bullshit, I knew you could. >And if you >want other languages, Ada for instance, you'll have to buy that >separately also for Unix. No one said nothing was for sale for Unix, that every imaginable piece of software was available on the dist tape, just that it was *usefully* bundled. Can you spell bullshit, I knew you could. >>The claim that Unix is somehow less secure than VMS is a red herring. >Ah, good televangelist preaching! Another devastating feat of logic, I'm humbled. >But, hey, you argue for Unix for that yuo can keep the security because >you can have the source code. But with the same arguments you use against >the VMS privilieges, can be used against the code: Will you ever fully >understand it? Zillions of line of code. (Zillion seems to mean 30+ here.) Oh, I see, you fix security bugs in VMS by playing with the security privilege bits. Can you spell bullshit, I knew you could. >This is a damned lie! > >If I look up the man-page for the Pascal compiler on our machine I >learn about the compiler, but for the langauge as such I am referred >to a separate document, which is not on the machine, at least the man- >page gives me no reference. A lie? I dunno, it's on my machine in /usr/doc, go speak to your vendor, or tell your sysadmins not to delete the docs. The pc command should document the pc command, not the entire Pascal language. I think you use the term "liar" a little freely. >And this brings us on to another issue which Barry does not mention: >Unix may have some clever tricks, but it's user interface is really >arcane. One-letter options is certainly not state-of-the-art. I don't mention it because I believe it's a chocolate/vanilla issue I specifically said I would avoid. Or would you like to give us all a good definition "arcane", with units preferably, perhaps something like measured learning curves etc. Can you spell bullshit, I knew you could. >I could continue, but I shall not. I think a campus should have >some Unix systems since they are quite frequent in the real world. >They should also have some non-Unix systems, since Unix systems >are so frequent in the real world. The student should get more than >one view. And if you bothered to read my note I said the same thing. Devastating, truly, I hope you don't do this sort of thing for a living. -Barry Shein, Boston University
sommar@enea.se (Erland Sommarskog) (03/15/88)
Barry Shein (bzs@bu-cs.BU.EDU) responds to my article and ask if can spell a certain word. Hm, let's see. Was it "bolschytt", no, hm... No I give up. Anyway, doesn' matter, Mr. Scein seems to know quite well how write it. >Are they bundled or not? I'm sorry you don't like the quality of the >compilers, they seem to serve quite a number of people fairly well. Is I don't know. May be they only know Unix compilers and believe that all langauges but C are so goddamn slow. They should try some on VMS :-) >>But, hey, you argue for Unix for that yuo can keep the security because >>you can have the source code. But with the same arguments you use against >>the VMS privilieges, can be used against the code: Will you ever fully >>understand it? Zillions of line of code. (Zillion seems to mean 30+ here.) > >Oh, I see, you fix security bugs in VMS by playing with the security >privilege bits. No. First you argue in favour of Unix that the code is available, intimating that anyone can hack around with it. Then you argue against the security system of VMS, and say that is too complicated. If you can't learn to understand the VMS privilieges you will never grasp your Unix code either. >A lie? I dunno, it's on my machine in /usr/doc, go speak to your >vendor, or tell your sysadmins not to delete the docs. The pc command >should document the pc command, not the entire Pascal language. I >think you use the term "liar" a little freely. On my machine, it is not. And if it had, it would have been of no interest, since "man pc" doesn't refer to it. (I don't say that the pc page should describe Pascal, but it should give the reference. And it does. But not to an on-line document.) >>And this brings us on to another issue which Barry does not mention: >>Unix may have some clever tricks, but it's user interface is really >>arcane. One-letter options is certainly not state-of-the-art. > >I don't mention it because I believe it's a chocolate/vanilla issue I >specifically said I would avoid. Well, may be as a acquinted Unix user you may find user interfaces as just a matter of taste. Me, who being used to a slightly more modern fashion, think it is. (Wonder if you call pipes and redirection as a chocolate/vanilla issue as well. That's typically a thing I find nice to have, but can live without. Guess why.) >And if you bothered to read my note I said the same thing. Sorry, if I missed it. But your article was so full emotional arguments and intimations about DEC's motives for doing things, it was hard to see the wood for the trees. -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP "Si tu crois l'amour tabou... Regarde bien, les yeux d'un fou!!!" -- Ange
nevin1@ihlpf.ATT.COM (00704a-Liber) (03/19/88)
Well, Erland, I guess I get to argue with you in another group :-) :-)!!
First off, my background: I have been both a general user and system
administrator on both Unix and VMS systems. Currently, I prefer Unix, but
I think that that is just a personal preference. I really don't want to
add fuel to the OS war, but I don't like it when people make points
through invalid arguments.
In article <2814@enea.se> sommar@enea.UUCP(Erland Sommarskog) writes:
.
.Now, watch it here. A Unix system comes with a bunch of compilers
.that's true. VMS does not. But what about the quality of the compilers?
.My experience of Unix compilers restricts to the Fortran and Pascal
.compiler that comes with 4.3 BSD on our VAX. The code they produce
.have a speed which hardly is acceptable for procduction. And if you
.want other languages, Ada for instance, you'll have to buy that
.separately also for Unix.
Come on, give it some time. Until recently, Unix was not even considered
for doing anything but development. And not all VMS compilers are all that
great, either. The Modula-2 compiler I used did SEVEN passes!! Nor have I
ever seen a VMS Pascal comppiler that works nearly as well as Turbo Pascal
for PCs! Is this a fault of the OS?? I think not. As more and more
demands are made better and better compilers will be written.
..The claim that Unix is somehow less secure than VMS is a red herring.
.
.Ah, good televangelist preaching!
.
.Seriuosly: The VMS privilieges makes it possible to just use those
.you need at the moment. And for giving away: Very few students ever
.need more than NETMBX and TMPMBX. They should have *very* good reasons
.for getting any other.
Sorry, but the VMS privileges do NOT make it possible to give out only just
what is needed. When you give a student NETMBX and TMPMBX privileges,
exactly what do they have access to that they didn't have before?? When
you give out privileges, you give people access to a whole bunch of
things, and not necessarily just the stuff they need access to. For
instance, create an account to allow someone to make full backups of the
hard drive onto a tape device, and see how much more access to the system
he/she has.
When I was a student using VMS (before I was a VMS system administrator),
there were certain things we weren't supposed to be able to do, such as
copy files among students (they disconnected SET FILE /PROT), print
help files, and boost our priority (boy, do you get in trouble when you run
at priority 15 and you get caught :-)); yet I managed to do all these
things with only NETMBX and TMPMBX. And I wasn't even trying to break
security! VMS seems to promote security thru obscurity!! Many VMS sys
admins feel their system is secure because they can't think of ways to
break it.
Unix sysadmins, however, can understand their security problems because
they can learn about how the OS works. However, most users have access to
this same information, which means that the security issues really have
to be thought all the way out. To say that VMS is more secure than Unix or
vice-versa is ridiculous. They just have different security issues, that's
all.
.And this brings us on to another issue which Barry does not mention:
.Unix may have some clever tricks, but it's user interface is really
.arcane. One-letter options is certainly not state-of-the-art.
One letter options are not really part of the OS user interface, per-se.
Each command handles it's own arguments (although there are standard system
calls such as getopt() so that some sort of consistency can be maintained).
The user interface of Unix is really the shell (Bourne, Korn, csh, vsh,
etc.). And if you want to write your own interface, go do it! It's not
that hard. Try doing it for VMS!!
If you really want to continue the war on VMS vs Unix, you had better come
up with some much better arguments!! What I would really like to see,
however, is how to incorporate the best of both OSs into a new OS (this
probably belongs in another newsgroup, however).
--
_ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194
' ) ) "The secret compartment of my ring I fill
/ / _ , __o ____ with an Underdog super-energy pill."
/ (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blahjohn@basser.oz (John Mackin) (03/20/88)
In article <90rrk@byuvax.bitnet> rrk@byuvax.bitnet writes: > VMS most definately [sic] does not lock you into an architecture or a hardware. Ho ho ho ho ho ho ho ho ho! John.
sommar@enea.se (Erland Sommarskog) (03/21/88)
Nevin J. Liber (nevin1@ihlpf.UUCP) writes: >Come on, give it some time. Until recently, Unix was not even considered >for doing anything but development. And not all VMS compilers are all that >great, either. The Modula-2 compiler I used did SEVEN passes!! Nor have I >ever seen a VMS Pascal comppiler that works nearly as well as Turbo Pascal >for PCs! My point was was that it's not simply one-to-one between layered VMS compilers and bundled Unix compilers. You do get something for that extra money. As a side note: We bought an Ada compiler to our Unix machine for a good deal of money. The code it produces is not over- whelming, but it leaves the bundled "f77" and "pc" far behind. What's wrong with seven passes, by the way? VAX-Pascal uses eight or so. I would also say that compiler works very well. I have no experience of Turbo, though. >Unix sysadmins, however, can understand their security problems because >they can learn about how the OS works. I guess as there are knowledgeable and ignorant system managers for VMS, it's the same for Unix machines. >To say that VMS is more secure than Unix or >vice-versa is ridiculous. They just have different security issues, that's >all. I wouldn't say that it's ridiculous. VMS 4.3, was approved for the C2 level of security. Unix is not even near of this. VMS certainly has much more sophisticated and diversified tools for controlling access than Unix: Privilieges, access control lists, rights indentifiers etc. You call that ridiculous? (I don't know if any higher versions of VMS have been approved, anyone who knows?) >One letter options are not really part of the OS user interface, per-se. >Each command handles it's own arguments (although there are standard system >calls such as getopt() so that some sort of consistency can be maintained). >The user interface of Unix is really the shell (Bourne, Korn, csh, vsh, >etc.). And if you want to write your own interface, go do it! It's not >that hard. Try doing it for VMS!! The same drivel as always. Yes, I know there are exceptions, but the vast bulk of Unix program use one-letter options, and it is also the preferred standard. And if they have longer names, they are seldom abbriavatable. When you are used to CDU on VMS, getopt really seems like the poor man's replacement. And, yes, I know I can write my own shell, but is that realistic? Let's keep the discussion what is actually being provided, not what I could theoretically write myself. (And I doubt that a CLI for VMS would be that harder to write than a Unix shell. In VMS I have to load the command tables. In Unix I have to expand wild cards in file names.) -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP "Si tu crois l'amour tabou... Regarde bien, les yeux d'un fou!!!" -- Ange
bzs@bu-cs.BU.EDU (Barry Shein) (03/21/88)
From: sommar@enea.se (Erland Sommarskog) >I wouldn't say that it's ridiculous. VMS 4.3, was approved for the C2 >level of security. Unix is not even near of this. Just for the record, Gould sells govt approved C2 Unix. C2 isn't that hard. It's also a bad thing to throw around as a feature, people should read what these classifications mean, particularly B and above, I would imagine most of them wouldn't actually want this level of security on their systems (for example, it can requre you don't allow file sharing of any sort between users.) There's security and there's security, you have to be careful what is being discussed, this is spook stuff mostly, not what you might think. Of course, certain govt agencies require these security levels, whatever the cost to "user friendliness", and that's fine I guess, just irrelevant to most of us who just want to feel our accounts and files are guaranteed integrity (as opposed to foiling two enemy agents on a system from passing data back and forth by signaling with morse code on an enqueue flag, etc., the kind of thought that motivates the orange book requirements.) Also certification means that it can be operated at these security levels, that the proper tools to do so and features have been implemented (or not implemented, as the case may be.) There is a definite operational requirement that the system be administered in a certain way, it's not like it's something everyone who operates such a system achieves by just buying it. For example, as has been said many times, if you're on a network, you ain't secure, at least not by their standards, not a fun restriction (secure networks can be built, but that's not what we've all been putting in, Unix, VMS whatever.) -Barry Shein, Boston University
val@wsccs.UUCP (Val Kartchner) (03/22/88)
In article <20597@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes: > >And this brings us on to another issue which Barry does not mention: > >Unix may have some clever tricks, but it's user interface is really > >arcane. One-letter options is certainly not state-of-the-art. > > I don't mention it because I believe it's a chocolate/vanilla issue I > specifically said I would avoid. Or would you like to give us all a > good definition "arcane", with units preferably, perhaps something > like measured learning curves etc. Can you spell bullshit, I knew you > could. Any Eunuchs programmer could easily: bllsht. Anyone else could spell it correctly. Shall we compare learning curves? A new user on VMS can learn more in less time because the options make sense. For instance, what does "-s" mean as opposed to "-S" as opposed to "/system" or "/security"? Which would make more sense to a new user? And what about consistency? A comparison of a (hypothetical) command on Eunuchs and VMS: flame/full/type=(eunuchs,consistency) commands vs flame -f -t=(eunuchs,consistency) commands In the VMS environment, the command would be parsed (and verified syntactically correct) in a consistent manner before the program (image) was even loaded. In the Eunuchs evironment, the command parsing is left totally up to the programmer. This means a wide variety (and inconsistent) method of parsing between programmers. (Sometimes the options to the "-" command must follow immediately, other times a space, and other times an equals.) This was a problem in the AmigaDOS environment before ARP (AmigaDOS Replacement Project) came along. AmigaDOS parses the commands just like Eunuchs (inconsistencies included) and with cryptic "-" commands. ARP provides a standard library of routines to parse the command line arguements in a consistent manner. These libraries are available for use of all Amiga programmers to provide this consistency. Something like this is _*DESPERATELY*_ needed in all Eunuchs like environments. P.S.: If the Eunuchs programmer really wants to, he(/she/it) can parse the command line totally him(/her/it)self. This is to provide Eunuchs compatability for those who want it. Could Eunuchs (and like environments) provide optional and consistent command line parsing. ----------------------------------------------------------------------------- Another thought on Eunuchs: Get an editor. -- --- /\ ------------ Val Kartchner {UT@WSC} ---- #include <flamesuit.h> ----- /\/\ . /\ | "Those who don't understand VMS are condemmed to reinvent / \/ \/\/ \ | Unix; those who understand VMS and Unix use VMS." ==/ U i n T e c h \====!ihnp4!utah-cs!utah-gr!uplherc!sp7040!obie!wsccs!val====
val@wsccs.UUCP (Val Kartchner) (03/22/88)
Before you flame me (see my previous article), I posted the previous
article from a soapbox. Please, take it with a large grain of salt.
The opinions expressed are my own, but they were undilluted with
tolerance.
VMS has it's good points, but Unix is does too. I would like to become
as proficient with Unix as I am with VMS.
--
--- /\ ------------ Val Kartchner {UT@WSC} ---- #include <flamesuit.h> -----
/\/\ . /\ | "This space intentionally left blank"
/ \/ \/\/ \ |
==/ U i n T e c h \====!ihnp4!utah-cs!utah-gr!uplherc!sp7040!obie!wsccs!val====darin@laic.UUCP (Darin Johnson) (03/22/88)
Ok, I have been staying out of the fray, but I will put in my two sense worth (or as a recent DEC magazine said - 10 cents for uucp message :-) I learned UNIX and VMS in school - both without instruction (and with projects due in two weeks after start of class). Right now, I spend 80% of my time as a VMS programmer (system utilities/management) and the rest as a UNIX manager. I must admit VMS was much quicker to pick up (after one hour tutorial). I just kept trying a few commands until one of them worked (REMOVE vs. DELETE). This part was not as easy as UNIX. As a beginner, I found the help equally useful (we had a help command on our unixes, as well as man). The VMS editor at the time was EDT, which I abhored. Most of the vt series terminals on campus were used quite a bit, so I was forced to either use line mode, or redraw a lot with ANSI-but-not-DEC compatible terminals. Albeit, VI is no marvel of engineering, after a one-hour intro, I was able to edit quite well on any terminal that happened to be open (especially my $300 adm3a). Later on, a friend and I wrote our own VMS editor just to avoid EDT. Now of course, I use TPU and/or EMACS (Emacs on UNIX/VMS/Amiga all works the same). However, after I became slightly proficient at both OS's, I found UNIX to be much easier to keep learning new tricks and easier ways to do things, such as pipes, job control, etc. VMS however, I was pretty much stuck at my same level of competence. When it got around to doing system's level programming, I found UNIX much easier to use. To do the same with VMS required ALWAYS yanking out the manuals, HELP was pretty useless as it never told what I needed to know (such as what parameter to put into an item list to $GETJPI). UNIX online manuals almost always told what you needed or else referred you to the manual page that did. Programming in C made VMS just that much worse. Everything to all system calls usually required passing by reference, passing null parameters, using descriptors, treating a 1 return code as succeeding, etc. I admit, if you program in MACRO, FORTRAN, etc., then you don't have to worry about these details. I have only seen UNIX source once, and only then to track down what I thought was a bug. I have never used it to figure out how to do something (although some people have implied that the manual pages are useless without source code). As far as system cost, bundles software, etc. I should point out that there are quite a few machines here that don't have "necessities" or "luxuries" for VMS, just because of limited budgets. Some people have actually said that they would have bought the "whatsit" package if it didn't cost $20,000 (they then went and bought it for a uVAX for ~$1000 :-) I can probably summarize by saying that the learning curve on VMS starts out steep, but quickly levels out, while the learning curve for UNIX is pretty much opposite. They meet in the middle somewhere. Of course, as most people have said, try to get a mix of both (our campus also had Burroughs with CANDE which no-one knew how to use :-). I haven't gone into too many details of what I like/dislike about each system since enough people are bashing these issues around. > As far as the communities "rapidly switching to UNIX", as far as it goes > on VAX's, the existing base of VAX's is (last time I checked) 60% VMS, 40% > UNIX. The new VAX's being shipped are about 80% VMS, 20% UNIX. I read different and conflicting figures everywhere I look :-) I do know of at least one machine licensed for VMS, but actually running BSD Unix (mostly because DEC used to not service machines with non-DEC software, but this has changed), and quite a few machines originally bought with VMS, but then converted to UNIX. I suppose some figures take this stuff into account, and others don't. I have even seen some reports that show x% UNIX when they meant ULTRIX. Do they show the figures of VAXen shipped without either one (to put someone elses unix on it)? *** flame on - replies to this flame ignored *** > So we can choose from either > DOS, or whatever the MAC runs or VMS. I myself, would prefer that MS-DOS, MAC, and other LemmingWare should not be discussed in the same breath as real-operating systems: VMS, UNIX, AmigaDos (well, perhaps Kickstart 2.0). -- Darin Johnson (...ucbvax!sun!sunncal!leadsv!laic!darin) (...lll-lcc.arpa!leadsv!laic!darin) All aboard the DOOMED express!
terry@wsccs.UUCP (terry) (03/22/88)
In article <341@wsccs.UUCP>, val@wsccs.UUCP (Val Kartchner) writes: > In article <20597@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes: > > >And this brings us on to another issue which Barry does not mention: > > >Unix may have some clever tricks, but it's user interface is really > > >arcane. One-letter options is certainly not state-of-the-art. > > > > I don't mention it because I believe it's a chocolate/vanilla issue I > > specifically said I would avoid. Or would you like to give us all a > > good definition "arcane", with units preferably, perhaps something > > like measured learning curves etc. Can you spell bullshit, I knew you > > could. > > Any Eunuchs programmer could easily: bllsht. Anyone else could spell it > correctly. Actually, Val, it would be blsht. Doubled consonants are usually eliminated, too :-). > Shall we compare learning curves? A new user on VMS can learn more in > less time because the options make sense. For instance, what does "-s" > mean as opposed to "-S" as opposed to "/system" or "/security"? Which > would make more sense to a new user? It would depend on several factors: 1) The user's previous experience For instance, MS-DOS, CP/M, MP/M, and most older DEC user interfaces all used single character options. 2) How the user "remembers" Does the user perceive things visually, or does he/she perceive tactorily or dimensionally? Does the user remember commands via analogy? Or auditorily (remembers only the commands he/she was told verbally or that he/she verbalized themselves (many programmers talk to themselves, for instance repeating variable names to themselves while switching edit sessions, etc). 3) Can the user spell I have caught myself spelling keywords wrong a number of times on many systems (I'm dyslexic). Longer commands are harder for me to get correct (Although, interestingly enough, I can feel my fingers mispelling something and correct using the backspace immediately, accounting for my 80 WPM average typing spped). > And what about consistency? I won't flame your example except to say it was inconsitant with UNIX parameterization. Generally, your consistancy argument is basically one of user interface preferences... I won't say chocolate vs. vanilla, as that is a rather misguided analogy. > > In the VMS environment, the command would be parsed (and verified > syntactically correct) in a consistent manner before the program (image) > was even loaded. Only if the command was defined prior to invoking it; this is not true of "external" commands. While I believe CLD's to be, in general, a good idea, there are a number of drawbacks, making them more difficult to impliment than external commands: 1) No non-error inducing way to check programatically if a CLD is defined. I can't tell, from within the program, whether or not I should try to parse the command line as a CLD or as an external command without setting up an error trap; something which is not shown as a source-code example in the manuals. 2) One must resort to non-portable calls to get CLD information, as opposed to main( ac, av) parsing. > In the Eunuchs evironment, the command parsing is left totally up to > the programmer. I agree, that while there are some merits to this approach (faster testing of quick-and-dirty programs and less source code and less debugging of external files), it does lead to the non-uniform implimentation of command lines by bad programmers. A CLD or BTOS style command interface would probably lend a great deal to UNIX. Note, however, that CLD's are a feature of DCL, the command interpreter, not of VMS. A *very* VMS-style interface, down to the implimentation of VMS-compatable library routines has been done under UNIX by the Celerity corporation. > This means a wide variety (and inconsistent) method of parsing between > programmers. (Sometimes the options to the "-" command must follow > immediately, other times a space, and other times an equals.) I agree that this has been a problem in the past; one of the goals of the proposed POSIX standard is to rectify this, however. Where did you find the '='? The only place that comes to mind is the 'dd' command, an originally student-written utility adopted from Berkely. I could, as easily, expect all DECUS software to be consistant. Agreed that it should not have been adopted without cleanup. But it is the fault of the development environment, NOT UNIX itself. > This was a problem in the AmigaDOS environment before ARP (AmigaDOS > Replacement Project) came along. AmigaDOS parses the commands just like > Eunuchs (inconsistencies included) and with cryptic "-" commands. ARP > provides a standard library of routines to parse the command line > arguements in a consistent manner. These libraries are available for > use of all Amiga programmers to provide this consistency. Something > like this is _*DESPERATELY*_ needed in all Eunuchs like environments. Obviously, you have not explored _all_ ARP commands! ;-). > P.S.: If the Eunuchs programmer really wants to, he(/she/it) can parse > the command line totally him(/her/it)self. This is to provide Eunuchs > compatability for those who want it. Could Eunuchs (and like > environments) provide optional and consistent command line parsing. Obviously, according to your first sentence, this is possible, but it is up to the programmer (that's you!) to do so. And again, this is a feature of the programs under UNIX, not UNIX itself. > Another thought on Eunuchs: Get an editor. Not UNIX; a program under UNIX. I think that what Val and everyone else have been bandying about with such a show of hormone-induced religious mania are *NOT* UNIX and VMS, per se, but in reality, the developement environments provided by each. Nowhere has it been argued the relative merits of a message passing architecture vs. a pure turing architecture, or any other features of the operating systems themselves. Do you have _any_ idea how VMS or UNIX does page allocation or timeslicing for task switches? By the way, Val, you spelled "UNIX" incorrectly... perhaps you are in need of a developement operating environment which is not so demanding on spelling ;-). | Terry Lambert UUCP: ...{ decvax, ihnp4 } | | @ Century Software : ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'There are monkey boys in the facility. Do not be alarmed; you are secure' |
terry@wsccs.UUCP (terry) (03/22/88)
In article <342@wsccs.UUCP>, val@wsccs.UUCP (Val Kartchner) writes: } } Before you flame me (see my previous article), I posted the previous } article from a soapbox. Please, take it with a large grain of salt. } The opinions expressed are my own, but they were undilluted with } tolerance. } } VMS has it's good points, but Unix is does too. I would like to become } as proficient with Unix as I am with VMS. Too late; gotcha. terry@century
dave@sea375.UUCP (David A. Wilson) (03/22/88)
in article <2886@enea.se>, sommar@enea.se (Erland Sommarskog) says: > > I wouldn't say that it's ridiculous. VMS 4.3, was approved for the C2 > level of security. Unix is not even near of this. Gould has developed a Unix system that is also C2. Almost any Unix system can be made C2 without great difficulty. Berkeley-style multiple group membership can provide very effective security, if /etc/group is carefully administered and root access is strictly limited. Some simple changes to the kernal could easily provide priviledged groups for some functions that are currently restricted to superuser only. I still haven't see a convincing argument to the claim that access-lists are more secure than user/group/other style permissions(where multiple group membership is allowed). -- David A. Wilson uw-beaver!tikal!slab!sea375!dave
msf@amelia.nas.nasa.gov (Michael S. Fischbein) (03/22/88)
In article <4236@umn-cs.cs.umn.edu> davidli@umn-cs.UUCP (Dave Meile) writes: > If you >don't believe this, try writing your own version of UNIX and marketing it >without paying AT&T any money. You'll quickly experience the how "non >proprietary" it really is! You mean like Doug Comer and Xinu? Or Tannenbaum (I think) and MINIX? Or Rich Stallman and GNU? Or CMU and Mach? If you don't use AT&T source code, you don't pay AT&T. If you rewrote VMS, you wouldn't have to pay DEC any royalties either, except they would throw look and feel lawsuits at you. I don't know anyone interested in writing/who has already written a PD version of VMS. I don't know any vendor who has been able to license VMS from DEC either -- to be fair, I haven't asked them. Does anybody know of any? mike -- Michael Fischbein msf@ames-nas.arpa ...!seismo!decuac!csmunix!icase!msf These are my opinions and not necessarily official views of any organization.
arosen@eagle.ulowell.edu (MFHorn) (03/23/88)
(Val Kartchner) writes: > Any Eunuchs programmer could easily: bllsht. Anyone else could spell it > correctly. [Eunuchs, Eunuchs, Eunuchs...] I think this is a sign of immaturity that I sadly find too often among the VMS Holies. At least the Unix people acknowledge VMS for it's good points _without_ making fun of VMS or it's fans. > In the VMS environment, the command would be parsed (and verified > syntactically correct) in a consistent manner before the program (image) > was even loaded. Which means DCL has to know the syntax of every command on the sytem. Yeah, real modern. Makes it real easy to add commands to the system, too. Especially for users who write their own private little utilities. Can you say search path? > Another thought on Eunuchs: Get an editor. What do you call GNU? I hate EDT and am quite happy with VI. But, I'm ignoring TPU (because I don't know it :-), so this isn't totally fair. > Before you flame me > Please, take it with a large grain of salt. But my blood pressure :-) > I would like to become > as proficient with Unix as I am with VMS. Funny, I'd like to become as proficient with VMS as I am with Unix. Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I ULowell, Box #3031 | ulowell!arosen | learned how to make it Lowell, Ma 01854 | | talk" -Thunder Road RD in '88 - The way it should be
sarge@swindle.Berkeley.EDU (Steven Sargent) (03/23/88)
In article <5640@swan.ulowell.edu>, arosen@eagle.ulowell.edu (MFHorn) writes: > (Val Kartchner) writes: > > Any Eunuchs programmer could easily: bllsht. Anyone else could spell it > > correctly. > [Eunuchs, Eunuchs, Eunuchs...] > > I think this is a sign of immaturity that I sadly find too often among the > VMS Holies. At least the Unix people acknowledge VMS for it's good points > _without_ making fun of VMS or it's fans. Speak for yourself. I've seen VMS and its fans flamed plenty here. > > > In the VMS environment, the command would be parsed (and verified > > syntactically correct) in a consistent manner before the program (image) > > was even loaded. > > Which means DCL has to know the syntax of every command on the sytem. Yeah, > real modern. Makes it real easy to add commands to the system, too. > Especially for users who write their own private little utilities. Can you > say search path? No reason that can't be made to work in a plausible way; programs have their own command tables, stored as ASCII documents or some such; could even be searchable in the path. Having a table-driven central command parser would be a real win for interactive help, argument completion, &c. -- not that DCL does all this, of course; if it did, it would be Tenex, and we wouldn't be having this discussion. A more annoying (to me, as a "Eunuchs" true believer; though my shower singing is still baritone...) is DCL's silly treatment of *. Leaves interpretation of the damn thing up to the command. So some do, some don't. And the ones you want 'em to, don't. E.g., the infamous SET DEF: $ set def somewhere::$disk437:[incredibly.frobulous.pathname .invented.by.masochists] <all ok> $ set def somewhere::$disk437:[incr*.frob*.pa*.inv*.by.mas*] %DCL-E-INSCRUTABLE$MESSAGE: Invalid specification (The problem here is actually more fundamental than a miscue on wildcard recognition; rather, it's that SET DEF is just accepting a string, which it vaguely checks for the right number of punctuation chars, to do filename translations with. It's entirely YOUR responsibility to ensure that the name actually lines up with a directory in the file system; if you didn't spell it right, set def back to SYS$LOGIN and try again. Now THAT's user-friendly!) Well, so, there's this lib$find_file or similar routine that your program can use, that will parse filenames iteratively, giving you back one per call. And your users have stood outside your office with cut-down shotguns, occasionally blasting one of your potted plants for laughs, while you hammered the puppy into your program so it would do *-expansion right. Only you're one of the Digital Equipment Brothers, and your program is DELETE: so you screw it up! That's right, you traverse the directory hierarchy preorder, rather than postorder, so you try to delete directories before you've deleted their children! So, now we have the answer to the VMS fans wanting to know why rm -r * is superior to DELETE [*...]*.*;* -- it's because rm -r works. A little bit of this mickey-mouse and UNIX-style globbing, where the shell does all filename expansion before the command sees anything, looks mighty good. Even with the god-cursed limit on number of chars in arguments. > > > Before you flame me > > Please, take it with a large grain of salt. > > I would like to become > > as proficient with Unix as I am with VMS. > > Funny, I'd like to become as proficient with VMS as I am with Unix. > With all this onesies-twosies, "mine's bigger" nonsense, we're sounding like a bunch of Model T owners, slugging it out for dragstrip supremacy at 25 mph. But I wanted a starship... > Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I > ULowell, Box #3031 | ulowell!arosen | learned how to make it > Lowell, Ma 01854 | | talk" -Thunder Road > RD in '88 - The way it should be "A foolish consistency is the hobgoblin of small minds." -- Emerson. UNIX is a Registered Trademark of AT&T. VMS and DEC are trademarks of the Digital Equipment Corporation. ---- Steven Sargent ARPA Internet: sarge@scam.Berkeley.EDU TPCnet: {from here to Eternity}!ucbvax!scam!sarge
davidli@umn-cs.cs.umn.edu (Dave Meile) (03/24/88)
In article <375@amelia.nas.nasa.gov> msf@amelia.nas.nasa.gov (Michael S. Fischbein) writes: >In article <4236@umn-cs.cs.umn.edu> davidli@umn-cs.UUCP (Dave Meile) writes: >> If you >>don't believe this, try writing your own version of UNIX and marketing it >>without paying AT&T any money. You'll quickly experience the how "non >>proprietary" it really is! > >You mean like Doug Comer and Xinu? Or Tannenbaum (I think) and MINIX? Or >Rich Stallman and GNU? Or CMU and Mach? If you don't use AT&T source code, >you don't pay AT&T. If you rewrote VMS, you wouldn't have to pay DEC >any royalties either, except they would throw look and feel lawsuits at you. > Umm... GNU stands for "GNU's Not UNIX". And, by definition, MINIX and Xinu are not UNIX either. One of the original propositions was that "you can easily transport between any system because it's all UNIX" -- well, if it isn't all UNIX then the transport question seems moot. You can probably port programs between GNU, MINIX, VMS, UNIX all with about the same amount of blood, sweat and tears. My point -- you can't *call* these systems "UNIX systems". Giventhe fact that DEC's operating system is a standardized architecture, I doubt that anyone *could* rewrite VMS. But then again, I am assured that standard code compiled on my MicroVAX II will run on the 8600 with which it communicates. Actually, I would prefer the POSIX standard to AT&T UNIX. Since many vendors are trying to get this thing set up, we should be living in interesting times... And since DEC is one of the vendors pushing POSIX, we can expect that over time VMS will look more POSIXish...
sommar@enea.se (Erland Sommarskog) (03/24/88)
Ah, it's not really over yet. But get to the next article if you feel you have more important things to do. Val Kartchner (val@wsccs.UUCP) writes: > And what about consistency? A comparison of a (hypothetical) command on > Eunuchs and VMS: > > flame/full/type=(eunuchs,consistency) commands > vs > flame -f -t=(eunuchs,consistency) commands > > In the VMS environment, the command would be parsed (and verified > syntactically correct) in a consistent manner before the program (image) > was even loaded. In the Eunuchs evironment, the command parsing is left > totally up to the programmer. This means a wide variety (and > inconsistent) method of parsing between programmers. (Sometimes the > options to the "-" command must follow immediately, other times a space, > and other times an equals.) And you forgot to mention another real bonus: When you have multi-letter options in Unix, you are forced to type the entire option. Same goes for the command. In VMS you have to type what is significant. So you memorize as Val wrote above, but you only type fl/fu/t=(eu, cons) commands if you feel like. For options parsing this is possible in Unix, but I have never seen it. (But I'm sure it exists somewhere.) For commands it's dead. (You can define an alias, but it's not really the same, since you abbreviate them.) Andy Rosen (arosen@hawk.ulowell.edu) comments Val's article: >Which means DCL has to know the syntax of every command on the sytem. Yeah, >real modern. Makes it real easy to add commands to the system, too. >Especially for users who write their own private little utilities. Can you >say search path? Can you say Command Definition Utility? Can you say foreign command line? With CDU you can define your own DCL commands. It's fairly easy for a somewhat experienced VMS user. If you want to parse the command line yourself, you use a foreign command line instead. Say what you want of DCL's syntax checks, but VMS does here provide a tool here that Unix doesn't. And being used to it, I miss it on Unix. -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP "Si tu crois l'amour tabou... Regarde bien, les yeux d'un fou!!!" -- Ange
hildum@iris.ucdavis.edu (Eric Hildum) (03/24/88)
In article <5640@swan.ulowell.edu> arosen@hawk.ulowell.edu (MFHorn) writes: > >Which means DCL has to know the syntax of every command on the sytem. Yeah, >real modern. Makes it real easy to add commands to the system, too. >Especially for users who write their own private little utilities. Can you >say search path? > You might want to look into this a bit more. To teach DCL a new command, one uses the command SET COMMAND filename, where the file contains a description of the command verb, the filename of the image to be activated, the qualifiers allowed or required, defaults, etc. Having added several commands to the system, I can assure you that it is quite easy. I am not sure what you mean by "modern." Why shouldn't your command table know the syntax of your commands? Eric dehildum@ucdavis.ucdavis.edu (Internet) dehildum@ucdavis.bitnet (BITNET) ucbvax!ucdavis!dehildum (uucp)
msf@amelia.nas.nasa.gov (Michael S. Fischbein) (03/24/88)
In article <4454@umn-cs.cs.umn.edu> davidli@umn-cs.UUCP (Dave Meile) writes: >In article <375@amelia.nas.nasa.gov> msf@amelia.nas.nasa.gov (Michael S. Fischbein) writes: >>You mean like Doug Comer and Xinu? Or Tannenbaum (I think) and MINIX? Or >>Rich Stallman and GNU? Or CMU and Mach? If you don't use AT&T source code, >>you don't pay AT&T. If you rewrote VMS, you wouldn't have to pay DEC >>any royalties either, except they would throw look and feel lawsuits at you. > >Umm... GNU stands for "GNU's Not UNIX". And, by definition, MINIX and Xinu >are not UNIX either. One of the original propositions was that "you can >easily transport between any system because it's all UNIX" -- well, if it >isn't all UNIX then the transport question seems moot. First, the named (royalty free) systems aren't UNIX for much the same reason Ultrix, HP-UX, UNICOS, SunOS, UTX, AIX, etc aren't ``UNIX:'' The word ``UNIX'' is a trademark of AT&T and they are the only ones who can, therefore, market a ``UNIX'' system. I call the others UNIX, as is common practice, to avoid circumlocutions like ``Operating system, utilities, and compilers that are source code compatible with the UNIX operating system originally developed by Bell Telephone Laboratories and since ported to a wide variety of computer architectures by a large number of researchers and vendors.'' > You can probably >port programs between GNU, MINIX, VMS, UNIX all with about the same amount >of blood, sweat and tears. Having done some of these ports from one to another of the ``Operating system, utilities, and compilers that are source code compatible with the UNIX operating system originally developed by Bell Telephone Laboratories and since ported to a wide variety of computer architectures by a large number of researchers and vendors,'' and to and from VMS I feel that I can report that porting C code, at least, to VMS is MUCH more difficult than going, say, from Silicon Graphics' GL3.5 to Cray's UNICOS. Or to Gould's UTX. Or, for that matter, to Xenix. We have non-trivial programs that run without any source code changes on systems from IBM-PCs to Macs to HP minis to Cray-2's. We have slightly more machine specific code (raw vs cooked mode, etc) that runs with no modifications but has a few ifdef's scattered about. They don't run on VMS. >My point -- you can't *call* these systems "UNIX systems". A rose by any other name would smell as sweet. >Given the fact that DEC's operating system is a standardized architecture, An OS is an architecture? Or does Ultrix run on a different architecture than VMS? >I doubt that anyone *could* rewrite VMS. But then again, I am assured that >standard code compiled on my MicroVAX II will run on the 8600 with which >it communicates. Yep. I also am assured that the code I compile on my Sun 3/140 will run on the Sun 3/280 with which it communicates. I can also take my source, recompile it, and run it on an HP, say, for better performance -- better performance at a lower price than that 8600. Or on a PC-AT for a cheaper, dedicated platform. Or on a Cray-2 for perfomance (and price) way above anything DEC offers. When VMS runs on both $1500 machines and 300 MFLOP machines with multiple vendor support (competitive procurement) it will be a viable alternative to UNIX. mike -- Michael Fischbein msf@ames-nas.arpa ...!seismo!decuac!csmunix!icase!msf These are my opinions and not necessarily official views of any organization.
sqkeith@csvax.liv.ac.uk (03/25/88)
Please, please don't change the subject header of these stupid drivellings about my 'OS is bigger and better than yours' (see Dr. Ruth). I've added some code to our newsfeed that removes all such messages before our NEWS system even gets to process them, sending them to NL: (or /dev/null in Unix speak) where they belong. I just don't want to know about other's personal preferences - I have my own Keith
sommar@enea.se (Erland Sommarskog) (03/27/88)
Off we go again. Some quibblings about wild cards this time. And if you feel you had enough of this already, well the form feed it's for you. >A more annoying <...> is DCL's silly treatment of *. Leaves >interpretation of the damn thing up to the command. So some do, some >don't. And the ones you want 'em to, don't. E.g., the infamous SET DEF: >... >Well, so, there's this lib$find_file or similar routine that your program >can use, that will parse filenames iteratively, giving you back one per >call. And your users have stood outside your office with cut-down First we discussed command parsing. DCL parses the command and inkoves the image. In Unix the program has to parse them itself, giving a non- uniform interface. With wild cards it's the opposite. The shell expands them, whereas DCL leaves that to the program and the file system. The good way with the Unix style is that it's easy to write a utility that operates on a suite of files. Just read argv to the end. This is harder under VMS. LIB$Find_file (or $parse and $search) are more difficult for the unexperiencd user. The VMS way has two advanteges. Unix assumes that all arguments are files. This is often, but not always true. "HELP *" does also give a better result than "man *". The other point is that you use file specification in more places than the command line interpreter. Instead of putting the file- name parsing in DCL, VMS provides routines (in RMS) for a uniform behaviour. Not only wild cards, but also logical names, related names and defaults. But of course, the programs must actually use them, for it all to work. I assume Unix has *something* similar to this - it ought to have - but ~-substitution does not always work, as translation of environment variables. (Which is the closest to logical names Unix comes as far as I know.) And for postorder/preorder of DELETE: DELETE uses the same routines as all the other commands, in which we would prefer preorder. No problem for "rm" to make it right. It has to do the traversal itself anyway. Unix doesn't provide a wild card like "...". At least no one has told me about it. -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP
afr@erialfa.UUCP (Anders Fredrikson ZX/DRG) (03/30/88)
Why don't we cut this crap about UNIX vs. VMS. Readers are getting tired, at least me. I thought this was a *Technical* newsgroup, but correct me if i'm wrong! Let's talk tech - not grumble. /Anders
bzs@bu-cs.BU.EDU (Barry Shein) (04/05/88)
From: val@wsccs.UUCP (Val Kartchner) >In article <20597@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes: >> >And this brings us on to another issue which Barry does not mention: >> >Unix may have some clever tricks, but it's user interface is really >> >arcane. One-letter options is certainly not state-of-the-art. >> >> I don't mention it because I believe it's a chocolate/vanilla issue I >> specifically said I would avoid. Or would you like to give us all a >> good definition "arcane", with units preferably, perhaps something >> like measured learning curves etc. Can you spell bullshit, I knew you >> could. > > Any Eunuchs programmer could easily: bllsht. Anyone else could spell it > correctly. > > Shall we compare learning curves? A new user on VMS can learn more in > less time because the options make sense. For instance, what does "-s" > mean as opposed to "-S" as opposed to "/system" or "/security"? Which > would make more sense to a new user? Uh, no Val, you miss the whole point. Learning curves aren't something you speculate on, it's something you can measure, numbers, plots, statistical analysis etc. For example, you take two groups of people of roughly equivalent whatever (education, job status etc, whatever your design goal is) and one uses one system while the other uses a different system, then you measure how long it takes them to do some relevant tasks, probably with weighting for errors. Then you compare the numbers and see if there is a real difference. Studies like this I have heard of rarely find any much difference. Obviously one can devise better methods. Not intuitive? Gee, science isn't always intuitive. Think of it this way: Look at your telephone, does it look "user-friendly" to you? Do you see your friend's full names on it anywhere? Or do you have to punch in lots of long strings of digits to find them? Can your average 7 year old use the telephone? Anything else you'd like to tell AT&T they've missed the boat on? -Barry Shein, Boston University