eugene@eos.UUCP (Eugene Miya) (02/22/89)
A Modest Proposal
With all this current debate about who's OS is better, and what's
optimal for their special kind of hardware. I think the pundits
of various OSes should be forced to port their OSes to all the
different kinds of computers out there. They should not be allowed
to sell hardware which does not have their OS running on different
machines. Think of it, hundreds of programmers porting OS/360/MVT
to the Modcomp Classic, Microsoft programmers porting PC/DOS to
ETA-10s. VMS running on the Unisys 1100/90, CTSS running on the
IBM/PC. Do you know what a V73 is? [Am I forgetting your favorite
bizarre combination of OS to machine?] We will be in the gravy forever
(See the deal the philosophers made with Deep Thought).
These von Neuman uniprocessors don't differ that much.
We Unics should encourage these other OSes to prove their manhood
and port their OSes and get them out of our hair. Just think
you too can relive the 60s. American Operating System Stand.
Yes, revive the 60s on the hardware of the 80s, using OSes of the 70s
and 60s, writing in languages of the 50s, in algorithms of the 90s,
1890s that is.
We know there are EXEC*1100, RSTS, NOS, MVT, et al programmers out there.
The goal is to get them bogged down, smile and nod your head,
encourage fast feature-itis: add graphics,
add porting to N-different architectures, add light weight processes
(oh, wait a minute! that's a useful concept). Let's encourage them to
dig big pits.
Think of it!
Another gross generalization from
--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
resident cynic at the Rock of Ages Home for Retired Hackers:
"Mailers?! HA!", "If my mail does not reach you, please accept my apology."
{uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene
"Post follow ups. Contribute to network noise."
The future currently lies in loosely coupled distributed algorithms
like the factoring done at DEC.
"I believe that 2/3 of the Pentagon should be forced to write each other
memos in long hand. And let the other 1/3 get on with doing work."
-- Hyman Rickoverraveling@vaxb.isi.edu (Paul Raveling) (02/23/89)
In article <2685@eos.UUCP> eugene@eos.UUCP (Eugene Miya) writes: >A Modest Proposal > > [Lots about porting OS's such as OS/360/MVT and VMS to > other machines... I wasn't going to comment until the > day's work took the turn noted in item 3 below.] > >We Unics should encourage these other OSes to prove their manhood >and port their OSes and get them out of our hair. Just think >you too can relive the 60s. You mean by using UNIX? (sorry, I couldn't resist) We're looking for application portability, right? 1. We didn't have to even recompile or change [ugh] JCL to move from one machine running OS/360 to another. In case the '91 was down, we just ran the same batch of jobs on a model 75 -- or even a mod 40. [However, I'll second the motion that OS/360 should RIP ... or even IEHRIP0666I; Brownie points to whoever can name the atrocity Release 13 committed if you forgot the SPACE parameter on a DD statement for a scratch data set] 2. It's been some years since I used VMS, but I can believe the same is substantially true across the VAX line, anywhere from Microvax through 8800. 3. Here's what prompted me to not keep quiet -- a small portion of a log file from today's "adventures" in portable software on UNIX: widgets Dclock Make failed; Xlib symbols unresolved despite -lX Mailwatch Make failed; Xlib symbols unresolved despite -lX MenuBox Made Needed to hack includes for test Xhp Make failed; syntax errors in header files Xsw Make failed; missing include file cpicker Make failed; compilation errors in Bargraph.c tblwidget Make failed; syntax errors in Tbl.c widgeteditor extensions Made qp Make failed; incompatible cmd line syntax for ld [cc] wedit Make failed; incompatible cmd line syntax for ld [cc] Widgetwrap Make failed; depends on header file installation xpalette Make failed; undefined externals when linking Not to mention that it was necessary to hack Makefiles for most of these to get even that far. ---------------- Paul Raveling Raveling@isi.edu
rscott@woods.unix.eta.com (Richard Scott) (02/24/89)
In article <7612@venera.isi.edu> raveling@vaxb.isi.edu.UUCP (Paul Raveling) writes: ->In article <2685@eos.UUCP> eugene@eos.UUCP (Eugene Miya) writes: -> .... ->We Unics should encourage these other OSes to prove their manhood ->and port their OSes and get them out of our hair. Just think ->you too can relive the 60s. - - You mean by using UNIX? (sorry, I couldn't resist) - - - We're looking for application portability, right? - - 1. We didn't have to even recompile or change [ugh] JCL - to move from one machine running OS/360 to another. - In case the '91 was down, we just ran the same batch - of jobs on a model 75 -- or even a mod 40. - So? This is comparable to me saying that my binaries which run on the Sun 3/60 on my desk also run on a 3/280 in our lab. Both are running SunOS, a variant of UNIX, (not even the same version, though). Shell scripts run on both our Sun-3's and our Sun-4's, unmodified; if you're willing to recompile, C programs will also run on both, again unmodified. This is nothing new; notice, however, we are both talking about machines all made by the same manufacturer. - 2. It's been some years since I used VMS, but I can believe - the same is substantially true across the VAX line, - anywhere from Microvax through 8800. Ditto for Sun or any mfgr. of multiple-architecture UNIX machines. This really means nothing new. - - 3. Here's what prompted me to not keep quiet -- a small - portion of a log file from today's "adventures" in - portable software on UNIX: - -widgets - - Dclock Make failed; Xlib symbols unresolved despite -lX - Mailwatch Make failed; Xlib symbols unresolved despite -lX - MenuBox Made Needed to hack includes for test - Xhp Make failed; syntax errors in header files - Xsw Make failed; missing include file - cpicker Make failed; compilation errors in Bargraph.c - tblwidget Make failed; syntax errors in Tbl.c - widgeteditor - extensions Made - qp Make failed; incompatible cmd line syntax for ld [cc] - wedit Make failed; incompatible cmd line syntax for ld [cc] - Widgetwrap Make failed; depends on header file installation - xpalette Make failed; undefined externals when linking - - Not to mention that it was necessary to hack Makefiles for - most of these to get even that far. Ah, but you haven't told us how trivial it is for you to port code between the machines you talk about in ex. 1 and the machines mentioned in your ex. 2 (i.e. IBM running OS/360 <--> VAX running VMS)? Complete software compatability in the lines of machines *by the same manufacturer* is easy; UNIX is good in that it gives you a *reasonably* portable platform between machines of different companies. [vis-a-vis Bill Joy's keynote address at SUG, Winter '88] -Paul Raveling -Raveling@isi.edu ---------- rich scott (612) 642-8404 internet: rscott@unix.eta.com eta systems, st. paul, mn uucp: {amdahl,rutgers}!bungia!eta!rscott "I've been on a calendar, but never on time" - Marilyn Monroe
raveling@vaxb.isi.edu (Paul Raveling) (02/25/89)
In article <2882@eta.unix.ETA.COM> rscott@woods.unix.eta.com (Richard Scott) writes: > > Ah, but you haven't told us how trivial it is for you to port code >between the machines you talk about in ex. 1 and the machines mentioned in >your ex. 2 (i.e. IBM running OS/360 <--> VAX running VMS)? Complete software >compatability in the lines of machines *by the same manufacturer* is easy; UNIX >is good in that it gives you a *reasonably* portable platform between machines >of different companies. [vis-a-vis Bill Joy's keynote address at SUG, Winter '88] Actually the easiest ports I've done have been from [PC/MS]DOS to UNIX. They've been easier than the typical UNIX-to-UNIX port. In truth, support for the same progamming language is by far the most important factor in porting noninteractive applications. The next question is whether a standard such as X11 will succeed in producing portability for interactive code. ---------------- Paul Raveling Raveling@isi.edu