[TUHS] Systematic approach to command-line interfaces

[Bakul Shah]

On Aug 2, 2021, at 6:49 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> Bakul Shah writes:
>> 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
> 
> I thought that I posted something about this recently when someone
> was arguing for threads being unnecessary and bad.
> 
> My two cents is that GUIs were the big driver for threads.  I would
> personally like to get rid of them as they're "the same but different"
> with regards to processes.  My preference would be to solve the
> heaviness of processes problem.  I'm not in the thick of that these
> days, but I don't see it being solved in software alone; it's going
> to take some serious hardware/software architecture work.  Might be
> easier to accomplish now that the world has pretty much settled on
> the process model.
> 
> Jon

AFAIK pretty much all GUI frameworks are (or were) single threaded.
At least I don't see the GUI as the main motivation for threads.

I was mainly complaining about the complexity of graphics subsystem,
including user interaction. Don't see what fork() has to do with it.