[comp.unix.wizards] New

ml@gandalf.UUCP (Marcus Leech) (05/30/89)

There has been some discussion lately about "what you'd like to see in the
  GNU kernel".  Here's what I'd like to see in "the next great version of
  UNIX"--GNU or otherwise. It's kinda long--hit 'n' now if this sort of thing
  bores you.


    There are several areas that I'd like to see addressed.

User-interface:
    Make a sweep of all the commands in the system and decide on a consistent
 command-line options scheme that has the following attributes.  Options should
 be case insensitive.  Options that perform the same function in different
 commands should have the same names.  Options should be complete words, with
 a minimum-unambiguous scheme to reduce typing. Getopt() is certainly a
 reasonable starting point for this sort of thing.  Commands should all use
 perror(), wherever possible.  Commands should print a useful Usage: message
 when they are handed something they don't understand--"Huh?" just doesn't
 cut it.  In general, the messages coming out of programs should walk that
 fine-line between brevity, and useful information content.
 Interactive subsystems (editors, mailers, etc) should follow the
 same rules as for non-interactive commands, wherever possible.  Interactive
 subsystems should always provide a decent "help" facility.

Documentation:
  The online help should be better.  Either an entirely new facility needs to
  be added, or MAN needs to have better indexing.  The MANuals should be
  swept for inconsistencies between what they state, and reality.  There needs
  to be a better index.  The one-line command summary that is used in the
  permuted index doesn't seem to provide enough information when you don't
  know exactly what you're looking for.  There needs to be more tutorial-style
  documentation, particularly in the area of system management.

