[TUHS] Systematic approach to command-line interfaces

[Bakul Shah]

Or perhaps the issue is not having graphics/GUI designers with the
creativity and sensibilities of the early Bell Labs crowd of researchers?
I keep thinking there ought to be something simpler/more elegant than
the current graphics subsystems....

> On Aug 2, 2021, at 11:16 AM, Adam Thornton <athornton at gmail.com> wrote:
> 
> 
> It's a measure of Unix having been wounded by its own success.
> 
> fork() is a great model for a single-threaded text processing pipeline to do automated typesetting.  (More generally, anything that is a straightforward composition of filter/transform stages.)  Which is, y'know, what Unix is *for*.
> 
> It's not so great for a responsive GUI in front of a multi-function interactive program.
> 
> These days, the vast majority of Unix applications are "stuff people play with on their phones."
> 
> Adam
> 
> On Mon, Aug 2, 2021 at 7:59 AM Theodore Ts'o <tytso at mit.edu> wrote:
> On Sun, Aug 01, 2021 at 10:42:53PM -0400, Douglas McIlroy wrote:
> > > spawn() beats fork()[;] fork() should be deprecated
> > 
> > Spawn is a further complication of exec, which tells what signals and
> > file descriptors to inherit in addition to what arguments and
> > environment variables to pass.
> > 
> > Fork has a place. For example, Program 1 in
> > www.cs.dartmouth.edu/~doug/sieve/sieve.pdf forks like crazy and never
> > execs. To use spawn, the program would have to be split in three (or
> > be passed a switch setting).
> > 
> > While you may dismiss Program 1 as merely a neat demo, the same idea
> > applies in parallelizing code for use in a multiprocessor world.
> 
> It's certainly clear that some kind of primitive is needed to create
> new threads.  An open question is whether if there exists some kind of
> "new thread" primitve plus either spawn(2) or some kind of "create a
> child process and then then frob like crazy using 'echo XXX >
> /proc/<pid>/<magic files>'" whether there still is a need for a
> fork(2) system call.
> 
> Obviously, as soon as we start going down this path, we're deviated
> quite strongly from the "radical simplicity" of Unix Version 7 that
> people have accused modern systems (whether they be Linux or FreeBSD)
> of lacking.  It's rather interesting that we haven't heard complaints
> about how people who dare to try come up with new API's are somehow
> traitors to "The Unix Philosphy" that we've seen on other threads.  :-)
> 
>                                             - Ted