New (GNU) kernels--what I think

[Marcus Leech]

In article <10344 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn) wrote:
> [paraprasing for brevity:  Bourne-shell interface cannot be made
> appropriate for general users with small changes such as the ones I've
> suggested. Doug suggests that Menus/Icons with an escape-to-shell
> mechanism are more appropriate.]
> to do so.)
I think I disagree. I think that the migration to restricted-environment
  menu/icon systems is largely due to the generally poor design of the
  UNIX line-mode interface.  I really do think that little changes such as
  the ones I have suggested can make a BIG impact on "user-friendliness".
  I don't think that I'm completely off-the wall in wanted an internally-
  consistent linemode interface to UNIX.  I don't think I should need a
  $10K bitmapped display to get something that is friendly and consistent.
  I know of several examples of remarkably computer-naieve Zoologists
  who turned into moderately-sophisticated programmer/users in a fairly
  short time.  They had only the Bourne-shell and some prettied-up line
  editors to work with.  The notion that most users are computer-idiots,
  and that a sophisticated environment isn't appropriate for them just
  isn't true.  This based on experience with my own user-populations. Mileage
  may vary.
I wrote:
> >  Restrict filenames to alphabetics,numbers,and punctuation, keeping in
> >  mind national character sets.
And Doug wrote:
> Which means that you cannot restrict the directory entry names,
> beyond outlawing / and NUL (and it's a shame to have to outlaw those).
I probably overstated the name restrictions here. It's one approach to making
  it difficult to generate hard-to-remove/hard-to-type filenames.  If there
  exists a mechanism for expressing bizzare-looking filenames without
  having to write a program to remove them, that would be just as good.
I wrote:
> >  The notion of CLISTs should certainly be re-visited, and probably abandoned.
and Doug wrote:
> In favor of something like streams.
Probably.  And probably the V8-style, rather than the SystemV-style. I don't
  know enough about either flavour to comment on their wonderfulness.
I wrote:
> >    - 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.<<
And Doug wrote:
> We already have far more useful forms of command history available via
> various shells (tcsh, BRL sh, ksh, etc.) and terminal facilities (mux, etc.).
I find the CSH-style history mechanism very awkward to use.  The VMS4.x
  history mechanism is easy to use, and is available from nearly all
  interactive programs.  Making it universal seemed to me to imply having
  hooks in the tty driver.
I wrote:
> >  There ought to be a "resource" allocator that is responsible for allocating
> >  peripherals to users.
And Doug wrote:
> 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.
> 
> [stuff about terminal allocator having different roles that a magtape alloc.]
Agreed. I was thinking of a user-mode process.  I also have some design
  notes kicking around for such a beast.  You'd probably want to be able to
  add special handlers for each "class" of resource that is subject to
  allocation.  Utmp updating would simply be part of the "method" for "objects"
  of class "tty"  :-)
-- 
"Better Living through modern chemistry" PaperMail: 130 Colonnade Rd, Nepean,ON
Marcus Leech                             E-mail:     ml at gandalf.UUCP
Gandalf Data Ltd                         PacketRadio: VE3MDL at VE3JF
"The opinions expressed herein are solely my own" So there