Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site unisoft.UUCP
Path: utzoo!watmath!clyde!floyd!harpo!decvax!ucbvax!ucbtopaz!unisoft!phil
From: phil@unisoft.UUCP
Newsgroups: net.jokes
Subject: 4.3 BSD
Message-ID: <247@unisoft.UUCP>
Date: Thu, 5-Apr-84 17:00:22 EST
Article-I.D.: unisoft.247
Posted: Thu Apr  5 17:00:22 1984
Date-Received: Sat, 7-Apr-84 04:25:52 EST
References: <6750@decwrl.UUCP>
Organization: UniSoft Corp., Berkeley
Lines: 63

---------------------------------------------------------------------------
In the spirit of the progression of 4.2 from 4.1, I would like to
help the folks at UCB with the following suggestions for BSD 4.3.

I realize, of
course, that these are obvious and have probably been thought of,
but they should elicit some further (?) ideas from (?).



16,384 character file names.

Selectable directory hierarchy character. (Why always have to use '/' ?)

Implementation of /bin/* into the kernel (except, maybe, more(1) as
being too obvious)

Implementation of record and block sizes for files. Record types would be
real nice too. I MISS variable length, unblocked spanned records (with ASA
control characters).

More upper case TTY driver support. Enhanced 3270 screen mapping software,
with maybe a vt100 emulation (implemented in the shell??).

MS/DOS file system compatibility. Should require only a few bits in the inode.

Implementation of the ``filename'' in the inode itself. Why UCB did not think
of this earlier is a major mystery to me. The savings in the elimination of
all those directory searches (I mean, one file per level, come on now!) alone
makes this a winner. Of course, this may impact 16K filenames, but probably
won't be noticed if RECSIZ and BLKSIZ are added.

Coagulation of the hordes of utilities such as cp, mv, ln, more, lpr,
wc, sort, rm into one really useful utility. This will pay for the effort
of doing it by all the man hours saved searching for just that RIGHT
manual page. Should cut down on maintanance, too. I.e., pip(1) ?????

Expansion of the open system call with extra arguments to handle the
device drivers better. It's a real pain to try to remember the correct
filename for mag tape (rewind, 1600 bpi, etc.). Even better, a new
system call, device_open(a,b,c,d,e,f,g,...). Then UNIX can properly
support ``write backwards with reduced IRG'' properly, once and for all.

Real batch processing. Even you have to admit that this is where IBM
MVS/XA/PFU has it all over UNIX. This would allow proper utilization
of expensive machine resources. When some of our customers machines
cost 8, 9, even 15 thousand dollars, one can appreciate the value of
fully utilizing it. Although there may a slight, (psychological ??)
perception of system degradation, implemention of block mode SNA
terminal support and/or off hours interactive access should remedy this.

Proper language support. C is fine, of course, but to broaden the use of
UNIX, we need a language that both the real old time hackers, and the
general DP community is familar with. To ensure the proper UNIX commitment,
the kernel should be re-written in it. Just a few, time critical parts,
at first of course. We simply must have a proper language. FORTRAN. (II or IV).

Conversion of all lower case usage to upper case. There are 1000's of UC
devices out there -- how else can I print UNIX source on my 2780???


I welcome your further suggestions.
---------------------------------------------------------------------------