Management/Administration:
  There need to more and higher-quality tools for the management and
  administration of systems.  The system needs to be better instrumented to
  support this kind of thing.  [I'd hate to say this, but one of the distinct
  advantages of VMS over UNIX is it's substantially better instrumentation].
  It ought to be trivial, for example, to discover who has what files
  open (by name);  UNIX currently provides no such facility (or an only
  partially functional facility).

Kernel:
  Whatever mods are required to support any of the above-mentioned stuff.
  Restrict filenames to alphabetics,numbers,and punctuation, keeping in
  mind national character sets.  The basic notion is that it ought to be
  impossible to create a filename you can't trivially remove/display.  I'd
  further distance the I/O system (drivers, etc) from the main part of the
  kernel, mostly for robustness--it ought to be difficult for a malfunctioning
  piece of non-critical hardware to take the system down or wedge a user
  process.  I'd make device drivers dynamically loadable.  I'd re-arrange
  the kernel so that more of it is dynamically tunable, and provide an
  interface to inspect and modify dynamically-tunable kernel parameters.
  I'd make a sweep of the I/O system to generalize non-blocking I/O, and
  make sure it WORKS in all the places you'd expect it to work.  I'd probably
  make select() available.  I'd probably make shared-memory available, but
  I'm not sure how wonderful the shm*() calls are.  TCP/IP networking is a
  must--it should be tunable at run-time (I'd like to see the KA9Q code in
  the kernel, with some performance enhancements).  I'd probably modernize
  the overall kernel structure.  I'd generalize the filesystem code to make
  it trivial to support all kinds of filesystems (a la the filesystem switch).
  It ought to be possible, for example, to mount an ANSI-labelled tape, and
  have it appear as a collection of files on a mount-point; restrictions would
  obviously apply.  Security should be improved by reducing the "granularity"
  of priviledge.  That is, priviledged operations currently all require that
  you are "root".  Perhaps there ought to be VMS-style privilege bits, or
  perhaps just a reorganization of the kernel to allow various UIDs with
  increasing levels of privilege.  VMS has too many privilege bits, UNIX has
  too few.  There ought to be shared-libraries--they save disk-space, if
  nothing else.  The number of "panic" conditions should be reduced--if
  a situation can economically be recovered from without crashing the system,
  it should be recovered from.  When a I/O error occurs during swap,
  for example, the bad-blocks should be marked, and the affected process
  terminated.

Miscellaneous other stuff:
  The current TTY driver should be trashed and re-written.  It almost certainly
  qualifies as the most over-worked piece of code in the system.  The notion
  of CLISTs should certainly be re-visited, and probably abandoned.  The driver
  should have hooks to support windowing systems easily.  Flow control should
  be bullet-proofed (in particular, TANDEM should work properly in both
  RAW and COOKED modes).  I like the VMS-style echo-at-read-time echoing.
  It should probably be a configurable option.  The tty-driver needs the
  following characters (configurable, of course):
    - Kill line
    - Kill character
    - Re-display current input line
    - Flush type-ahead
    - History-next
    - History-previous
  The "History" characters should do something (post an interrupt?) that
  causes the current command interpreter to place appropriate history into
  the tty driver input buffer. Some other mechanism may suggest itself.
  The filesystem layout should be redone to reduce complexity and confusion
  Currently, there are executable files sprayed all over the filesystem
  with no or very little reasonable justification. It ought to be easier to
  find stuff when you go looking for it.  There ought to be a "resource"
  allocator that is responsible for allocating peripherals to users.
  The current ad-hoc schemes used by cu and uucp, for example, should be
  changed to use the "resource allocator".  Modems,tapedrives, and special-
  purpose output devices come to mind as objects that could reasonably be
  under the control of a "resource allocator".


Just in case anyone is under the impression that I'm a VMS-lover, I'd like to
  say that in general I detest it.  There are specific ideas in VMS
  that I think UNIX could adopt without suffering significant conceptual
  damage.
-- 
"Better Living through modern chemistry" PaperMail: 130 Colonnade Rd, Nepean,ON
Marcus Leech                             E-mail:     ml@gandalf.UUCP
Gandalf Data Ltd                         PacketRadio: VE3MDL@VE3JF
"The opinions expressed herein are solely my own" So there

arosen@hawk.ulowell.edu (MFHorn) (05/31/89)

In article <2501@gandalf.UUCP> ml@gandalf.UUCP (Marcus Leech) writes:
>Kernel:
>  Security should be improved by reducing the "granularity"
>  of priviledge.  That is, priviledged operations currently all require that
>  you are "root".  Perhaps there ought to be VMS-style privilege bits, or
>  perhaps just a reorganization of the kernel to allow various UIDs with
>  increasing levels of privilege.  VMS has too many privilege bits, UNIX has
>  too few.

VMS' problem isn't too many privilege bits, but that administrators make
too many accounts privileged.  I think having multiple privileged accounts
lowers security.  We have a large VAX with lots of accounts.  20 of them
have privileges in the ALL category.  I've got 20 username/password pairs
to attack.  Unix systems have 1 such pair.

A few months ago I put together a spec to implement privileges in Unix.
One of the design goals was to keep uid 0 from being magic.  I still wouldn't
recommend making any more than 1 account fully privileged.  The idea of the
privileges was to isolate all the privileged functions an administrator
performs, so that more accurate and controlled logging can be done.

(I can send anyone the spec who wants it.  Some day, I might even get the
resources to implement it ;-)

--
Andy Rosen           | arosen@hawk.ulowell.edu | "I got this guitar and I
ULowell, Box #3031   | ulowell!arosen          |  learned how to make it
Lowell, Ma 01854     |                         |  talk" -Thunder Road
		RD in '88 - The way it should've been

guy@auspex.auspex.com (Guy Harris) (06/01/89)

>  It ought to be trivial, for example, to discover who has what files
>  open (by name);  UNIX currently provides no such facility (or an only
>  partially functional facility).

What do you mean "by name"?  Does "name" mean the name of the open file,
or the name of the "who" (which means a process) that has the file open?
The former isn't quite as easy as you seem to think....

>  Whatever mods are required to support any of the above-mentioned stuff.
>  Restrict filenames to alphabetics,numbers,and punctuation, keeping in
>  mind national character sets.  The basic notion is that it ought to be
>  impossible to create a filename you can't trivially remove/display.

I hope "punctuation" includes blanks; maybe the UNIX shells make it
inconvenient to remove such files (but not *too* hard), but not
everybody necessarily uses them.

Furthermore, some "national character sets" include characters that are
neither alphabetics, numbers, nor punctuation (can you say "Kanji"?).

>  The tty-driver needs the following characters (configurable, of
>  course):

I'd just trash most of the "user interface" features of the tty driver
completely, and have people run their choice of user-mode front ends
instead; cf. EMACS windows, the "ile" editor or whatever, etc..  This
means you don't have to teach the "tty driver" about history, or line
editing, or termcap/terminfo, or....

peter@ficc.uu.net (Peter da Silva) (06/01/89)

In article <2501@gandalf.UUCP>, ml@gandalf.UUCP (Marcus Leech) writes:
>  Options that perform the same function in different
>  commands should have the same names.

Within reason. -v should always be verbose, say.

>  Options should be complete words,

No, I think not. We still want to run UNIX shell scripts.

>  Commands should all use perror(), wherever possible.

Damn straight. I'm amazed AT&T hasn't taken a summer hire and just had them
go through the sources and fix this. It wouldn't take more than a couple of
months.

>  In general, the messages coming out of programs should walk that
>  fine-line between brevity, and useful information content.

Also the output of a program should, whenever possible, also be acceptable
as input. env(1), for example, should properly quote arguments. stty(1) should
dump the semicolons and the verbose 'speed 9600' stuff unless it's willing
to accept it as input. Stty -g isn't a solution to the problem... what if
you want to cut and paste? Windowing environments are becoming more common
and this would make the command more window-friendly.

>   Restrict filenames to alphabetics,numbers,and punctuation, keeping in
>   mind national character sets.

What do you mean by this? What's an example of a filename that isn't made
of alphabetics, numbers, and punctuation? What's wrong with a file called
"Error Log 23 Jan 1989"?

>   I'd make a sweep of the I/O system to generalize non-blocking I/O, and
>   make sure it WORKS in all the places you'd expect it to work.  I'd probably
>   make select() available.

I'd hope for something more general than select().

>   I'm not sure how wonderful the shm*() calls are.  TCP/IP networking is a
>   must--it should be tunable at run-time (I'd like to see the KA9Q code in
>   the kernel, with some performance enhancements).

This doesn't make sense when taken together with your call to remove I/O
from the kernel.

>     - History-next
>     - History-previous
>   The "History" characters should do something (post an interrupt?) that
>   causes the current command interpreter to place appropriate history into
>   the tty driver input buffer.

No, they should pull the next or previous lines from a circular buffer in
the driver. If you're going to duplicate the history mechanism in all
your programs you might as well just take the history code from ksh and
put it in a library.

>   The current ad-hoc schemes used by cu and uucp, for example, should be
>   changed to use the "resource allocator".

Actually, we find that LCK files work just fine for allocating all sorts
of resources.
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.

Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.

gwyn@smoke.BRL.MIL (Doug Gwyn) (06/01/89)

In article <2501@gandalf.UUCP> ml@gandalf.UUCP (Marcus Leech) writes:
> Options should be case insensitive.

Why?  Nothing else in UNIX is.  It isn't even clear how to perform
case mapping in some locales, although presumably option letters
(not their arguments) would be parsed in the "C" locale for which
it is clear.

I like to use upper-case option letters for local extensions to
standard utilities, on the theory that they won't conflict with
future versions of the utility as the vendor adds options.  ("ls"
is an obvious exception; it already has more than 26 standard
options.)

> Options should be complete words, with a minimum-unambiguous scheme ...

I think there is a fundamental misconception here, namely that the
Bourne shell-based software developer interface to UNIX can be made
appropriate for general users through small changes like this one.
I don't think general users should be subjected to an environment
that makes such demands on their understanding of so many system-
related concepts.  Far better to provide them with menus, icons,
etc. plus instructions on how to enter the developer environment
when they have a real need to do so.  (Most users should never need
to do so.)

>  Restrict filenames to alphabetics,numbers,and punctuation, keeping in
>  mind national character sets.

Which means that you cannot restrict the directory entry names,
beyond outlawing / and NUL (and it's a shame to have to outlaw those).

>  The notion of CLISTs should certainly be re-visited, and probably abandoned.

In favor of something like streams.

>    - History-next
>    - History-previous
>  The "History" characters should do something (post an interrupt?) that
>  causes the current command interpreter to place appropriate history into
>  the tty driver input buffer. Some other mechanism may suggest itself.

We already have far more useful forms of command history available via
various shells (tcsh, BRL sh, ksh, etc.) and terminal facilities (mux, etc.).

>  There ought to be a "resource" allocator that is responsible for allocating
>  peripherals to users.

Yes, and this can be done entirely in user mode.  If anyone actually starts
such a project, contact me for design notes I have sitting around.

A "terminal" allocator would be exceedingly helpful, especially for pty and
window management.  The terminal manager would have a more specific role
than, say, a magtape device allocator, in that it would keep utmp updated
(or the equivalent), slip appropriate modules onto the initial stream, etc.

bzs@bu-cs.BU.EDU (Barry Shein) (06/01/89)

The problem with VMS's privilege bits is that it's just a grab-bag of
privileges roughly modeled on the system resource categories, but not
what you might do with access to them. It seems to have basically
accreted over time with only a little thought to how they might be
used. The result is that the privilege required to do something
reasonable (like create a global mailbox for IPC programming) often
gives you the ability to do something non-obvious and damaging.

And it's the non-obvious and damaging part that often leads systems
admins down the garden path.

See, the model is based on resources, not the power access to those
privileges (resources) grants.

Unix, on the other hand, has basically no model for privileges. All
you can do is grant the rights of another user or group with little
information on what that might imply. I've seen new users write setuid
shell scripts to allow a friend the right to put files into his/her
directory tree. They understand what the problem with this is when you
explain it to them but rarely seem to come up with this prudence on
their own.

It's a problem waiting for yet another solution (model). Even as we
retreat to personal computing environs we simply off-put the access
problems to network resources. This one requires hard thought.
-- 
	-Barry Shein

Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202

mb@everex.UUCP ( OS Group) (06/01/89)

In article <2501@gandalf.UUCP> ml@gandalf.UUCP (Marcus Leech) writes:
>
>There has been some discussion lately about "what you'd like to see in the
>  GNU kernel".  Here's what I'd like to see in "the next great version of
>  UNIX"--GNU or otherwise. It's kinda long--hit 'n' now if this sort of thing
>  bores you.
>    There are several areas that I'd like to see addressed.
[Stuff delete about UI's, Documentation and adminstration]
>Kernel:
>  Whatever mods are required to support any of the above-mentioned stuff.
>  Restrict filenames to alphabetics,numbers,and punctuation, keeping in
>  mind national character sets.
I don't agree. There needs to be a way to represent language symbols as
found in Oriental langauges and other such like languages. Remeber that these
languages contants a couple hunderd to a couple thousand or  more symbols
and which are represented by 16-bit characters. Currently the only way
to do this is to allow the full range of possibilities with 8-bits/16-bit
characters.
(Is there a better way?)

>  			....				I'd re-arrange
>  the kernel so that more of it is dynamically tunable, and provide an
>  interface to inspect and modify dynamically-tunable kernel parameters.
>  I'd make a sweep of the I/O system to generalize non-blocking I/O, and
>  make sure it WORKS in all the places you'd expect it to work.  I'd probably
>  make select() available.
I'd like to see  system calls that work in async. You could start up multiple
requests and then wait on selected events or system call to occur/complete.
I believe this is already done in several Unix variants. This would work
well with multi/parallel systems and could provided a good base for real time
support. As far as select() goes, I'd prefer poll() - it's slighty more
dynamic.

>Miscellaneous other stuff:
>  The current TTY driver should be trashed and re-written.  It almost certainly
>  qualifies as the most over-worked piece of code in the system.  The notion
>  of CLISTs should certainly be re-visited, and probably abandoned.  The driver
>  should have hooks to support windowing systems easily.  Flow control should
>  be bullet-proofed (in particular, TANDEM should work properly in both
>  RAW and COOKED modes).
This should have happened ALONG ago. System V could have done a really good
job, since AT&T decided go with a thing called termio but it really didn't
turn out to be anything special. A process should have greater control
over hardware functions (i.e. such as notification when various hardware
line get assert/deasserted). Also have some type of permissions associated
with setting of the line (i.e. have the ablility to restrict certain processes
from issuing 'harmful' ioctl's.)

I think something simular to the Stream Driver for the networking and/or
tty drivers would work well. Since under the concept you can "push" and
"pop" various drivers on to the stream allow for a array of processing
to occur on the data before it's received  by the  user process and 
hardware driver. What would be great is that if you could "push" and "pop"
a User Process on to the stream.

In a filesystem I would like to see better security and auditing. CDC in
their NOS operating system came up with a great (or did they adopt it?)
system call/command called PERMIT. This allows you to "permit" a file to a
selected user with various permissions. Also, the other things that this
OS had was that you can place a file into "semi-private" status and
the system would log each time a process opened the file.

Signals is another thing that should go, or should be rewritten. There
should be a way to "queue" multiple occurances of the same signal to a
process *AND* a way to find out WHERE IT CAME FROM and WHEN IT OCCURED!!!

Process RECOVERY is a must. It seems that almost every
operating system except UNIX has this. There have been thousands of times
I've been logged into a system via modem and have gotten dropped and lossed
everything that I was working on. (Maybe some like a Session Group assigned
per login, Process groups would be a subset of it thus the OS could suspend
a Session Group which would include your background tasks that are running
under different process groups)

I feel that the first few release of the OS should include binary
compability for the machines it will be ported to. Also, some sort
of emulation package/library should be included for those programs
which conform to various "standards" (i.e. POSIX/SVID/SysVR4, etc).

-- 
-------------------------------------------------------------------------------
Mike Burg Everex Systems Inc. 10525 Humbolt Street Los Alamitos, CA 90720
E-Mail: uunet!zardoz!everex!mb	Voice: (213) 493-3749

dsill@relay.nswc.navy.mil (06/01/89)

>From: Marcus Leech <ml@gandalf.uucp>
>
> Options should be complete words, with a minimum-unambiguous scheme
> to reduce typing.

I'd prefer Twenex COMND JSYS style help/completion, which, for those
not familiar with it, allows partially-typed commands and options to
be completed, as long as they're unique, by pressing a single key.
Another key lists possible completions.  I've used systems that allow
(necessitate) abbreviations (VMS, MS-DOS, AmigaDOS), provide command
completion (TOPS, Emacs, tcsh), and a couple that do neither (sh,
csh).  I much prefer completion to abbreviation because completion
provides feedback, preventing me from typing a long complicated
command only to discover one or more ambiguous abbreviations.  With
completion, I'm much more confident that that the command will work
right the first time.

> Commands should all use perror(), wherever possible.

I'd take it a step further and implement VMS-style configurable error
messages.  Let the user decide whether his error messages include the
gory details, only the text of the message, or anything in between.

>  The online help should be better.  Either an entirely new facility needs to
>  be added, or MAN needs to have better indexing.

This is already taken care of.  GNU will use the same TeX/Info format
for documentation that Emacs uses.  Last I heard, a stand-alone Info
browser was Almost Finished.  For the unfamiliar, this format allows
hardcopy manuals, using TeX, and on-line, tree-structured
documentation to be produced from a single file.

-Dave (dsill@relay.nswc.navy.mil)

rk@lexicon.com (Bob Kukura) (06/02/89)

In article <19834@adm.BRL.MIL> dsill@relay.nswc.navy.mil writes:

> >From: Marcus Leech <ml@gandalf.uucp>
> >
> > Options should be complete words, with a minimum-unambiguous scheme
> > to reduce typing.
> 
> I'd prefer Twenex COMND JSYS style help/completion, which, for those
> not familiar with it, allows partially-typed commands and options to
> be completed, as long as they're unique, by pressing a single key.
> Another key lists possible completions.  I've used systems that allow
> (necessitate) abbreviations (VMS, MS-DOS, AmigaDOS), provide command
> completion (TOPS, Emacs, tcsh), and a couple that do neither (sh,
> csh).  I much prefer completion to abbreviation because completion
> provides feedback, preventing me from typing a long complicated
> command only to discover one or more ambiguous abbreviations.  With
> completion, I'm much more confident that that the command will work
> right the first time.
> 

I would like to see some sort of extension to command completion that
enabled shells to complete not only the command name, but option
names, file names, and anything else in the command line.  Each word
would be completed in exactly the context in which the command would
use it.

One approach to this would be to replace the argv mechanism with some
sort of interactive scheme.  A shell would start up an application as
soon as its command name was successfully completed, and then would
communicate with the application using some protocol to determine the
namespace from which completion alternatives for each argument come,
and to validate the actual arguments as they are entered.  Finally,
when all the arguments are negotiated, the shell would tell the
application to go do its thing.  Of course, there would also have to
be a non-interactive method of invoking all commands.  Maybe a single
command-line option would be reserved for all commands that would
cause them to enter this interactive protocol to get their arguments.

Maybe GNU should support some even more general mechanism for
communicating with users that would provide consistent editing,
completion, and history features in all contexts.  Does this sort of
thing belong in the kernel?  The shells?  The window system?  The
libraries?  The tty driver?
-- 
-Bob Kukura		smart: rk@lexicon.com
			dumb: {husc6,linus,harvard,bbn}!spdcc!lexicon!rk
			phone: (617) 891-6790

matt@oddjob.uchicago.edu (Matt Crawford) (06/02/89)

In article <445@lexicon.com>, rk@lexicon (Bob Kukura) writes:
) One approach to this would be to replace the argv mechanism with some
) sort of interactive scheme.  A shell would start up an application as
) soon as its command name was successfully completed, and then would
) communicate with the application using some protocol to determine the
) namespace from which completion alternatives for each argument come, ...

