rbj@uunet.UU.NET (Root Boy Jim) (04/25/91)
Some vendors have "dual universe" machines, where you can pretend that you're on a machine running Berkeley Unix or one running System V. Other vendors start with one as a base and add features of the other. Of course it is easy to just add missing pieces; the hard part is resolving conflicts. Given this state of affairs (pre POSIX) how do y'all feel about the relative merits of dual universes vs merged systems? Which model do you think serves customers better? -- [rbj@uunet 1] stty sane unknown mode: sane
fitz@mml0.meche.rpi.edu (Brian Fitzgerald) (04/25/91)
Root Boy Jim writes: >Some vendors have "dual universe" machines, where you can >pretend that you're on a machine running Berkeley Unix or >one running System V. Other vendors start with one as a base >and add features of the other. Of course it is easy to just >add missing pieces; the hard part is resolving conflicts. ... >Which model do you think serves customers better? Well, I'm not a wizard, I'm a customer. Since there's no comp.unix.customers, here's my two cents worth: I like the way Sun has done it up to the present. The principal utilities are in /bin or /usr/ucb. System V programs are distributed as an installation option. If you don't install them, nothing is broken. The default behavior of a program is usually BSD, and in any event is specified in the man page. The default behavior of shell builtins such as echo depend on whether /bin or /usr/5bin is earlier in the path. If you want to run sysV programs, just add /usr/5bin to your path, ahead or after the other directories, to suit, otherwise leave it out. If you prefer to routinely use the sysV version of one particular program over the BSD variant, use an alias. (I do this with pr.) If, instead of this arrangement, I had to select a "Universe" in which to operate, I'd probably choose BSD the first time I logged in and then change it seldom or never. If I could avoid installing two universes on my machine, I probably would. Brian -- We need to secure as many banks in our computer banks as possible. We don't want no one else's help, but yours. Miller's Comsumer Service
richard@locus.com (Richard M. Mathews) (04/26/91)
rbj@uunet.UU.NET (Root Boy Jim) writes: >Given this state of affairs (pre POSIX) how do y'all feel >about the relative merits of dual universes vs merged systems? The survival of Unix depends on portability. The marketplace perceives portability (rightly or not) as being the biggest advantage of Unix, so portability must be a major concern of Unix system developers. New systems with new features will always come up. If we do not periodically push everything back together, the set of Unix systems will diverge to the point of uselessness. The split between BSD and AT&T is becoming less significant with merged systems such as AIX and SVR4. On the other hand, new splits (OSF versus UI?) will pop up. The universe model will fall apart when it turns into a huge menu system: choose one from each column BSD OSF X FOO AT&T UI Y BAR POSIX Let's merge BSD and SysV now, resolve the conflicts, then start over inventing new features to create the next generation of splitting. At least that split will have started from just one place. On AIX there are only a few commands left (nm and tr are the only ones which come to mind) which are not completely merged. It is wonderful to not have to remember whether each particular feature I use comes from this system or that one. I don't have to worry about which universe I'm in right now -- I know that each feature I want is always there. I can just type "stty crt -ixany", and I know it will work. Richard M. Mathews D efend richard@locus.com E stonian-Latvian-Lithuanian lcc!richard@seas.ucla.edu I ndependence ...!{uunet|ucla-se|turnkey}!lcc!richard
martin@mwtech.UUCP (Martin Weitzel) (04/27/91)
In article <130311@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes:
:Some vendors have "dual universe" machines, where you can
:pretend that you're on a machine running Berkeley Unix or
:one running System V. Other vendors start with one as a base
:and add features of the other. Of course it is easy to just
:add missing pieces; the hard part is resolving conflicts.
:
:Given this state of affairs (pre POSIX) how do y'all feel
:about the relative merits of dual universes vs merged systems?
:
:Which model do you think serves customers better?
Well, that totally depends on the demands of the customer. If the
users at the customer's site usually are totally split up and only
work in one or the other universe, the former model has its benefits.
But as soon as they start to pick one thing from here, something else
from there (and boy, they do, they do, I only know too well!) dual
universes get a real pain in the back. At least this is the experience
I've made on a tripple universe system: 'Conditional symbolic links' are
exactly that sort of thing that make me turn and step away if I can (as
you may guess: I could not step away sometimes because there were some
work to do ...)
Merged systems appear a bit smoother in my opinion, but I must confess
that I more and more look over to rid of all those bloated kernels that
have grown by the factor of 20 in size but only by the factor of 2 or 3
(at most) in functionality, because most of the additional functionality
duplicates other existing functionality with minor variations. (I think
I'll give COHERENT a try on the Notebook-PC I'll buy as my next personal
system.)
--
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83gwyn@smoke.brl.mil (Doug Gwyn) (04/27/91)
In article <mxtg5lj@rpi.edu> fitz@mml0.meche.rpi.edu (Brian Fitzgerald) writes: -Root Boy Jim writes: ->Some vendors have "dual universe" machines, where you can ->pretend that you're on a machine running Berkeley Unix or ->one running System V. Other vendors start with one as a base ->and add features of the other. Of course it is easy to just ->add missing pieces; the hard part is resolving conflicts. -... ->Which model do you think serves customers better? -If I could avoid installing two universes on my machine, I probably -would. As the implementor of the second "dual universe" BSD/ATT implementation (Pyramid was the first), I'd like to say that dual universes suck. If you can, simply use SVR4 and get essentially all the BSD facilities worth having added in a consistent way to a technically superior base system.
gwyn@smoke.brl.mil (Doug Gwyn) (04/27/91)
In article <richard.672629724@fafnir.la.locus.com> richard@locus.com (Richard M. Mathews) writes: >Let's merge BSD and SysV now, resolve the conflicts, then start over >inventing new features to create the next generation of splitting. >At least that split will have started from just one place. Hear, hear.
andys@ulysses.att.com (Andy Sherman) (04/29/91)
In article <richard.672629724@fafnir.la.locus.com> richard@locus.com (Richard M. Mathews) writes: |>Let's merge BSD and SysV now, resolve the conflicts, then start over |>inventing new features to create the next generation of splitting. |>At least that split will have started from just one place. Pardon my naivete, but isn't that what SVr4 is supposed to do? -- Andy Sherman/AT&T Bell Laboratories/Murray Hill, NJ AUDIBLE: (908) 582-5928 READABLE: andys@ulysses.att.com or att!ulysses!andys What? Me speak for AT&T? You must be joking!
rcd@ico.isc.com (Dick Dunn) (04/30/91)
andys@ulysses.att.com (Andy Sherman) writes: > richard@locus.com (Richard M. Mathews) writes: > |>Let's merge BSD and SysV now, resolve the conflicts, then start over > |>inventing new features to create the next generation of splitting. > |>At least that split will have started from just one place. > Pardon my naivete, but isn't that what SVr4 is supposed to do? (OK, your naivete is duly pardoned.:-) Yes, there was a time when it appeared that SVR4 was intended to be a merge of BSD and SysV...at least, many of us were led to believe that. It turned out not to be the case, if you understand "merge" in the sense Richard is using it. V.4 is a combination of the two systems. It contains all of the facilities of both systems, as one might expect. However, where BSD and V.3 implemented the same idea in different ways, or provided different options, etc., V.4 provides *both* mechanisms, plus a way to choose one or the other. Thus, for example, you've got both sockets and streams (one imple- mented in terms of the other, but both still present). You've got both types of file system. You've got two versions of any command which is significantly different under V.3 and BSD. In this sense it's not a merge. Granted, the plethora of features and the "upward compatibility" from either BSD or V.3 will probably help make it a Commercial Success, but it's distressing to folks who thought V.4 might help simplify things. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...If you plant ice, you're gonna harvest wind.
sef@kithrup.COM (Sean Eric Fagan) (05/01/91)
In article <richard.672629724@fafnir.la.locus.com> richard@locus.com (Richard M. Mathews) writes: >Let's merge BSD and SysV now, resolve the conflicts, then start over >inventing new features to create the next generation of splitting. >At least that split will have started from just one place. Better yet, let's start from scratch and do everything better. Then write equivalent commands and compatible library functions. One person I've talked to had a 5MByte SysVr4 kernel. Sick. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
gwyn@smoke.brl.mil (Doug Gwyn) (05/02/91)
In article <14673@ulysses.att.com> andys@ulysses.att.com (Andy Sherman) writes: >In article <richard.672629724@fafnir.la.locus.com> richard@locus.com (Richard M. Mathews) writes: >|>Let's merge BSD and SysV now, resolve the conflicts, then start over >|>inventing new features to create the next generation of splitting. >|>At least that split will have started from just one place. >Pardon my naivete, but isn't that what SVr4 is supposed to do? Yes, but not everybody is cooperating. OSF/1, AIX, A/UX, and 4.4BSD all appear to be continuing to evolve in their own separate ways.
gwyn@smoke.brl.mil (Doug Gwyn) (05/02/91)
In article <1991Apr29.222849.7981@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >... it'sdistressing to folks who thought V.4 might help simplify things. But it DOES help simplify things. Surely it's better to provide a single kernel mechanism (streams) and provide a socket compatibility library than to provide just one or the other? At least they did this right and put just one mechanism (the more generally useful mechanism) in the kernel.
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (05/02/91)
In <1991Apr30.233337.6112@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >Better yet, let's start from scratch and do everything better. Then write >equivalent commands and compatible library functions. That's roughly what Berkeley did, while preserving Version 7 compatibility. Then AT&T came along... -- Rahul Dhesi <dhesi@cirrus.COM> UUCP: oliveb!cirrusl!dhesi
stripes@eng.umd.edu (Joshua Osborne) (05/02/91)
In article <1991Apr30.233337.6112@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: [...] >Better yet, let's start from scratch and do everything better. Then write >equivalent commands and compatible library functions. Isn't this what Mach is all about? (or at least Unix under Mach, and Unix under V, and mabie even Amoeba (but I know less about it then V or Mach, anyone have any good references on that, if you do mail 'em to me please)) >One person I've talked to had a 5MByte SysVr4 kernel. Sick. And I thought the 3M genvmunix for DECStations was sick... -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Multitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "CNN is the only nuclear capable news network..." - lbruck@eng.umd.edu (Lewis Bruck)
rcd@ico.isc.com (Dick Dunn) (05/02/91)
sef@kithrup.COM (Sean Eric Fagan) writes: > richard@locus.com (Richard M. Mathews) writes: > >Let's merge BSD and SysV now, resolve the conflicts, then start over > >inventing new features to create the next generation of splitting. ... > Better yet, let's start from scratch and do everything better. Then write > equivalent commands and compatible library functions. But how do we do this without hitting the "second system effect" in spades? Why not just help something like the BSD effort (which is doing the second half of what Sean suggests) but not starting from scratch? > One person I've talked to had a 5MByte SysVr4 kernel. Sick. Also screwed-up somehow. The V.4 kernels I've seen have been larger than V.3 kernels, but nothing all that huge. I'm curious what you have to botch to get a kernel that large. (I'm *not* saying that V.4 isn't huge--just that I haven't seen it *that* huge [yet].) -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...If you plant ice, you're gonna harvest wind.
shore@theory.tn.cornell.edu (Melinda Shore) (05/02/91)
In article <1991May1.213542.248@eng.umd.edu> stripes@eng.umd.edu (Joshua Osborne) writes: >In article <1991Apr30.233337.6112@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >[...] >>Better yet, let's start from scratch and do everything better. Then write >>equivalent commands and compatible library functions. > >Isn't this what Mach is all about? No. Mach is a research OS that is being commercialized. The Unix stuff that runs on top of Mach (3.0 that is - Mach 2.5 and earlier is deeply embedded in the 4.3BSD kernel and is almost certainly not what you're thinking of) makes extensive use of Unix source, as well as source from hardware vendors for drivers, math libraries, boot code, etc. For rewrites of existing software you're better off looking to CSRG and the FSF. -- Software longa, hardware brevis Melinda Shore - Cornell Information Technologies - shore@theory.tn.cornell.edu
gwyn@smoke.brl.mil (Doug Gwyn) (05/02/91)
In article <3100@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes: -In <1991Apr30.233337.6112@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: ->Better yet, let's start from scratch and do everything better. Then write ->equivalent commands and compatible library functions. -That's roughly what Berkeley did, while preserving Version 7 -compatibility. Then AT&T came along... Your summary of UNIX development history is radically wrong.
sef@kithrup.COM (Sean Eric Fagan) (05/05/91)
In article <3100@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes: >>Better yet, let's start from scratch and do everything better. Then write >>equivalent commands and compatible library functions. >That's roughly what Berkeley did, while preserving Version 7 >compatibility. Then AT&T came along... Right. That's why you need an AT&T source license for BSD. Yep. I can see how they started from scratch. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
fpb@ittc.wec.com (Frank P. Bresz) (05/15/91)
I have been following the thread and more people then I care to mention have said things and I have also lost some of the thread. This is honest to goodness inquiry not a joke. My understanding is that it has basically come down to 2 'major corporate' camps : SVR4(Sun, Now HP?) vs. OSF/1 (DEC, IBM, ???) 1. I know there are more but just what is the current scorecard as for whose on whose side. Or more appropriately Who's on first What's on second... 2. Having been a user of Sun Workstations for >2 years, and also having just received 10 DECstation 5000's + a shiny new VAX running VMS. I have this inquiry. Is there somewhere on the Net I can get an 'informative' comparison to what these things are going to evolve to be. I have read trade rags ad infinitum and to me they just confuse the issue. I know that this forum has a better (or at least should) idea than they do. I mean, their combined knowledge could probably be summed up quicker than it has already taken me to write this. 3. I have been barraged by the local DRECnoids as to 'OSF/1 and MOTIF is the wave of the future' what will you do with your Suns when it arrives? My current 'unverbalized' response has been : 'Since that date is as near to, when hell freezes over, as not to matter I personaly am not overly concerned.' Should I be? -- | () () () | Frank P. Bresz | Westinghouse Electric Corporation | \ /\ / | fpb@ittc.wec.com | ITTC Simulators Department | \/ \/ | uunet!ittc!fpb | Those who can, do. Those who can't, simulate. | ---------- | +1 412 733 6749 | My opinions are mine, WEC don't want 'em.