xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/02/90)
1) We've seen a lot of SYSV4 versus BSD bashing here. Can anybody actually say with some authority what you give away in going from BSD to SYSV4, rather than just the known-to-be-false statement that SYSV4 is a superset of BSD? What will be the effect at the user/developer interface level? 2) _The_ thing that made BSD so much better than its AT&T parent that AT&T finally had to bow to the inevitable (as the workstation market "all" went BSD) and mutate SYSV4 into a BSD clone to be marketable, was the ready availability of _almost free_, _full_ source code licences to the user/programmer community, so that the tremendous resource of free user community programming effort could be brought to bear on improving BSD through several extremely impressive upgrades while AT&T fell further and further behind. Now that AT&T has wrested control of the future of Unix back from the user community, are we going to see the same dreary game of home-mortgage-sized source licence fees and vendor-only code improvements retarding the future of Unix, or has the lesson of open software systems finally been learned, so that cost-of-media source code licenses and ready adoption/sharing of user written OS improvements will keep the future of Unix bright? 3) Tripos would have been out of AmigaDOS two years ago if the user community had been allowed to participate in the process. Has Commodore learned the BSD lesson yet? 4) BSD's other great advantage was _hundreds_ of utilities, compilers, whatnot bundled with the (cheap, cheap, cheap) OS. Are we getting the "real" Unix with AmigaUX, or just a stripped down file server and a chance to bleed to death $100 at a time buying the utilities that make everyday BSD use the most productive software development environment in existance? Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
thad@cup.portal.com (Thad P Floryan) (12/03/90)
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan)
in <1990Dec2.153612.28555@zorch.SF-Bay.ORG> writes:
[...]
{numerous comments praising BSD and condemning SysV}
And his comment:
_The_ thing that made BSD so much better than its AT&T parent ... was
the ready availability of _almost free_, _full_ source code licences
to the user/programmer community, so that the tremendous resource of
free user community programming effort ...
That's the VERY problem SVR4 prevents. Now hear me out. I, too, am from the
"school" where ready availability of sources was de rigeur, and I've had mixed
emotions on the SysV sources issue for quite some time.
One of the very reasons UNIX was NOT being as readily accepted in the "real"
world was due to all the hundreds of customized "hacks" and non-portable
features at each of 100's or 1000's of sites. If one used feature "foo()"
at site bar.edu, that feature was NOT guaranteed to be available or work
the same at site nematode.com.
One reason that I see for AT&T's recent high source license fees was to
restrict random hacks to "responsible" port teams for platform-specific
features as required, and to assure that SVR4 would have the same "look and
feel" no matter what vendor's UNIX one chose to use.
As UNIX is becoming "essentially" a standard, it MUST conform to the other
vendors' ports. This follows the reasoning behind the Application Binary
Interface (the UNIX "shrink wrap software" compatibilty) formulated by very
seasoned and capable persons.
Everything I've wanted in SysV is in SVR4, and it appears that everything
from 4.3BSD is in there too: file systems, networking, etc etc etc.
Kent continues:
3) Tripos would have been out of AmigaDOS two years ago if the user
community had been allowed to participate in the process. Has Commodore
learned the BSD lesson yet?
So? Programs I've written which worked under pre-1.0 AmigaDOS are still
working under the latest OS. What's your point?
And finally, he says:
... the utilities that make everyday BSD use the most productive
software development environment in existance?
Bushwa! As just ONE example of BSD's obsoletedness that recently caused me
MUCH grief, let's look at BSD curses vs. *ANY* SysV curses since SVR3.
Where's the BSD terminfo support, alternate character set, region scrolling,
line insert/delete, color support, etc etc etc? I just had to buy a source
license from Aspen Scientific for their "curses" package (SVR3.2 compatible)
just so my programs WOULD have the same "look and feel" under BSD, A/UX, and
VAX/VMS as they do under SysV; the BSD, A/UX and VAX/VMS curses are garbage,
plain and simple. I've thrashed THIS issue out in comp.sys.att, comp.unix.*,
and several other newsgroups. Guy Harris' only comment about my postings and
other info concerned A/UX (and if you don't know who Guy Harris is, then you
don't know your UNIX history; you can look him up at either auspex!guy or in
"The Design and Implementation of the 4.3BSD UNIX Operating System").
And don't talk to me about X; all my application needed was tiled and over-
lapping pop-up fancy-line-border windows, menus and "forms" along with various
text and character video attributes (and now color) and cursor-key, mouse and
keypad user input WITHOUT the overhead of X, especially since most "real world"
business customers do NOT have X-terminals and may be calling in at 2400 to
9600 baud on serial lines. The application couldn't be done under BSD without
writing my OWN graphics library (or buying the Aspen one), since BSD doesn't
provide those features BUT SVR3 and SVR4 do.
Kent, it appears to me you haven't studied any recent SysV system, and are
just parroting the statements of others without having had the opportunity
to form your OWN opinions. This is not meant as an insult or an attack, just
an observation based on your comments.
For MANY years I thought *ALL* UNIX systems were garbage because I was
listening to others whose opinions I respected ... until I had the opportunity
to buy my own system and actually LEARN what UNIX is all about (all versions);
I now own, personally, 7 UNIX boxes and have many others available to me
because it wasn't until I could SEE and USE UNIX that I realized how really
good it is for the type of things I and my clients need to do. And that's why
I also formed the Silicon Valley AT&T UNIX Users' Group: to help spread "The
WORD!" :-)
My only REAL gripe with pre-SVR4 systems has been the 14-character filename
limit ... that has been REALLY a hassle for me. But with SVR4 you just bring
up the BSD FFS and no sweat.
If you want some SVR4 systems to play with, there are several opportunities
available besides the one listed in the net-posting re: A3000 UNIX; many of
them are '486-based, but some 68040-based ones should be available VERY soon
(assuming I haven't been fed some marketing hype).
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]n025fc@tamuts.tamu.edu (Kevin Weller) (12/04/90)
In article <36488@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes:
------------------------------------------------------------------------------
....
And don't talk to me about X; all my application needed was tiled and over-
lapping pop-up fancy-line-border windows, menus and "forms" along with various
text and character video attributes (and now color) and cursor-key, mouse and
keypad user input WITHOUT the overhead of X, especially since most "real world"
business customers do NOT have X-terminals and may be calling in at 2400 to
9600 baud on serial lines. The application couldn't be done under BSD without
writing my OWN graphics library (or buying the Aspen one), since BSD doesn't
provide those features BUT SVR3 and SVR4 do.
....
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
------------------------------------------------------------------------------
Well said! I for one can't afford to set aside the memory, disk
space, and CPU power for the resource-hog that is X. My group can
have quite a few more things going at once without X than with it, a
much more cost-effective practice for those that don't need
*everything* in bit-mapped graphics. It seems that, at least for now,
character-based windowing is the key to true portability.
-- Kev
--
Kevin L. Weller /-------+--------------------\
internet: n025fc@tamuts.tamu.edu | aTm | GIG 'EM, AGGIES! |
CIS: 73327,1447 \-------+--------------------/lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/04/90)
In <36488@cup.portal.com>, thad@cup.portal.com (Thad P Floryan) writes: > >My only REAL gripe with pre-SVR4 systems has been the 14-character filename >limit ... that has been REALLY a hassle for me. But with SVR4 you just bring >up the BSD FFS and no sweat. While 14 character file names are annoying, the SysVism that I got bitten by not too long ago was the 1 second resolution on file dates. Seems the SPARCs are getting fast enough for that to make a difference. -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/04/90)
In article <36488@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: > Bushwa! As just ONE example of BSD's obsoletedness that recently caused me > MUCH grief, let's look at BSD curses vs. *ANY* SysV curses since SVR3. > Where's the BSD terminfo support, alternate character set, region scrolling, > line insert/delete, color support, etc etc etc? Terminfo support? Where's System V's termcap support? Not an issue. BSD alternate character set: as, ae. Region scrolling: cr. Line insert: il. Line delete: dl. There's no color support, but there also aren't two color terminals in a thousand. And you can pretty much standardize the name for a new feature by calling up Berkeley and asking for it. > Kent, it appears to me you haven't studied any recent SysV system, I don't see any errors or implied errors in what Kent wrote. I see a nearly complete travesty of the truth in your only example of supposed BSD failings. ---Dan
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/04/90)
thad@cup.portal.com (Thad P Floryan) writes: > xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > [...] > {numerous comments praising BSD and condemning SysV} >And his comment: > _The_ thing that made BSD so much better than its AT&T parent ... was > the ready availability of _almost free_, _full_ source code licences > to the user/programmer community, so that the tremendous resource of > free user community programming effort ... >That's the VERY problem SVR4 prevents. Now hear me out. I, too, am from the >"school" where ready availability of sources was de rigeur, and I've had mixed >emotions on the SysV sources issue for quite some time. >One of the very reasons UNIX was NOT being as readily accepted in the "real" >world was due to all the hundreds of customized "hacks" and non-portable >features at each of 100's or 1000's of sites. If one used feature "foo()" >at site bar.edu, that feature was NOT guaranteed to be available or work >the same at site nematode.com. Umm. Thad. All those workstations that let AT&T know they had to incorporate BSD in SYSV or go out of the computer business weren't running SYSV, they were running BSD clones. And not because it was cheaper. You had to pay a BSD license on top of a SYSV license. The workstation manufacturers didn't pick BSD because it was impossible to find a standard release; they picked it because it worked better for their customers doing those customers' applications. BSD's open source policy meant that user developed software could be ported among platforms, which meant their customers saw a much more cost effective, leading edge capability combined hardware and software platform. The marketplace saw SYSV as junk, and the AT&T platforms running it did so poorly in the market, AT&T did massive layoffs for the first time in their history, to make up for the losses. >One reason that I see for AT&T's recent high source license fees was to >restrict random hacks to "responsible" port teams for platform-specific >features as required, and to assure that SVR4 would have the same "look and >feel" no matter what vendor's UNIX one chose to use. Gee, I just saw it as corporate greed, bureacratic stupidity, development incompetence, idea infertility, and hostility to their customer base. >As UNIX is becoming "essentially" a standard, it MUST conform to the other >vendors' ports. This follows the reasoning behind the Application Binary >Interface (the UNIX "shrink wrap software" compatibilty) formulated by very >seasoned and capable persons. Naturally, that's why there are two intensely hostile GUI groups -- to make sure all the platforms conform. That's why POSIX blessed the idiotic 14 character file name limit into the forseeable future. Trust me, nobody's doing anything out of sweetness and light. AT&T was watching their market share vanish, and read the handwriting on the wall. >Everything I've wanted in SysV is in SVR4, and it appears that everything >from 4.3BSD is in there too: file systems, networking, etc etc etc. I'm happy for you. Every time I've been stuck on a SYSV system, I felt like I was trying to work with my hands tied behind my back. >Kent continues: > 3) Tripos would have been out of AmigaDOS two years ago if the user > community had been allowed to participate in the process. Has Commodore > learned the BSD lesson yet? >So? Programs I've written which worked under pre-1.0 AmigaDOS are still >working under the latest OS. What's your point? That all the third party code is a god-awful mess of BPTR's, casts, and other idiocy, from trying to conform to Tripos, and that all that could have been gone long before the OS finally settled out if the free labor had been used. Where's the win in having software development retarded, and the number of commercial programs decreased, by forcing the developers to try to learn two ways of thinking at once? The added complexity of Tripos has probably cut the available software by 1/3 (wild ass guess). >And finally, he says: > > ... the utilities that make everyday BSD use the most productive > software development environment in existance? >Bushwa! As just ONE example of BSD's obsoletedness that recently caused me >MUCH grief, let's look at BSD curses vs. *ANY* SysV curses since SVR3. >Where's the BSD terminfo support, alternate character set, region scrolling, >line insert/delete, color support, etc etc etc? I don't do curses programming; pretty interfaces deserve graphics support, and _any_ curses is an inadequate hack. Nevertheless, BSD curses completely supports the applications I've seen use it. The methods may be different, but the results on the screen are the same. >And don't talk to me about X; OK, I won't, but in my field, if you can't do it, you're unemployed, as I am. >Kent, it appears to me you haven't studied any recent SysV system, Bingo! Could it be that's why I asked for a comparision to find out how much of BSD I'd be losing? Any gains are gravy. > and are just parroting the statements of others without having had the > opportunity to form your OWN opinions. My opinions of SYSV have been formed on SYSV, but not the newer releases. The ones I've worked on were just half a step above being a direct insult to the user. My opinions of open software systems to go along with open hardware systems are based on common sense and the success of those who won't take no for an answer and disassemble the code anyway, to find out just what vendor supplied bug is keeping them from writing the software miracle that will double hardware sales. BSD is so good that lots of software houses develop code for completely different machines under BSD just to have the great _programmers_ development environment available. I'm under no illusion that _any_ Unix system is friendly to the non-programming user. > This is not meant as an insult or an attack, just an observation based > on your comments. Taken in that spirit. >My only REAL gripe with pre-SVR4 systems has been the 14-character filename >limit ... that has been REALLY a hassle for me. But with SVR4 you just bring >up the BSD FFS and no sweat. I rest my case. ;-) Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
thad@cup.portal.com (Thad P Floryan) (12/04/90)
In <24221:Dec400:05:0790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan
Bernstein) writes some comments which I'll address in a moment. But first I
assert this is neither the TIME (too late) nor the PLACE (wrong newsgroup) for
OS wars (and how DID this thread get cross-posted to alt.religion.computers?)
so I'll be brief and hopefully succinct, and try to keep this interesting.
First a background summary to put the remainder of this post into perspective:
In October I discovered a severe deficiency with BSD curses compared to SysV's
curses, and I instigated much discussion in comp.sys.att, unix-pc.general,
comp.unix.questions, comp.unix.programmer, and comp.unix.aux in this regards.
I followed up ALL the leads, read ALL the docs, and discovered a lot. Among
the material I studied are included the sources of the latest 4.3BSD "Tahoe"
curses library, 4.3BSD termcap, the pertinent SVR3 books (SVR3.2 Programmer's
Reference Manual and SVR3.2 Programmer's Guide, Vol. II), the O'Reilly books
("termcap & terminfo" (Sept.1990 edition) and "Programming with curses"), and
a large number of other curses-related documents, and even email with Berny
Goodheart (root@tndsyd.oz.au (0000-Berny Goodheart(0000))) who's the author of
the JUST-published "UNIX CURSES EXPLAINED", Prentice-Hall, ISBN 0 13 931957 3.
I've checked the AT&T Toolchest, and was finally referred to Vaughn Vernon of
Aspen Scientific for a source license to their SVR3.2-compatible "curses" due
to the deficiencies of BSD curses. I even keep the BSD curses' source online
so I can check and verify comments I make in these regards:
CLI6> ls -l sys6b:*bsd4.3*
----ar-e- 90-10-08 04:08:30 90 45303 libcurses-bsd4.3.tar.Z
----ar-e- 90-10-08 04:11:49 223 112593 window-bsd4.3.tar.Z
Dirs:0 Files:2 Blocks:313 Bytes:157896
Now for Dan's response to my post:
>In article <36488@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes:
>> Bushwa! As just ONE example of BSD's obsoletedness that recently caused me
>> MUCH grief, let's look at BSD curses vs. *ANY* SysV curses since SVR3.
>> Where's the BSD terminfo support, alternate character set, region scrolling,
>> line insert/delete, color support, etc etc etc?
>
>Terminfo support? Where's System V's termcap support? Not an issue.
>
>BSD alternate character set: as, ae. Region scrolling: cr. Line insert:
>il. Line delete: dl. There's no color support, but there also aren't two
>color terminals in a thousand. And you can pretty much standardize the
>name for a new feature by calling up Berkeley and asking for it.
>
>> Kent, it appears to me you haven't studied any recent SysV system,
>
>I don't see any errors or implied errors in what Kent wrote. I see a
>nearly complete travesty of the truth in your only example of supposed
>BSD failings.
At first I was going to dismiss Dan's comments as just some more BSD-babble
parroting the BSD party line opinions and conveniently omitting any fact, BUT
I've seen this same kind of BSD-response sooo often I've been wondering "Why?"
for over 4 years.
To date, I have never seen any compelling facts that support the contention
"BSD is better than SysV". (Bear with me, see below)
And please limit any comments to the kernel, system libraries, and "devices";
EVERYTHING else is just a program(s) which can be ported to any system of
one's choosing as I did to put the BSD networking software on most my SysV
systems because I was unhappy with the stock WIN 3B/TCP stuff.
Regarding termcap, ALL the SysV-like ports to which I have access support BOTH
termcap and terminfo (and the corresponding libraries) for "compatibility"
reasons (this includes stuff from AT&T, HP, and others).
I stated the SysV 14-char filename limit has been a hassle, but SVR4 solves
that problem. Networking, sockets, BSD FFS, etc all exist in SVR4. What's
left that I'm not seeing? Dunno (at least from the application level).
Dan's comment: "And you can pretty much standardize the name for a new feature
by calling up Berkeley and asking for it." SHEESH! That's just the nature of
the PROBLEM with which I opened my original post! Government and business
clients will NOT tolerate eleventy-seven different "versions". AT&T's high
license fees are designed to prevent "random", non-standard hacks which create
a plethora of "proprietary" features at (only) some sites; the goal is to
have, from a business point of view, a stable platform upon which one can run
the $$$ software one buys, and ONLY with that stability will UNIX become more
accepted and widespread.
Dan's OWN examples belie his arguments, and illustrates the PROBLEM with BSD
(the random user hacks not generally found with SysV). To wit:
He states: "BSD alternate character set: as, ae. Region scrolling: cr. Line
insert: >il. Line delete: dl."
Maybe on *HIS* "BSD" system, but not on mine. For example: right out of the
4.3BSD curses' source code, in tty_cr.c, we find the pattern strings:
namp = "ambsdadbeohchzinmimsncnsosulxbxnxtxsxx";
namp = "albcbtcdceclcmcrcsdcdldmdoedeik0k1k2k3k4k5k6k7k8k9hoicimip\
kdkekhklkrkskullmandnlpcrcscsesfsosrtatetiucueupusvbvsveALDLUPDOLERI";
and from 4.3BSD's curses.h we find (supporting the above):
extern bool AM, BS, CA, DA, DB, EO, HC, HZ, IN, MI, MS, NC, NS, OS, UL,
XB, XN, XT, XS, XX;
extern char *AL, *BC, *BT, *CD, *CE, *CL, *CM, *CR, *CS, *DC, *DL,
*DM, *DO, *ED, *EI, *K0, *K1, *K2, *K3, *K4, *K5, *K6,
*K7, *K8, *K9, *HO, *IC, *IM, *IP, *KD, *KE, *KH, *KL,
*KR, *KS, *KU, *LL, *MA, *ND, *NL, *RC, *SC, *SE, *SF,
*SO, *SR, *TA, *TE, *TI, *UC, *UE, *UP, *US, *VB, *VS,
*VE, *AL_PARM, *DL_PARM, *UP_PARM, *DOWN_PARM,
*LEFT_PARM, *RIGHT_PARM;
And in the 4.3BSD docs we find:
alternate char set: not in 4.3BSD per the source code and per comments on
page 139 of the O'Reilly "termcap and terminfo"
region scrolling: "cs" to set the region line range, and "sf", "sr", "SF"
and "SR" to manipulate the region
line insert: "AL" (not Dan's "il" (not in the source))
line delete: "DL" and "dl" (which differ; not just Dan's "dl")
color: not in 4.3BSD
Point being (again): the 4.3BSD curses is seriously deficient when contrasted
to that available with SysV. Even AT&T conceded the realities of the "real
world" by supporting DEC's "vt100" mode and alternate character sets for SVR3
curses; due to sheer numbers of vt100-like terminals out there it's become a
de facto standard and cannot be ignored.
As for "There's no color support, but there also aren't two color terminals in
a thousand.", that's a suprising comment to make in a newsgroup where one can
read about many Amiga-hosted terminal emulators. :-)
In "my" world, clients do NOT have X-terminals but they will have monochrome
and color VT100-like, VT240, and other ASCII-graphic devices for which a
SVR3.2 curses is perfectly suited. These clients are the BigGuys who process
your checks, medical records, tax returns, military procurement, and &tc.
They're switching to UNIX for its networking, interconnectivity and other neat
features including stability and freedom from proprietary operating system
"gotchas" as new hardware is necessarily acquired.
I would NEVER denigrate the fine, taxpayer-supported R&D work done at UCB and
at many other places. The BSD networking HAS become the standard. But those
are application-level enhancements for the most part, and even AT&T had to
concede some of the neat goodies of BSD by putting them in SVR4, making them
part of the new standard. Those concessions DIDN'T imply that SysV was a
deficient unusable OS, and many of the BSD-isms and SysV-isms can co-exist on
the same system. I prefer ready availability of sources, but I also have to
look beyond the Ivory Tower to the Real World because that's where my clients
and I operate.
I'm getting long-winded again, but I'm hoping some of these discussions are
proving useful/interesting. At this point in time, with SVR4 "here", any
continued discussions of BSD vs. SysV are moot and should be dropped, but I
felt a documented response was necessary due to Dan's claiming my comments
were a "... complete travesty of the truth ...."
You be the judge. :-)
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]karl@ima.isc.com (Karl Heuer) (12/05/90)
In article <24221:Dec400:05:0790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <36488@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >> [BSD curses doesn't have all these features that are in SysV curses] > >BSD alternate character set: as, ae. Region scrolling: cr. Line insert: >il. Line delete: dl. Dan, are you really talking about the curses library, or the termcap library? In SysV, these features are available at the curses level. (I also happen to think curses was done poorly from the start, and about 3/4 of it should be removed, but that's another issue.) Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint (Followups to alt.religion.computers only.)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/05/90)
In article <36537@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: > Dan's comment: "And you can pretty much standardize the name for a new feature > by calling up Berkeley and asking for it." SHEESH! That's just the nature of > the PROBLEM with which I opened my original post! Government and business > clients will NOT tolerate eleventy-seven different "versions". I fail to see your logic. Why does the ability to easily standardize a feature make for problems? TELNET was originally a MIL-STD protocol, and it has lots of options. You can pretty much call up the IETF and ask for another option number. The government uses TELNET all the time. What's the problem? > alternate char set: not in 4.3BSD per the source code and per comments on > page 139 of the O'Reilly "termcap and terminfo" Perhaps Doug would know when and where as/ae were added. [ region scrolling is cs, line insert is AL, line delete is DL/dl ] Sorry for my typos. In any case, the features are there, and they are used. You stated that BSD doesn't support these features; you are wrong. > Point being (again): the 4.3BSD curses is seriously deficient when contrasted > to that available with SysV. What serious deficiency are you talking about? It is impossible for a program to use color or alternate character sets really well, since different terminals have different colors and different alternate characters. Other than that, everything you've claimed missing from BSD is there. > At this point in time, with SVR4 "here", any > continued discussions of BSD vs. SysV are moot and should be dropped, but I > felt a documented response was necessary due to Dan's claiming my comments > were a "... complete travesty of the truth ...." Okay, only a partial travesty of the truth. ---Dan
spike@world.std.com (Joe Ilacqua) (12/06/90)
In article <36537@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: <At this point in time, with SVR4 "here", any continued discussions of >BSD vs. SysV are moot and should be dropped, but I felt a documented <response was necessary due to Dan's claiming my comments were a "... >complete travesty of the truth ...." At this point with 4.4BSD on its way with many new and interesting features, I think the debate will go on. And given the facts that, (if all goes according to plan) 4.4BSD will be freely availble in source form, and that it runs on the 386, 4.4BSD may be the death of SYSV. ->Spike -- The World - Public Access Unix - +1 617-739-9753 24hrs {3,12,24,96,192}00bps
guy@auspex.auspex.com (Guy Harris) (12/09/90)
>2) _The_ thing that made BSD so much better than its AT&T parent that >AT&T finally had to bow to the inevitable (as the workstation market >"all" went BSD) and mutate SYSV4 into a BSD clone to be marketable, was >the ready availability of _almost free_, _full_ source code licences to >the user/programmer community, Well, BSD source licenses required AT&T source licenses, so the cost of a BSD source license >= the cost of an AT&T source license. Given that it required a "32V or better" license, those folks with 32V licenses only paid the price of a 32V license, rather than the price of an S5 license, but I don't think AT&T's sold 32V licenses for a while. *Commercial* sites didn't get licenses that I'd call "almost free", although university sites did. >so that the tremendous resource of free user community programming >effort could be brought to bear on improving BSD through several >extremely impressive upgrades while AT&T fell further and further >behind. I suspect it can be attributed more to the fact that, when VAXes started becoming UNIX platforms, the VAX UNIXes from AT&T were far elss functional - especially for big virtual-memory jobs (the reason why Berkeley put demand paging into BSD) - than the Berkeley versions. This "seeded" the VAX UNIX community with BSD - especially those members of the community more likely to develop software - so that the bulk of the user-community improvements were for BSD. This may have been somewhat of a self-sustaining process, helped along by the fact that, for much the same reason, those workstation vendors who adopted UNIX started with BSD. >Now that AT&T has wrested control of the future of Unix back from the >user community, are we going to see the same dreary game of >home-mortgage-sized source licence fees and vendor-only code >improvements retarding the future of Unix, Not all vendors *now* make all their improvements generally available. You can't say that's all AT&T's doing. >or has the lesson of open software systems finally been learned, so >that cost-of-media source code licenses and ready adoption/sharing >of user written OS improvements will keep the future of Unix bright? Perhaps, if 4.4BSD comes out and is mostly or completely AT&T-free, it will provide an alternative to AT&T UNIXes?
bzs@world.std.com (Barry Shein) (12/09/90)
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) >I don't see any errors or implied errors in what Kent wrote. I see a >nearly complete travesty of the truth in your only example of supposed >BSD failings. Hmm, I wonder if you've looked at SYSV curses as it's currently being distributed (e.g. with Sun/OS.) It's much better than the old V7 curses library. One major added feature is *input* support. I can write things like: switch(getch()) { case KEY_RIGHT: do_right_thing(); break; and all those KEY_RIGHT symbols are mapped properly (e.g. function keys). They turn them into 0400+code symbols so they're distinguished from ASCII. It works, they do it right. There's nothing resembling that in the older curses stuff, and I use this new feature a lot. They have a lot more than just cursor keys defined also, you can throw all sorts of handy codes into your switch statements (KEY_CLEAR, KEY_PAGEUP and so on), and add ASCII equivalents of course: case KEY_PAGEUP: case CTRL('U'): /* whatever */ Attributes (underscore, blinking etc) are also handled much better now. And, heavens, you can even write a program which reliably uses box-drawing characters and so forth. Look at the manual page (I'll send it to you if you like.) I think you'll quickly see it's impossible to support the view that SYSV curses is only trivially improved over BSD curses. -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/10/90)
In article <BZS.90Dec8172930@world.std.com> bzs@world.std.com (Barry Shein) writes: > Look at the manual page (I'll send it to you if you like.) I think > you'll quickly see it's impossible to support the view that SYSV > curses is only trivially improved over BSD curses. I didn't say that. System V curses/terminfo does indeed have lots more features than BSD curses/termcap. But that System V fanatic was accusing BSD of missing basic features which have been around for years. Somehow I don't really care about the infinite pile of frills in System V. ---Dan
thad@cup.portal.com (Thad P Floryan) (12/10/90)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) in <4271:Dec1003:29:5790@kramden.acf.nyu.edu> writes: In article <BZS.90Dec8172930@world.std.com> bzs@world.std.com (Barry Shein) writes: > Look at the manual page (I'll send it to you if you like.) I think > you'll quickly see it's impossible to support the view that SYSV > curses is only trivially improved over BSD curses. I didn't say that. System V curses/terminfo does indeed have lots more features than BSD curses/termcap. But that System V fanatic was accusing BSD of missing basic features which have been around for years. Somehow I don't really care about the infinite pile of frills in System V. Oh? How quickly some forget; sigh. I clearly stated there are some parts of BSD which are DEFICIENT (not "missing") when compared to SysV, and, as ONE example, cited the curses issue which recently caused me much grief. "System V Fanatic"? Gee, as previously posted, I even tested curses/termcap on my own BSD machine, and there are several more available to me. A true "SysV Fanatic" wouldn't have a BSD box in the same room as a SysV box. Personally, I consider myself more an Amiga-fanatic! :-) The point of my continued participation in this thread was to elicit some informed statements as to why some think BSD is so much greater than SysV. To date, none have surfaced. Not in this thread nor in the years I've been asking the same question elsewhere. The ONLY comments I'm getting from BSD-fanatics is "BSD is better!" without any supporting evidence. Consider Kent Paul Dolan's recent posting as just another example (my original comments preceded by "> "): You had to pay a BSD license on top of a SYSV license. [...] BSD's open source policy meant that user developed software could be ported among platforms, which meant their customers saw a much more cost effective, leading edge capability combined hardware and software platform. [...] > {Re: AT&T's license fees} Gee, I just saw it as corporate greed, bureacratic stupidity, development incompetence, idea infertility, and hostility to their customer base. [...] Every time I've been stuck on a SYSV system, I felt like I was trying to work with my hands tied behind my back. [...] > Kent, it appears to me you haven't studied any recent SysV system, Bingo! Could it be that's why I asked for a comparision to find out how much of BSD I'd be losing? Any gains are gravy. [...] My opinions of SYSV have been formed on SYSV, but not the newer releases. The ones I've worked on were just half a step above being a direct insult to the user. My opinions of open software systems to go along with open hardware systems are based on common sense and the success of those who won't take no for an answer and disassemble the code anyway, to find out just what vendor supplied bug is keeping them from writing the software miracle that will double hardware sales. BSD is so good that lots of software houses develop code for completely different machines under BSD just to have the great _programmers_ development environment available. [...] > My only REAL gripe with pre-SVR4 systems has been the 14-character > filename limit ... that has been REALLY a hassle for me. But with > SVR4 you just bring up the BSD FFS and no sweat. I rest my case. ;-) Opinions, opinions, opinions. BSD's "open sources"? Sure, if you already had the SysV source. Then comments about "hands tied" WRT SysV, and SysV being an "insult to user"; more opinions without examples. Then the "undefined" ``programmer development environment'' of BSD. And what might THAT be? If it's just a collection of progams and utilities, then that is NOT BSD-specific since such programs can be ported to or installed upon any system of one's choosing (as I previously stated, and have demonstrated to my satisfaction re: emacs, bison, HDB uucp, smail3.1.19, networking utils, etc.). The fact that such "programmer development environment" utilities may have been first developed on an BSD system is irrelevant. Back in the early '60s such programs were developed on SDS-930 and PDP-10 systems because, then, THOSE machines were readibly available to university students and researchers. You'd be surprised to learn how many good programs from back then I've since ported to TOPS-20 and again to the UNIX (and other) boxes I use today. And I was using ftp, telnet, network sockets, etc. LONG before BSD UNIX even existed, on the ARPAnet host systems such as Tenex, ITS, SAIL, &c back in 1970; that year is significant, because that's the "birth" year of UNIX at AT&T, 20 years ago. Those ARPA networking capabilities and protocols were ported to BSD UNIX from those other systems much later (but NO earlier than 1977 when 1.0BSD surfaced). Point is, you use what machine(s) are available at the time. The fact that a given program runs on machine A does not automatically make machine B an inferior, substandard system simply because a given program hasn't been ported to it. Again, when comparing SYSTEMS, one must restrict the discussion to the kernel and its intrinsic support libraries. Ancillary support programs can be ported to (practically) ANY system. I've been stating facts; most everyone else has been stating opinion and getting emotional about the issue. I suppose this is not the time nor place to discuss the superiority of SysV's ksh to BSD's csh, or .... :-) :-) Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
bzs@world.std.com (Barry Shein) (12/11/90)
>BSD's "open sources"? Sure, if you already had the SysV source.
Much of the BSD sources are right now sitting in UUNET's anon FTP
area, and the rest are heading there. So much for that. That includes
kernel source.
BSD was/is vastly superior to SYSV, at least pre-SYSVR4 which
basically cloned most of BSD so what's there to say? The fast file
system alone was enough to make you run the other way from systems
which lacked it. Not to mention SYSV's lack of any backup facility. A
stable file store is kind of important, at least to me.
--
-Barry Shein
Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLDcks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (12/12/90)
thad@cup.portal.com (Thad P Floryan) writes: | xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) | _The_ thing that made BSD so much better than its AT&T parent ... was | the ready availability of _almost free_, _full_ source code licences | to the user/programmer community, so that the tremendous resource of | free user community programming effort ... | | That's the VERY problem SVR4 prevents. Now hear me out. I, too, am | from the "school" where ready availability of sources was de rigeur, | and I've had mixed emotions on the SysV sources issue for quite some | time. | | One of the very reasons UNIX was NOT being as readily accepted in the "real" | world was due to all the hundreds of customized "hacks" and non-portable | features at each of 100's or 1000's of sites. If one used feature "foo()" | at site bar.edu, that feature was NOT guaranteed to be available or work | the same at site nematode.com. Despite what vendor propaganda would have you believe, the reason so many production sites want OS source code is not so that we can make custom hacks but so that we can fix bugs. No smart system admin counts on timely bugfixes from major vendors like SUN and DEC and SGI, not even for important or critical bugs. A secondary issue is to be able to adapt the system to important local requirements, such as a special 'nice' value for processes you want to run only when the system is utterly idle, mass creation of (student) accounts from canned data, a passwd command that refuses to let you use stupid passwords and lets instructors change student passwords, a new working SMD disk driver, or a rdump that understands using a remote account besides "root", or similar things (all these examples are real ones from around the University of Toronto). A tertiary issue is the ability to make disparate systems look and feel the same (by such methods as modifying SGI's stty to understand a number of BSDoid options -- things like this are surprisingly important to local users). We demand source because we've been burned too much by its lack, not because we have this desire to add custom hacks to our kernels or utilities. Believe me, we'd all like to run stock systems, straight off the vendor distribution tapes; it'd be significantly less work. But our users have this liking for working systems and prompt fixes for the bugs they find, neither of which the vendors we buy from have been particularly good in supplying. | One reason that I see for AT&T's recent high source license fees was to | restrict random hacks to "responsible" port teams for platform-specific | features as required, and to assure that SVR4 would have the same "look and | feel" no matter what vendor's UNIX one chose to use. Uh huh. I suppose "broken" and "nonfunctional" everywhere is one defenition of "consistent look and feel". It's just not a particularly useful one. [Needless to say, I do not speak officially for the University of Toronto as a whole or for UTCS.] -- "If the vendors started doing everything right, we would be out of a job. Let's hear it for OSI and X! With those babies in the wings, we can count on being employed until we drop, or get smart and switch to gardening, paper folding, or something." - C. Philip Wood cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
martin@cbmvax.commodore.com (Martin Hunt) (12/13/90)
In article <1990Dec11.164431.819@jarvis.csri.toronto.edu> cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) writes: >thad@cup.portal.com (Thad P Floryan) writes: >| xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) >| _The_ thing that made BSD so much better than its AT&T parent ... was >| the ready availability of _almost free_, _full_ source code licences >| to the user/programmer community, so that the tremendous resource of >| free user community programming effort ... >| >| That's the VERY problem SVR4 prevents. Now hear me out. I, too, am >| from the "school" where ready availability of sources was de rigeur, >| and I've had mixed emotions on the SysV sources issue for quite some >| time. >| >| One of the very reasons UNIX was NOT being as readily accepted in the "real" >| world was due to all the hundreds of customized "hacks" and non-portable >| features at each of 100's or 1000's of sites. If one used feature "foo()" >| at site bar.edu, that feature was NOT guaranteed to be available or work >| the same at site nematode.com. > > Despite what vendor propaganda would have you believe, the reason so >many production sites want OS source code is not so that we can make >custom hacks but so that we can fix bugs. No smart system admin counts >on timely bugfixes from major vendors like SUN and DEC and SGI, not >even for important or critical bugs. Generally, only large companies or universities have system administrators who are able to fix bugs in the Unix kernel. Does this mean that small and medium size companies cannot use Unix? Do Sun, DEC and SGI ship software with critical bugs and fail to fix them? Would you buy an OS that was so buggy that the sources were included so you could fix it yourself? No wonder the business world has been avoiding Unix. >A secondary issue is to be able >to adapt the system to important local requirements, such as a special >'nice' value for processes you want to run only when the system is >utterly idle, mass creation of (student) accounts from canned data, a >passwd command that refuses to let you use stupid passwords and lets >instructors change student passwords, a new working SMD disk driver, >or a rdump that understands using a remote account besides "root", or >similar things (all these examples are real ones from around the >University of Toronto). A tertiary issue is the ability to make >disparate systems look and feel the same (by such methods as modifying >SGI's stty to understand a number of BSDoid options -- things like >this are surprisingly important to local users). If you need OS source code to do this, then you bought the wrong OS. > > We demand source because we've been burned too much by its lack, not >because we have this desire to add custom hacks to our kernels or >utilities. Believe me, we'd all like to run stock systems, straight >off the vendor distribution tapes; it'd be significantly less work. >But our users have this liking for working systems and prompt fixes >for the bugs they find, neither of which the vendors we buy from have >been particularly good in supplying. > >| One reason that I see for AT&T's recent high source license fees was to >| restrict random hacks to "responsible" port teams for platform-specific >| features as required, and to assure that SVR4 would have the same "look and >| feel" no matter what vendor's UNIX one chose to use. > > Uh huh. I suppose "broken" and "nonfunctional" everywhere is one >defenition of "consistent look and feel". It's just not a particularly >useful one. Perhaps the problem is that Berkeley admitted that BSD was broken and AT&T refused to admit their Unix was broken? Whichever, distributing sources is a good thing in an academic environment, but a very bad idea if you are trying to capture the business market.
scott@mcs-server.gac.edu (Scott Hess) (12/13/90)
In article <16482@cbmvax.commodore.com> martin@cbmvax.commodore.com (Martin Hunt) writes: Generally, only large companies or universities have system administrators who are able to fix bugs in the Unix kernel. Does this mean that small and medium size companies cannot use Unix? No. But small and medium sized companies (and small and medium sized schools, for that matter) oftern have people who are perfectly capable of applying patches that someone elsewhere wrote. It's not like everyone across the country who owns Unix source must find their own method of fixing each and every bug . . . Do Sun, DEC and SGI ship software with critical bugs and fail to fix them? Would you buy an OS that was so buggy that the sources were included so you could fix it yourself? No wonder the business world has been avoiding Unix. Many of the bugs are not "critical", but are simply misfeatures. It's not critical that your stty work nicely, or that your getty automagically determines the line speed, it's just alot nicer. >A secondary issue is to be able >to adapt the system to important local requirements, such as a special >'nice' value for processes you want to run only when the system is >utterly idle, mass creation of (student) accounts from canned data, a >passwd command that refuses to let you use stupid passwords and lets >instructors change student passwords, a new working SMD disk driver, >or a rdump that understands using a remote account besides "root", or >similar things (all these examples are real ones from around the >University of Toronto). A tertiary issue is the ability to make >disparate systems look and feel the same (by such methods as modifying >SGI's stty to understand a number of BSDoid options -- things like >this are surprisingly important to local users). If you need OS source code to do this, then you bought the wrong OS. ??? I don't get it. Can you do this with VMS, or something? Out of the box? I've never heard of an OS which covered every single possibility of user-configurability without distributing source. >| One reason that I see for AT&T's recent high source license fees was to >| restrict random hacks to "responsible" port teams for platform-specific >| features as required, and to assure that SVR4 would have the same "look and >| feel" no matter what vendor's UNIX one chose to use. > > Uh huh. I suppose "broken" and "nonfunctional" everywhere is one >defenition of "consistent look and feel". It's just not a particularly >useful one. Perhaps the problem is that Berkeley admitted that BSD was broken and AT&T refused to admit their Unix was broken? Whichever, distributing sources is a good thing in an academic environment, but a very bad idea if you are trying to capture the business market. Why, can't businesses find a use? I'd think the opposite would be true - many businesses can afford to bring someone in to add features if they have to, even small ones. There is currently a consulting firm which will come in and get GNU stuff running on your machines, and add things you need, for a fee, of course. This is how it should work - rather than begging the company to come fix your stuff, you should be able to do it on your own. That cures many problems (for instance, if ATT is not all that interested in a version of vi with built-in robots and rogue.) I'm not really arguing that all software should have source included, or anything. Sure, that would be really nice, but I don't believe in it enough that I distribute my stuff with source (I gotta make a living, after all). But I can see many reasons why _I_ would want source to my Unix, not the least of them being the ability to find out what's really going on in there, rather than realying on a scanty, and probably buggy, manual to tell me . . . -- scott hess scott@gac.edu Independent NeXT Developer GAC Undergrad <I still speak for nobody> "Tried anarchy, once. Found it had too many constraints . . ." "Buy `Sweat 'n wit '2 Live Crew'`, a new weight loss program by Richard Simmons . . ."
bzs@world.std.com (Barry Shein) (12/13/90)
From: martin@cbmvax.commodore.com (Martin Hunt) >Whichever, distributing >sources is a good thing in an academic environment, but a very bad idea >if you are trying to capture the business market. Hey! Who let the MBA in? And I suppose you're next going to argue that auto manufacturers should put their own locks on car hoods to help capture the business markets? Look, all OS's have bugs. Many are tolerable. Most are tolerable by most people. But if you're the site that has to virtually shut down operations because of a security flaw which doesn't seem to bother that many other sites (e.g. if it's an internet break-in opportunity, most customers won't be on the internet) then you're in trouble w/o the sources. Beyond that kind of extreme situation there are many shades of gray. None of this is peculiar to Unix, everything I say could apply to VMS, AOS/VS etc. Systems with absolutely no security, like DOS or Macs (or Amigas I assume, but I don't know Amiga/OS), are obviously excluded from these examples. I don't know of any OS, for example, which gives much control over when someone can log in. Say you have operators with (some) privileges and would rather not have them logging in off-shift. Do you know any OS which lets you put that kind of logic in? (Oh, under most I can write scripts which disable accounts at various times, but I get to monkey around with some things which are fraught with peril.) (I assume someone will say "so ask them not to log in off-shift", a logic I agree with, but just an example.) So you tell the vendor, and the answer is "we don't have too many customers who want that (they always know exactly what their customers want, until someone comes in to auction off the furniture), so forget it". One compromise I've called for for years is that the sources to certain critical applications, such as login and password checking modules, should be supplied as source (certain pieces, like the encryption stuff, might not, just appear as library calls, but the mainline logic at any rate.) If I want to add code to demand longer passwords, or a secondary password if I think it's a really odd time (or place) for this particular person to be logging in, why should it be so difficult? What's the big deal? There probably aren't any big deal trade secrets in the login sources (in fact, I know Unix' login sources quite well, they're quite boring and predictable, which is good!) It's this binary mentality that either you get all the sources, or none that goads me. How about a few device driver sources? Some windows applications (admittedly some vendors do make these available, tho it's usually just the most trivial cases)? Is this sort of stuff really the family jewels? Not likely. Fortunately this situation is changing itself within the Unix community as almost everything you might want is available as a freely distributable source equivalent. I can't help but wonder where the motivation to write all those free-source clones comes from if there's really no need. -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/13/90)
cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) writes: >thad@cup.portal.com (Thad P Floryan) writes: >| xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) >| _The_ thing that made BSD so much better than its AT&T parent ... was >| the ready availability of _almost free_, _full_ source code licences >| to the user/programmer community, so that the tremendous resource of >| free user community programming effort ... >| >| That's the VERY problem SVR4 prevents. Now hear me out. I, too, am >| from the "school" where ready availability of sources was de rigeur, >| and I've had mixed emotions on the SysV sources issue for quite some >| time. >| >| One of the very reasons UNIX was NOT being as readily accepted in the "real" >| world was due to all the hundreds of customized "hacks" and non-portable >| features at each of 100's or 1000's of sites. If one used feature "foo()" >| at site bar.edu, that feature was NOT guaranteed to be available or work >| the same at site nematode.com. > Despite what vendor propaganda would have you believe, the reason so > many production sites want OS source code is not so that we can make > custom hacks but so that we can fix bugs. No smart system admin counts > on timely bugfixes from major vendors like SUN and DEC and SGI, not > even for important or critical bugs. A secondary issue is to be able > to adapt the system to important local requirements, such as [...] > (all these examples are real ones from around the University of > Toronto). A tertiary issue is the ability to make disparate systems > look and feel the same (by such methods as modifying SGI's stty to > understand a number of BSDoid options -- things like this are > surprisingly important to local users). > We demand source because we've been burned too much by its lack, not > because we have this desire to add custom hacks to our kernels or > utilities. A fourth "good" from having system source available is the _tremendous_ increase in programmer productivity it gives. When chasing down a bug, it is much faster to chase _my_ bug through the vendor's code to see just why it is a bug, than to chase _their_ bug all over my code, looking for something that just isn't there. In a day of source level debuggers, having _all_ the source is crucial. Having it priced out of reach is a devastating blow to code implementation. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/13/90)
martin@cbmvax.commodore.com (Martin Hunt) writes: >cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) writes: >> Despite what vendor propaganda would have you believe, the reason so >> many production sites want OS source code is not so that we can make >> custom hacks but so that we can fix bugs. No smart system admin >> counts on timely bugfixes from major vendors like SUN and DEC and >> SGI, not even for important or critical bugs. > Generally, only large companies or universities have system > administrators who are able to fix bugs in the Unix kernel. Does this > mean that small and medium size companies cannot use Unix? Do Sun, DEC > and SGI ship software with critical bugs and fail to fix them? Would > you buy an OS that was so buggy that the sources were included so you > could fix it yourself? No wonder the business world has been avoiding > Unix. Compared to what? In the micro world, MS-DOS has still got bugs in it from the first release. In the mainframe world, the most successful vendor, IBM, releases OSs so buggy it is standard practice for big businesses to "rent" _several_, full time (in some cases, 24 hours, 7 days a week) IBM systems analysts to be on-site to fix problems that would otherwise prevent them from conducting business. Compared to the general run of commercial OSs, Unix is a marvel of robustness and utility. Watch a Unix site bring itself back on line from a cold, dropped power shutdown, unattended, including fixing the corrupt file structures on its way up. Compare that to the one armed paperhanger mood bringing up a mainframe from a similar shutdown. I'm talking from person experience in all these cases. >> A secondary issue is to be able to adapt the system to important >> local requirements, such as a special 'nice' value for processes you >> want to run only when the system is utterly idle, mass creation of >> (student) accounts from canned data, a passwd command that refuses to >> let you use stupid passwords and lets instructors change student >> passwords, a new working SMD disk driver, or a rdump that understands >> using a remote account besides "root", or similar things (all these >> examples are real ones from around the University of Toronto). A >> tertiary issue is the ability to make disparate systems look and feel >> the same (by such methods as modifying SGI's stty to understand a >> number of BSDoid options -- things like this are surprisingly >> important to local users). > If you need OS source code to do this, then you bought the wrong OS. Nonsense. I've visited many vendors _making_ computers who do their own software development for their machines on a VAX under BSD. It isn't an accident that every OS that matters is either adopting Unixisms or being replaced by Unix. Take a look again at the principals in the two competing "standard" Unix efforts; no one of consequence is left out. Except for extremely special purposes, it won't be long before "the world's not Unix" will no longer be a fair putdown. > Perhaps the problem is that Berkeley admitted that BSD was broken and > AT&T refused to admit their Unix was broken? Whichever, distributing > sources is a good thing in an academic environment, but a very bad > idea if you are trying to capture the business market. Perhaps your experiment has been limited to talent-free businesses; the ones I've worked at had programmer staffs in the hundreds; one sold computers, one sold software, one sold ships. The one selling ships had the most programmers. Source code access is just too important to be hindered by the false image of people randomly hacking the kernel; that's not what happens in the real world. In the real world, user found patches go back to the vendor, where they are evaluated, added if sound, and distributed in the next release. No business is _forced_ to hack the source code it has available, or to run anything but a clean, vendor release OS. Every site that _does_ do kernel hacks also knows that the way to isolate problems with newly installed software is to go back to the clean release, and install patches one by one until the one causing the problem is isoleted. That's standard practice, well known, and completely removes the "hacked OS" bugaboo. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
martin@cbmvax.commodore.com (Martin Hunt) (12/13/90)
In article <BZS.90Dec12232338@world.std.com> bzs@world.std.com (Barry Shein) writes: > >From: martin@cbmvax.commodore.com (Martin Hunt) >>Whichever, distributing >>sources is a good thing in an academic environment, but a very bad idea >>if you are trying to capture the business market. > >Hey! Who let the MBA in? I'm insulted. (I'm not an MBA, but they do sometimes use computers). > >And I suppose you're next going to argue that auto manufacturers >should put their own locks on car hoods to help capture the business >markets? > >Look, all OS's have bugs. Many are tolerable. Most are tolerable by >most people. But if you're the site that has to virtually shut down >operations because of a security flaw which doesn't seem to bother >that many other sites (e.g. if it's an internet break-in opportunity, >most customers won't be on the internet) then you're in trouble w/o >the sources. > >Beyond that kind of extreme situation there are many shades of gray. > >None of this is peculiar to Unix, everything I say could apply to VMS, >AOS/VS etc. Systems with absolutely no security, like DOS or Macs (or >Amigas I assume, but I don't know Amiga/OS), are obviously excluded >from these examples. > >I don't know of any OS, for example, which gives much control over >when someone can log in. > >Say you have operators with (some) privileges and would rather not >have them logging in off-shift. Do you know any OS which lets you put >that kind of logic in? (Oh, under most I can write scripts which >disable accounts at various times, but I get to monkey around with >some things which are fraught with peril.) VMS has that and much more built into it. Some versions of so-called "Secure" Unix also offer features like this. >(I assume someone will say "so ask them not to log in off-shift", a >logic I agree with, but just an example.) I would agree in an engineering company or a university. If I was running the MIS department of a fortune 500 company, a bank, or a government contractor, I would strongly disagree with you. [...] >If I want to add code to demand longer passwords, or a secondary >password if I think it's a really odd time (or place) for this >particular person to be logging in, why should it be so difficult? > >What's the big deal? There probably aren't any big deal trade secrets >in the login sources (in fact, I know Unix' login sources quite well, >they're quite boring and predictable, which is good!) > >It's this binary mentality that either you get all the sources, or >none that goads me. > >How about a few device driver sources? Some windows applications >(admittedly some vendors do make these available, tho it's usually >just the most trivial cases)? Is this sort of stuff really the family >jewels? Not likely. I agree with you. Source code for this kind of stuff should be available to those who are interested. > >Fortunately this situation is changing itself within the Unix >community as almost everything you might want is available as a freely >distributable source equivalent. > >I can't help but wonder where the motivation to write all those >free-source clones comes from if there's really no need. >-- > -Barry Shein > I agree with you that source code is a really great thing for those of us who are capable of modifying it. In an academic or engineering environment, it is a necessity. What I really dislike is people who design operating systems so poorly that simple reconfigurations require modifying the sources and recompiling the kernel. OS kernels should be like color TVs; there are no user-servicable parts inside. VMS does this fairly well. Even AmigaDOS is way ahead of Unix in this. Operating systems (IMHO) should be simple, modular and expandable. In AmigaDOS, filesystems and networking protocols can be dynamically added or removed from the system. Why can't Unix do this? The other issue is the suitability of Unix to businesses. Why do most businesses with VAXen run VMS? It's very expensive and does not come with any source. Because it's easy to configure, is well supported and doesn't require a Unix kernel hacker to support it? Too many computer scientists and programmers write systems for their own world, instead of the real world. Reality is that if your product requires the user to have sources to configure his system or fix bugs, then you cannot expect to be taken seriously outside of the academic environment. Disclaimer: I don't work for the Unix group here, but I do deal with BSD sources every day. :^( Martin Hunt "Windows 3.0 is hot because it's really fun. It has martin@cbmvax.commodore.com brought some excitement back into the PC industry" Commodore-Amiga - Microsoft marketing manager I wonder who took the excitement out in the first place?
bzs@world.std.com (Barry Shein) (12/14/90)
From: martin@cbmvax.commodore.com (Martin Hunt) >I agree with you that source code is a really great thing for those of >us who are capable of modifying it. In an academic or engineering >environment, it is a necessity. What I really dislike is people who >design operating systems so poorly that simple reconfigurations >require modifying the sources and recompiling the kernel. OS kernels >should be like color TVs; there are no user-servicable parts inside. > >VMS does this fairly well... WHAT? How about those zillion OS tuning parameters in VMS? More importantly, how come Unix has been able to live w/o them all these years (just as another data point, so have IBM mainframe OS's.) No user serviceable parts...just answer a few simple questions about what you would like for page-cluster sizes and minimum/maximum resident and working sets and why the sea is boiling hot and whether pigs have wings. Oh, and let's let mere mortals muck with system logical names under VMS and see what you end up with... >Even AmigaDOS is way ahead of Unix in >this. Since you got the VMS example wrong it would be nice to know what you mean by this for those of us who don't use AmigaDOS. >Operating systems (IMHO) should be simple, modular and expandable. Right, and all together now, "except for the stuff I need..." >In AmigaDOS, filesystems and networking protocols can be dynamically >added or removed from the system. Why can't Unix do this? Sounds like a "user-serviceable part", make up your mind. Do you want tons of little tuning features or not? >The other issue is the suitability of Unix to businesses. Why do >most businesses with VAXen run VMS? Boy, you've narrowed the set quite a bit. Do most businesses have Vaxes? etc. Mostly because, until relatively recently, DEC refused to support VMS and Vaxes were a good hardware buy. How many businesses are buying Vaxes to run VMS anymore? I dunno, but judging by DEC's recent stock prices (~$50, down from a high of $175 three years ago), not an impressive number. And DEC just announced a $1B cost-trimming program. But I guess we should all follow their lead...? Meanwhile, Sun continues its 140% compounded annual growth, and they sell neither Vaxes nor VMS. Only Unix. (That's more significant than it might first appear, name another company over $1B that only sells Unix and the hardware to run Unix on. Now go thru companies that happen to sell Unix as a sideline [DEC, DG, Prime] and how they're doing financially, IBM is the only major exception I can think of, not sure how HP is doing OVERALL these days.) If we're really going to follow your logic we should all run out and buy 3090's to run MVS on, since that accounts for more bucks out there than a Vax can hold in its registers (I might be right on that, hmm, $4B/register, 16 registers, $64B, that's probably about the size of the MVS market...amusing.) >Because it's easy to configure, is well supported >and doesn't require a Unix kernel hacker to support it? Bosh. How many VMS shops don't have VMS hackers. Ever do a VMS OS upgrade and watch every third-party package bite the dust? I have. This is mythology, have you ever run a VMS shop? I have, it's a pain in the butt, give me Unix any day. -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
seanf@sco.COM (Sean Eric Fagan) (12/14/90)
In article <24221:Dec400:05:0790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Terminfo support? Where's System V's termcap support? Not an issue. kithrup 34$ type captoinfo captoinfo is /usr/bin/captoinfo There's termcap support. Not great, mind you (it's like saying the '386 runs C because you can get a C compiler), but it's there. >. There's no color support, but there also aren't two >color terminals in a thousand. You mean like color X terminals? Running under, say, Suns? Lots of people have color terminals, especially those running a variant of BSD. So why isn't there color support in termcap for it? -- -----------------+ Sean Eric Fagan | "*Never* knock on Death's door: ring the bell and seanf@sco.COM | run away! Death hates that!" uunet!sco!seanf | -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor") (408) 458-1422 | Any opinions expressed are my own, not my employers'.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/14/90)
In article <16499@cbmvax.commodore.com> martin@cbmvax.commodore.com (Martin Hunt) writes: > >I don't know of any OS, for example, which gives much control over > >when someone can log in. > VMS has that and much more built into it. Ah, yes, VMS. VMS, where the equivalent of ``make'' doesn't even come with the system. VMS, where you can buy an idle daemon for just $695 that UNIX users get for free off a source group. VMS, where DEC desperately tries to get its customers to install patches for security holes that are letting a virus run rampant through nearly every networked VMS machine in the world. VMS, where just one vendor has control, and will continue to set outrageous prices through next century. Now that's a cost-effective, secure operating system. > Why do > most businesses with VAXen run VMS? It's very expensive and does not > come with any source. Because it's easy to configure, is well supported > and doesn't require a Unix kernel hacker to support it? Oh, yeah, sure. Anyone who looks at the real statistics from DEC will observe that Ultrix and UNIX have slowly been eating away at the VMS market share. Even the most pessimistic projections show VMS with under half the VAX market by the year 2000. So why do you think this happens? Because VMS is so cost-effective and superior, right? ---Dan
rang@cs.wisc.edu (Anton Rang) (12/15/90)
In article <BZS.90Dec13145908@world.std.com> bzs@world.std.com (Barry Shein) writes: >From: martin@cbmvax.commodore.com (Martin Hunt) >>I agree with you that source code is a really great thing for those of >>us who are capable of modifying it. In an academic or engineering >>environment, it is a necessity. What I really dislike is people who >>design operating systems so poorly that simple reconfigurations >>require modifying the sources and recompiling the kernel. OS kernels >>should be like color TVs; there are no user-servicable parts inside. >> >>VMS does this fairly well... > >WHAT? I feel it does, having helped to manage a VMS system for several years, managed several UNIX systems, and written a number of system applications under both VMS and UNIX. (I also threw together a VMS device driver, but haven't done that under UNIX yet....) >How about those zillion OS tuning parameters in VMS? They're the knobs on the back of your TV set, I suppose. Sure, you can live without a tint knob, if the factory adjusted it more-or-less right. But sometimes you want to be able to change it. Hopefully, the default settings will be close to what you need; in operating systems, it really depends on your load. >More importantly, how come Unix has been able to live w/o them all >these years (just as another data point, so have IBM mainframe OS's.) Uhh, UNIX actually does have quite a few of them, they're just hidden in different places. Getting reasonable performance out of a Sun or DECstation without 16MB of memory requires poking around with desfree and the other memory management parameters. The param.c file (or your local equivalent) often requires tuning for your site (how many processes do you want? how much shared memory?). What's the difference? VMS has more, yes, but you can basically ignore them and usually still get reasonable performance, just as you can leave UNIX's desfree/lotsfree/... alone and get (usually) reasonable performance. The main difference I see here between VMS and BSD UNIX is that VMS has fewer parameters hardcoded (like the ones in the BSD process management code, commented with 'this is a magic number, you probably don't want to change it'). Lots of UNIXes have these tunable now, too. >Oh, and let's let mere mortals muck with system logical names under >VMS and see what you end up with... What does this have to do with the points above? I mean, presumably it does, but.... I wouldn't want to give 'mere mortals' write access to /vmunix's parameters on a BSD box, either. Seriously, and to try to avoid a *major* flame war (minor ones are fun and often informative), there are things about VMS's system design I'd like to see in UNIX. * System parameters should be documented and tunable. VMS gets this partly right--they document them, just often very obscurely, and they're usually tunable. I don't want to see a magic number in the code like "use a 10ms quantum because it works right on our PDP-11/07" which are likely to give less-than-optimal performance on a 30MHz 68030 machine. I think newer UNIXes are moving in this direction. * Device drivers should be easy to install into the system. AIX gets this right, according to hearsay at least. Being able to install them dynamically is good if availability is important. * At least some of the interfaces to kernel routines should be documented, so that local kernel changes are less likely to break when you do an upgrade. There are other things I'd like to see in both. * The ability to have a foreign file system installed easily. VMS can do this in theory (you write an ACP process to interpret the file system commands) but I've never seen anyone do one, and it would be a lot of work. The Apple //gs, Macintosh, and Amiga all have this. Does SVR4? (They support both SysV and BSD, at least.) I think that Mach is a good step in this direction (not just for file systems, but for VM etc. as well.) * A larger set of system management tools. 'ps' and 'ac' on the UNIX side don't do much for me. 'MONITOR' on the VMS side, and 'iostat/vmstat/pstat' on the UNIX side, let you see potential problems, but the fixes are often obscure. Performance tuning on both UNIX and VMS is a black art. Oh well. I'm curious about whether UNIX is evolving much any more, actually. VMS is changing incrementally (data file recovery is an optional product now, for instance, and access control lists are a relatively recent [ca. 1985?] addition). UNIX seems to be doing the same; neither one has many innovations in commercial versions, at least. Maybe that's not a bad thing. Or maybe it is. Anton +---------------------------+------------------+-------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | +---------------------------+------------------+-------------+
rang@cs.wisc.edu (Anton Rang) (12/15/90)
In article <29400:Dec1405:54:4990@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Ah, yes, VMS. <grin> Another not-perfect OS. (Hi Greg.) >VMS, where the equivalent of ``make'' doesn't even come with the system. True. It probably should, but hey, DEC's in business to make money, and right now they've decided that they can make more by forcing their users to buy it separately. This will change in the future the instant they decide that their profits will go up by including it as part of the base VMS package to attract customers. >VMS, where you can buy an idle daemon for just $695 that UNIX users get >for free off a source group. You can buy idle daemons for UNIX systems, too. There's at least 6 "watchdog" type programs on the DECUS tapes; there's a ton of public-domain VMS software around. You don't see it as much on USENET for the obvious reason that USENET is primarily UNIX machines. >VMS, where DEC desperately tries to get its customers to install patches >for security holes that are letting a virus run rampant through nearly >every networked VMS machine in the world. <blink> Excuse me? Which security hole would this be? There's a few around, but I haven't seen a serious one which has let in a virus of sorts, except for sites which leave open unprotected network accounts (kinda like leaving open a plain UUCP account). Overall, I'd say that most VMS systems are more secure than UNIX ones, but not necessarily because of the OS--because most sites running VMS care more about security. Besides, if you want to pick on VMS for a network security problem, you could at least mention that UNIX has had the sendmail and finger bugs fixed so that *that* virus can't get around. (And there are plenty of sites out there which haven't fixed it yet....) >VMS, where just one vendor has control, and will continue to set >outrageous prices through next century. True. >Now that's a cost-effective, secure operating system. It's got the potential to be more secure than most off-the-shelf UNIX versions today, I think. Why? Because it provides some tools (like access control lists and [optionally] file classification levels) that make it easier to give people limited privilege in a relatively safe way. That doesn't mean there aren't secure UNIXes out there (there certainly are). Cost-effective? It depends on what you need it for. If you need to use an application which runs only under VMS, it's infinitely more cost-effective than UNIX. If you want to develop software in C, UNIX is very likely more cost-effective. If you want to develop COBOL or Ada software, for instance, you have to start looking carefully at the different options the OSes and compilers give you. >> Why do >> most businesses with VAXen run VMS? It's very expensive and does not >> come with any source. Because it's easy to configure, is well supported >> and doesn't require a Unix kernel hacker to support it? It's considerably easier to configure and support than Unix is, at least all Unixes I've seen, though I've heard the new AIX version isn't bad for configurability (comments?). But I think the real reasons lots of businesses run VMS are (a) it existed before UNIX was widely available, and there's a lot of software they can't afford to port; and (b) it provides functionality that current VAX UNIX versions don't (volume shadowing and multiple volume sets, for instance). >So why do you think this [the UNIX/Ultrix incursion] happens? >Because VMS is so cost-effective and superior, right? Because VMS was at nearly 100% of the VAX market, and UNIX has its own set of attractions (portability not the least)? When you start out with 100% of market share, you don't really expect to stay there if somebody else (or you :-) start making a competitor.... Anton +---------------------------+------------------+-------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | +---------------------------+------------------+-------------+
martin@cbmvax.commodore.com (Martin Hunt) (12/15/90)
In article <29400:Dec1405:54:4990@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <16499@cbmvax.commodore.com> martin@cbmvax.commodore.com (Martin Hunt) writes: >> >I don't know of any OS, for example, which gives much control over >> >when someone can log in. >> VMS has that and much more built into it. > >Ah, yes, VMS. > >VMS, where the equivalent of ``make'' doesn't even come with the system. Not a big loss. You can get it PD. Remember, languages don't come with VMS either. Of course you can always get GNU C. >VMS, where you can buy an idle daemon for just $695 that UNIX users get >for free off a source group. You can also get one PD for VMS. Of course its not as neat as the $695 one. >VMS, where DEC desperately tries to get its customers to install patches >for security holes that are letting a virus run rampant through nearly >every networked VMS machine in the world. Yeah, right. There was a security hole in 4.7 that DEC distributed patches for. Of course it was nothing compared with the security holes in typical Unix implementations. >VMS, where just one vendor has control, and will continue to set >outrageous prices through next century. This is the first thing you've said I agree with. > >Now that's a cost-effective, secure operating system. > >> Why do >> most businesses with VAXen run VMS? It's very expensive and does not >> come with any source. Because it's easy to configure, is well supported >> and doesn't require a Unix kernel hacker to support it? > >Oh, yeah, sure. Anyone who looks at the real statistics from DEC will >observe that Ultrix and UNIX have slowly been eating away at the VMS >market share. Even the most pessimistic projections show VMS with under >half the VAX market by the year 2000. VMS still holds well over half the market. Of course, Unix will eventually win out as it becomes more of a standard. >So why do you think this happens? >Because VMS is so cost-effective and superior, right? Why do people use MS-DOS systems? I am not arguing for the continued existence of VMS. I was merely trying to refute the increasing common assumption "If Unix does it that way, that must be the best way to do it." VMS has many advantages over Unix. It also has many disadvantages. To say an operating system is inferior because you don't like DEC, its pricing, or because your favorite utility is not included, is narrow-minded. > >---Dan Martin Hunt Commodore-Amiga martin@cbmvax.commodore.com "Windows 3.0 is hot because it's really fun. It has brought some excitement back into the PC industry" - Microsoft I wonder who took the excitement out in the first place?
alfter@uns-helios.nevada.edu (SCOTT ALFTER) (12/17/90)
In article <RANG.90Dec14123755@nexus.cs.wisc.edu> rang@cs.wisc.edu (Anton Rang) writes: > * The ability to have a foreign file system installed easily. VMS > can do this in theory (you write an ACP process to interpret the > file system commands) but I've never seen anyone do one, and it > would be a lot of work. The Apple //gs, Macintosh, and Amiga all > have this. Does SVR4? (They support both SysV and BSD, at least.) > I think that Mach is a good step in this direction (not just for > file systems, but for VM etc. as well.) The IIGS does have this capability (file system translators, or FSTs), but it's presently severely underused (can you say "no ability to read Mac disks yet?"). FSTs are available for ProDOS (the Apple II's native file system), AppleShare (for file servers), and High Sierra (for CD-ROM), but that's it presently. I've heard the Amiga has something similar, but I'll leave the answer to somebody who knows what he's talking about WRT the Amiga. The Mac doesn't have this capability at all. Otherwise there would be no need for Apple File Exchange. With an HFS (the Mac's file system) FST installed in a IIGS, you could just pop a Mac disk in any drive and read and write info. The Mac can't do that; Apple File Exchange is a standalone program that translates stuff between HFS, ProDOS, and MeSsy-DOS. MultiFinder might make using it a bit easier, but if I have a text file on a ProDOS disk that I want to read into Microsoft Word, I'd have to run Apple File Exchange first. If the Mac had FSTs, you could read the file directly off the ProDOS disk into Word. Scott Alfter-----------------------------_/_---------------------------- / v \ Apple II: Internet: alfter@uns-helios.nevada.edu ( ( the power to be your best! GEnie: S.ALFTER \_^_/