8 May
2018
8 May
'18
7:51 p.m.
On Tue, 08 May 2018 08:24:29 -0400 "Theodore Y. Ts'o" <tytso(a)mit.edu>
wrote:
Theodore Y. Ts'o writes:
On Mon, May 07, 2018 at 02:53:26PM -0700, Steve
Johnson wrote:
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.
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