Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!
bloom-beacon!mit-eddie!uw-beaver!tektronix!orca!tekecs!frip!andrew
From: and...@frip.gwd.tek.com (Andrew Klossner)
Newsgroups: comp.unix.wizards
Subject: More notes from V.4.0 software developer conference (LONG)
Message-ID: <10421@tekecs.TEK.COM>
Date: 4 Oct 88 20:37:18 GMT
Sender: and...@tekecs.TEK.COM
Organization: Tektronix, Wilsonville, Oregon
Lines: 407
I attended the UNIX V.4.0 conference in Los Angeles. Herewith some
highlights from my trip report.
OVERALL IMPRESSIONS
UNIX V.4.0 really is all things to all people, and AT&T is working hard
to make it that way. If a program worked under V.3, or under Xenix, or
under SunOS, or under 4.3BSD, it will work here.
PHILOSOPHIES
The philosophy of the V.4.0 source tape is that it provides a "menu" of
software, and it's up to the OEM to select a subset (within the
constraints of the SVID). AT&T hopes that the market will narrow down
to a core set of features/utilities, so they can slough off the
remainder (e.g., they'd like to discard one of the three shells).
We found out what an "open system" is. An "open system" is a closed
system. Here's why: AT&T defines an open system to be the opposite of
a proprietary system. Proprietary systems come from one vendor and run
on one architecture. Open systems run on many architectures and are
supported by many vendors. The advantage of an open system is that an
application will run, without much modification, on each architecture.
Therefore it is important that the open system not be changed
significantly between architectures. Therefore an open system is
substantially closed to the OEM. This closure is expressed in the
language of the infamous UNIX V.3 license, which requires that any
derivation of V.3 conform to the System V Interface Definition (SVID),
a Levitican document.
However, the above notwithstanding, AT&T seems to be looking for
industry comment on several aspects of V.4.0 now, before it is cast in
concrete. In particular, they want comment on the draft ABI and on the
draft Open Look spec.
UNIX UNIFICATION
V.4 includes not quite all of 4.3BSD. Little things, like biff and
sendmail, are missing.
The porting base for V.4 will continue to be the 3B2. Presumably there
will also be a 386 source tape, as there is for V.3.2. No word on a
SPARC tape.
VIRTUAL MEMORY
V.3-style shared memory is discarded in favor of Berkeley/SunOS-style
shared memory. V.3-style shared memory calls are implemented with a
compatibility library. In addition, it will support mapped files, even
across the net.
FILE SYSTEMS AND I/O
V.4 will support both the Berkeley Fast File System, now called
"ufs," and the standard AT&T file system, called "s5." Ufs is the
default. Ufs has long filenames, s5 has the usual 14-character
filenames. All file systems now have symbolic links.
The Berkeley dump/restore programs are there but they work only on ufs.
Quotas work only on ufs.
A process can have up to 2048 files open. To exceed 64, the process
must call setrlimit to raise the "soft limit." Stdio supports up to
256 open files. Root can exceed 2048. File descriptors are "cheaper"
-- dynamically allocated/freed from kernel memory.
The buffer pool "has been re-architected." No details. But, since the
results of file I/O on mmap'ed files are immediately visible to the
mapping process, presumably paging still goes through the buffer pool.
The directory layout will look like that of SunOS. No more /bin.
DEVICES
All tty devices are Streams devices. Ptys are also Streams based.
There will be standard Stream modules to implement the favorite tty
line disciplines: "LDTERM" for V.3, something else for Berkeley "new
tty."
Pipes are implemented as Streams. Named pipes are implemented as named
Streams (a new feature). The names are in the file system space. They
seem to have repudiated the terrible V.3 philosophy of establishing an
independent name space for each new construct.
The poll system call (like Berkeley select) works on non-Streams file
descriptors. For character devices, this requires a mod to each
driver. They didn't explain just what poll does on files and
directories.
The "CONLD" Stream module creates a unique Stream on open. It's used
for pipes only. A client process could open a particular file and find
itself talking on a dedicated Stream to a server, a nice simple
mechanism.
SIGNALS
The system will support three different signal abstractions (!): the
V.3 one, the Berkeley one, and the POSIX one. AT&T recommends that new
code use the POSIX one; the other two are built on top of it.
SHELLS
Korn shell and C-shell will come standard on the tape, along with the
Bourne shell.
The kernel will be able to exec shell scripts which begin with "#!".
The setuid/setgid bits for such files will be ignored.
LANGUAGE SUPPORT AND DEBUGGERS
Any C compiler provided with V.4 must implement both ANSI C and some
AT&T-defined extensions. It must also be able to produce
position-independent code, because those libraries can be mapped to any
virtual address that the mapping process chooses.
An ELF (the new object file format) manipulation library will be
provided.
A process filesystem, /proc, is standard. The debuggers have been
reworked to use it instead of the ptrace system call, which will be
phased out.
Adb and gprof will be in the Berkeley compatibility package.
There will be no dbx. Sdb will be "enhanced."
Truss (an interesting debug tool) is standard.
LIBRARIES
Shared libraries are now dynamically-linked, to addresses chosen by the
main program. This means that shared libraries must use only
position-independent code, which means that the compiler must generate
PIC. Static libraries are still there but are being phased out.
"Message management" has been added. The user can select a format for
error messages by setting environment variables. If all components of
a message are turned on, the message can occupy several lines, and the
information can include who was running, what operation was attempted,
why it failed, and what the suggested fix is.
The message formatting facility is still open for "industry review."
It is part, but not all, of an effort to provide easy conversion of
applications to use foreign languages in messages, with the language
chosen dynamically.
Not all utilities in V.4.0 will be converted to use it.
REAL-TIME SUPPORT
Real-time support is as follows: kernel code that contributes to long
latencies has been filled with preemption points. At each such point,
the kernel checks to see if a real-time event needs to be handled, and,
if so, the current process goes to sleep and the scheduler is called to
start the process that gets the event.
NETWORKING
There is full socket support, including UNIX-domain sockets.
Sockets are implemented on top of Streams. They are a peer to TLI
(transport level interface), they are not on top of TLI.
r* (rlogin, rsh, etc) commands are still built with sockets.
TCP/UDP/IP is the only transport provider on the V.4.0 tape. No OSI
code yet.
V.4.0 includes SMTP.
"Mail has been completely re-architected."
DES authentication cannot be removed from RPC. They claim "there is an
export license."
YP (NFS yellow pages) is considered deficient and will be revised after
V.4.0.
There is a new network line printer spooling mechanism, an extension of
the V.3 "lp" package.
"RFS and NFS are complementary." The philosophy is that NFS is for
heterogenous file sharing (talking to MSDOS and Cray computers), and
RFS is for intra-UNIX machines when full file system semantics are
needed (including talking to remote devices). They said all this with
a perfectly straight face.
RFS communicants must have the same byte-order, alignment, etc. in
order to use remote devices.
RFS symlinks are interpreted local to the client, just as NFS symlinks
are. This is "being discussed." (The now-obsolete Tektronix network
file system interprets symlinks local to the host, and our customers
are giving us grief about the "new" NFS semantics.)
Diskless node support is said to be easy to do, although it doesn't
come already done on the V.4.0 tape. It uses TFTP, reverse-ARP, and
NFS.
RFS allows UID mapping. NFS doesn't, except for root.
Both NFS and RFS can be used to page across the net.
Any file system node can be mounted. For example, you could mount
remote:/bin even if /bin is not a separate file system on remote.
CHARACTER WINDOW SYSTEMS
Curses has been extended; it can now deal with colors. However, it
cannot deal with SIGWINCH. It was implied that vi would not deal with
SIGWINCH, but that's counter-intuitive since the Berkeley version does
(and doesn't rely on curses).
ETI, the "extended terminal interface," is a window toolkit for
character ttys. It's built on top of curses, but allows for
overlapping windows, sort of.
FMLI, the "Form and Menu Language Interpreter," is an interpreted
language in which character tty windowing programs are written. It has
a standard look&feel, that isn't anything like Open Look. It's built
on top of curses. The language design itself is hideously bad,
reminiscent of IBM JCL.
The new sysadm (system administration) is written in FMLI, so it uses
curses and menus etc. (The V.3 sysadm assumed a dumb tty.)
FACE, the "Framed Access Command Environment," is ... well, I'm not
sure what it is. It might be a windowed shell for character ttys.
It's built on top of either ETI or FMLI.
GRAPHICAL WINDOW SYSTEMS
The Open Look Graphical User Interface is a document, not software.
There will be software to implement it, but it's the document that
they're pushing right now.
The Open Look window "shine mark" was inspired by cartoonists.
Open Look windows seem to waste a lot of precious screen space: title,
header, footer, extra border past the scrollbar. Yech.
To direct keyboard input to a different window, it is necessary both to
mouse to the window and to click a mouse button. (Under X, the button
click is not needed.) There were hints that this might be true only
under the NeWS implementation of Open Look.
In an Open Look window, selected text does not include white space past
EOL. In X's xterm, it does. I prefer xterm's design.
Inaccessible menu items don't appear at all. In the xterm/Macintosh
model, they appear but in halftone (gray letters instead of black). I
find the Macintosh approach a lot less confusing; it saves the naive
user from hunting about for the menu item that "I know is there
somewhere."
Exclusive/non-exclusive items are not well differentiated. Exclusive
items are those from which exactly one can be selected (e.g.,
bold/italic/normal font). Non-exclusive items are independent (e.g.,
jump scroll/reverse video/autowrap). Exclusive items appear in
contiguous horizontal boxes; non-exclusive items are in boxes separated
by a bit of white space. The currently-selected item is displayed in
boldface.
The whole notion of separating menu items with horizontal instead of
vertical distance I found ugly. Sigh.
Scrolling warps the cursor. This is awful -- you should never warp the
cursor!
On the plus side, "notice" windows are great. If you select a menu
button which causes the system to request confirmation (e.g., deleting a
write-locked file), a notice window "grows" out of the screen from that
button:
+--------+
|warning |\
|file is |\
|r/o | \
+--------+ \
\ \
\ \
(It looks much better than this poor pictorial attempt.) The
perspective lines converge at the menu button which gave rise to the
notice, so the user knows why the notice happened.
Another good design feature is the built-in help function that assists
the user in learning about Open Look. To request information about a
feature, you designate a widget (e.g., the scrollbar), and the help
screen includes an image of a window with a magnifying class over that
widget to let you know what it's describing. Very intuitive.
And everybody likes the push-pin widget (used to keep a menu window
from disappearing).
V.4 includes a window manager (which manages both X and NeWS windows),
an X terminal emulator, a NeWS terminal emulator, and a desktop (but
they're not sure if the desktop code is on the tape). None of this
stuff seems very far along. The prototype software they showed us, a
text editor, was apparently hacked together on top of an existing
window package. This is GOOD, of course; you want to get experience
with a new look&feel before committing to a lot of software
development. It was interesting that, when someone asked the presenter
how the prototype had been written, his only answer was that it didn't
matter, all he wanted to discuss was the look&feel. He refused to give
prototype implementation details.
They don't know or haven't decided whether Open Look widgets will be
donated to MIT for addition to the X software base.
The NeWS application level supports object-oriented programming in C++.
They don't know whether any GKS or Phigs support will be done, which
means it probably won't.
ABI (APPLICATION BINARY INTERFACE)
There is no plan to make an ABI for the 3B2 (the WE32000 architecture).
The only standard media for application packaging defined in the ABI
are 3.5" floppy and 120M cartridge tape. It was noted that neither of
these are available on the 3B2 series. This is generic, not
architecture-specific: these two devices will be the only choice for
all ABIs. They are "looking for industry comment" on this.
The system interface routine library *must* be dynamically linked; the
method by which the syscall library routines call the kernel is NOT
specified by the ABI and may be changed by the OEM.
AT&T is focusing now on the generic portion of the ABI, getting it
"right."
V.4.0 has Extended Fundamental Types (EFT). Type widths will be
architecture-specific, i.e., it's up to the architecture-specific
portion of each ABI whether that architecture will have EFT.
LICENSING ISSUES
[The license expert missed his plane, so a non-expert handwaved his way
through this presentation.]
A UNIX-tm must be a derivative of V.3.2. You can cobble up something
that conforms to the SVID without using UNIX code (and without having
to pay UNIX license fees), but to make something that's eligible for
the UNIX trademark, you have to start with genuine UNIX.
A UNIX-tm must conform to (as yet unspecified) quality standards.
Perhaps auditing procedures.
The status of machine-readable man pages is "in dispute."
Any UNIX license questions should be directed to (800) 828-UNIX.
BIBLIOGRAPHY
They sent home enough documentation that the handle broke off my
suitcase. This included all the overhead slides, and, with each slide,
up to a page of explanatory text. Outstanding!
The Software Developer Conferences, Volume 1:
-- The Worldwide Open Industry Standard (why open software is good)
-- Basic Operating System Services (files, VM, etc)
-- Applications Development Environment (C language and software
generation system changes)
-- Networking
The Software Developer Conferences, Volume 2:
-- User Interfaces (both character and graphic)
-- Enhanced System Administration
-- Application Binary Interfaces (discussion of)
-- Continued Commitment to Open Standards -- Future Plans
-- Licensing
-- Glossary and Index
-- Further Information: available manuals and courses; speaker
bibliographies
A copy of the SVID, edition 2 (describes V.3). A draft of edition 3,
which describes V.4, will be distributed eventually for industry
comment.
OPEN LOOK X User Environment Application Programmer's Interface --
everything the X programmer needs to use the (not yet available) Open
Look X toolkit. 100 pages.
OPEN LOOK (tm) Graphical User Interface Functional Specification, dated
July 15, 1988. About 150 pages.
AT&T Character User Interface Style Guide -- discusses ETI, FMLI, FACE,
other aspects of character-tty windowing software. About 100 pages.
System V Application Binary Interface (ABI): Draft for Industry Review,
dated August 31, 1988. The cover letter says that industry comments
must be in by Halloween. About 200 pages.
"Migration Reference Guides" for SunOS (20 pages), XENIX (50 pages),
and UNIX V.3 (100 pages). To be used by an application developer
coming from one of those environments into V.4; it addresses
porting/transition questions. Another such guide is promised for
Berkeley.
Software Developer Conference Bulletin Board System. They've
established a bulletin board system in New Jersey with a 1200 baud
line, to be used for getting information about and asking questions
about V.4.0. [Don't ask me for access details, I don't believe I'm
allowed to divulge this ... go to a conference or call AT&T directly.]
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek....@relay.cs.net) [ARPA]
Newsgroups: comp.unix.wizards
Path: utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Subject: Re: More notes from V.4.0 software developer conference (LONG)
Message-ID: <1988Oct6.183106.1110@utzoo.uucp>
Organization: U of Toronto Zoology
References: <10421@tekecs.TEK.COM>
Date: Thu, 6 Oct 88 18:31:06 GMT
In article <10...@tekecs.TEK.COM> and...@frip.gwd.tek.com (Andrew Klossner) writes:
>The philosophy of the V.4.0 source tape is that it provides a "menu" of
>software, and it's up to the OEM to select a subset (within the
>constraints of the SVID). AT&T hopes that the market will narrow down
>to a core set of features/utilities, so they can slough off the
>remainder (e.g., they'd like to discard one of the three shells).
I trust everyone got a good laugh out of this. The way to discard one
of the three shells is to discard it, now. Same thing for the other stuff:
there will always be some diehard fraction of the user community that
really wants feature X to stay around. Cleaning things up requires
biting the bullet and making such people unhappy, not postponing the
issue in hopes that they will go away. The problem will only get worse
if all the alternatives are "officially supported".
--
The meek can have the Earth; | Henry Spencer at U of Toronto Zoology
the rest of us have other plans.|uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Path: utzoo!attcan!uunet!husc6!bloom-beacon!gatech!ulysses!cjc
From: c...@ulysses.homer.nj.att.com (Chris Calabrese[rs])
Newsgroups: comp.unix.wizards
Subject: Re: More notes from V.4.0 software developer conference (LONG)
Message-ID: <10707@ulysses.homer.nj.att.com>
Date: 7 Oct 88 21:06:46 GMT
References: <10421@tekecs.TEK.COM> <1988Oct6.183106.1110@utzoo.uucp>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 23
In article <1988Oct6.183106.1...@utzoo.uucp>, he...@utzoo.uucp (Henry Spencer) writes:
> In article <10...@tekecs.TEK.COM> and...@frip.gwd.tek.com (Andrew Klossner) writes:
> > [...]
>
> I trust everyone got a good laugh out of this. The way to discard one
> of the three shells is to discard it, now. Same thing for the other stuff:
I heartily agree. The obvious solution (in my mind) is to
'ln /bin/ksh /bin/sh'. Since ksh will work (almost) exactly like
sh (most of the differences being bugs in sh)
without the various environment variables which turn on history, etc.
defined, there is no reason not to do this.
The only problem I can think of off the top of my head is the
behavior of 'echo \c'.
BTW, we did this a long time ago around here, and I have done
so on my own personal machine.
--
--------
Christopher J. Calabrese
AT&T Bell Laboratories
ulysses!cjc
Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!ulysses!
hector!ekrell
From: ekr...@hector.UUCP (Eduardo Krell)
Newsgroups: comp.unix.wizards
Subject: Re: More notes from V.4.0 software developer conference (LONG)
Message-ID: <10709@ulysses.homer.nj.att.com>
Date: 8 Oct 88 14:07:27 GMT
References: <10421@tekecs.TEK.COM> <1988Oct6.183106.1110@utzoo.uucp>
<10707@ulysses.homer.nj.att.com>
Sender: netn...@ulysses.homer.nj.att.com
Reply-To: ekr...@hector.UUCP (Eduardo Krell)
Organization: AT&T Bell Laboratories
Lines: 12
In article <10...@ulysses.homer.nj.att.com> c...@ulysses.homer.nj.att.com
(Chris Calabrese[rs]) writes:
>The only problem I can think of off the top of my head is the
>behavior of 'echo \c'.
This is something that can be controlled at compile time. The default
action is that you get ksh's echo to be the same as /bin/echo or
/usr/5bin/echo, depending on which comes first in your PATH.
Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ
UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekr...@ulysses.att.com