[TUHS] unix "awesome list"

[bakul@bitblocks.com (Bakul Shah)]

On Tue, 08 May 2018 08:24:29 -0400 "Theodore Y. Ts'o" <tytso at mit.edu> wrote:
Theodore Y. Ts'o writes:
> On Mon, May 07, 2018 at 02:53:26PM -0700, Steve Johnson wrote:
> > Some would argue that it was well on its way to being forgotten by
> > BSD. The problem with that statement is that the deployment of mice
> > and touchscreens meant that the base premise (universal interface) was
> > no longer true. Fonts and markup completed the job.
> > 
> > When I first used Unix, I wrote several ed scripts every day, and
> > several shell scripts each week. Glass terminals made ed scripts
> > obsolete without any similar abstraction being available for doing
> > similar text operations on several related files.
> 
> While true, that's only part of the story.  There was also the issue
> that what users wanted to *do* with computers got more complex.
> Consider spreadsheets and relational databases --- how do they get
> implemented in "the Unix way"?  There was rdb, but it was a bit of a
> disaster from a performance perspective and only worked for toy
> databases.  And this wasn't unique to Unix.  In the VMS world,
> ALL-IN-1 offered group scheduling/calendaring and other "office
> software" features.  You *could* implemnt a group scheduling system
> using sed, awk, grep, cat, and pipelines --- but would you want to?
> Is that the best way to go about doing things?
> 
> And on the hardware side, the advent of hot-pluggable hardware devices
> and much more complex UI devices (sound, video cameras, etc.) that
> need to be made accessible to the logged-in user sitting in front of a
> particular console, put a lot more pressure on the simple login and
> /dev model of historical Unix.
> 
> So sure, it's easy to criticize "PenguinOS" for departing from the
> Unix ideal.  But what's the alternative?  Can the criticis design
> something better that matches the needs and requirements of the users
> (who don't like big question marks on dashboards as "user friendly"
> error reporting) and the realities of modern hardware and modern user
> interface?
> 
> And if so, would those critics care to implement it and contribute it
> under a BSD-style license?  (Or some other Open Source License)?
> After all competing with the user friendliness of GNOME should be that
> hard --- and it's been getting easier over the years as GNOME cuts
> feature after feature from their system.  :-)
> 
> 					- Ted

Great response! Agree with a lot of this (except GNOME!).

Shell was a good glue language in that it allowed easy
composition of programs that fit its model from simpler
programs. A similar model exists for services composed from
microservices but now the 'pipes' are often not unidirectional
or simple lines of text. And dynamic scaling is required. etc.
But we do not have a similar easy to use glue language.
Graphical interfaces get used but except in special fields
they are not compositional. Graphical languages remained
researchy. in other areas existing solutions are rejected as
being not efficient enough or hard to integrate in the unix
model. Example: capabilities. Unix file descriptors are in
fact capabilities but they are still file/dir/device or socket
descriptors, mainly confined to individual processes.
Experiments in pure capability based OSes havent gone far. In
FreeBSD we have capsicum but that has added complexity, not
removed it. And we are still writing concurrent programs using
mutexes. No practical progress in 40 years.

If you think about it, most all the new things added in last 3
decades haven't had the cohesion of design like the original
unix design. And yet, I think extending the unix model is quite
possible.