Awfully hard to graft this onto unix, though, since you don't know what
to tie the file descriptors to until you get past all the arguments.

Last time this came up, about 2-3 years ago, I suggested sticking a
structure in a well-known place in the object file, with the structure
describing the valid argument list.  The application would then not have
to contain the completion and prompting code; that would be in the shell
(so every shell could do it differently  :-).
________________________________________________________
Matt Crawford	     		matt@oddjob.uchicago.edu

rcd@ico.ISC.COM (Dick Dunn) (06/02/89)

In article <2501@gandalf.UUCP>, ml@gandalf.UUCP (Marcus Leech) writes:
>...Make a sweep of all the commands in the system and decide on a consistent
>  command-line options scheme...

This is a sound basic idea...existing command-line options of various
commands are known to be screwy or difficult, leading to BUGS entries like
"The syntax is painful" (find) or "The conventions of join, sort, comm,
uniq, look, and awk(1) are wildly incongruous" (join).  Progress in this
area has been very slow, due to compatibility constraints (whether real or
just perceived).

We're not talking about kernel stuff here, but it's a matter of general
interest as GNU looks toward becoming a "system" with some focus instead of
only a "collection".

>...Options should be case insensitive...

Hello?  UNIX command names are case-sensitive.  Lexically, C is case-sen-
sitive.  I don't see any precedent for removing case-sensitivity in one
part of the system when it exists in others.

>...Options that perform the same function in different commands should
> have the same names...

In principle, a good idea, but this depends on the (very loosely coupled)
command authors to get together and agree a priori.  It's a "system issue"
but it doesn't have a "system solution"...in fact, I suspect that's the
reason UNIX command options lack uniformity.

>...Options should be complete words, with
>  a minimum-unambiguous scheme to reduce typing...

This is a radical change from the UNIX approach.  It will yield something
that is NOT a replacement for UNIX.  Why do it?
-- 
Dick Dunn      UUCP: {ncar,nbires}!ico!rcd           (303)449-2870
   ...CAUTION:  I get mean when my blood-capsaicin level gets low.