Several System 5.2 questions
Tim Curry
Anyone outside of AT&T with a 3B2 system been upgraded to 5.2?
How many 3B2 systems are there outside AT&T?
I debated with myself whether to break this into several small postings
or one large one. I've opted for one large article. I hope that someone
with all the answers makes it through all the questions. Our software
development will require many different changes depending on what a real
System 5.2 looks like. My account executive is a friendly guy and attempts
to be helpful but just can't get me the kind of answers I need to make
programming decisions and purchase packages. I need to know what I will be
seeing if I can ever get upgraded to 5.2. I am hoping that the majority of
my bad reactions to system 5 vs. BSD are related to the fact that version 0.5
was a quick release to get the machines out the door and version 2 (2.1,2.2)
will be a complete version of UNIX.
1) What is the current release of System 5? I see some postings in this news
group with 5.2.2. Anyone answering subsequent questions please
indicate what version they are refering to.
2) termcap vs. terminfo vs. curses. Our software uses screen manipulations
throughout but system 5.0.5 doesn't have the -lcurses or -ltermcap
I have written my own code with our own termcap-like file but
would much prefer using the system standard. What will 5.2 have?
What is the difference between termcap and terminfo? Will both
stay around or is termcap likely to die. Does 4.3BSD stick with
termcap or move to terminfo? Do the curses routines work with both
termcap and terminfo? Are the curses routines compatable between
4.xBSD and S5? Does terminfo have graphic character information
to allow real boxes to be drawn vs. the box(stdwin,'|','-') type.
Does terminfo distinquish attribute modes by name rather than function.
i.e. "Reverse video" rather than "stand-out mode" which might be "half
intensity" for a different terminal.
3) nroff/troff and "man" command. I have none of these. I believe I heard
that troff might be unbundled to either the documentor's workbench
or writer's workbench but I would think that nroff and man should
be standard on each system. If nroff is available, then are neqn,
table, col etc. also available. If these aren't standard, what
package do I have to buy to get them?
4) is lp (line printer spooler) an optional package or standard? Our software
makes a distinction between a "display" to the terminal and a "report"
to hardcopy. We popen (pipe open) our output for the report to lp
but if this is not standard, then I'm not sure where to send it.
Is there a "printcap" file that describes the command sequences for
printers like in 4.2BSD?
5) virtual memory/record locking - I understand that 5.2 does finally
incorporate virtual memory but is that part of the requirements
for ALL versions of 5.2? e.g. When (or if) the XENIX version that
is 5.2 compatable on the IBM PC is implemented, will it support virtual
memory so that I can freely fork and execl etc. to my hearts content
without worring about a 256k system running out of memory and hence
having to try some overlay techniques or something?!? Likewise, will
all record locking calls be supported identically on all 5.2 compatable
versions?
6) is "make" standard? Does "make" still only come with the C compiler package?
When distributing software (even binarys only) "make" is the usual
way to do it. I suppose that shell scripts can be set up but still ...
7) What is the toolchest? I have been off of the net for 9 months and just
caught the tail end of disscussions about the toolchest when I started
reading USENET again. Where can I get details?
8) Is there an (MS|PC)-DOS C cross compiler available so that I can do my
compile work on the 3B2 and down-load the executable to a PC machine.
I would think that AT&T would have such a beast since the 6300 is
a DOS machine.
9) Does anybody know if I can buy a CSH for the 3B2 from any source? I
understand that the bourne shell under 5.2 has some job control
finally (could somebody tell me how this interface works? Is it
like the csh with ctl-z, fb, bg etc.?) and the shell functions are
probably more powerfull than aliasing in the csh but I desperately
miss the history, push/pop directorys, ~ expansion, and ctl-w word
delete. I use these things EVERY SESSION that I'm on a BSD system.
I simply don't understand why AT&T is hesitant to make the BSD software
available at least as an optional package. I'm 99% sure that they use
a lot of BSD software themselves!! I'd like a lot of programs that
I miss. Since Berkeley is not trying to make a profit from BSD and
the BSD enhancements make a considerably nicer user interface, why
aren't these things available? Furthermore, I know there is a package
that gives System 5.2 support under 4.2BSD but why not the reverse
from AT&T? This would allow the best of both worlds to be available.
10) what is available? Perhaps the last statement was over harsh. Where can
I get a list of what software is available from AT&T and its cost?
The one price I got for the Documentor's Workbench was a Source price.
Are binary prices available for the unbundled protions of UNIX?
11) What does it take to get a software package sanctioned by AT&T for
System 5.2?
Tim Curry
USENET: decvax!ucf-cs!tim
ARPANET: tim.ucf-cs@csnet-relay
--
Tim Curry
USENET: decvax!ucf-cs!tim
ARPANET: tim.ucf-cs@csnet-relay
Ron Heiby
quickly. Some questions related to BSD features which I am not qualified
to address.
In article <20...@ucf-cs.UUCP> t...@ucf-cs.UUCP (Tim Curry) writes:
>1) What is the current release of System 5?
The currently available version for the 3B2/300 is:
UNIX System V Release 2.0 3B2 Version 2
AT&T has announced a paging release for the 3B2 which
will be available shortly and be (I believe) Release 2.1.
>2) termcap vs. terminfo vs. curses.
"You sure ask a lot of questions." Anyway, SVR2 has libcurses.a and uses
the terminfo database. /etc/termcap is still delivered for software that has
not been recompiled to use terminfo. Termcap is not likely to die completely
as long as there are many systems that do not yet have terminfo. Although,
new development should use terminfo, as it is technically superior. Termcap
is one big file with all the terminal descriptions. Terminfo is a hierarchy
of files, where each file describes one terminal, hence it's more efficient.
Whether termcap or terminfo is used depends on the library code with which
the application was linked. Most of the other questions can be answered
by the terminfo manual.
>3) nroff/troff and "man" command.
The nroff and troff commands (and I think man) are in the Documenter's
Workbench, which is a seperately priced package. Man files for all of
the section 1-n stuff is not supplied, as AT&T feels that a machine of
the class of a 3B2 does not generally have enough free disk space to devote
to that kind of material and the information can be had from the paper copy,
anyway. Documenter's Workbench comes with tbl, eqn, neqn, col, etc.
>4) is lp (line printer spooler) an optional package or standard? Our software
> makes a distinction between a "display" to the terminal and a "report"
> to hardcopy. We popen (pipe open) our output for the report to lp
> but if this is not standard, then I'm not sure where to send it.
> Is there a "printcap" file that describes the command sequences for
> printers like in 4.2BSD?
The LP Spooler package is a seperately priced package. The command to
queue something for printing is named "lp" and is found in /usr/bin. There
is no "printcap" that I know of. Each printer has an interface file (which
is generally a shell script) which handles set-up for each print job.
>5) virtual memory/record locking
"All" versions of UNIX have supported "virtual memory" (with exceptions like
the iAPX-86 architecture, which doesn't do memory management). What is new
is "Demand Paging" rather than "Swapping". System V with demand paging is
currently available for the DEC VAX and AT&T 3B20 systems and has been
announced for the 3B2 and 3B15, although it is not yet available there. It
is extremely unlikely that any implementation of UNIX for AT&T PC 6300
machines (or compatibles) would include demand paging, as there is no hardware
support for it in the iAPX-86 architecture. Those systems would continue to
be swap based. AT&T has committed to supporting the /usr/group standard for
file and record locking across its product line. The currently available
3B2 release supports the "Advisory" locking, which is what most applications
really want. The paging release on the 3B2 supports the "Mandatory" locking,
as well.
>6) is "make" standard?
I assume that you mean "bundled". No, I believe that "make" comes in the
"Extended Software Generation" package.
>7) What is the toolchest?
The AT&T Software Toolchest is a system which provides electronic distribution
of purchased software. Source code is licensed for a fee and delivered via
uucp. The license is not for a single machine, but for every machine in
(at least location, probably organization, can't remember). Binary resale
licenses are available with no per-sale royalty. See your AT&T Account
Executive for more information.
>8) Is there an (MS|PC)-DOS C cross compiler available
I know of now MS-DOS C cross compiler being sold. Sounds good though.
>9) Does anybody know if I can buy a CSH for the 3B2 from any source?
I know of no source for CSH. System V Release 2.0 introduced "Shell Layers",
which many Berkelyites sneer at, but which I find to be quite useful. It
is a facility for having multiple logical terminal sessions multiplexed over
the same connection. See the User Manual for more info [shl(1)]. Regarding
the csh capabilities that you want, you should look into the Korn Shell (ksh)
which is available through the Toolchest. I use nothing else. My guess
about csh not being available from AT&T is that it is rather a botch, changing
quite a few things just for the sake of changing them and is thus quite
incompatible with Bourne. Korn, being 99 and 44/100 % upward compatible with
Bourne does not have this problem. As to any other BSD developments: They
are all known of and looked at by AT&T developers. Some appear in System V,
like "cat -v" and "ls -RadCxmnlogrtyucpFbqisf" and "mailx" (alias Mail). The
thing to remember is that Berkeley is (supposed to be) in the education
business. They do a good job by letting students experiment. AT&T is in the
stable computing environment business. We do a good job by making darn sure
that what we do doesn't break something (like a shell script or worse) and
that we spend our efforts spending resources on the most important/needed
enhancements first.
>10) what is available?
See your AT&T Account Executive. Binary packages are available for the
3B2. Prices are in the price book.
>11) What does it take to get a software package sanctioned by AT&T for
> System 5.2?
By "sanctioned", do you mean in the catalog, AT&T co-labling, or what?
For any of that, you need to talk with the AT&T Independent Software
Vendor program people. Your AT&T Account Executive should be able to
find the right contact.
Have fun.
--
Ron Heiby he...@cuae2.UUCP (via ihnp4)
AT&T-IS, /app/eng, Lisle, IL (312) 810-6109
Guy Harris
I believe it depends on what machine you're on. It's S5R2V2 for the VAX.
> 2) termcap vs. terminfo vs. curses. What will 5.2 have?
The VAX 5.2 has the "curses"/"terminfo" package.
> What is the difference between termcap and terminfo?
"terminfo" has a lot more per-terminal capabilities (i.e., control strings,
characteristics, etc.) than "termcap". The database is in a "compiled"
format for faster loading.
> Will both stay around or is termcap likely to die.
There's no technical reason for "termcap" to stick around, other than the
cost of conversion. There is a "termcap"-emulator package in the "curses"
library, so programs written for "termcap" should work (unless they do
something *really* weird), and there is a monster "ex" script that does a
lot of the work of converting "termcap" descriptions to "terminfo"
descriptions. However, "terminfo" requires an S5R2 license, so...
> Does 4.3BSD stick with termcap or move to terminfo?
I don't think they move to "terminfo", unless Pavel Curtis' public-domain
"curses" supports "terminfo" and they picked that up.
> Do the curses routines work with both termcap and terminfo?
The 4.2BSD curses could probably work with "terminfo" using the "termcap"
emulator (but it may do "something really weird", so it may not). The S5R2
"curses" uses a lot of the added capabilities of "terminfo" so it won't work
with "termcap".
> Are the curses routines compatable between 4.xBSD and S5?
Pretty much. I've recompiled a number of "curses"-using programs written
for "old curses" with "new curses" and they work. A number of 4.2BSD
programs already have hooks in them for "new curses" (like "mille" and, I
think, "sysline").
> Does terminfo have graphic character information to allow real boxes
> to be drawn vs. the box(stdwin,'|','-') type.
Not to my knowledge. Solving that problem in general is difficult if not
impossible. Not all terminals have line-drawing characters, and even those
that do don't have compatible characters in the same position in the
alternate character set.
> Does terminfo distinquish attribute modes by name rather than function.
> i.e. "Reverse video" rather than "stand-out mode" which might be "half
> intensity" for a different terminal.
"terminfo" has "enter_standout_mode" and "exit_standout_mode" capabilities
(which are, presumably, terminal-dependent in what they actually do, just as
in "termcap); it also has "enter_blink_mode", "enter_bold_mode",
"enter_dim_mode", etc. capabilities and their equivalent "exit"
capabilities. It also has a "set_attributes" capability which directly sets
video attributes. This capability is, in effect, the ANSI X3.64 Set Graphic
Rendition sequence (the "terminfo" capabilities mirror X3.64 control
sequences to a large degree).
> 3) nroff/troff and "man" command. I have none of these. I believe I heard
> that troff might be unbundled to either the documentor's workbench
> or writer's workbench...
They are unbundled in S5R2 distributions (i.e., you don't get *roff with an
S5R2 tape). I don't know how AT&T bundles it in binary distributions for
the 3Bs.
> 5) virtual memory/record locking - I understand that 5.2 does finally
> incorporate virtual memory but is that part of the requirements
> for ALL versions of 5.2?
S5R2 Version 2 (for the VAX) has virtual memory, but S5R2 Version 1 doesn't.
It is definitely NOT a requirement for all version of S5R2; what if you port
to a machine which can't support virtual memory?
> When (or if) the XENIX version that is 5.2 compatable on the IBM PC is
> implemented, will it support virtual memory...
Not bloody likely; the 808[68] can't support virtual memory (you can't trap
on a missing segment) and the 80286 can't support paged virtual memory, so
you won't see it on a non-AT PC and I don't think it's in the 80286
microport so you may not see it on an AT either.
> Likewise, will all record locking calls be supported identically on all
> 5.2 compatable versions?
Again, S5R2V2 on the VAX has the record locking calls, but S5R2V1 doesn't.
Any S5 based on the releases which have record locking will have compatible
versions.
> 9) Does anybody know if I can buy a CSH for the 3B2 from any source? I
> understand that the bourne shell under 5.2 has some job control
> finally (could somebody tell me how this interface works? Is it
> like the csh with ctl-z, fb, bg etc.?)
S5R2 doesn't have job control. It has "shell layers" which is basically a
window system except for the stuff that actually manages the screen; i.e.,
everything except the part that actually makes windows useful. You have N
(~7, I think) "layers" managed by a "window" manager called "shl". Each
layer has a pseudo-tty (or its moral equivalent) as its controlling TTY.
One layer is connected to your keyboard; whatever you type goes into its
pseudo-tty. All layers are connected to your screen/printhead, although you
can set "loblk" which is like "tostop" in that any attempt by a process
whose layer isn't the "current" layer causes the process to block. You type
^Z and the TTY switches to the layer manager's pseudo-tty; you then type
commands at the layer manager to switch the TTY to other layers.
The TTY's tty driver modes are the modes of whatever the "current" layer's
process has set them to, so if you switch from a layer in cooked mode to a
layer in character-at-a-time mode the modes switch automatically. However,
NO indication is given to a process that the TTY is being taken away from it
or given to it, so it can't clear the screen, or move the cursor to a
reasonable place, or take the terminal (as opposed to the TTY driver) out of
what funny mode it's put the terminal into (i.e., setting the keypad of a
VT100 to transmit numbers or escape sequences, putting a VT100 with a
graphics board into Tektronix 4014 or VT100 mode, etc.).
It's also not job control in that you can't stop a process and restart it
later; you can only take the terminal away from it and give it back later.
> but I desperately miss the history,
If you can get the Korn shell (AT&T permits a sublicensor to offer the Korn
shell in binary form with a system; they should take themselves up on that
offer and provide it with 3Bs), you can get history and ~ expansion. Also,
if you have source you can snarf the history mechanism for the S5R2 Bourne
shell that Arnold Robbins posted to net.sources; I've been using it and it's
very nice.
> push/pop directorys,
I think you can do this with shell functions - I think such a function was
posted by Robbins along with his other stuff.
> ~ expansion,
THe Korn shell and Robbins' changes to the Bourne shell have this.
(Unfortunately, I haven't been using it because it has to read the password
file itself - trying to use something that does "malloc"s inside the Bourne
shell is a headache, due to the way the Bourne shell manages its memory -
and on a Sun workstation running 2.0 or later most of the password file is
probably *not* on your machine but on a server so reading the password file
yourself doesn't help. Sigh...)
> and ctl-w word delete.
That's not a C shell feature, it's a tty driver feature. Having added it
(along with all the other Berkeley extensions) to the S5R2 driver I can
testify that it could be in S5R2. Unfortunately, it isn't.
Enough complains about this kind of stuff and AT&T might put it in - after
all, it worked with the Coca-Cola company...
Guy Harris
Inventor of micro-S
>System V with demand paging is
>currently available for the DEC VAX and AT&T 3B20 systems and has been
>announced for the 3B2 and 3B15, although it is not yet available there.
-----------------------------------------
Samuel A. Figueroa, Dept. of CS, Univ. of KY, Lexington, KY 40506-0027
ARPA: ukma!sambo<@ANL-MCS>, or sambo%ukma...@anl-mcs.arpa,
or even anlams!ukma!sa...@ucbvax.arpa
UUCP: {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!sambo,
or cbosgd!ukma!sambo
"Micro-S is great, if only people would start using it."
John Gilmore
AT&T distribute [possibly optional] Berkeley enhancements, I hear they
use them in house anyway" with:
> As to any other BSD developments: They
> are all known of and looked at by AT&T developers. Some appear in System V,
> like "cat -v" and "ls -RadCxmnlogrtyucpFbqisf" and "mailx" (alias Mail). The
> thing to remember is that Berkeley is (supposed to be) in the education
> business. They do a good job by letting students experiment. AT&T is in the
> stable computing environment business. We do a good job by making darn sure
> that what we do doesn't break something (like a shell script or worse) and
> that we spend our efforts spending resources on the most important/needed
> enhancements first.
By implication that puts all commercial vendors of 4.2BSD systems
in the "unstable computing environment business"?
Rich A. Hammond
> in the "unstable computing environment business"?
Judging by how often we find bugs and our machines crash, I'd say yes,
runnning 4.2 BSD is being in an unstable computing environment.
Ron Heiby
>By implication that puts all commercial vendors of 4.2BSD systems
>in the "unstable computing environment business"?
There there, John. I was talking about the University of CA at Berkeley.
I was not talking about any commercial vendors. I have no knowledge of
Sun's quality control, although I have heard good reports from users
of Sun systems. BTW, in my previous job, I used a commercial port of
System III to a M68000 based system. The quality on that product was
marginal. So, I know enough not to be talking about quality of commercial
products based only on their porting base (although I have my favorite).
My remarks dealt only with the orientation of the organization that puts
out System V versus the organization that puts out BSD. Both are available.
It is up to the organization that purchases either to understand the
pros and cons involved. I'm sorry my remarks could have been mis-interpreted.
Dave Stewart
>> that what we do doesn't break something (like a shell script or worse) and
>> that we spend our efforts spending resources on the most important/needed
>> enhancements first.
>
>By implication that puts all commercial vendors of 4.2BSD systems
>in the "unstable computing environment business"?
There are also plenty of examples where AT&T adds a BSD feature,
but changes the command or system call name or syntax. Isn't that
referred to as the NIH (Not Invented Here) syndrome? When will AT&T
(and DEC for that matter) realize that UC Berkeley is NOT a competitor?
Stepping down from his soapbox ...
--
David C. Stewart uucp: tektronix!davest
Small Systems Support Group csnet: davest@TEKTRONIX
Tektronix, Inc. phone: (503) 627-5418
Ron Heiby
>>announced for the 3B2 and 3B15, although it is not yet available there.
> What is a ^^^^ ?
I don't have the product blurb in front of me at the moment, but it is basically
a very high performance 3B5. As I recall, it is based on the WE 32100 instead
of the WE 32000, has MAU support, high performance disk, and supports demand
paging. It was announced a few weeks ago.
Guy Harris
John didn't say "by implication that says 4.2BSD is an unstable computing
environment", he said "by implication that puts all *commercial* vendors of
4.2BSD systems in the 'unstable computing environment business'." My
machine is supplied by a "commercial vendor of 4.2BSD systems" (as is
John's, I suspect :-) :-) :-)), and, well,
4:00pm up 5 days, 2:33, 6 users, load average: 0.23, 0.07, 0.00
It's been up longer. The only times it's crashed due to an OS bug are a few
times when some pre-release software hung and it had to be rebooted (that
problem hasn't recurred, and it wasn't the 4.2BSD base's fault) and once
when it crashed due to some code I'd added (which, for the benefit of those
of you who sneer at "lint", would have been reported by "lint"ing the
kernel).
I've rarely found bugs, and most of them have been pretty small. (Several
pieces of code from the System V release would have crashed on this machine,
because they dereference null pointers, so the Berkeley people aren't the
only people who ship buggy UNIX software.)
Then again, the "stability" being discussed here is not resistance to
crashes but the absence of system changes that break existing code. Yes,
4.2BSD has introduced some changes which break existing code. So has System
V. (Remember the time they decided to enforce the "only one external
definition" rule? The old COMMON-block semantics came back faster than Old
Coke...)
Guy Harris
x0705
> >System V with demand paging is
> >currently available for the DEC VAX and AT&T 3B20 systems and has been
> >announced for the 3B2 and 3B15, although it is not yet available there.
> What is a ^^^^ ?
with the floating point chip. It's 2-3 times as fast as the 3B5 CPU,
and about 35% faster than the 3B2/400 CPU (which runs at 10 or 11 MHz)
--
Bill Stewart, AT&T Bell Labs, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
Doug Gwyn <gwyn>
> but changes the command or system call name or syntax. Isn't that
> referred to as the NIH (Not Invented Here) syndrome? When will AT&T
> (and DEC for that matter) realize that UC Berkeley is NOT a competitor?
There may be some "NIH" syndrome at work, but you should also appreciate
that BSD software is not necessarily up to commercial standards, so it
might need some adaptation before being supported by a commercial outfit.
Unfortunately, AT&T has been picking up some of the WORST features from
BSD. cat -v, ls -[a-z][A-Z], yuck.
Doug Gwyn <gwyn>
AT&T just announced this. It appears to be basically a 3B5 with
the new 32100 chip set, including floating-point.
I have also heard that there is a new 3B C compiler that generates
much faster code for both hardware and software implementations of
floating-point. Let's hope so..
Jim Gettys
>...................................................... My
>machine is supplied by a "commercial vendor of 4.2BSD systems" (as is
>John's, I suspect :-) :-) :-)), and, well,
>
> 4:00pm up 5 days, 2:33, 6 users, load average: 0.23, 0.07, 0.00
>
>It's been up longer. The only times it's crashed due to an OS bug are a few
>times when some pre-release software hung and it had to be rebooted (that
>problem hasn't recurred, and it wasn't the 4.2BSD base's fault) and once
>when it crashed due to some code I'd added (which, for the benefit of those
>of you who sneer at "lint", would have been reported by "lint"ing the
I have seen an amusing bug in ruptime on our machines here (running a
"not commercially supported" version of 4.2).
mit-zeus up ??+17:42, 0 users, load 0.01, 0.03, 0.03
This occurs if a machine has been up more than 99 days......
Several other machines on that local net had been up over 80 days, so
it was not a fluke. Unfortunately, we had a power failure at 111 days.
Sigh.... I suppose we should all get up on our high horses and swear
at Berkeley for "buggy" software, but I for one am willing to forgive
them for this particular bug.
Jim Gettys
Project Athena
Barry Shein
>Subject: Re: instability in Berkeley versus AT&T releases
Ok Doug, it's fighting time. If by 'commercial standards' you mean
bug-free, I don't see where 4.2 has any corner on the bug market. For
example, you should see how many core-dumps per minute I get from sdb on
my 3B5 (the only debugger, no adb or dbx, this was under R1, maybe it
got better under R2, but maybe some bugs are out under 4.3, no?) It
won't even start about 25% of the time, just dies (yes, that's vanilla C
programs, trust me, its buggy as heck.)
And 3BNet...? C'mon, that's not a feature, that's a bug. How much does
dumb, incompatible, NIH design count? I mean, correct me if I'm wrong,
but doesn't networking have something to do with speaking to other
machines? I fought DECNET here, everyone fought SNA and now this? Ok,
they're gonna pick up TCP/IP cause now they got a $1Billion contract
from NSA, I'm glad, but I'm not impressed by the decision-making process.
As far as I can tell, you've got to have the sources to enable FLEXNAMES
(I do and am.) Unfortunately, I am still trying to re-build comp because
a source file is just missing. I understand the arguments to keep ids
down (and they're good arguments, I agree) but that's a funny compromise.
And things that are just plain missing that are mostly taken for granted
these days, like pty's (re: 4.2, VMS, tops-20)?? (forget sxts.)
And which file system is up to commercial standards? I think I have a
lot more faith in 4.2 than the SYSV 4.1 clone (how come 4.2 sites don't
even have an 'fsdb' [file sys debug], not because they never thought of
it, they really don't need it.)
And the back-up programs, what a joke, a complete and utter joke
compared to dump/restore on 4.2 (or is file system backup and retrieval
just not important to 'commercial' sites.) Follow the suggested backup
procedures in the administrators manual, now try to recover a lost file
(not file system, just one file.) Ooops, gotta know the inode number...
Oh yeah, what about file system quotas? Completely missing in SYSV
(except for the filesize limit, better than nothing I guess.) Or, again,
is avoiding filled file systems just not something of interest to
'commercial' environments. The administrator's manual suggests running
a job several times a day to check user's usage (I guess that's if you
still have room on the disk to run the program.)
And unbundling everything useful is a real strong point (hey, don't
worry about nroff bugs, you don't get nroff! bugs fixed.) Again, maybe I
read this wrong, maybe what I don't understand about commercial sites is
that they're too stupid to take something for free when they can pay
extra for the same thing. Along the same lines, should I tell my users
to use all the nifty graphics packages? Or as soon as they get them
debugged are they gonna unbundle them? Should I project my budget to
reflect paying unbundled prices for every piece of software on the
system that my users will end up screaming for? If unbundled nroff is
here, can 'cat' be far behind? How about the accounting package, backup
software, editors, mail system, make, sccs, games (what games?),
shl, help, terminfo, cpio, debuggers (what debuggers?), C, f77....
I think price predictability is of some importance to a commercial market.
Yeah, I know, how are they gonna make a living (poor AT&T.) On the other
hand, as I said when DEC handed me the same line about VMS utilities
(which are obscenely unbundled), ok, make a living off me not buying the
whole system then, if that's your plan. I believe I have pretty much
killed the idea of VMS workstations on this campus for that reason. Now
what am I gonna have to say about a 3B2 to remain consistent?
A -v arg to cat so it doesn't screw your terminal and a -C arg to ls so
you have a chance to to actually see more than 20 files, I can
understand your objections, but don't you think my list is a *little*
more important....honestly? (maybe that's what you meant.)
Ok, I *do* have a lot of faith in AT&T, I actually think as fast as you
are playing apologist they are filling in the gaps, I have heard very
solid rumours of a joint effort between AT&T and a 4.2 developer to just
finish the gap between the two once and for all. R2 was a huge
improvement over R1, I am very optimistic, and following SYSV right into
the whole 'phone system as network' technology coming up from AT&T
should be very exciting (not that 4.4BSD won't also have this :-)
They shouldn't be afraid to write 'unsupported' or 'not yet supported'
on a man page, it's a lot better than living without a feature for most
of us (probably not on a dump utility, but how about a csh or other
handy redundancies.)
Don't misunderstand me, I'll take SYSV over anything on the market...
except 4.2.
Hey, maybe B.U. just isn't a commercial site and doesn't understand?
But we have 2 3081s, a 4341, 19 vaxes, a 2060, 3B5, 3B2s etc etc,
a lot of the strategy recomendations come out of this office...do we
count too? How much of it is UNIX? not enough.
I think you asked for this. I also think too much of this appeared to be
pointed at you, this is actually a much broader shot.
-Barry Shein, Boston University
P.S. I may have made some small technical errors in my examples, we've
only had SYSV here a few months and R2 a couple of weeks (maybe you
*can* get a file off a backup tape by name, I couldn't see how.)
Let's try to stick to the big issues.
P.P.S. Hopefully, those at ATT who feel attacked will take this all as
constructive criticism and remember that *I* am the customer (and a
relatively happy one.)
P.P.P.S (this is getting obnoxious) Maybe it's time to form a good
ATTUS (analagous to DECUS.)
hi doug, you're the only one who got this far.
Jim Hutchison
>I was not talking about any commercial vendors. I have no knowledge of
>Sun's quality control, although I have heard good reports from users
>of Sun systems. BTW, in my previous job, I used a commercial port of
>System III to a M68000 based system. The quality on that product was
>marginal. So, I know enough not to be talking about quality of commercial
>products based only on their porting base (although I have my favorite).
Sir, BSD's spring from the loins of version 7. System V is of system III,
hint think death star. :-)
--
/*
Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch
ARPA: hutch@sdcsvax
[ Of course, these statements were typed into my terminal while I was away. ]
*/
Brad Davis
crashes the operating system with a
panic error: out of swap space
main()
{
while (malloc(1024)) ;
}
Don't have any problem with our BSD 4.2 1/2 Vax though.
(HP says it will be fixed in the next release that we
don't have yet.)
--
Brad Davis
{ihnp4, decvax, seismo}!utah-cs!b-davis
b-d...@utah-cs.ARPA
Doug Gwyn <gwyn>
> >> but changes the command or system call name or syntax. Isn't that
> >> referred to as the NIH (Not Invented Here) syndrome? When will AT&T
> >> (and DEC for that matter) realize that UC Berkeley is NOT a competitor?
> >
> >There may be some "NIH" syndrome at work, but you should also appreciate
> >that BSD software is not necessarily up to commercial standards, so it
> >might need some adaptation before being supported by a commercial outfit.
>
Hey, Barry, all I was saying is that it isn't a crime for AT&T to change
some aspects of the code that they borrow from 4BSD when they integrate
it into their product. I agree that there have been some very stupid
decisions made in the UNIX System V packaging as well as some good ones.
I am glad that they're making an effort to organize the UNIX package.
I agree that there is no real networking (by Internet standards) in the
AT&T product yet. TCP/IP is long overdue, but it is certainly not the
ideal. AT&T has promised full ISO protocols implemented with streams,
and have demonstrated a prototype full-semantics (unlike NFS) transparent
remote filesystem which is expected to appear in their product "soon".
I don't have 3Bs, so I don't know why you're having problems with the SGS.
Our DMD SGS works fine. I thought flexnames were a standard feature now.
Ptys should appear along with stream I/O, where they can be done right.
The 4.2BSD "fast file system" is unnecessarily complex; AT&T is rumored
to have a simple implementation of a fast file system. I don't know
whether it fragments big blocks. It is funny that you take AT&T to task
for providing "fsdb" and fault them for not providing other things..
4.2BSD backup and restore is certainly an improvement over old tools.
To their credit, AT&T has been improving many of the system administration
procedures. Perhaps they will pick up on this one.
The right way to implement file system quotas is subject to debate. I
have been burned by the 4.2BSD scheme, which has some real lossages..
Unbundling is a sore point. Seems that what is really needed is a way
for VARs/OEMs to sell packaged systems for minimal licensing fees, while
end-users get a "rich" set of utilities in their basic package, in order
to ensure that they have what is needed to support add-on software.
I think the main problem is that AT&TIS sees themselves in the "iron"
(computer hardware) business, not the information business. I hope they
can see that UNIX is much more than just a 3B operating system. I note
that they're dropping the VAX from future releases; is DEC going to fill
in for them or are they going to keep Ultrix a 4BSD look-alike (or both)?
The PWB/Graphics and Plot facilities are scheduled to be replaced by
something else, probably based on GKS. Specs have not yet been published.
I don't have any real stake in "playing apologist" for AT&T. I too have
chastised them publicly for their mistakes. I do think, however, that
there are better performance metrics than the degree to which they lift
pieces of 4BSD unmodified.
I hope the rumors of convergence between 4.nBSD and System V are true;
otherwise, 4BSD's days are numbered. I've been doing my bit to help
bring about such a merger, which does not necessarily mean that there
would not continue to be two distinct systems for the different target
user populations (research vs. commercial). The biggest roadblock to
4.nBSD migrating in a System V direction seems to have been the silly
policy that AT&T now has of not permitting exchange of UNIX-derived
software among source UNIX licensees who have different CPU types.
I agree fully with AT&T's position that there should not be two flavors
of standard shell. It looks like the Korn shell may filter into the
AT&T product (other than as a ToolChest add-on); if so, there would be
little reason to ask for a Cshell. Ksh is very nice, is Bourne shell
compatible, and does everything the Cshell can do.
An AT&T UNIX user's group that could exert pressure for wanted goodies
might be a good idea. The existing UNIX groups do not seem to fulfill
this role.
> hi doug, you're the only one who got this far.
Hi, Barry! Let's hope the AT&T UNIX policy makers are listening, too.
p.davidson
The 3B5 vs 3B15
3B5 3B15
Max Ports 128 128
Typical # users 16-48 16-60
CPU
MIPS 1.0 1.4
Word Size 32 32
Memory
RAM 16MB 16MB
Cache 8KB 8KB
Max Disk Storage 2.7 GB 2.7 GB
See the big difference is in MIPS
Henry Spencer
was worse. Which even some long-live-Berklix independents openly admit.
If you caught Clem Cole's discussion of software distribution at Masscomp
in the panel discussion at Usenix, you may have noted that he said there
was often a quandary about which version of a utility to pick: the one
from AT&T usually has more bugs fixed, while the one from Berkeley often
runs faster.
> And which file system is up to commercial standards? I think I have a
> lot more faith in 4.2 than the SYSV 4.1 clone (how come 4.2 sites don't
> even have an 'fsdb' [file sys debug], not because they never thought of
> it, they really don't need it.)
fsdb dates back to the days when *no* Unix filesystem was reliable, and
the automatic repair algorithms in fsck didn't exist. Its existence in
SysV is more likely to be a relic of the past than a real reflection of
need, since even the V7 file system essentially never needed patching
given fsck. (I speak as the sys admin of a V7 site, by the way.)
> Oh yeah, what about file system quotas? Completely missing in SYSV
> ... Or, again,
> is avoiding filled file systems just not something of interest to
> 'commercial' environments...
The lack of file system quotas probably reflects AT&T's openly-expressed
view (which I agree with) that except in special situations, if you think
you need disk quotas then you really need more disks instead. Situations
involving hostile users, e.g. undergrads, are obviously an exception --
note that this was the original motive for the 4.2 implementation of
quotas -- but how many businesses have that problem?
> And unbundling everything useful is a real strong point...
As many people have pointed out, unbundling (a) is a botch, and (b) is
necessary if you are selling Unix boxes with small disks. Not everybody
has Eagles to put it all on. Whether AT&T's unbundling strategy is
rational, even given this excuse, is another question... but it is not
totally without reason.
> ... maybe what I don't understand about commercial sites is
> that they're too stupid to take something for free when they can pay
> extra for the same thing...
Pray tell, how can a binary-only licensee (most commercial sites do not
have source, remember) get these things for free? I know quite a few
binary-only sites that would love to know.
> A -v arg to cat so it doesn't screw your terminal and a -C arg to ls so
> you have a chance to to actually see more than 20 files, I can
> understand your objections, but don't you think my list is a *little*
> more important....honestly?
Since I think both cat -v and ls -C are botches, I agree.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Tom Faulhaber
> > > By implication that puts all commercial vendors of 4.2BSD systems
> > > in the "unstable computing environment business"?
> John's, I suspect :-) :-) :-)), and, well,
>
> 4:00pm up 5 days, 2:33, 6 users, load average: 0.23, 0.07, 0.00
>
I am afraid that this is the point that proves the argument. We have
an Ethernet composed of Convergent MiniFrames (the parent of the PC 7300)
in Un*x engineering at CT. A few days ago an ruptime display would have
shown you that the Networking development machine (mine) and the OS development
machine had been up for 45 days. These machines had rebooted after PG&E
decided to run over one of the power lines to our building. Unfortunately last
week they ran over the power lines again! I would note that the OS
development machine was running the latest CTIX version, and the networking
machine was running an experimental kernel.
I say this only partially to brag about our systems. Primarily, I would like
point out that five or even fifteen days of uptime does not make a solid
operating system.
Tom Faulhaber
...decwrl!greipa!tommif!tom
P.S. Of course, we run System V.
Westerman
>
>P.P.P.S (this is getting obnoxious) Maybe it's time to form a good
>ATTUS (analagous to DECUS.)
>
Yes, let's form ATTUS. As I see it, AT&T is our only hope to get UNIX
out of being a much talked about OS into being a much used OS.
Whom: Rick Westerman Phone: +1-317-494-8344
UUCP: {decvax, ihnp4, seismo, ucbvax}!pur-ee!westerm
USPS: Ag Data Network, Purdue University, West Lafayette IN 47907
A proud owner of a 3b2, but a *user* of 4.2 ---> "4.2 > V"
Peter da Silva
Judging by how much stuff Bell broke when they came out with SV, and judging by
the fact that BSD is still sufficiently compatible that you can run a
V6 binary on it (2BSD, but 2 is source compatible with 4), even if it
uses stty, I'd say it's Bell that's in the unstable computing environment
business.
System III.
System V, consider it standard.
System V, release 2, from now on consider it standard.
System V, release 2, Version 2?
--
-- Peter da Silva (the mad Australian)
-- UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter
-- ARPA: baylor...@RICE.ARPA
-- MCI: PDASILVA; CIS: 70216,1076; DELPHI: PJDASILVA
--
Larry Campbell
> view (which I agree with) that except in special situations, if you think
> you need disk quotas then you really need more disks instead. Situations
> involving hostile users, e.g. undergrads, are obviously an exception --
> note that this was the original motive for the 4.2 implementation of
> quotas -- but how many businesses have that problem?
Hostile users aren't the only good reason to have quotas. What about
buggy software that gets into an infinite loop writing to a file?
It's pretty annoying that such a bug can essentially crash (i.e., make
useless) a timesharing system.
> As many people have pointed out, unbundling (a) is a botch, and (b) is
> necessary if you are selling Unix boxes with small disks. Not everybody
> has Eagles to put it all on...
I thought unbundling was done mainly to reduce the entry-level price
of a Unix license. After all, you could always ship everything and let
the user decide which pieces to devote disk space to. (And I agree --
unbundling is a botch.)
> --
> Henry Spencer @ U of Toronto Zoology
> {allegra,ihnp4,linus,decvax}!utzoo!henry
Larry Campbell decvax!genrad
The Boston Software Works, Inc. \
120 Fulton St. seismo!harvard!wjh12!maynard!campbell
Boston MA 02109 / /
ihnp4 cbosgd
ARPA: decvax!genrad!wjh12!maynard!camp...@DECWRL.ARPA
Doug Gwyn <gwyn>
UNIX 3.0
> System V, consider it standard.
UNIX 5.0 (4.0 was not released for public licensing)
> System V, release 2, from now on consider it standard.
UNIX 6.0, until AT&T decided to establish "UNIX System V" as
a recognized symbol. Now UNIX 5.2
> System V, release 2, Version 2?
This has been a remarkably upward-compatible evolutionary path.
5.2.2 added demand paging (much cleaner than 4BSD's) and
record locking (more general than either 4BSD or /usr/group)
without visibly changing the semantics of already-existing
facilities. This is the way it should be.
Both 4BSD and UNIX System V have good and bad points and both
have unnecessarily broken things in new releases. The main
advantage of System V (notice that "UNIX" is omitted here)
with regard to stability is that all significant commercial
UNIX and C standardization efforts are adhering closely to it
(and vice-versa).
Could we go on to more productive topics?
Henry Spencer
> I haven't used V5 much...
I'd be suprised if you had, since V5 means "Version 5", which was a Bell
Labs (not USG) Unix around 1974. If you mean "System V", please say it
that way -- they are not the same thing.
"Calling System V `V5'?!? Them's fightin' words, bub!"
Guy Harris
> hint think death star. :-)
Umm, err, V7 also came out of the death star, although it came from a
different place therein. S3 came from a slightly pre-V7 release (*much
much* closer to V7 than to V6).
Then again, you can't hold AT&T (from whose code *all* the aforementioned
UNIXes ultimately derives) responsible for what other people do to it when
bringing it up on their machines, so his S3 problems may have had nothing to
do with S3 as it came out of AT&T.
Guy Harris
Guy Harris
> >
> > (etc.)
>
> I am afraid that this is the point that proves the argument.
Bull. Absence of evidence is not evidence of absence. If you mean that the
"uptime" listing there proves that 4.2BSD systems can't stay up more than 5
days, it's time to take a course in reasoning. All it proves is that "sun"
(a machine which has had its share of hardware problems) had been up for 5
days at the time I type "uptime" at it. The last time I bounced my own
machine, it was because it hung when I tried to exit the window system -
this could have been the fault of the window system (not 4.2BSD code), the
shell I'm running (an S5R2 Bourne shell with *lots* of hacks thrown into
it), or a number of other programs whose problems you couldn't blame on
Berkeley.
> Primarily, I would like point out that five or even fifteen days of uptime
> does not make a solid operating system.
OK. Now I'll point out that frequent crashes/reboots does not make a flaky
operating system (I suspect hardware problems cause most of the trouble
around here).
> P.S. Of course, we run System V.
With, I believe, 4.1BSD memory management code (unless you've dropped the
S5R2V2 code in) and possibly 4.2BSD (or 4.1aBSD or 4.1cBSD) networking code
(the use of "ruptime" in your message gives a possible hint). As such, the
fact that CTIX stayed up on one particular machine for 45 days doesn't say
much about the reliability of System V vs. 4.xBSD.
Guy Harris
> from AT&T usually has more bugs fixed, while the one from Berkeley often
> runs faster.
Which means, if the utility is important enough that it's worth the work,
the best strategy might be to "diff" the suckers and take the best from both
and put it into one version. (There is one utility where the one from AT&T
runs faster, and the one from Berkeley has more bugs fixed - "awk". The
S5R2 "awk" is quite a bit faster than all previous "awk"s, including the
4.2BSD one - one change is that it no longer uses structure-valued arguments
and functions - but it still has null-pointer-dereferencing bugs. We beat
those out of the 4.2BSD one...) (Then again, there are those utilities
where the only difference is the formatting of the code, or the presence,
absence, or shape of an SCCS ID - yes, there *are* utilities that haven't
changed since V7, as I know you're aware, but some people might be shocked
to hear that, especially the people who don't think AT&T had anything to do
with Berkeley UNIX...)
> The lack of file system quotas probably reflects AT&T's openly-expressed
> view (which I agree with) that except in special situations, if you think
> you need disk quotas then you really need more disks instead.
Maybe yes, maybe no. I think Parkinson's Law applies to disk space as well;
give users more disk space and they'll find some way to fill it, even if
they just fill it with "net.politics" archives.
Think of it as an economic
problem; you have a scarce resource, but the price mechanism has a long
time-scale over which it works - possibly too long to prevent short-term
space shortages. Quotas can keep users from eating the disks until you can
buy new ones, or until their managers get the bill for their disk space and
say "delete something or else". I'd be curious to know how many commercial
VMS sites, say, use the VMS disk quota mechanism? We've started to use disk
quotas here; we frequently have space problems. We had them at CCI as well.
CCI's customers also had them; our office automation systems were often sold
to people who weren't necessarily experienced system administrators, and who
may not really think about the fact that every big document they keep around
represents a document that some other user can't keep around. Again, there
are administrative techniques that can control disk usage over the long
term, but quotas can help deal with shortages in the short term.
> As many people have pointed out, unbundling (a) is a botch, and (b) is
> necessary if you are selling Unix boxes with small disks. Not everybody
> has Eagles to put it all on. Whether AT&T's unbundling strategy is
> rational, even given this excuse, is another question... but it is not
> totally without reason.
There's a difference between unbundling and charging separately; you can
provide a basic utility set and additional utilities as a single package, or
you can sell the additional utilities as add-ons. I believe it is the
latter policy that people object to. This policy is not a solution to the
technical problem of not having enough disk space to store all UNIX
utilities; it is a solution to the economic problem of paying for the
development and maintenance of software without charging people who have no
use for that software.
Guy Harris
Cheryl Stewart
Is there a place where the differences between sysV and 4.2 are
documented? (please don't tell me "sure, diff the sources of both!" I'm
no sorcerer.)
ihnp4!oddjob!cs1
--
Guy Harris
> judging by the fact that BSD is still sufficiently compatible that you
> can run a V6 binary on it (2BSD, but 2 is source compatible with 4),
"V6 binary"? What have you been smoking? For one thing, 2BSD is V7, not V6
(I think 1BSD was the V6 Berkeley distribution), but, more importantly, you
*can't* run V6 binaries on V7. You don't even have a good chance of
compiling *source* written for V6 on a V7 system and having it run.
And there are programs written for V7 that will break when you try to
compile them and run them under 4.2BSD...
> even if it uses stty, I'd say it's Bell that's in the unstable computing
> environment business.
If you're referring to the S3 terminal driver, from Bell's standpoint they
didn't break anything. It's compatible with UNIX 2.0 (or PWB/UNIX 2.0 or
whatever the hell the release before UNIX 3.0 was). The trouble is that the
release that went out the door before System III was V7, not UNIX 2.0, which
means the S3 driver's backward compatibility with UNIX 2.0 is totally
useless to anybody outside the former Bell System.
Guy Harris
Guy Harris
> > I haven't used V5 much...
>
> I'd be suprised if you had, since V5 means "Version 5", which was a Bell
> Labs (not USG) Unix around 1974. If you mean "System V", please say it
> that way -- they are not the same thing.
Furthermore, the index/strchr difference is probably not an example of NIH
in the way the original poster thought. *Both* routines are products of
AT&T - the routine was called "index" in V7 and "strchr" in System III. At
what point it was renamed, I dunno. The S3 documentation comes with a
description of changes between S3 and some unspecified earlier version of
UNIX. One of the changes was that "strcpyn" was renamed "strncpy". This
predates V7, since it was called "strncpy" there as well.
Guy Harris
Roy Smith
> Henry Spencer @ U of Toronto Zoology
Why is "cat -v" a botch? If you want to see if you have junk in a
file it's a lot nicer than "od -c". And what's so terrible about "ls -C"?
The multi-column format is much nicer, and it turns out that most of the
time it does the right thing (i.e. picks 1-column vs. multi-column mode).
Oh, BTW, for you net.micro.att readers, note that I've added a
Followup-To: net.unix-wizards line.
--
Roy Smith <allegra!phri!roy>
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
j...@im4u.uucp
and ditroff (after extracting it with sh). I make no claims as to its
accuracy or completeness.
(By the way, I've added "Followup-To: net.unix" to the header lines.)
: This is a shar archive. Extract with sh, not csh.
echo x - history.pic
sed -e 's/^X//' > history.pic << '!RoNnIe!RaYgUn!'
X.\" pic -Pip history.pic | ditroff -Pip
X.ps -2
X.PS
Xsmallb = 0.5i
Xmedb = 0.75i
Xbigb = 1i
Xbiggerb = 1.5i
Xboxwid = smallb
Xboxht = smallb / 2
Xmovewid = 0.5i
X
Xspacing=0.5i
Xsysv=spacing
Xmert=sysv + spacing
Xpwb=mert + spacing
Xcbunix= pwb + spacing
Xresearch=cbunix + spacing
Xv32=research + spacing
Xbsd4=research + (2 * spacing)
Xbsd2=bsd4 + spacing
X
Xboxwid = medb
XD69: box invis "1969"
XD73: box invis "1973"
Xboxwid = smallb
XD76: box invis "1976"; move
XD77: box invis "1977"; move
XD78: box invis "1978"; move
XD79: box invis "1979"; move
XD80: box invis "1980"; move
XD81: box invis "1981"; move
XD82: box invis "1982"; move
XD83: box invis "1983"; move
XD84: box invis "1984"; move
XD85: box invis "1985"
XLabel: box invis at D69
X
Xboxwid = smallb
XV1: box invis "V1" at D69 + (0, research)
XV5: box invis "V5" at D73 + (0, research)
XV6: box invis "V6" at D76 + (0, research)
Xboxwid = bigb
XV7: box "Version 7" at D78 + (0, research)
Xarrow from V1.e to V5.w
Xarrow from V5.e to V6.w
Xarrow from V6.e to V7.w
X
Xboxwid = smallb
XV32: box invis "32V" at 1/4 <D78, D79> + (0, v32)
Xboxwid = bigb
XV8: box "Version 8" at D83 + (0, v32)
Xarrow from V7.n to V32.s
Xarrow from V32.e to V8.w
Xarrow right from V8.e
X
X"\fIBell Research\fP" ljust at Label + (0, research + (v32 - research) / 2)
X
Xboxwid = smallb
XPWB: box invis "PWB" at 1/2 <V6, V7> + (0, pwb - research)
Xarrow from V6.s to PWB.nw
XU30: box invis "3.0" at 1/2 <D79, D80> + (0, pwb)
Xarrow from V32.se to 4/5 <PWB, U30>
Xarrow from V7.sw to 1/2 <PWB, U30>
XU40: box invis "4.0.1" at D81 + (0, pwb)
XU301: box invis "3.0.1" at 1/2 <U30, U40>
XU50: box invis "5.0" at D82 + (0, pwb)
XU52: box invis "5.2" at D83 + (0, pwb)
XU524: box invis "5.2.4" at D84 + (0, pwb)
Xarrow from PWB.e to U30.w
Xarrow from U30.e to U301.w
Xarrow from U301.e to U40.w
Xarrow from U40.e to U50.w
Xarrow from U50.e to U52.w
Xarrow from U52.e to U524.w
Xarrow right from U524.e
X
Xboxwid = bigb
XCBUNIX: box invis "CB UNIX" at PWB + (0, cbunix - pwb)
Xarrow from 1/4 <V6, V7> to CBUNIX.n
Xspline -> from CBUNIX.e to U301 + (0, cbunix - pwb) then to 1/2 <U301, U40>
X
X"\fIBell Columbus\fP" ljust at Label + (0, cbunix)
X
Xboxwid = medb
XMERT: box invis "MERT" at PWB + (0, mert - pwb)
Xboxwid = bigb
XUNIXRT: box invis "UNIX/RT" at D78 + (0, mert)
Xarrow from V6.s to MERT.nw
Xarrow from MERT.e to UNIXRT.w
Xarrow from UNIXRT.ne to 3/4 <PWB, U30>
X
Xboxwid = bigb
XSysIII: box "System III" at D82 + (0, sysv)
XSysV: box invis "System V" at D83 + (0, sysv)
Xoldht = boxht
Xboxht = oldht * 2
XSysV2: box "System V" "Release 2" at D84 + (0, sysv)
Xboxht = oldht * 3
XSysV24: box dotted "System V" "Release 2" "Version 4" at D85 + (0, sysv)
Xboxht = oldht
Xarrow from U301.se to SysIII.n
Xarrow from U50.se to SysV.n
Xarrow from U52.se to SysV2.n
Xarrow from U524.se to SysV24.n
X
X"\fIUSG / USDL\fP" ljust at Label + (0, sysv + (pwb - sysv)/2)
X
Xboxwid = smallb
XBSD3: box invis "3BSD" at 1/2 <D78, D79> + (0, bsd4)
Xarrow from V32.n to BSD3.s
Xboxwid = medb
XBSD40: box invis "4.0BSD" at 1/2 <D79, D80> + (0, bsd4)
XBSD41: box "4.1BSD" at 1/2 <D80, D81> + (0, bsd4)
XBSD42: box "4.2BSD" at 1/2 <D83, D84> + (0, bsd4)
XBSD41A: box invis "\s-14.1aBSD\s0" at 1/3 <BSD41, BSD42>
XBSD41C: box invis "\s-14.1cBSD\s0" at 2/3 <BSD41, BSD42>
XBSD43: box dotted "4.3BSD" at 1/2 <D84, D85> + (0, bsd4)
Xarrow from BSD3.e to BSD40.w
Xarrow from BSD40.e to BSD41.w
Xarrow from BSD41.e to BSD41A.w
Xarrow from BSD41A.e to BSD41C.w
Xarrow from BSD41C.e to BSD42.w
Xarrow from BSD42.e to BSD43.w
Xarrow right from BSD43.e
X
Xarrow from 1/5 <V32, V8> to BSD41.sw
X
Xboxwid = smallb
XBSD1: box invis "1BSD" at 1/2 <V6, V7> + (0, bsd2 - research)
XBSD2: box invis "2BSD" at V7 + (0, bsd2 - research)
Xboxwid = medb
XBSD28: box invis "2.8BSD" at D82 + (0, bsd2)
XBSD29: box invis "2.9BSD" at D83 + (0, bsd2)
Xarrow from V6.n to BSD1.s
Xarrow from BSD1.e to BSD2.w
Xarrow from BSD2.e to BSD28.w
Xarrow from BSD28.e to BSD29.w
Xarrow right from BSD29.e
X
Xarrow from BSD2.s to BSD3.n
Xarrow from BSD41.ne to BSD28.sw
Xarrow from 1/2 <BSD41A, BSD41C> to BSD29.sw
X
X"\fIBerkeley\fP" ljust at Label + (0, bsd4 + (bsd2 - bsd4)/2)
X
Xarrow from BSD41.se to 3/4 <V32, V8>
Xarrow from BSD41.s to U50.n
X
Xboxwid = medb
Xbox dashed "PDP-11" at BSD1 + (-1, 0)
Xboxwid = smallb
Xbox dashed "VAX" at 1/2 <V32, BSD3> + (-1, 0)
Xboxwid = medb
Xbox dashed "PDP-11" at PWB.w + (-1, 0)
Xboxwid = biggerb
Xbox dashed "PDP-11 / VAX" with .ne at 1/2 <U30, SysIII>
X
X.PE
X.ps +2
!RoNnIe!RaYgUn!
exit
--
John Quarterman, UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET: j...@ut-sally.ARPA, soon to be j...@sally.UTEXAS.EDU
Tim Smith
fsck. There are problems that fsck refuses to deal with, for example,
an unallocated root inode. Fsdb is very handy in this case. Also,
possible file size errors are reported by fsck, but nothing is done with
them. Fsdb is very useful here. You can look at the inode, figure out
what the size should be ( actually, I have a program to do this part... ),
and set the size in the inode. And how about trashed superblocks?
Also, I have noticed that if an ordinary file overwrites a directory,
fsck tends to core dump on that filesystem.
--
Tim Smith
ihnp4!{wlbr!callan,cithep}!tim
Clyde W. Hoover
>> judging by the fact that BSD is still sufficiently compatible that you
>> can run a V6 binary on it (2BSD, but 2 is source compatible with 4),
>"V6 binary"? What have you been smoking? For one thing, 2BSD is V7, not V6
>(I think 1BSD was the V6 Berkeley distribution), but, more importantly, you
>*can't* run V6 binaries on V7. You don't even have a good chance of
>compiling *source* written for V6 on a V7 system and having it run.
Sorry Guy, I've got some V6 binaries that run just fine under 2.9BSD
(The sources were lost a LONG time ago).
As long as you stick to basic UNIX system calls (e.g. 'open', 'close', 'fork',
'read' and 'write'), in a '407' executable, there is no essential
system interface difference between V6 and V7 or 2.XBSD.
And except for VAX-related braindamage, I have easily gotten code
from V7/2.8/2.9 systems to compile & run under 4.1c/4.2BSD. (Suns are
another matter - much like the VAX but without some of the stranger
braindamage).
--
Shouter-To-Dead-Parrots @ Univ. of Texas Computation Center; Austin, Texas
"Forward my mail to the corner of Pork and Beans"
cl...@ut-ngp.ARPA, cl...@ut-sally.ARPA
...!ihnp4!ut-ngp!clyde, ...!allegra!ut-ngp!clyde
John Mashey
> > > * Don't flame me if the index/strchr difference isn't an example of NIH --
> > > I haven't used V5 much...
>
> in the way the original poster thought. *Both* routines are products of
> AT&T - the routine was called "index" in V7 and "strchr" in System III. At
> what point it was renamed, I dunno. The S3 documentation comes with a
> description of changes between S3 and some unspecified earlier version of
> UNIX. One of the changes was that "strcpyn" was renamed "strncpy". This
> predates V7, since it was called "strncpy" there as well.
0) As usual, Guy has pretty good model of the history, minor details:
1) index->strchr happened in UNIX/TS 1.0 (in some sense, System I of the System
V sequence). My 1.0 manual reads November 78; as I recall, this particular
change happened fairly early in the packaging effort that was trying to
get Edition 7 (late, but not released), PWB/UNIX 1.2, and some USG G3
UNIX all back together.
2) strcpyn ->strncpy happened at the same time, early 78. The rename
was because some non-UNIX systems (GCOS, I think) took only the first
6 characters, so that strcpy and strcpyn conflicted, a clearly bad thing.
3) In general, it is unwise to EVER label something as NIH unless you know
for a fact that it is NIH. There are more weird reasons for things being
different in different UNIX versions than you would ever believe; only a few
of them are NIH; it is always best to ask why things are different.
--
-john mashey
UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash
DDD: 415-960-1200
USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043
John Mashey
> > environment business.
>
> If you're referring to the S3 terminal driver, from Bell's standpoint they
> didn't break anything. It's compatible with UNIX 2.0 (or PWB/UNIX 2.0 or
> whatever the hell the release before UNIX 3.0 was). The trouble is that the
> release that went out the door before System III was V7, not UNIX 2.0, which
> means the S3 driver's backward compatibility with UNIX 2.0 is totally
> useless to anybody outside the former Bell System.
1) PWB/UNIX 2.0 was the release before, and before that was UNIX/TS 1.0
(Nov 78). Both of these still had stty/gtty in section (2), with ioctl(3),
with everybody warned to switch over.
2) It is always worth remembering:
a) Research versions of ANYTHING have no commitment whatsoever to
upward compatibility (whether from ATT, UCB, or anywhere else). Once
they do that, the research content falls off pretty badly. Back in
the real old days when we got releases straight from 127, we were
happy when something was upward compatible, but certainly didn't
expect it.
b) Supported versions that do have such commitments must play by
radically different rules, which make them take longer to do:
1) Worry about major customers [for example, as I recall,
the ioctl stuff came from CB/UNIX, or Operations Systems Unices
in general, because the V6/V7 stuff wasn't quite enough.
Remember that such Unices paid the bills for a long time.
2) Never add anything that you not sure of lasting for a while,
because you do have the commitment to keep it semi-forever.
3) Work very hard on transition aids and strategies.
Henry Spencer
> the best strategy might be to "diff" the suckers and take the best from both
> and put it into one version.
Also important is to take the worst from both and *not* put it into the
new version.
> > The lack of file system quotas probably reflects AT&T's openly-expressed
> > view (which I agree with) that except in special situations, if you think
> > you need disk quotas then you really need more disks instead.
>
> ...Think of it as an economic
> problem; you have a scarce resource, but the price mechanism has a long
> time-scale over which it works - possibly too long to prevent short-term
> space shortages. Quotas can keep users from eating the disks until you can
> buy new ones...
The AT&T observation was not that there is no reason for quotas, but that
(like password aging) they don't work satisfactorily. If you can *impose*
quotas on your user community, you can make them work. If users can argue
with the quotas, then you're sunk, because the sum total of the quotas that
users feel they can live with probably exceeds the size of the disk. That
is, if disk space is short enough that you *need* quotas, it's probably
overcommitted already. My own experience with space-short systems certainly
supports this claim. There is also the related problem of maxima becoming
minima: "I'm under my quota, so I don't need to clean up yet".
I have no personal experience with quota systems, but I really wonder if
they aren't like password aging: a superficially-plausible idea that
doesn't really work all that well.
Hostile users are another story, of course.
Doug Gwyn <gwyn>
> documented?
All such lists that I've seen, including internal documents of vendors,
have been quite incomplete. There really seems to be little point in
such a list, unless you're a UNIX package vendor. Only people who
specialize in this topic are likely to be able to remember most of the
differences.
The good news is, that you can develop applications under the System V
environment in such a way that they will run unmodified on any 4.2BSD
system having an appropriate compatibility package such as the BRL
emulation. (Contact your vendor for availability of some such package.)
There are a few constraints when you use this approach, but they are
much less troublesome than trying to write code to a lowest common
denominator or with enough #ifdefs to accommodate all flavors of UNIX.
Brandon Allbery
Quoted from <1...@tommif.UUCP> ["Re: instability in Berkeley versus AT&T releases"], by t...@tommif.UUCP (Tom Faulhaber)...
+---------------
| > 4:00pm up 5 days, 2:33, 6 users, load average: 0.23, 0.07, 0.00
| >
|
| machine had been up for 45 days. These machines had rebooted after PG&E
+---------------
We've shown an uptime of over 4 MONTHS (I believe it was ~ 140 days).
Microsoft Xenix 2.3a (TRS-Xenix 1.3.2) at the time. The only reason we've had
downtime is to upgrade from 1.3.2 up ultimately to 3.0.1 (Xenix 3.0), and
to format floppies since diskutil is, regrettably, standalone.
I post this not to show off, but to note that an uptime war between AT&T and
BSD is just a bit ridiculous. I thought unix-wizards were more mature than
that. (Or did this cross over from net.unix? If so, send it back!)
--bsa
--
Brandon Allbery, Unix Consultant -- 6504 Chestnut Road, Independence, OH 44131
decvax!cwruecmp!ncoast!bsa; ncoast!b...@case.csnet; +1 216 524 1416; 74106,1032
========================> Trekkies have Warped minds. <=======================
Stanley Friesen
>
>compared to dump/restore on 4.2 (or is file system backup and retrieval
>just not important to 'commercial' sites.) Follow the suggested backup
>procedures in the administrators manual, now try to recover a lost file
>(not file system, just one file.) Ooops, gotta know the inode number...
>
Holy Cow! Is this really true! How revolting. I think you
could retrieve a backed-up file by name even back in V7 days!
Now my two cents worth on the general subject. We have almost
never run into significant software related problems here, and we have
been running vanill BSD 4.x for about 2 years. The closest we came was
a flaky interaction between Massbus 2 and Massbus 0 which resulted in
a hung tape drive periodically. Our vendor fixed this almost immediately.
Other than this we have only had hardware problems - the perennial
tbuf parity fault bit(which I think System V is also subject to),
and the usual power failures and so on. seems like a stable system to
me.
--
Sarima (Stanley Friesen)
{trwrb|allegra|cbosgd|hplabs|ihnp4|aero!uscvax!akgua}!sdcrdcf!psivax!friesen
or {ttdica|quad1|bellcore|scgvaxd}!psivax!friesen
Ron Heiby
>Hostile users aren't the only good reason to have quotas. What about
>buggy software that gets into an infinite loop writing to a file?
That's what "ulimit" is for. Don't use an SST when roller skates will do.
--
Ron Heiby he...@cuae2.UUCP (via ihnp4)
AT&T-IS, /app/eng, Lisle, IL (312) 810-6109
Peter DaSilva
>
> As many people have pointed out, unbundling (a) is a botch, and (b) is
> necessary if you are selling Unix boxes with small disks. Not everybody
> has Eagles to put it all on. Whether AT&T's unbundling strategy is
> rational, even given this excuse, is another question... but it is not
> totally without reason.
Venix comes with virtually all the utilities & runs on a PC-XT. That's a 10
megabyte disk, folks. Not an Eagle. That's not a reason, that's not even an
excuse, that's just a rationalisation.
Peter DaSilva
> >
> > (etc.)
>
> I am afraid that this is the point that proves the argument. We have
> an Ethernet composed of Convergent MiniFrames (the parent of the PC 7300)
> in Un*x engineering at CT. A few days ago an ruptime display would have
> shown you that the Networking development machine (mine) and the OS development
> machine had been up for 45 days. These machines had rebooted after PG&E
> decided to run over one of the power lines to our building. Unfortunately last
> week they ran over the power lines again! I would note that the OS
> development machine was running the latest CTIX version, and the networking
> machine was running an experimental kernel.
>
> I say this only partially to brag about our systems. Primarily, I would like
> point out that five or even fifteen days of uptime does not make a solid
> operating system.
>
> Tom Faulhaber
We have an old LSI-11 running V7. Uptime is 49 days. I don't recall the
last time it went down but I think it was because of a power failure. Before
that the last reboot was in March when we replaced the flakey hard drive.
I have no intention of ever getting a SV system if I can at all avoid it. I
have too much software that Bell won't run because they used PWB as the basis
for SIII instead of V7 (the last true UNIX). 4.2 is exceptionally compatible
with V7... and the 4.2 system next door has proven itself reliable.
Peter DaSilva
> advantage of System V (notice that "UNIX" is omitted here)
> with regard to stability is that all significant commercial
> UNIX and C standardization efforts are adhering closely to it
> (and vice-versa).
It is to laugh. Most real world UNIX systems are STILL descendents of V7.
Peter DaSilva
> out of being a much talked about OS into being a much used OS.
I'd love to join a UNIX users group which doesn't have outrageous membership
fees. Next question: who is going to implement it?
Peter DaSilva
> [Guy Harris]
[ME]
> > Judging by how much stuff Bell broke when they came out with SV, and
> > judging by the fact that BSD is still sufficiently compatible that you
> > can run a V6 binary on it (2BSD, but 2 is source compatible with 4),
>
> "V6 binary"? What have you been smoking? For one thing, 2BSD is V7, not V6
I never said it wasn't. The V7 was an early 2BSD release. The V6 was vanilla
V6 (the Berkeley comp center is terribly conservative. They still had one
machine running V5!).
> (I think 1BSD was the V6 Berkeley distribution), but, more importantly, you
> *can't* run V6 binaries on V7. You don't even have a good chance of
> compiling *source* written for V6 on a V7 system and having it run.
I have run V6 binaries on V7. I was at berkeley when the V6/V7 switch was
going on and this was the only way to get certain traditional programs for
V7. We were also running an RSX (!) version of basic+, suitably patched.
Source for V6 ran on V7 with very few problems (had to change RAW to CBREAK,
that was about all).
> And there are programs written for V7 that will break when you try to
> compile them and run them under 4.2BSD...
Yes, but it's a hell of a lot easier to fix them for 4.2 than for
> > even if it uses stty, I'd say it's Bell that's in the unstable computing
> > environment business.
>
> If you're referring to the S3 terminal driver, from Bell's standpoint they
> didn't break anything. It's compatible with UNIX 2.0 (or PWB/UNIX 2.0 or
> whatever the hell the release before UNIX 3.0 was). The trouble is that the
> release that went out the door before System III was V7, not UNIX 2.0, which
> means the S3 driver's backward compatibility with UNIX 2.0 is totally
> useless to anybody outside the former Bell System.
And since V7 and derivatives is the most common UNIX in the real world...
> Guy Harris
Peter da Silva
Peter DaSilva
> [Guy Harris]
[Me: second try at replying]
> > Judging by how much stuff Bell broke when they came out with SV, and
> > judging by the fact that BSD is still sufficiently compatible that you
> > can run a V6 binary on it (2BSD, but 2 is source compatible with 4),
>
> "V6 binary"? What have you been smoking? For one thing, 2BSD is V7, not V6
I know. I was referring to the V7 system as 2BSD, not the V6 one. I know what
2- and 4- BSD are. Hell, some of my code went out in one of the releases (I've
seen it at IUVAX).
> (I think 1BSD was the V6 Berkeley distribution), but, more importantly, you
> *can't* run V6 binaries on V7. You don't even have a good chance of
> compiling *source* written for V6 on a V7 system and having it run.
At Berkeley there were several V6 programs that there was no source to. They
were running on a 2BSD system (ucbcory). QED.
> And there are programs written for V7 that will break when you try to
> compile them and run them under 4.2BSD...
Actually once you change RAW to CBREAK they're quite compatible. I've moved
stuff between V5, V6, and V7 with few problems. SIII and SV are a royal pain,
though.
> > even if it uses stty, I'd say it's Bell that's in the unstable computing
> > environment business.
>
> If you're referring to the S3 terminal driver, from Bell's standpoint they
> didn't break anything. It's compatible with UNIX 2.0 (or PWB/UNIX 2.0 or
> whatever the hell the release before UNIX 3.0 was). The trouble is that the
> release that went out the door before System III was V7, not UNIX 2.0, which
> means the S3 driver's backward compatibility with UNIX 2.0 is totally
> useless to anybody outside the former Bell System.
And since most real world UNICES are V7 derived, what does that say about Bell?
HopkinsWE
yes, stty is no longer included in official System V Release 2 documentation,
but it is still there in the kernal (it calls ioctl). I ran into it
while modifying some code, didn't find it in 5.2, 5.0, or 3.0 manual,
then asked someone who had 4.2bsd background who recognized it and
then tracked it down in the kernal.
Bill Hopkins
AT&T Information Systems
ihnp4!druny!weh
Griff Smith
> >Hostile users aren't the only good reason to have quotas. What about
> >buggy software that gets into an infinite loop writing to a file?
>
> That's what "ulimit" is for. Don't use an SST when roller skates will do.
If you haven't worked where people use UNIX systems to do real data
processing, don't propose "ulimit" as an alternative to quotas. A 50
meg file won't even cause a batted eyelash here. When you lose half a
day because you forgot to cast the proper spell to bypass a per-file
size limit, per-file-system limits look much more attractive. The BSD
quota system also supplies detailed, quickly-accessible, reports of
disk usage. I don't have time to use combinations of "find" and "du"
when the console is screaming "disk full". We set our quotas very high,
but they are convenient fire walls. The first thing we do to "ulimit"
is to set it to a huge value; the time lost due to hitting the standard
value is just not worth it.
--
Griff Smith AT&T Bell Laboratories, Murray Hill
Phone: (201) 582-7736
Internet: g...@ulysses.uucp
UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs )
J. Shapiro
> > Henry Spencer @ U of Toronto Zoology
>
The only thing terrible about ls -C is that it ought to be the default for
CRTs. USG ls _requires_ the "-C" to get the multiple columns, which _is_
brain damaged.
Jon Shapiro
Haverford College
Chuck Hedrick
Control, I have little sympathy. It is crazy to think that quotas are
going to let you decrease a user's disk usage below what he seriously
believes he needs. But in a cooperative environment, they provide a
convenient benchmark, that documents what the user has agreed to. The
4.2 quota system is particularly nice, since it forgives a few
overages, and allows for more working space when logged in. They
cause people to look at their file usage a bit more than they would
otherwise, and to think for 30 seconds whether they really want to ask
me for more space. That's useful, and about all one should expect.
Doug Gwyn <gwyn>
Must be an alternate universe (see net.physics).
Joel West
> However, this is misleading. In the first place, dungeon is really an RSX-11
> binary (from a Fortran source) which was munged into a V6 binary which was
> in turn munged into a V7 binary (the differences between V6 and V7 binaries
> really aren't that great), and chess is really a V7 binary.
>
> In the second place, what's really happening here is that these binaries are
> PDP-11 binaries (that's what V6 and V7 ran on) which are run in VAX
> compatibility mode (the VAX hardware supports such a thing) using a program
> called /usr/games/lib/compat and a front end to open the files.
Oh, oh. I'm no longer looking forward to getting my MicroVAX II (which
I think has dumped PDP-11 once and for all). I won't be able to play zork!
:-( [:-)]
Joel West CACI, Inc. - Federal (c/o UC San Diego)
{ucbvax,decvax,ihnp4}!sdcsvax!jww
j...@SDCSVAX.ARPA
Roy Smith
What started out as (yet another) discussion about 4.2 vs. Sys5 has
now turned to discussing disk quota systems. Since I would hate to see
mod.unix die out, I have taken advantage of this change of topic and sent a
followup article to mod.unix; see you all there.
J.WOOD
Mash:
While we're arguing about who's the biggest pack rat,
my PWB UNIX Usser's Manual Edition 1.
It has neither strcatn nor strncat nor index in strings(III),
but it does have an original "Programmer's Workbench
Documentation Roadmap," Author J. R. Mashey, 01/18/77 :-)
Joseph L. Wood, III
AT&T Information Systems
Laboratories, Holmdel
(201) 834-3759
<ariel!>titania!jlw
Guy Harris
> is misleading.
Certainly is. 4.2BSD can run PDP-11 V6 binaries (there are other V6
binaries), but V7 can't. ("stat" changed radically, and unlike the
V7/4.2BSD change to "stat" it isn't source-compatible or binary-compatible.
"seek" got replaced by "lseek".) 4.2 can do it because the
compatibility-mode emulator simulates the system calls, and can simulate V6
calls as well as V7 ones.
> not on a Sun or other 4.2BSD machine (where you won't find zork or chess.)
For what it's worth, my Sun UNIX 2.0 manual has a section CHESS(6) -
somebody here rewrote the assembler-language part of "chess" in 68000
assembler language.
> Nonetheless, most V7 programs will compile and run happily on 4BSD, which
> is not true of System V.
Depends on how you define "most". V7 programs which assume "read"s and
"write"s on slow devices return EINTR when a signal breaks through them
don't run happily on 4.2BSD. S5 programs that don't use any library
routines not in V7 (other than "strchr"/"strrchr") and don't do terminal
"ioctl"s will (modulo a couple of exceptions, I suspect) compile and run
happily on V7, 4.1BSD, 4.2BSD, ... (S5 programs that *do* use library
routines not in V7 won't work, but then 4.2BSD programs which use library
routines not in V7 won't work on V7 or S5 either.)
Guy Harris
Guy Harris
> >Hostile users aren't the only good reason to have quotas. What about
> >buggy software that gets into an infinite loop writing to a file?
>
> That's what "ulimit" is for. Don't use an SST when roller skates will do.
*ONLY* if the default "ulimit" is infinity, not the dumb 1MB that comes with
S3/S5 out of the box from AT&T. Put a "ulimit" on programs you want to
debug (note that an almost-identical facility, except for a signal SIGXFSZ
which is delivered to the errant program, exists in 4.xBSD). DON'T penalize
database systems which want to maintain big databases (and don't force me to
run those systems as root just to boost their "ulimit"), or other programs
which, for whatever reason, need files bigger than 1MB.
Guy Harris
Geoff Kuenning
>
>If you haven't worked where people use UNIX systems to do real data
>processing, don't propose "ulimit" as an alternative to quotas. A 50
>meg file won't even cause a batted eyelash here. When you lose half a
>day because you forgot to cast the proper spell to bypass a per-file
>...We set our quotas very high,
>but they are convenient fire walls.
Sounds to me like quotas aren't really what you want, either. You don't
want to set artificial limits on people's work (and any limit, no matter how
high, is going to be a problem for someone someday). What you really want
is an OS that doesn't make it nearly impossible to deal with exceptional
conditions. UNIX's response to a filled disk comes from the "panic: out
of swap space" days when nobody really wanted to write the tough code because
it wasn't that important. If Berkeley (or AT&T) would put as much effort into
the disk-full problem as was put into "swkill()" in 4.2, I bet you'd happily
stop using quotas.
--
Geoff Kuenning
...!ihnp4!trwrb!desint!geoff
Doug Gwyn <gwyn>
> S3/S5 out of the box from AT&T.
Yes, AT&T, please change this. A 1Mb default ulimit is unnecessary;
the system manager could set this up in /etc/profile (like umask) if
he thinks it is needed.
Doug Gwyn <gwyn>
> CRTs. USG ls _requires_ the "-C" to get the multiple columns, which _is_
> brain damaged.
I would sure get upset if when I ran "ls" in the long skinny window
on my DMD, it didn't print the file names one per line. You are
making the same mistake that a lot of the more crufty BSD software
has made, namely: assuming an overly-restrictive model of how the
software is to be used.
k...@cbrma.uucp
> > If you're referring to the S3 terminal driver, from Bell's standpoint they
> > didn't break anything. it's compatible with UNIX 2.0 (or PWB/UNIX 2.0 or
> > whatever the hell the release before UNIX 3.0 was). The trouble is that the
> > release that went out the door before System III was V7, not UNIX 2.0, which
> > means the S3 driver's backward compatibility with UNIX 2.0 is totally
> > useless to anybody outside the former Bell System.
> And since most real UNICES are V7 derived, what does that say about Bell?
Um, I'd like to bring this point in question for just a second. Although I
work for Bell, I am neither (a) defending my company nor (b) trying to convince
anybody that S3/S5 is better/worse than BSD/V7. I just want to question the
statement that most UNICES are V7-derived. This is basically
numbers-juggling, since the complaint is based on `most UNICES.'
I work at Columbus Bell Labs. My department has something like 60 people in
it. We have 2 VAX 780s, 2 PDP-11/70s, 1 3B, 7 PDP-11/73s, 6 PDP-11/23+'s,
and 6-or-so PDP-11/23s. My understanding (more or less confirmed by my
local sysadmin) is that my department is not particularly equipment-rich with
respect to processors. All of our processors run USG Unix systems, i.e., S3
or S5. There are, in turn, around 550 people (last I heard) working here at
Columbus BL. Scaling up my department's systems to account for the rest of
the systems at this location means that there are in the vicinity of
200 processors running Unix systems around here.
It is of course important that not all of them are running USG Unix systems;
the obvious case in point is that Mark Horton works (lives?) somewhere on the
next floor down, and his department works primarily with BSD, I guess; knock
off a dozen processors for those VAXen and SUNs, and maybe another half dozen
for some other department's systems that I don't know anything about. But I
think the wide majority can be said to be running non-BSD stuff.
My major point is this: Columbus is far from the largest of the Bell Labs
locations; we're only a `branch' location anyway. There are something like
5000 people in the Indian Hill area, and I don't even want to guess who's in
NJ. I'm aware of a sysadmin in Indian Hill who has responsibility for 28 VAXen
on one floor alone. Try scaling those kinds of numbers up to account for
who's running what version of the Unix system; I think it'll alarm you.
Thus, I don't think it's reasonable or fair to say that most Unix systems
are V7-derived. Just dealing with our own internal systems, it's nowhere
near true, and I haven't even made the faintest attempt to consider outside
customers who are buying S5 at a substantial pace. And, further, maintaining
compatibility for all those folks who were doing things in UNIX 2.0 or
PWB/UNIX x.x (long, long before I showed up here) was a substantial concern.
Just a thought for reflection...someone will probably flame me anyway with
`Yeah, but my company runs these <n> Widget-62s that are so popular and use
BSD'...sigh.
[This is probably completely unrelated to company position, of course.]
--
Karl Kleinpaste
Tim Smith
--
Tim Smith
ihnp4!{wlbr!callan,cithep}!tim
Father of micro-S
>> The only thing terrible about ls -C is that it ought to be the default for
>> CRTs. USG ls _requires_ the "-C" to get the multiple columns, which _is_
>> brain damaged.
>
>I would sure get upset if when I ran "ls" in the long skinny window
>on my DMD, it didn't print the file names one per line.
So make ls check the width of the window, and do multi-column if possible
according to the width of the window.
-----------------------------------------
Samuel A. Figueroa, Dept. of CS, Univ. of KY, Lexington, KY 40506-0027
ARPA: ukma!sambo<@ANL-MCS>, or sambo%ukma...@anl-mcs.arpa,
or even anlams!ukma!sa...@ucbvax.arpa
UUCP: {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!sambo,
or cbosgd!ukma!sambo
"Micro-S is great, if only people would start using it."
Ron Heiby
cross-posted with net.unix-wizards (trash dump). Really, I'm very
sorry that I started a religious battle (or two or three) on V7 vs.
4BSD vs. SysV vs. ..... P-leeeeease read what I say and assume that
I mean it if I don't use a smiley face.
I made a remark about the different orientation of a research /
teaching organization vs. a commercial computer vendor and suddenly
I was accused of bad-mouthing products that had adapted software
developed by the research / teaching organization. I made a remark
that ulimit could be used in direct response to someone who asked
about how to control / test "buggy software". I did NOT recommend
that a small ulimit be used for database applications, nor did I
recommend that it be a low value by default in all cases, nor did I
suggest that it was a panacea that eliminated the need for other
disk usage tracking and control tools. Good grief!
Can we drop all this now and get on to something worthwhile? Or
maybe we can at least leave the religious debates in
net.unix-wizards and obviate the need for a mod.micro.att.
x0705
Actually, the SVR2 ls -C looks at the COLUMNS variable to find out how much
space is available, and adjusts the number of columns accordingly.
The 4.1BSD ls checked whether isatty(stdout), and set the output to single or
multi-column accordingly; I always hated that since I normally wanted
multi-column all the time.
--
## Bill Stewart, AT&T Bell Labs, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
Peter DaSilva
>
> Must be an alternate universe (see net.physics).
Replace "real world" by "outside AT&T". WHat AT&T does internally on their
3B20Ds is pretty much irrelevent to what I want to do on my PDP-11. IBM is
pretty braindamaged but even they don't require you to run MVS on your XT. AT&T
was quite happy with having an external and an internal system before System
III.
Also most "non AT&T" UNIX systems predate System V. The ones that claim to be
System III are almost all Microsoft or Unisoft releases and are V7 with
SIII patches (which is why I didn't have to know about MIN & TIME when I was
working on Xenix 3.0. Nice of Microsoft to tell me).
Peter DaSilva
> yes, stty is no longer included in official System V Release 2 documentation,
> but it is still there in the kernal (it calls ioctl).
If it's there it should be documented or porters will eat it. What are the
parameters & structures this version accepts? V6 or V7?
Peter DaSilva
> > is misleading.
>
> Certainly is. 4.2BSD can run PDP-11 V6 binaries (there are other V6
> binaries), but V7 can't. ("stat" changed radically, and unlike the
> V7/4.2BSD change to "stat" it isn't source-compatible or binary-compatible.
> "seek" got replaced by "lseek".) 4.2 can do it because the
> compatibility-mode emulator simulates the system calls, and can simulate V6
> calls as well as V7 ones.
Fine, as long as it doesn't use stat, sgtty, or lseek it's OK. How many
programs use stat, sgtty, or lseek? Mainly system programs, which will
come with the new system.
Peter DaSilva
> on my DMD, it didn't print the file names one per line. You are
Then why don't YOU alias "ls | cat" and let the majority of the world work.
It's these weird variants put in for esoteric special cases that really
bugs me about SV. How many AT&T 7300s are going to benefit from SV accounting
stuff?
Guy Harris
> were running on a 2BSD system (ucbcory). QED.
That's nice. They sure as hell didn't use "seek" or "stat"...
> > And there are programs written for V7 that will break when you try to
> > compile them and run them under 4.2BSD...
>
> Actually once you change RAW to CBREAK they're quite compatible.
I'll assume this statement refers to V6 vs. V7; I hope nobody is ignorant
enough to think CBREAK was a Berkeley invention...
> I've moved stuff between V5, V6, and V7 with few problems.
Bet you had fun with the stuff using the old V5/V6 I/O library which was not
available in V7...
> SIII and SV are a royal pain, though.
Only if you don't know what you're doing. I've moved stuff between V7 and
S3/S5 with few problems.
In case you're curious, I once (as a hack) got most of the way through
turning V7 kernel source into S3 kernel source, working with on-line V7
source and an S3 kernel printout. I submit that the chances of a V6 binary
running on S3/S5 are very close to the chances of a V6 binary running on V7
(PDP-11 binaries here - although, from a quick look at the system call and
"exec" code of S5R2 and 4.2BSD, the chances look *very* good that you can
run many S5 binaries under 4.2BSD!). At least V7's "lseek" and "stat" calls
are the same in S5... (if I had a V6 manual, I'd check to see how compatible
the V6 and V7 drivers' "sgtty" structures were, and then check how
compatible the V6 and PWB/UNIX 2.0 structures - as used by S5 - were...)
Then again, you can't run PDP-11 *or* VAX binaries on the 4.2BSD machine I'm
typing this on, so the question of binaries is irrelevant anyway...
Moving on to sources, I merely state again that I've moved code between V7,
4.2BSD, and S5 with few hard glitches. Converting "ioctl"s is certainly
tedious, but *if* you know what you're doing there are few surprises. Of
course, a number of flamers against the S3/S5 driver haven't bothered doing
the work of figuring out the (admittedly complex) interface...
(BTW, try porting an S5, S3 *or* V7 program which expects "read", "write",
"wait", etc. system calls to be interrupted by signals to 4.2BSD. You may
get a little surprise...)
> > ...the S3 driver's backward compatibility with UNIX 2.0 is totally
> > useless to anybody outside the former Bell System.
>
> And since most real world UNICES are V7 derived, what does that say about
> Bell?
It says that due to a mixture of technical and legal reasons they couldn't
a) throw away the 2.0 compatibility in S3 replacing it with V7 compatibility
or b) offer two versions of UNIX 3.0.1/S3.
As for your claim that "most real world UNICES are V7 derived", I don't
believe it. Period. Most commercial vendors are offering S3 or S5-based
systems. Several 4.2 vendors are now offering 4.2BSDs that have some degree
of S5 compatibility. Some of them are even clever enough to offer 4.2
functionality and S5 compatibility to the same programs as opposed to
walling the two systems off in separate worlds. I suspect this will happen
more in the future.
I think enough has been said - more than enough, since most of the postings
on this subject have been broadsides fired in religious wars rather than
accurate discussions of the places where {V7,4.2BSD,S5} do well and where
they do poorly. If anybody else wants to wage holy war over why their
favorite version of UNIX is the "only true UNIX", could they please move the
discussion to net.flame or net.religion.software?
Guy Harris
J. Shapiro
I was waiting for someone to say that. I knew the net could be relied on for
a straight line. Consider that generating multiple columns requires a know-
ledge of terminal width, and that I did not insist that "ls" be stupid. I
If my window is wide enough for two columns, that is how I want my display.
There is a difference between being "crufty" and paying attention to detail
and niceities that make life easier on a user. Whether -C should be the
option or -1 should be the option should not be determined by your or my
blathering. It should be determined by what the bulk of the users
want, modified by what is feasible, reasonable, and sensible.
Part of the pleasure of dealing with UNIX, to me, is the fact that
utility programs don't insist on being unduly stupid. As to my model
being overly restrictive, that is simply untrue, as I hope is now
clear. Utilities ought to behave reasonably, and this in no way
detracts from the robustness of my model - she's terrific;-)
Jon Shapiro
Haverford COllege
Robert Elz
> If Berkeley (or AT&T) would put as much effort into
> the disk-full problem as was put into "swkill()" in 4.2, I bet you'd happily
> stop using quotas.
I would love to somehow handle full disk conditions gracefully,
but can you suggest how?
Swap errors (swkill stuff) is easy - kill the process with the problem.
If the system had paniced the process would be killed anyway, so its
no worse off, and the rest of the processes are considerably better
off for not panicing.
But how do I handle a full disk? Killing some random process won't
fix it (not even killing ones writing to the full filesys).
I could just delete some random files - but somehow I suspect their
owners might get upset.
So, does anyone have any good suggestions on how to sensibly handle
full discs? The problem is really one of user control - only users
know which of the allocated blocks on the disk contain useful information,
and which contain trash.
This seems to be a situation where avoiding the problem (by simply
plugging in another eagle every week for preference, disk quotas
if that answer isn't viable) is the only reasonable action.
Robert Elz ucbvax!kre
Bruce Robertson
It is V6, unfortunately. I was very disappointed when I found this out, and
promptly upgraded it to V7.
--
Bruce Robertson
UUCP: {ucbvax!menlo70,seismo}!unr70!unrvax!stride!bruce
Guy Harris
> 4.2BSD!).
Well, let me amend that to "S3 binaries"; S5 COFF binaries can't be executed
by vanilla 4.2BSD, although the changes required are (relatively) localized
(unless you want to execute demand-paged binaries from S5R2V2, in which case
the fact that S5R2V2 is basically modeling a segmented/paged MMU on the VAX
hardware, and as such wants to put segments on 64KB boundaries, will bite
you - you can still do it, but it reaches the point of diminishing
returns...)
Guy Harris
John Mashey
> > > useless to anybody outside the former Bell System.
> >
> > And since most real world UNICES are V7 derived, what does that say about
> > Bell?
>
> It says that due to a mixture of technical and legal reasons they couldn't
> a) throw away the 2.0 compatibility in S3 replacing it with V7 compatibility
> or b) offer two versions of UNIX 3.0.1/S3.
remember that UNIX/TS -> PWB 2.0 -> SIII ->SV was a convergence process
to desperately try to get a UNIX that more people could agree
on and avoid having to make weird extensions; terminal driver was a notorious
area for such extensions; too many people doing non-research projects found
they needed other things. Again, ANYONE WHO EXPECTS TO GET UPWARD-COMPATIBLE
RELEASES FROM SOMETHING LABELED RESEARCH does not understand research.
Research versions of things and production, guaranteed-upward-compatible
things are different animals [not better or worse, just different].
>
> As for your claim that "most real world UNICES are V7 derived", I don't
> believe it. Period. Most commercial vendors are offering S3 or S5-based
> systems. Several 4.2 vendors are now offering 4.2BSDs that have some degree
> of S5 compatibility. Some of them are even clever enough to offer 4.2
> functionality and S5 compatibility to the same programs as opposed to
> walling the two systems off in separate worlds. I suspect this will happen
> more in the future.
is certainly true, since XENIX, V and 4.2 are all V7-derived. In the more
specific sense of "V7, rather than III", this is probably true [numbers,
somebody?] because I suspect there are a lot of V7-derived XENIX systems
still out there [by sheer numbers of CPUs]. By number of users, who knows?
>
> I think enough has been said - more than enough, since most of the postings
> on this subject have been broadsides fired in religious wars rather than
> accurate discussions of the places where {V7,4.2BSD,S5} do well and where
> they do poorly. If anybody else wants to wage holy war over why their
> favorite version of UNIX is the "only true UNIX", could they please move the
> discussion to net.flame or net.religion.software?
to flame upon its stupidity; sometimes environments and tradeoffs are
different and you learn something. Some of the "X is better than Y"
arguments are really "[in my situation] X is better than Y [and I don't
have much experience with other kinds of situations] and therefore people
who use Y must be communist mutants from space [or worse!]
Here's a test case: how many people think UNIX is better than IBM's OS/MVS?
....
If you answered:
-What do you want to use it for? 10 points - good answer.
-What's MVS? 5 points for honesty.
-UNIX is better, of course - MVS is UGLYYYYY. - 0 points [because what you
get to do is a 10 Gigabyte database with required response times that
and needs a 3084.] Don't laugh; I've known people who tried to put
projects like that on UNIX; not too many worked.
Much insight can come from tradeoff analysis; sometimes by looking at
differences we learn what the real general cases are and make progress
by synthesizing better mechanisms that cover more cases; little
progress is made in religious wars.
Guy Harris
> your XT.
That's a remarkably irrelevant example, considering 1) it has nothing to do
with internal vs. external releases and 2) since MVS is written in 360
assembler and PL/S, and since the former *can't* run on an 8088 without a
slow simulator and the latter probably has lots of 360-dependent goo in it,
you couldn't run MVS on a PC anyway.
> AT&T was quite happy with having an external and an internal system before
> System III.
I see no reason to assume they were happy about it. Remember a little
something called the "Consent Decree"? AT&T *wasn't allowed* to be in the
computer business *at all* before the breakup - there were suits from ADAPSO
trying to get UNIX off the market!
> Also most "non AT&T" UNIX systems predate System V. The ones that claim to
> be System III are almost all Microsoft or Unisoft releases
The HP ones? The CCI one? (more on that one later) The Plexus one?
> and are V7 with SIII patches
So what? The TTY driver seems to be your primary source of dyspepsia; I
suspect most systems which are "V7 with S3 patches" have S3 libraries and a
kernel which started out as a V7 kernel and got changed to resemble S3,
including having the S3 tty driver dropped into it (I know that's how the
CCI system was done, since I was one of the people who did it). As such,
well, if it looks like a duck, and walks like a duck, and quacks like a
duck, who cares if it's a goose with duck patches?
> (which is why I didn't have to know about MIN & TIME when I was working
> on Xenix 3.0. Nice of Microsoft to tell me).
This has been explained to you elsewhere, but if you're clearing the ICANON
bit, you either have to set MIN and TIME to get reliable results or they
botched the tty driver.
Guy Harris
John Mashey
> It's these weird variants put in for esoteric special cases that really
> bugs me about SV. How many AT&T 7300s are going to benefit from SV accounting
> stuff?
"Weird variants put in for esoteric special cases..." is a pejorative
description that could be read "I don't need this so it's dumb". A better
way to have written this might be: "Does anyone know why SYS V accounting
is included in the system? We haven't seen any use for it in our environment,
and it seems particularly unnecessary for single-user workstations. Who
uses it?"
Now, the true facts [and I wrote it, so I know] are:
a) It is (correctly) in the Optional part of the SYS V spec.
b) Computer centers do like to be able to usage accounting so they
can charge people money. This might not make sense if you've never
used a computer center or run one, but it is true.
c) Various people sometimes like to analyze system performance
and usage [without actually charging people] by looking at
the accounting output.
V6 shell accounting was [in practice] found to be inadequate for real
computer centers; there was a major push by BTL computer centers starting
about 1977 to offer UNIX; we therefore tried hard to get a minimal
mechanism to become part of V7 [many thanks to DMR for cooperation here]
that would satisfy b) and c) above to avoid having every comp center
do their own thing; the original version had to work on both V6 and V7's;
had to work on PDP-11s; had to be a toolkit to adapt to different people's
ideas of charging algorithms; ought to be reworked because requirements
have changed!
Weird? Esoteric? No, just different needs.
Peter DaSilva
> the work of figuring out the (admittedly complex) interface...
First I had to FIND the interface. That's exactly my complaint. It's complex.
It's also well hidden (what in the hell is it doing in the administrator's
manual?????).
> (BTW, try porting an S5, S3 *or* V7 program which expects "read", "write",
> "wait", etc. system calls to be interrupted by signals to 4.2BSD. You may
> get a little surprise...)
This is a problem, though non-interrupting signals are nice they should have
implemented it only in the new signal stack, leaving the old signals alone.
4.2 has 2 counts against it (signals and directories). SV has more than that.
> > > ...the S3 driver's backward compatibility with UNIX 2.0 is totally
> > > useless to anybody outside the former Bell System.
> >
> > And since most real world UNICES are V7 derived, what does that say about
> > Bell?
>
> It says that due to a mixture of technical and legal reasons they couldn't
> a) throw away the 2.0 compatibility in S3 replacing it with V7 compatibility
> or b) offer two versions of UNIX 3.0.1/S3.
Well, they should have made 2.0 compatible with V7 when it became obvious that
V7 was succeeding outside Bell, but... c) keep the V6 system call emulation
or change it to V7 emulation. Either would do.
> As for your claim that "most real world UNICES are V7 derived", I don't
> believe it. Period.
Most real world UNICEs were installed before the SV interface definition came
out. But examples: UniPlus+ SIII is actually V7 with some SIII additions. So
is Xenix 3.0. The TRS80 Model 16 is an extremely common UNIX box. It's V7.
> Most commercial vendors are offering S3 or S5-based
> systems.
Most SIII systems are actually V7 plus SCCS, as noted above. This is why I
thought SIII was V7 compatible: all teh SIII systems I had used were actually
V7.
> they do poorly. If anybody else wants to wage holy war over why their
> favorite version of UNIX is the "only true UNIX", could they please move the
> discussion to net.flame or net.religion.software?
You first.
Peter DaSilva
> >> yes, stty is no longer included in official System V Release 2
> >> documentation, but it is still there in the kernal (it calls ioctl).
> >
> >If it's there it should be documented or porters will eat it. What are the
> >parameters & structures this version accepts? V6 or V7?
>
> It is V6, unfortunately. I was very disappointed when I found this out, and
> promptly upgraded it to V7.
Well if they'd document this & make sure it doesn't go away I'd drop any
possible objection to the current ioctl. It's a lot more powerful, but for
simple stuff (like setting rawmode) it's too complex.
Doug Gwyn <gwyn>
> > > CRTs. USG ls _requires_ the "-C" to get the multiple columns, which _is_
> > > brain damaged.
> >
> > I would sure get upset if when I ran "ls" in the long skinny window
> > on my DMD, it didn't print the file names one per line. You are
> > making the same mistake that a lot of the more crufty BSD software
> > has made, namely: assuming an overly-restrictive model of how the
> > software is to be used.
>
> space is available, and adjusts the number of columns accordingly.
> The 4.1BSD ls checked whether isatty(stdout), and set the output to single or
> multi-column accordingly; I always hated that since I normally wanted
> multi-column all the time.
Columnators should also do an ioctl(TIOCGWINSZ) or the DMD equivalent.
Our "mpx" does not alter the COLUMNS environment variable for each
layer, but rather stores the window size in the tty structure.
Actually, if you want columnated "ls", given the way "ls" works it
is necessary to either build the columnation into "ls" or to provide
a very specific columnizing filter, since "ls" lists multiple
directories WITH HEADERS so that simple-minded columnizing will mess
up the output. I think the SVR2 method (requiring an explicit request
for columnation) is preferable to Berkeley's automatic behavior. It is
very easy to make up a shell function, alias, or script like
l(){
ls -Cf $*;
}
to make your own personalized "l" command if you want one.
Default command behavior should be simple, with complexities reserved
for the options.
P.S. I think I started the "ls" debate, but all I said was that I
thought "ls -[a-z][A-Z]" was yucky (too many options to remember).
I don't like a directory-entry listing utility having to know about
terminal characteristics, though. This seems like an unnecessary
combining of function. I like Peter Weinberger's idea of having a
directory format that is directly printable:
10038 .
10039 ..
10502 myfile
10501 mydir
etc. It would even be nice to get rid of . and .. I guess it's too late...
Mark Horton
Sheesh! What does all this have to do with AT&T micros?
Can't we move this discussion to, say, mod.unix?
>the obvious case in point is that Mark Horton works (lives?) somewhere on the
>next floor down, and his department works primarily with BSD, I guess; knock
>off a dozen processors for those VAXen and SUNs,
Lest anyone get the wrong impression, we have only 4 4.2BSD machines in
our dept - one VAX, one Sun fileserver, and two Sun workstations. The
rest of the machines mostly run System V (except for a Masscomp which is
SIII derived, two SIII based HP machines, and a 6300 that runs Xenix.)
Our project is committed to System V too.
And strangely enough, I do go home a lot. Sometimes I get more work
done from home than my office (and sometimes vice versa.) I can produce
a lot nicer environment in my office at home than AT&T provides there.
(Haven't figured out how to take my Sun workstation home yet, though.)
>I just want to question the
>statement that most UNICES are V7-derived. This is basically
>numbers-juggling, since the complaint is based on `most UNICES.'
Well, I could probably say just about anything here and produce a
statistic to back it up.
In terms of pure numbers, my understanding is that over half of the
UNIX systems in the world today run Xenix. Since Xenix is V7
derived (with lots of System III and V stuff added in later) it
can be reasonably said that ``most unices are V7-derived''
However, most Xenix machines are micros or even PC's, so this
number can be misleading. Most of these machines don't connect
into the net as we see it. (Whether such connection matters is
no doubt part of your definition of "real world", which is certainly
subject to some creative wording.)
Another way of looking at it is this. Of about 2500 known machines
on the UUCP network (not counting the various machines that we've just
"heard of" but don't really know anything about), about half of them
are owned by AT&T, and about half are in the outside world. And it's
certainly true that most of AT&T has System V colored glasses on
(internally it isn't even called System V, it's called "Standard UNIX",
at least when spoken this is the term I usually hear.) There are a few
pockets of 4.2BSD, but even these pockets tend to have lots of System V
machines around too. So, assuming there are even a few System V machines
outside AT&T, if you count the machines that are well enough known to
be on UUCP, System V would win (and System V is NOT V7-derived.) Note
that the typical 3B2 or UNIX PC or Xenix machine is NOT on the map,
and believe me, there are gobs and gobs of them up and down the halls
(not to mention the 6300's that people use as terminals.)
Mark Horton
Tim Smith
>> I would sure get upset if when I ran "ls" in the long skinny window
>> on my DMD, it didn't print the file names one per line. You are
>
Ever used a windowing system in a bit mapped display? HE will be part of
the majority, not you.
>It's these weird variants put in for esoteric special cases that really
>bugs me about SV. How many AT&T 7300s are going to benefit from SV accounting
>stuff?
Excuse me, but it is not AT&T that is putting in special cases! And why is
accounting a special case? You are perfectly free to turn off and remove all
accounting stuff from your 7300 ( This is complete speculation on my part,
but they couldn't have shpxrq(ROT 13) it up THAT badly, could they? )
--
Multi-column output should be handled in the terminal driver, so
all program will be able to use it. :-)
Doug Gwyn <gwyn>
> > yes, stty is no longer included in official System V Release 2 documentation,
> > but it is still there in the kernal (it calls ioctl).
>
> If it's there it should be documented or porters will eat it. What are the
> parameters & structures this version accepts? V6 or V7?
Stty/gtty are there for binary compatibility, not for use in new code.
Thus it doesn't matter if stty/gtty are removed during porting.
Peter da Silva
> > your XT.
>
> That's a remarkably irrelevant example, considering 1) it has nothing to do
> with internal vs. external releases and 2) since MVS is written in 360
> assembler and PL/S, and since the former *can't* run on an 8088 without a
> slow simulator and the latter probably has lots of 360-dependent goo in it,
> you couldn't run MVS on a PC anyway.
OK. Take any IBM operating system and stick it in there. I'm not an expert
on IBM.
> > Also most "non AT&T" UNIX systems predate System V. The ones that claim to
> > be System III are almost all Microsoft or Unisoft releases
>
> The HP ones? The CCI one? (more on that one later) The Plexus one?
No, just most. A goodly percentage are TRS-80 model 16s.
> > and are V7 with SIII patches
>
> So what? The TTY driver seems to be your primary source of dyspepsia; I
> suspect most systems which are "V7 with S3 patches" have S3 libraries and a
> kernel which started out as a V7 kernel and got changed to resemble S3,
> including having the S3 tty driver dropped into it (I know that's how the
> CCI system was done, since I was one of the people who did it). As such,
> well, if it looks like a duck, and walks like a duck, and quacks like a
> duck, who cares if it's a goose with duck patches?
It doesn't quack like a duck since I took a program from V7 to Unisoft SIII
and compiled it and it ran. No problems.
> > (which is why I didn't have to know about MIN & TIME when I was working
> > on Xenix 3.0. Nice of Microsoft to tell me).
>
> This has been explained to you elsewhere, but if you're clearing the ICANON
Yes, it was explained by the OEM the "SIII" came from, after I asked him
why the SIII wasn't SV compatible.
> bit, you either have to set MIN and TIME to get reliable results or they
> botched the tty driver.
They didn't appear to have attempted to convert the TTY driver. VMIN and
VTIME should never have been part of c_cc[] in the first place, so if they
had converted it and made them seperate somewhere I'd hardly call it a botch.
> Guy Harris
Peter da Silva (wondering why he's still flaming me over VMIN and VTIME).
PS: I don't know what current Xenix3 or Uniplus+ are like, so if they have
"fixed" these "bugs" since the systems I was trying to port things between
were released don't flame me for that. I get enough of it from Guy & Bill.
--
Peter da Silva (the mad Australian)
UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter
MCI: PDASILVA; CIS: 70216,1076
Peter da Silva
> Can't we move this discussion to, say, mod.unix?
How about shutting it down? I've already admitted I blew it by claiming
that SIII wasn't compatible with SV. I've explained why. The rest of the
flames are matters of opinion & statistics. I don't even care if you have
to type "lc" to get columns, for god sake, so long as I can get them, and
I think cat -v is obscene! OK? Have I sufficiently placated the ghods?
Peter da Silva
> the majority, not you.
The majority will also have better things than ls for looking at directories.
Like, say, icons? And have you ever done windowing at 300, 1200, or even 2400
baud?
> Excuse me, but it is not AT&T that is putting in special cases! And why is
> accounting a special case? You are perfectly free to turn off and remove all
> accounting stuff from your 7300 ( This is complete speculation on my part,
> but they couldn't have shpxrq(ROT 13) it up THAT badly, could they? )
It was my understanding from reading the manuals that it was implemented in
the kernal, and thus couldn't be removed. I've been informed that this is
not true. (wipes egg off face)
Henry Spencer
> viewpoint, it's simpler to have it run down the left margin. From the
> novice user's viewpoint, it's simpler to have it appear in columns on
> the side of the screen than to (a) learn to lunge for ^S before it runs
> off the screen, (b) remember to type -C every time, or (c) learn how to
> make a .profile that contains the function.
From *both* viewpoints, it is simpler to have pagination available in the
tty driver. This means that the implementors don't have to kludge it into
every program, and the users need neither lightning reflexes nor high
sophistication. Try it, you'll like it.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Guy Harris
> VTIME should never have been part of c_cc[] in the first place, so if they
> had converted it and made them seperate somewhere I'd hardly call it a
> botch.
If their system claims to be S3/S5 compatible, but doesn't permit you to set
VMIN and VTIME and get the *documented* behavior, it's broken. Period.
On the other hand, reading between the lines of what you're saying, it seems
you were able to take a V7 program on some S3 port and compile and run it,
*still using the V7 ioctls*. Fine. Lots of systems do that. However, this
does not mean you "don't have to fiddle with MIN and TIME" or whatever you
said. If you did TCGETA, turned off ICANON *but* didn't change MIN or TIME,
and did TCSETA, either your program would get surprising results or it's
running on a broken system. You didn't make it clear in your original
comments that this is what you'd done.
The fact that you tried doing the same "compile and go without changes" on
somebody else's S5 system, where the UNIX/TS compatibility had *not* been
replaced with V7 compatibility, says nothing about S3, S5, V7, or their
relative compatibility. It says something about the vendors' documentation
(they should have told people about the new tty driver) and about your
willingness to read documentation (you yourself admitted that you hadn't
*read* the documentation until recently).
> Peter da Silva (wondering why he's still flaming me over VMIN and VTIME).
Because it's *very* tiresome reading somebody making the same incorrect
statement over and over again. It's unfortunate that the vendor's
documentation, or somebody, didn't make the tty driver differences clear,
and that it wasn't made clear that S3 and S5 don't normally have a
V7-compatibility mode. However, the fact remains that 1) the drivers do
require you to do things differently, in general, 2) some systems support V7
compatibility, but not all, and 3) just because a V7 program worked on an S3
system which was modified to support V7 ioctls does NOT mean that if the
program doesn't work on an S5 system not so modified that a) S3 and S5 or
incompatible, b) you don't have to worry about MIN and TIME if you use the
S3/S5 ioctls or c) that the S5 which doesn't support the V7 ioctls is
"broken". It's fairly clear that you don't have a thorough understanding of
the differences between the TTY drivers. Could you please find a discussion
where you have something to contribute other than content-free flames?
Guy Harris
Mark Horton
>From *both* viewpoints, it is simpler to have pagination available in the
>tty driver. This means that the implementors don't have to kludge it into
>every program, and the users need neither lightning reflexes nor high
>sophistication. Try it, you'll like it.
We have page mode in our tty driver too. I agree that it's a win to have
page mode. However, in the specific case of the ls command, it's still
much better to have it come out in columns. It's really useful to be
able to see the entire directory at once, instead of having to look at it
in snippets of 24 lines.
Mark
Peter da Silva
> tty driver. This means that the implementors don't have to kludge it into
> every program, and the users need neither lightning reflexes nor high
> sophistication. Try it, you'll like it.
You mean like on TOPS-20? Where it seems the tty drivers use TERMCAP or an
equivalent (if you type more than 1 line & hit ^U it cursors to the beginning
of the input line (maybe several terminal lines above) and sends a CL sequence!
But back to the subject... I tried it. I didn't like it. It seems to be
difficult to tell what's a page and what isn't.
--
Peter da Silva (the mad Australian werewolf)
Peter da Silva
> comments that this is what you'd done.
What I did (for the last time) is take the program, look up "ioctl" and
"tty" in the appropriate sections of the manual, see that there were no
changes or surprises, and compile. The manual did NOT contain any refs
for termio in ioctl(2). Since the system is now SV, I can't check the
SV code to see if it works on the putative SIII system.
> The fact that you tried doing the same "compile and go without changes" on
> somebody else's S5 system, where the UNIX/TS compatibility had *not* been
> replaced with V7 compatibility, says nothing about S3, S5, V7, or their
> relative compatibility. It says something about the vendors' documentation
> (they should have told people about the new tty driver) and about your
> willingness to read documentation (you yourself admitted that you hadn't
> *read* the documentation until recently).
I hadn't read the SYSTEM V docs until about a week after I started porting
the program because I couldn't get them until them. That was several months
ago, so if that's how you define recently, fine. I was never unwilling to
read the docs, just unable to get them. The system I was working on and
the docs were (and still are) over 30 miles away, at the house of a person
with extremely exotic hours.
> > Peter da Silva (wondering why he's still flaming me over VMIN and VTIME).
>
> Because it's *very* tiresome reading somebody making the same incorrect
> statement over and over again.
Who are you talking about?
> It's unfortunate that the vendor's
> documentation, or somebody, didn't make the tty driver differences clear,
The standard Bell system V documentation didn't make it clear. Look at page
6 of the docs again.
> and that it wasn't made clear that S3 and S5 don't normally have a
> V7 compatibility mode.
It wasn't made clear that SIII was anything but V7 with SCCS. In afct the
system involved WASN'T anything but V7 with SCCS and a few other SIII
utilities. SV is a different matter. I made the comment the SIII and SV were
incompatible in one message. I apologised for the error and explained where
and why I made the mistake. u!Some time AFTERWARDS you flamed me about it.
Now I don't know whether that was network delay or you just not reading
messages from me directed explicitly at you or what, but if it wasn't
a case of network delay it was completely unjustified.
> require you to do things differently, in general, 2) some systems support V7
> compatibility, but not all, and 3) just because a V7 program worked on an S3
> system which was modified to support V7 ioctls does NOT mean that if the
You mean a V7 system modified to support the SIII utilities.
> program doesn't work on an S5 system not so modified that a) S3 and S5 or
> incompatible, b) you don't have to worry about MIN and TIME if you use the
> S3/S5 ioctls or c) that the S5 which doesn't support the V7 ioctls is
> "broken".
I never said it was. I said that SV broke the SIII ioctls. As far as I was
able to discern at the time it did. I'm not at a large corporation or Bell
where I can get the documentation on every system I might happen to be working
on (I'm an independant contractor, so I work on LOTS of machines) on short
notice. I still have not got access to the SIII docs.
NOT EVERYONE IN THE WORLD HAS ACCESS TO THE RESOURCES YOU DO!
I made a mistake. I apologised for it. I explained why I made it. I still
don't know why you found it necessary to badger me for it at a later date.
> It's fairly clear that you don't have a thorough understanding of
> the differences between the TTY drivers.
How thorough do you want? I don't have a copy of the sources at hand, nor
any of the ancilliary documents on the subject. I have the slightly obscure
and ambigious documentation that Bell supplied, and using this I have
managed to get several peices of screen-oriented software up on V7, 4.2,
kinky SIII, kinky V7, and SV. It has been my experience that most
implementations have differences in the drivers, but never had I run into
as great a difference as that between SV and all the other systems I had
used (with the exception of RSX :->). I have a problem remaining with
a host-side XMODEM program that core dumps on SV. It's heavily patched
code that includes stuff ported from MS-DOS and 4.2, as well as my own code.
It has worked efficiently up to now. I don't know what on SV crashes it,
and since the terminal driver is the biggest problem I have so far I
immediately suspected it. I'm still not sure there's not a problem there...
> Could you please find a discussion
> where you have something to contribute other than content-free flames?
>
> Guy Harris
Could you please discuss this without putting words into my mouth? Reply
to net.flame.
--
Peter (Made in Australia) da Silva
John Woods
> tty driver. This means that the implementors don't have to kludge it into
> every program, and the users need neither lightning reflexes nor high
> sophistication. Try it, you'll like it.
>
liked. I have seen a few that I liked less than typing ^S/^Q myself. The
advantage of not having pagination in the kernel is the ability to have
tailored paginators.
Although, the TRIX operating system (done at MIT) would allow the kernel
tty handler to call user code for pagination with as little (or as much)
trouble as switching to any other kernel thread... Perhaps we are at the
point where UNIX is retarding, rather than advancing, development of new
ideas.
> --
> Henry Spencer @ U of Toronto Zoology
> {allegra,ihnp4,linus,decvax}!utzoo!henry
>
Oh, Henry, Henry, Henry. And I thought you had such good taste. Version 6
didn't have pagination, after all. ;-)
--
John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101
...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit...@MIT-XX.ARPA
George Williams
> tty driver. This means that the implementors don't have to kludge it into
> every program, and the users need neither lightning reflexes nor high
> sophistication. Try it, you'll like it.
> --
> Henry Spencer @ U of Toronto Zoology
> {allegra,ihnp4,linus,decvax}!utzoo!henry
One problem with pagination in the tty driver:
At caltech we have a network that lives between most computers and
most terminals, now unfortunately the network uses ^S/^Q (of course)
and any ^S, ^Q you type on your terminal will go to the network
not to the computer. So putting pagination in the tty driver
really confuses novice users, the documentation says that pressing
^Q gets things started again, but it doesn't. Instead they have
to rummage arround, find the network documentation (which is not
written for novices) find that what they really want is ^P^Q.
I admit that I found this very useful when playing on a twenty
many years ago, but when I started using our network I discovered
that about half the lines I logged into had old processes hanging
arround that just needed a ^P^Q typed on them.
There must be a better soln. somewhere.
George Williams
cit-vax!aphasia!gww
the moon is nothing
But a circumambulating aphrodisia
Divinely subsidized to provoke the world
Into a rising birth-rate
Ian F. Darwin
>One problem with pagination in the tty driver:
> At caltech we have a network that lives between most computers and
> most terminals, now unfortunately the network uses ^S/^Q (of course)
> and any ^S, ^Q you type on your terminal will go to the network
> not to the computer. So putting pagination in the tty driver
> really confuses novice users, the documentation says that pressing
Please, let's not confuse one bad implementation of terminal
pagination with the good idea of terminal pagination. As has
been pointed out (by Henry & others) it is _possible_ to do
it right; our system does it moderately well _without_ relying
on ^S/^Q. We've tried it, and we like it.
Mark Horton
>One problem with pagination in the tty driver:
> At caltech we have a network that lives between most computers and
> most terminals, now unfortunately the network uses ^S/^Q (of course)
> and any ^S, ^Q you type on your terminal will go to the network
> not to the computer. So putting pagination in the tty driver
> really confuses novice users, the documentation says that pressing
> to rummage arround, find the network documentation (which is not
> written for novices) find that what they really want is ^P^Q.
There are many ways to implement page mode in the tty driver. In UNIX,
it turns out to be very convenient to put it right next to the xon/xoff
code, which does a similar thing. (This is the reason given by most of
the people who feel page mode should not be in the system, since xon/xoff
is implemented in each separate device driver rather than the tty driver
proper, you have to hack each new device driver to support page mode.
The same argument could be made that xon/xoff should not be supported by
the UNIX system either, but it's already there.)
If you do the quick-and-dirty page mode implementation, then typing ^Q
is one way to get it started again after you are at the bottom of a page.
However, this doesn't work well, if you have a terminal that uses xon/xoff
heavily, you may find the terminal sends the ^Q that lets it go on to the
next page when you weren't done reading the last one.
To do it properly, you have to present the interface that xon/xoff is a
flow control level used only by your terminal to keep its buffers from
overflowing. Page mode, on the other hand, is a user visible feature
which is different from xon/xoff. You use a different character (we
use space) to let it go another page. Typing ^Q at a stopped page doesn't
do anything, but then typing ^Q when the system is prompting you for
input doesn't do anything either - your terminal might have sent the ^Q.
The problem of users getting confused doesn't really happen, because
(and this is the beauty of page mode) the users never need to know
about ^S/^Q! Lunging for the ^S key to read something that's about
to go off the screen is not necessary, the system will stop automatically.
The users only need to know about the space bar, and since page mode is
set up so that ANY character (other than those eaten by the flow control
level) will wake it up, hung terminals never happen. (By convention,
the character typed is still passed through to the program reading from
the tty, except that a space typed while stopped in page mode is tossed.)
I have yet to have any of our users get confused, nor do I ever find a
terminal hung waiting for a space. And we have lots of users who are
new to the UNIX system here.
Mark