[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: web inherits UNIX console?
> I don't know about replacing X11, but I think that for 1/2 to 3/4 of
> X11 use cases, a browser will do.
It will do, perhaps. It will not be nearly as good, in many respects,
for almost all of even that 1/2 to 3/4 - except, of course, web
browsing, and even that only to the extent that the web browser in
question is (which, IME, isn't a very great extent).
> improved mouse+keyboard abstraction.
This sounds to me like "let's reinvent Display PostScript, badly".
> Also, web technology is improving where TTY is standing still.
You appear to be interpreting the latter as "stagnating" or something
similar. I think "got it right" comes closer.
> I think that to start, you could use a standard HTTP server.
Requiring "a standard HTTP server" merely to get GUI console
interaction is absolutely hair-raising from a security standpoint (and
almost as hair-raising from a bloat standpoint).
> You are in a good environment to type an email.
Actually, that sounds like a pretty miserable environment to type an
email - or, else, a pretty miserable environment to type anything else.
When I write email, my editor is configured rather differently from how
it's set up for most other things, and for good reason.
> #1: the new web environment, unlike a CLI, is a *direct manipulation*
This reinvents some of the worst problems of GUI interfaces:
specifically, unscriptability and the inability to manipulate things
that cannot be displayed. For exmaple, you appear to want to replace
pipelines with massaging a section of the display with multiple
commands. This is fine, until one of those commands produces a
half-gig of data which the next command distils down into something
usably small. I also don't see how your proposal would handle
> So you see that I do not propose to replicate the traditional
> command-line conversation in a browser window, but I propose to
> reinvent the UNIX interaction style while sticking with UNIX
Actually, it seems to me you would be losing two of the most important
and successful of those principles: "one job per program" and "run the
user's preferred tool for $JOB" ($EDITOR is a simple example of this;
$PATH is a more elaborate one).
> The new interaction is more direct and document-centered.
Which is - or at least may be - fine, if you're doing something
document-centred. It pretty much sucks for everything else.
> It rolls into one web app the functions of an editor, a command
> shell, a terminal multiplexer, and a terminal.
Indeed. But it does so at the same prices exacted by every other "roll
a bunch of stuff into one": it is difficult-to-impossible to replace
individual pieces, and it does a mediocre job at most-to-all of those
tasks, for some substantial fraction of the user base. (The latter is
unavoidable because it is not possible for the same interface to be
good for everyone.)
> You can use the new interface to build sophisticated functions from
> simple functions, and the power and interactivity of composite
> functions is greater than in traditional UNIX.
The flip side of interactivity is unscriptability - another deviation
from a very important piece of Unix philosophy.
I wouldn't say the power is greater than a traditional command-line.
I'd say it's _different_: greater for some kinds of tasks, worse for
This would be a very interesting experiment. Along about version five
or six it might have evolved into something usable, and at that point
it might be a good idea to put it into NetBSD. In its present form, I
don't think it should have anything more to do with NetBSD other than,
possibly, being built atop it.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Main Index |
Thread Index |