[9fans] gtk port

[9fans] gtk port

[Hiroki Tamakoshi]

Hello,

I'm trying to port gtk to Plan 9.
Thu purpose and current status is written in
http://mimi.aist-nara.ac.jp/%7Ehiroki-t/Plan9/gtk.html
I need help, because I'm not familiar with C, X Window System.

Re: [9fans] gtk port

[Artem 'Thomas' Hlushko]

Hiroki Tamakoshi <hiroki-t@is.aist-nara.ac.jp> wrote:
> Hello,

> I'm trying to port gtk to Plan 9.
> Thu purpose and current status is written in
> http://mimi.aist-nara.ac.jp/%7Ehiroki-t/Plan9/gtk.html
> I need help, because I'm not familiar with C, X Window System.

i think it is very _bad_ idea.
your next step will be to port gnome with 20MB cd player and so.

do you want make _yet another FSF Windoze_ of plan9, like linux?

look at tcl/tk better...

Re: [9fans] gtk port

[Hiroki Tamakoshi]

Hello,

Artem 'Thomas' Hlushko <tom@topspin.kiev.ua> writes:

> Hiroki Tamakoshi <hiroki-t@is.aist-nara.ac.jp> wrote:
> > I'm trying to port gtk to Plan 9.
> > Thu purpose and current status is written in
> > http://mimi.aist-nara.ac.jp/%7Ehiroki-t/Plan9/gtk.html
>
> i think it is very _bad_ idea.
> your next step will be to port gnome with 20MB cd player and so.
>
> do you want make _yet another FSF Windoze_ of plan9, like linux?
>
> look at tcl/tk better...

Why do you think that is a bad idea?
Why do you push tcl/tk?

It is not the problem to choose gtk or tcl/tk.
My opinion is, from the point of view of the Human-Computer
Interaction, that Plan 9 should have a potential to establish a good
GUI for end users. Off course, there could be another solusion than
porting gtk.
(and even if porting gtk fail, porting glib is worthwhile, because
glib is a very useful library.)

I put a discussion with Russ, which will tell more about this subject.

------------------------------
My view is a bit biased by working
at Bell Labs once in a while and having
written and revised some of the graphics
stuff.  For small jobs, though, I agree that
something like GTK is necessary.

You might think about whether it could be
provided as a file server, and whether
that would solve the problem of string
management or executing little code segments,
which Tcl does not have but GTK does
(as far as I can tell).

Russ

> Why biased?
> In the research field of Human-Computer Interaction, it is obvious
> that the computers should be intuitive, easy to understand, easy to
> use.
> Plan 9 need a good GUI toolkit, I believe.
>
> I used Plan 9 for about a week and found that acme is useful and
> innovative. But it is useful for only professionals in my opinion.
> There's no need to be decorative, but there should be a potential to
> build a useful GUI.
>
> How do you think about the concept?
>
> rsc@plan9.bell-labs.com writes:
>
> > This is a knee-jerk and fairly biased
> > reaction, but I'd suggest you familiarize
> > yourself with some of the Plan 9 graphical
> > utilities (acme, sam, etc.) before deciding
> > that GTK is necessary.  I think you'll find that
> > acme in particular has a radical way of doing
> > things that is easier and quicker to use than
> > things you can create with GTK.
> >
> > Russ

Re: [9fans] gtk port

[Artem 'Thomas' Hlushko]

Hiroki Tamakoshi <hiroki-t@is.aist-nara.ac.jp> wrote:
> Hello,

