[NCLUG] Re: Thoughts on Linux Users

[Chad Perrin]

On Wed, Nov 14, 2007 at 04:41:56AM -0700, John L. Bass wrote:
> "John L. Bass" <jbass at dmsd.com> writes:
> > Chad Perrin <perrin at apotheon.com> writes:
> > > > The advancement, would have been to put the energies which produced FreeBSD
> > > > and Linux into a next generation redesign and architecture.
> > 
> > > In any case, I don't see what the big problem is.  The parts of Unix
> > > design philosophy that work well should not be eliminated just for some
> > > kind of ideological devotion to the idea of "advancement".  Meanwhile, a
> > > lot of the new stuff showing up in projects like Plan 9 is being actively
> > > incorporated into Unix-like OSes such as FreeBSD.
> > 
> > Sorry, but Plan 9 is one of the Dinasours too.
> 
> I probably should expand on this statement a bit, to provide a frame of reference.

Thank goodness.  Until this email, you were starting to sound like a
broken record.


> 
> They made an excellent research start at how to do next generation OS's very mindful
> of what did and didn't work well in UNIX. There are some clear dated biases in their
> design that are difficult to ignore ... it's completely character based, IE the system
> has no native GUI support as a general and primary user interface.  In some ways,
> I too can relate to that, having grown up a character command line guy for the last
> 40 years. It's primarily for this reason the OS is a dinasour, but not only for that
> reason. It is EXCELLENT next generation research.

I don't in any sense at all regard refusing to jettison the underlying
command interface in favor of a WIMP-centric OS design as anything
approaching a good idea.  MacOS tried going in that direction, and MS
Windows did so to a somewhat lesser degree, and as they're finding out
now it was a mistake.  Restricting, or at least discouraging, text-based
command interfaces in favor of point-and-click may improve initial
discoverability for users, but guts productivity.  Essentially, it seems
to me that the only way to *improve* upon a text-based command interface
as the basis for all other interfaces would be to transcend physical
interaction with the computer at all.

In other words, until those experiments with monkeys moving dots on the
screen and Parkinson's patients sending email, all without using anything
but their minds and electrodes attached to their heads, reach a point
where end user interface software is viable, a GUI-centric OS is a *bad*
idea.  It's even possible that, once the direct mental interface is
ironed out, it too will be better served by being a translation layer
over a text-based command interface than by being the foundational human
interface of the OS itself, hard-coded into its architecture --
especially considering that I rather suspect the code weight of such an
interface would be prodigious, thus limiting its usefulness for embedded
devices and dedicated servers.

Text-based command interfaces are valuable for a number of reasons as the
default means of interacting with an OS.  One, for instance, is that
since a text-based command interface is a very thin veneer over the way
an OS communicates internally (with itself, as it were) it serves as
about the most efficient way for computers to communicate between each
other while still providing a certain amount of "by hand" debugging
accessibility for the communication protocols.

That works in the other direction, too: GUI tools that provide a
translation layer of sorts over a text-based command interface are much
more easily debugged and can be much more efficiently scripted and
controlled than GUI tools that have no underlying text-based command
interface driving their behavior.  One of the beautiful things about
Linux and Unix systems, as contrasted with MS Windows, is the fact that
when a GUI tool breaks I can still get work done.

. . . and yet, you seem to want to eliminate the underlying text-based
command interface, and just have the GUI (possibly with some kind of
text-based macro system shoehorned into it, or more likely bolted on,
with less pervasive control capability).  I can't help but think that
such an opinion of how OS design should advance is incredibly naive, and
worthy of someone who hasn't been working with anything but MS Windows
and MacOS "classic" for the most part.

Back when I used nothing but MS Windows, and hadn't used anything before
that but DOS, I actually believed that eliminating the text-based OS
interface under the GUI was a good idea, too.  Thank goodness, I've
learned better.


> 
> Anyone taking on the challenge of doing a next generation OS, really needs to read
> and understand the design consideration of Plan 9, as you will clearly miss the ball
> by thinking solely in the UNIX/FreeBSD/LInux frame of mind.

That seems to be apropos of nothing, really.  Was it meant to make a
point, or was it just a tangential comment?  Please clarify the intent in
making that statement.


> 
> You also need to clearly understand the fundamentals of GUI based architectures, which
> requires solid study of the Plato, Alto, Lisa, evolution of the Apple OS's, as well
> as MSWin and X11/Gnome/KDE.

If GNOME and KDE are your primary examples of GUI design in the Unix
world, I can certainly see how you think that nobody has been doing
anything useful with GUI design in the Unix world for the last twenty
years.  I'd think so too, if those were my examples.


> 
> There are a number of other OS's that need to be explored as well, including Mach
> (including Next OS and OS-X). The Next OS was a very interesting study into the
> impacts of having an object oriented, message based OS internally. At MIT, besides
> Mach, there are several other operating systems in their history that are a must
> study ... especially Exokernel Operating System and previous microkernel work.

I'm quite aware of Mach kernel development and the development of the
Mach hybrid used by NeXT.  That's one of the things I find most
intriguing about OpenDarwin -- though the rest of MacOS X is largely
fluff designed to lure in customers and desktop application developers.
The Cocoa framework is nice and all, but it's hardly unique these days in
its underlying design, and it's hardly an indicator of any real
advancement in the last fifteen years.

I find it interesting that you dismiss Linux and FreeBSD development so
quickly, in light of your reference to things like HURD, the MIT
Exokernel, and so on.  After all, such projects are still in the realm of
academia rather than in that of widespread, commodity OS use, largely
because of some practical failings that nobody has managed to figure out
how to solve yet (performance being a big one).  Meanwhile, the Linux and
FreeBSD kernels (as well as a couple other, very similar, kernels out
there) have very consciously staked out places in the middle ground
between the modular microkernels to which you refer and the monolithic
"megakernels" of OSes like MS Windows, and in so doing have leveraged the
(practical) best of both worlds to produce kernel designs that seem to
achieve greater in-practice effect than pursuing either extreme would
allow.

Ultimately, slimming things down to the level of the HURD or Exokernel
level might be The One True Way.  The hybrid Mach/BSD kernel of
OpenDarwin might be the next stepping stone.  In the meantime, modular
monolithic kernel design such as that used in the Linux and FreeBSD
kernels seems to be the de facto Right Answer to getting things done
while we wait for the technological revolution to overcome its own
limitations.


> 
> Only once you have explored other alternatives in detail, does it start to gel that
> we can do much better than UNIX/FreeBSD/Linux ... and probably should have spent
> at least the last decade expanding on this research, if not the last two decades.

We can do much better than *everything*, and I'm fully aware of that.  We
still have to live in the here and now while designing the future,
however, and I certainly don't regard some of the best examples of
technological advancement we have available to us (coupled with some of
the best examples of development process advancement) as evolutionary
dead ends that haven't advanced the state of the art at all for thirty
years, just because they're recognizably descended from something thirty
years old.  If I were to take that approach to things, I'd figure
humanity was at an evolutionary dead end around the days of the split of
genus Homo from Australopithecus afarensis -- assuming you buy into this
"evolution" stuff.  Otherwise, we were a dead end about four to six
thousand years ago with the birth of Abel and Cain.  Either way, I think
we've managed to advance the state of the art of the species since then,
and all that has happened in the meantime is not a complete waste of
time -- just as all the advancements in the state of the art of OS design
for general use since the 1960s is not a complete waste of time either.

"We" need to develop ideas along several avenues simultaneously if we
want advances we can actually use.  In the real world, practical
advancement of technology happens when academic advances and real-world
development meet.  It doesn't happen solely in an ivory tower.  The
mechanism for that sort of coming-together of advancement is, I think,
well exemplified in circumstances like those surrounding the
incorporation of Plan 9 protocols into BSD Unix and Linux-based OSes, and
the hybridization of microkernel and modular monolithic kernel concepts
to produce the Darwin kernel -- which, by the way, still manages to
support the core Unix environment as its standard interface with the
world both in OpenDarwin and, to some extent, in MacOS X.

In any case, I'm not married to the idea that Unix is the Platonic Ideal
of operating systems, which seems to be what you think of my opinion.
I'm just not married to the idea that Unix is crap that should have been
thrown out twenty years or so ago, either -- which seems to be your
position on the matter.  It's the middle ground between advancing the
state of the art and actually getting something done.

Sounds good to me.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
John W. Russell: "People point. Sometimes that's just easier. They also use
words. Sometimes that's just easier. For the same reasons that pointing has
not made words obsolete, there will always be command lines."