Post by Vester Thacker
Well, I apologize for offending you. But what ideas are you suggesting
that we migrate toward?
There are all sorts of different Plan 9's --
a) There is Plan 9 the research operating system, a small,
well-written kernel that's extremely portable, easily understood, and
fairly easy to extend and work with. It doesn't have as many
"features" as other modern operating systems, but in a way that is how
it has maintained its simplicity and relative stability.
b) There is Plan 9 the distributed system - an elegant approach
designed from the ground up to deal with a networked world.
c) Then there's Plan 9 the terminal, a highly productive, very
lightweight, and somewhat quirky interface which is more or less like
nothing a typical user has ever seen before. As evidenced by this
thread -- some love it, some hate it, some tolerate it, but most learn
to love it -- particularly as a development environment. If you want
a proper terminal environment under other operating systems you can
run drawterm or plan9ports and it gets you most of the way there.
There seem to be three major classes of gripes with Plan 9 the
terminal: it doesn't support my devices (which drawterm largely
overcomes), it doesn't run (or run with) my application/editor/browser
(which can be somewhat overcome with plan9ports), its different and/or
ugly. The different part is something many of us love, the ugly part
is something many of us don't care about -- both largely revolve
around the window manager and applications versus anything inherent in
the operating system.
d) There's also Plan 9, the tools - by which I primarily mean ken cc
-- which works well enough for the platforms they support, are
extremely quick, and were well understood (by Ken, and now by
In my opinion work on (a) and (b) constitutes operating systems
research -- and there's plenty to do, particularly to support
demanding customers with tens of thousands of nodes in a scalable and
efficient manner. Plan 9 just hasn't been stressed at those levels
before. There's nothing wrong with working on (c) or (d) -- stuff
like Plan B has shown us there's plenty of room for interesting
exploration and improvement -- but those are more about working on
applications versus working on the environment. In other words, they
really are projects onto themselves, not Plan9 per se -- in much the
same way that gnome != linux, rio != plan9. So if someone wants to go
out and write a new window manager (or port an existing one to Plan 9)
more power to them, and more choice to us. However, I really don't
think this should be a primary concern.
Ron is concerned (as am I) about keeping certain funding sources happy
-- and part of that is getting people at our organizations to use Plan
9. However, I think we should be focusing on getting them to use Plan
9 (a) and Plan 9 (b). Any discussion of (c) (and potentially (d))
will just turn religious and its not worth having that inquisition one
way (convince them to use our interfaces) or the other (jam their
interfaces into Plan 9).
My opinion is that time would be better spent with focusing on the
core of (a) and (b) and accomodating end-users who don't like the Plan
9 interface by providing gateways into Plan 9 systems from their
(existing) desktop environments -- meaning things like plan9ports,
xcpu, v9fs, etc. The issue of tools (d) is still complicated,
particularly with people plugging scripting languages like python into
their HPC applications -- but that's a battle that's more worth
fighting than a battle over marketing eye candy and wanting to rung
Mozilla inside Plan 9.