> Why do you think that is a bad idea?
because this is not plan9 way (see plan9.bell-labs.com/sys/doc/*)

> Why do you push tcl/tk?
because this is better approach in computer system design.
there is power not only in graphics capabilities of tk,
but in philosophy of tcl. systems are made of 'hard'
pieses in c and etc by gluing with tcl and pipes.
it is very close to real unix way (see upe by bwk&pike)

> It is not the problem to choose gtk or tcl/tk.
> My opinion is, from the point of view of the Human-Computer
> Interaction, that Plan 9 should have a potential to establish a good
> GUI for end users. Off course, there could be another solusion than
there are popular oses with drag'n'drop, point'n'click, popup menus'n'windows
they are used by housekeepers, clerks, sales managers and gamers.
but why do so many people think this is only way?
why Human-Computer Interface should be same for nuclear plant operator
or airport dispetcher and for sales manager or housekeeper?

i think plan9 is intended for cs researches, scientists in another fields,
mission-critical applications experts and so. they are primary
interact with computer by program it, order it and ask it.
sometimes they browse web, look at experimental data
and read ps/pdf/dvi then they need graphics interface.
good Human-Computer Interaction for them is close to plan9 one
and is far to gnome.

> porting gtk.
> (and even if porting gtk fail, porting glib is worthwhile, because
> glib is a very useful library.)
plan9 libc very useful too...

at least i don't think tcl/tk very need in plan9
you can create server with filesystem interface
or add some graphical capabilities in rc :)))

there is not only one way to compute!

Re: [9fans] gtk port

[Hiroki Tamakoshi]

Hello,

Artem 'Thomas' Hlushko <tom@topspin.kiev.ua> writes:

> why Human-Computer Interface should be same for nuclear plant operator
> or airport dispetcher and for sales manager or housekeeper?
> there is not only one way to compute!

I completely agree with the above opinion.

> Hiroki Tamakoshi <hiroki-t@is.aist-nara.ac.jp> wrote:
>
> > Why do you think that is a bad idea?
> because this is not plan9 way (see plan9.bell-labs.com/sys/doc/*)

Ok, I'll read them later.

> > Why do you push tcl/tk?
> because this is better approach in computer system design.

I'll consult the underlining philosophy of tcl/tk. Do you know any
good documentation?

> i think plan9 is intended for cs researches, scientists in another fields,
> mission-critical applications experts and so. they are primary
> interact with computer by program it, order it and ask it.
> sometimes they browse web, look at experimental data
> and read ps/pdf/dvi then they need graphics interface.
> good Human-Computer Interaction for them is close to plan9 one
> and is far to gnome.

If Plan 9 is intended for researchers, say professionals, there's no
need heavily decorative GUI, I also think so.
But I want to use Plan 9 as a home computer system, because it is a
very good computer system. MS Windows is not reliable to use, and I
prefer Plan 9 than UNIX because Plan 9 is more sophisticated than latter.
Suppose NEXTSTEP like environment on Plan 9. It is very good system to
both researchers and users at home, isn't it?

> plan9 libc very useful too...

Yes. And glib also contains usuful functions such as tree, hash, etc.

Re: [9fans] gtk port

[Artem 'Thomas' Hlushko]

Hiroki Tamakoshi <hiroki-t@is.aist-nara.ac.jp> wrote:
>> because this is not plan9 way (see plan9.bell-labs.com/sys/doc/*)

> Ok, I'll read them later.
you should read it now, for whole picture (and ../man/* too)

> I'll consult the underlining philosophy of tcl/tk. Do you know any
> good documentation?
www.scriptics.com
there many online docs and papers, and links to handbooks and intros.
the best detailed docs are man pages from distribution

> But I want to use Plan 9 as a home computer system, because it is a
> very good computer system. MS Windows is not reliable to use, and I
> prefer Plan 9 than UNIX because Plan 9 is more sophisticated than latter.
plan9 is _less_ sophisticated than unix!
compare posix threads with plan9 generalized fork!
try to write hellow_world.c in X!

perfection is reached then there is nothing to drop
not then there is nothing to add

plan9 is closest to perfection

> Suppose NEXTSTEP like environment on Plan 9. It is very good system to
> both researchers and users at home, isn't it?

maybe you should install linux, x, afterstep and choose nextish look&feel?

if you 9fan enjoy with rio

best regards, Hiroki

Re: [9fans] gtk port

[Berry Kercheval]

At 01:35 PM 06/30/2000 +0000, Artem 'Thomas' Hlushko wrote:

> > I'll consult the underlining philosophy of tcl/tk. Do you know any
> > good documentation?
>www.scriptics.com


Actually, the developer's site is what you want, and the name has
changed.  Scriptics is now Ajuba Solutions.  Try

         http://dev.ajubasolutions.com

The Scriptics names will redirect to ajuba.

(I work for but do not represent Ajuba)

   --berry
--
Berry Kercheval :: Ajuba Solutions :: http://www.ajubasolutions.com
Berry@ajubasolutions.com                 (Formerly Scriptics Corp.)

Re: [9fans] gtk port

[Dennis Ritchie]

Berry Kercheval wrote:
> 
> ... name is changed.  Scriptics is now Ajuba Solutions.  Try
> 
>          http://dev.ajubasolutions.com
> 
> The Scriptics names will redirect to ajuba.
> 
> (I work for but do not represent Ajuba)

The naming winds blow inconstantly and in different
directions.  The Lucent spinout company of the PBX/Enterprise
Network business is called Avaya.  And their home page
displays moving graphics just that much more irritating than
those of Scriptics->Ajuba.

Ah for the old days, when investing in companies with a K
at the beginning or end of the name was a lock, or perhaps
later when the terminal X looked good.

	Dennis

Re: [9fans] gtk port

[Randolph Fritz]

In my view, arguing about usability--though very common--generates
more heat than light; there is simply no way to predict such things
without testing, making for a very different design regime than that
of a software system with a well-defined specification; in software
with a substantial HCI component, the user is the specification.

In my view, the visual component of an interface is an important means
of communication with the user, not simply decorative.  An
architectural example will perhaps help: who here has encountered a
building without a clearly indicated entrance?  Of those of us who
have, what was the experience of finding that entrance like?

Both of those things said, I agree that gnome/gtk/gdk is not very
9ish.  However, having them available will make Plan 9 more accessible
to a wider user and developer community, which seems to me likely to
be positive.

--
Randolph Fritz
Eugene, Oregon, USA

Re: [9fans] gtk port

[Douglas A. Gwyn]

Randolph Fritz wrote:
> Both of those things said, I agree that gnome/gtk/gdk is not very
> 9ish.  However, having them available will make Plan 9 more accessible
> to a wider user and developer community, which seems to me likely to
> be positive.

I don't think attracting to Plan9 the kind of developer who *prefers*
GNOME is at all a positive step.  However, I see no harm in having
GTK+/GLIB implemented on Plan9; for one thing, it makes importing
useful apps that weren't developed with Plan9 in mind easier, much
as APE makes importing POSIX apps easier.

Re: [9fans] gtk port

[Wladimir Mutel]

Artem 'Thomas' Hlushko <tom@topspin.kiev.ua> wrote:

>> I'm trying to port gtk to Plan 9.

> look at tcl/tk better...

	Limbo/Tk, may be ?

	Tcl/Tk may be called 'bloated' too.

--
mwg@alkar.net, 340044, 7442333, 7786458 - О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫

Re: [9fans] gtk port

[arisawa]

Hello.

>>> I'm trying to port gtk to Plan 9.
>> look at tcl/tk better...
>	Limbo/Tk, may be ?
>	Tcl/Tk may be called 'bloated' too.

Yes Tcl/Tk may be bloated. However, if we have Tcl/Tk on Plan9,
We will also have "Grail", a web brawser written in Python.
Python is bloated but we can share many applications with
other platform.
Our society is too small to do everything by ourself.

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

Re: [9fans] gtk port

[James A. Robinson]

> Yes Tcl/Tk may be bloated. However, if we have Tcl/Tk on Plan9,
> We will also have "Grail", a web brawser written in Python.

It would be nice to have a webfs server.  I know the hardest part of a web
browser is the html display, but to have something that would let you do

        echo 'http://www.sciencemag.org/' > /mnt/web/get
        cat /mnt/web/data
or
        echo 'http://bmj.com/cgi/reprint/320/7251/1713.pdf' > /mnt/web/get
        if ( ~ 'application/pdf' `{cat /mnt/web/header/Content-type})
        {
                pdfview /mnt/web/data
        }

and so on.  It would make using existing tools simple, and could
be hooked into plumber.


Jim

Re: [9fans] gtk port

[Randolph Fritz]

On Thu, Jun 29, 2000 at 10:27:08PM +0000, James A. Robinson wrote:
> > Yes Tcl/Tk may be bloated. However, if we have Tcl/Tk on Plan9,
> > We will also have "Grail", a web brawser written in Python.
>
> It would be nice to have a webfs server.  I know the hardest part of a web
> browser is the html display, but to have something that would let you do
>
>         echo 'http://www.sciencemag.org/' > /mnt/web/get
>         cat /mnt/web/data

I like the idea, but I think there would have to be more than one web
server name.  If Plan 9 gets longer filenames, it would be Really
Neat to be able to say 'cat /http/www.sciencemag.org'...

--
Randolph Fritz
Eugene, Oregon, USA

Re: [9fans] gtk port

[Skip Tavakkolian]

It would be nice to follow the example of ftpfs, but http
does not map to a filesystem nicely. I suspect that is why there is
an hget in the distribution and not an httpfs. For example what should
the content of /http/x.y.com/i.html be, if a GET of 'http://x.y.com/i.html'
results in a redirect? How does one represent a query parameter of a URI
in a filesystem (like http://x.y.com/i.html?user="sam")? etc.

It seems that the display problems would be straight forward with LOTS
of code to display HTML (?and interpret Javascript?) and a little
code for a go-between filter to acme.

At 03:51 PM 6/29/00 -0700, Randolph Fritz wrote:
>On Thu, Jun 29, 2000 at 10:27:08PM +0000, James A. Robinson wrote:
>> > Yes Tcl/Tk may be bloated. However, if we have Tcl/Tk on Plan9,
>> > We will also have "Grail", a web brawser written in Python.
>>
>> It would be nice to have a webfs server.  I know the hardest part of a web
>> browser is the html display, but to have something that would let you do
>>
>>         echo 'http://www.sciencemag.org/' > /mnt/web/get
>>         cat /mnt/web/data
>
>I like the idea, but I think there would have to be more than one web
>server name.  If Plan 9 gets longer filenames, it would be Really
>Neat to be able to say 'cat /http/www.sciencemag.org'...
>
>--
>Randolph Fritz
>Eugene, Oregon, USA
>
>

Re: [9fans] gtk port

[Jim Choate]

On Thu, 29 Jun 2000, Skip Tavakkolian wrote:

> It would be nice to follow the example of ftpfs, but http
> does not map to a filesystem nicely.

I must disagree here, for example:

.../httpd/einstein.ssz.com/index.html
                          /cdr
                          /cdr/index.html
                          /cliology
                          /cliology/index.html
                          /...
         /google.com

    ____________________________________________________________________

          Life is a tale told by an idiot, full of sound and fury,
          signifying nothing.
                                            W. Shakespeare

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] gtk port

[arisawa]

Hello,

kip Tavakkolian wote:
>How does one represent a query parameter of a URI
>in a filesystem (like http://x.y.com/i.html?user="sam")? etc.

File name
   i.html?user="sam"
is admissible in Plan 9, although will not be recommended,
and mapping GET method string to file name sometime requires longer
name that exceeds the limit.

Arisawa Kenji
E-mail: arisawa@aichi-u.ac.jp

Re: [9fans] gtk port

[James A. Robinson]

> On Thu, Jun 29, 2000 at 10:27:08PM +0000, James A. Robinson wrote:
>
> I like the idea, but I think there would have to be more than one web
> server name.  If Plan 9 gets longer filenames, it would be Really
> Neat to be able to say 'cat /http/www.sciencemag.org'...

I was thinking of acme's model where each window get's it's own id and
file system.  So each host would have it's own hierarchy. My example
was poor, I should have posted something along the lines of:

  /mnt/web/new/ctl      (open a new <id> proto://host:port)
  /mnt/web/new/get      (get back an <id> with data filled from GET)

  /mnt/web/id/get       (quick 'n' dirty GET request)
  /mnt/web/id/set       (set ?default? outgoing headers/httpauth)
  /mnt/web/id/post      (longer data submissions?)
  /mnt/web/id/headers/* (incoming header response)
  /mnt/web/id/body      (read the body of the response)

Or somesuch. With a private namespace for each host, you don't
worry about long filenames.

Jim

Re: [9fans] gtk port

[Randolph Fritz]

On Fri, Jun 30, 2000 at 01:55:06AM +0000, James A. Robinson wrote:
>
> I was thinking of acme's model where each window get's it's own id and
> file system.  So each host would have it's own hierarchy. My example
> was poor, I should have posted something along the lines of:
>
>   /mnt/web/new/ctl      (open a new <id> proto://host:port)
>   /mnt/web/new/get      (get back an <id> with data filled from GET)
>
>   /mnt/web/id/get       (quick 'n' dirty GET request)
>   /mnt/web/id/set       (set ?default? outgoing headers/httpauth)
>   /mnt/web/id/post      (longer data submissions?)
>   /mnt/web/id/headers/* (incoming header response)
>   /mnt/web/id/body      (read the body of the response)
>
> Or somesuch. With a private namespace for each host, you don't
> worry about long filenames.
>

Having thought it over, I think you're right.  As Skip T points out:
>
> It would be nice to follow the example of ftpfs, but http
> does not map to a filesystem nicely. I suspect that is why there is
> an hget in the distribution and not an httpfs. For example what should
> the content of /http/x.y.com/i.html be, if a GET of 'http://x.y.com/i.html'
> results in a redirect? How does one represent a query parameter of a URI
> in a filesystem (like http://x.y.com/i.html?user="sam")? etc.
>

The following might be addressed by an NGLayout port:
>
> It seems that the display problems would be straight forward with LOTS
> of code to display HTML (?and interpret Javascript?) and a little
> code for a go-between filter to acme.
>

On Thu, Jun 29, 2000 at 08:41:31PM -0500, Jim Choate wrote:
> I must disagree here, for example:
>
> .../httpd/einstein.ssz.com/index.html
>                           /cdr
>                           /cdr/index.html
>                           /cliology
>                           /cliology/index.html
>                           /...
>          /google.com
>

But many sites aren't organized that way. :( The web's metadata format
is more confused than FTP's.  Hmmm...I don't really understand W3's
RDF metadata format, but that might offer a key to the problem.

--
Randolph Fritz
Eugene, Oregon, USA

Re: [9fans] gtk port

[Andy Newman]

Randolph Fritz wrote:
>The following might be addressed by an NGLayout port:
Preceeded by the g++ port no doubt.

Just ignore the real web, adopt the stylised file system view, use
it where it works and as it should be used. If it's a good idea
eventually Microsoft will adopt some bastardised version of it
and everyone will prosper. 20 years seems to be about the gestation
period of OS ideas so you need patience.

Re: [9fans] gtk port

[James A. Robinson]

>
> On Thu, Jun 29, 2000 at 08:41:31PM -0500, Jim Choate wrote:
> > I must disagree here, for example:
> >
> > .../httpd/einstein.ssz.com/index.html
>
> But many sites aren't organized that way. :( The web's metadata format
> is more confused than FTP's.

Yes, in general I think it is a very poor protocol. It is very flexible
about the name and parameters you can use to request a resource, but
doesn't return a name/value indicating the canonical name of the resource
you are retrieving.

The problem, as you point out, is that many sites just aren't organized
like this. If you request

	http://www.sciencemag.org/

You are not getting '/index.html' but '/index.dtl' with 'dtl' being a
homegrown dynamic template language like shtml. Naturally what the browser
sees is straight html (as with shtml), but the problems start to appear if
you want to cache the resource or refer to it by it's resource name.
If you cache it as '/index.html' then you will run into trouble when
you try and and do a 'HEAD /index.html' to see if it has been modified.
Our server will respond that it knows nothing about '/index.html'


Jim

Re: [9fans] gtk port

[Jonathan Sergent]

On Fri, 30 Jun 2000 01:55:06 GMT,
James A. Robinson <jim.robinson@stanford.edu> wrote:
>I was thinking of acme's model where each window get's it's own id and
>file system.  So each host would have it's own hierarchy. My example
>was poor, I should have posted something along the lines of:
>
>  /mnt/web/new/ctl      (open a new <id> proto://host:port)
>  /mnt/web/new/get      (get back an <id> with data filled from GET)
>
>  /mnt/web/id/get       (quick 'n' dirty GET request)
>  /mnt/web/id/set       (set ?default? outgoing headers/httpauth)
>  /mnt/web/id/post      (longer data submissions?)
>  /mnt/web/id/headers/* (incoming header response)
>  /mnt/web/id/body      (read the body of the response)
>
>Or somesuch. With a private namespace for each host, you don't
>worry about long filenames.

Hmm... this is interesting.

That seems right, or rather trying to map 'GET http://x/y/z' to
/mnt/http/x/y/z seems bad for the reasons that there is no way to get a
directory listing and because many HTTP semantics get lost; it doesn't
feel like a good fit.  What you describe sounds better.

Seems like doing a new directory for each request would be better.

I agree that it should be web instead of http and handle the necessary
abstractions underneath for other types of URLs (FTP at the least;
ideally also things like LDAP and such).

It seems like it would be desirable to have some of the protocol
semantics that are common for all applications handled in common
(i.e. cookies, HTTP authentication).  Cookies could show up as
a top file that you can look at to see what is in your jar and
send commands to in order to remove them.

headers/* is useful for being protocol-specific, but some of the
functionality there should be handled for the application, or at least
abstracted out for different protocols (i.e. content-type, range,
probably more) without trying to emulate HTTP headers on top of
the other protocols.

Doing a front end that works with acme seems like a good idea.
It's not clear how nicely acme could display HTML, though.  Even if we
forgo graphics, we still want to do a good job with tables and such.


--jss.

Re: [9fans] gtk port

[arisawa]

Hello,

Recent web pages are full of noisy commercials and junk images.
Therefore it may be a good idea to have a brawser based mainly
on text providing ability to get images in case of necessity.
Then the ideas:
>   echo 'http://www.sciencemag.org/' > /mnt/web/get
>   cat /mnt/web/data
or
>   cat /http/www.sciencemag.org
or some other operations like plumb may be nice for plan 9.

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

Re: [9fans] gtk port

[Randolph Fritz]

On Thu, Jun 29, 2000 at 08:57:02PM -0400, arisawa@ar.aichi-u.ac.jp wrote:
>
> Recent web pages are full of noisy commercials and junk images.
> Therefore it may be a good idea to have a brawser based mainly
> on text providing ability to get images in case of necessity.
> Then the ideas:
> >   echo 'http://www.sciencemag.org/' > /mnt/web/get
> >   cat /mnt/web/data
> or
> >   cat /http/www.sciencemag.org
> or some other operations like plumb may be nice for plan 9.
>

It depends...as an architecture student & photographer I deal in
graphics, and many sites of architectural firms would simply not be
usable without them--take a look at
<http://www.fosterandpartners.com>, for instance.  Even for more
conventionally-designed sites, a little bit of layout often makes all
the difference between clarity and obscurity--I use lynx sometimes,
but I don't enjoy it. :(

Perhaps the thing to do is port Mozilla's NGLayout (aka Gecko (tm)*)
HTML/XML rendering engine, and see what support it needs--most of the
graphic components are already there, and Plan 9's graphics model has
one excellent advantage over Windows and MacOS--it already does
transparency, which CSS requires.  Plan 9's distributed design might
be well-suited to a modular browser; that might even become a popular
app.

--
Randolph Fritz
Eugene, Oregon, USA

* Gecko is a trademark of Netscape, Inc. :)

Re: [9fans] gtk port

[rog]

> Suppose NEXTSTEP like environment on Plan 9. It is very good system to
> both researchers and users at home, isn't it?

plan 9 is better.
not prettier, but much more powerful. nextstep/openstep/(maxosX?)
suffers from the same problems of most GUIs - too many widgets, not
enough generality.

if you use plan 9 for a bit, you'll grow to like and rely upon its
sparsity and power.

  rog.

Re: [9fans] gtk port

[bwc]

Much of Plan 9's beauty lies in elegance.  Elegance is defined
as tasteful opulence.  If we union plan 9 with everything that
has come before it in the name of attracting more people, we loose
the elegance.  I'm for keeping the tastefulness.

  Brantley
	`If you want PL/I you know where to get it.' -- Dennis Ritchie

> Both of those things said, I agree that gnome/gtk/gdk is not very
> 9ish.  However, having them available will make Plan 9 more accessible
> to a wider user and developer community, which seems to me likely to
> be positive.

Re: [9fans] gtk port

[arisawa]

Hello.

>> Suppose NEXTSTEP like environment on Plan 9. It is very good
>> system to both researchers and users at home, isn't it?
>plan 9 is better.
>not prettier, but much more powerful.

I love both Plan 9 and NEXTSTEP.
Both are beautiful in different meaning.
I use NEXTSTEP in writing documents.
On the other hand I work with Plan 9 for programming.

The programming environment of Plan 9 is better than NEXTSTEP
partly because C library is well organized and partly
because acme is not bad for programming.

My wife uses Windows and my son loves NEXTSTEP.
Both of them never use Plan 9.

Plan 9 and NEXTSTEP are different in concept. The difference
comes from the supposed users of these operating systems.

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp