Re: [9fans] software quality and popularity

Re: [9fans] software quality and popularity

[okamoto]

>curses?  a port of curses?  what would be the point?

Maybe simpler to write some user friendly software. ^_^

I'm considering it to replace by control(2) library, too.  However,
if 'curses' is available in Plan 9, it must be easier.

>core, it has too many functions/macros and i'm sure you'd run
>into unicode and font problems.

Aa- (Japanese:-), I see.  It's not any simpler...

Ok, I'll forget it.  Thanks Boyd!

Kenji

Re: [9fans] software quality and popularity

[Boyd Roberts]

> Ok, I'll forget it.  Thanks Boyd!

douitashimashite

Re: [9fans] software quality and popularity

[Douglas A. Gwyn]

okamoto@granite.cias.osakafu-u.ac.jp wrote:
> I rather think Douglas is somewhat confusing between research and
> product.  Plan 9 is a research oriented project, and hence, we don't
> expect 'compatibility' to the older standards.

I don't understand that response, since I wasn't arguing for
compatibility with older standards, just for good interface design.

Re: [9fans] software quality and popularity

[okamoto]

I forgot one more thing.

In the case of 2nd release, this is not so clear, because it required us
money to buy it.  In this sense, it was a product in an extent.   However,
this release is open to the world, and this is that attitude we are familier
with in the science world.   It also indicates that anyone who cannnot
understand it has no vote to make it use.  :-)  This is a logical approach
to explain what is Plan 9.  In the real world, however, many researchers 
are responding here to newbies like me...

Kenji

Re: [9fans] software quality and popularity

[okamoto]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

I rather think Douglas is somewhat confusing between research and product.
Plan 9 is a research oriented project, and hence, we don't expect 'compatibility'
to the older standards.  The purpose of research is destroying that older
concepts.  :-)  Then, I think it's enough to ask designers why you do so,
when we feel something is missing in Plan 9.  Then, if you don't like it,
you can start another project by yourself...

Kenji


[-- Attachment #2: Type: message/rfc822, Size: 2027 bytes --]

From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Cc: 
Subject: Re: [9fans] software quality and popularity
Date: Thu, 24 May 2001 12:08:33 -0400 (EDT)
Message-ID: <200105241608.MAA11543@augusta.math.psu.edu>

Brothers!  Brothers!  Don't fight!

Doug had a valid point, others disagreed with him with equally valid
points; it's not worth pursuing further.

Can we please move on now?

	- Dan C.

Re: [9fans] software quality and popularity

[Dan Cross]

Brothers!  Brothers!  Don't fight!

Doug had a valid point, others disagreed with him with equally valid
points; it's not worth pursuing further.

Can we please move on now?

	- Dan C.

Re: [9fans] software quality and popularity

[David Lukes]

> Oh great, even more whining.

I don't think he's whining,
I think he's just missing the point.

Cheers,
	Dave.

Re: [9fans] software quality and popularity

[jmk]

On Thu May 24 10:40:28 EDT 2001, DAGwyn@null.net wrote:
> jmk@plan9.bell-labs.com wrote:
> > Oh great, even more whining.
> 
> On whose part?

Ant the whine goes on.

Re: [9fans] software quality and popularity

[David Lukes]

> It is an example of a long-standing and well-known mistake
> in interface design, which *should* be one of the things
> that is "rethought" in Plan 9.  If you guys didn't keep
> implying that the only rationally-designed software is
> that in Plan 9, I might be more tolerant of your mistakes.

Personally I think an apology is warranted.
1) While it may be a "mistake" in your opinion,
   I personally think that, while it ain't perfect,
   a) it works
   b) it has no untoward side effects other than
      a slight loss of efficiency
      (if someone does a wstat with no changes,
       the worst they get is a superfluous "fsync"),
2) You should first remove the plank from your own eye,
   as shown by Mr. Hogan.
3) In all they years since V6,
   I have seen evidence that those "guys" have many qualities,
   but I have never seen anything which suggests that
   they believe in their own infallibility.

Cheers,
	Dave.

P.S. Thank you for finding a use for the expression
     "Hoist on his own petard".

Re: [9fans] software quality and popularity

[Douglas A. Gwyn]

jmk@plan9.bell-labs.com wrote:
> Oh great, even more whining.

On whose part?

Re: [9fans] software quality and popularity

[jmk]

On Thu May 24 05:17:27 EDT 2001, DAGwyn@null.net wrote:
> jmk@plan9.bell-labs.com wrote:
> > On Wed May 23 11:25:26 EDT 2001, DAGwyn@null.net wrote:
> > > Oh, great, more usurping of data values for in-band
> > > signalling of exceptional conditions.
> > Oh, great, more whining.
> 
> It is an example of a long-standing and well-known mistake
> in interface design, which *should* be one of the things
> that is "rethought" in Plan 9.  If you guys didn't keep
> implying that the only rationally-designed software is
> that in Plan 9, I might be more tolerant of your mistakes.

Oh great, even more whining.

Re: [9fans] software quality and popularity

[Douglas A. Gwyn]

David Gordon Hogan wrote:
> |    As a special case, alloca(0) reclaims storage without
> |    allocating any.  It is a good idea to use alloca(0) in
> |    your main control loop, etc. to force garbage collection.  */

The storage reclamation occurs anyway.  The documentation
is misleading; the actual "special case" is that alloca()
always reports failure to allocate storage for a 0-sized
object.  This could easily be changed (to successfully
allocate a header-only chunk, basically just remove the
short-circuit that was added to make garbage collecting
more efficient), if C were ever changed to support
0-sized objects.

By the way, my alloca implementation was meant as a
transitional measure only; I hope you're not writing new
code that relies on alloca.  It's not feasible to
implement on some architectures.

Re: [9fans] software quality and popularity

[Douglas A. Gwyn]

jmk@plan9.bell-labs.com wrote:
> On Wed May 23 11:25:26 EDT 2001, DAGwyn@null.net wrote:
> > Oh, great, more usurping of data values for in-band
> > signalling of exceptional conditions.
> Oh, great, more whining.

It is an example of a long-standing and well-known mistake
in interface design, which *should* be one of the things
that is "rethought" in Plan 9.  If you guys didn't keep
implying that the only rationally-designed software is
that in Plan 9, I might be more tolerant of your mistakes.

Re: [9fans] software quality and popularity

[David Gordon Hogan]

"Douglas A. Gwyn" <DAGwyn@null.net> writes:
>  Oh, great, more usurping of data values for in-band
>  signalling of exceptional conditions.

| /* alloca.c -- allocate automatically reclaimed memory
|    (Mostly) portable public-domain implementation -- D A Gwyn

[snip]

|    As a special case, alloca(0) reclaims storage without
|    allocating any.  It is a good idea to use alloca(0) in
|    your main control loop, etc. to force garbage collection.  */

Gotcha!

Re: [9fans] software quality and popularity

[jmk]

On Wed May 23 11:25:26 EDT 2001, DAGwyn@null.net wrote:
> jmk@plan9.bell-labs.com wrote:
> > From STAT(5):
> >  A wstat request can explicitly avoid modifying some proper-
> >  ties of the file by providing explicit ``don't touch'' val-
> >  ues in the stat data that is sent: zero-length strings for
> >  text values and the maximum unsigned value of appropriate
> >  size for integral values.  As a special case, if all the
> >  entries in a Twstat message are ``don't touch'' values, the
> >  server may interpret it as a request to guarantee that the
> >  contents of the associated file are committed to stable
> >  storage before the Rwstat message is returned.  (Consider
> >  the message to mean, ``make the state of the file exactly
> >  what it claims to be.'')
> 
> Oh, great, more usurping of data values for in-band
> signalling of exceptional conditions.

Oh, great, more whining.

Re: [9fans] software quality and popularity

[Russ Cox]

> Oh, great, more usurping of data values for in-band
> signalling of exceptional conditions.

You can't please all the people all the time.

Re: [9fans] software quality and popularity

[Douglas A. Gwyn]

jmk@plan9.bell-labs.com wrote:
> From STAT(5):
>  A wstat request can explicitly avoid modifying some proper-
>  ties of the file by providing explicit ``don't touch'' val-
>  ues in the stat data that is sent: zero-length strings for
>  text values and the maximum unsigned value of appropriate
>  size for integral values.  As a special case, if all the
>  entries in a Twstat message are ``don't touch'' values, the
>  server may interpret it as a request to guarantee that the
>  contents of the associated file are committed to stable
>  storage before the Rwstat message is returned.  (Consider
>  the message to mean, ``make the state of the file exactly
>  what it claims to be.'')

Oh, great, more usurping of data values for in-band
signalling of exceptional conditions.

Re: [9fans] software quality and popularity

[Douglas A. Gwyn]

Boyd Roberts wrote:
> curses?  a port of curses?  what would be the point?

Probably, to allow ready import of curses-based applications
such as the Crypt Breaker's Workshop.

Re: [9fans] software quality and popularity

[Douglas A. Gwyn]

William Staniewicz wrote:
> How difficult is it to port FORTRAN code to Plan9? Back a few
> years ago in the archives there were inquiries into a FORTRAN
> compiler and there appeared to be none available.

There is a Fortran-to-C translator with run-time library
under the name "f2c" in NetLib.  It works well enough for
many purposes.

Re: [9fans] software quality and popularity

[Boyd Roberts]

> > By the way, what is designer's opinion of porting a CUI like curses to Plan 9?
> 
> Let's ask Boyd.

curses?  a port of curses?  what would be the point?

been a long time since i looked into that particular mess, but it
was for use with glass ttys.  apart from it being rotten to the
core, it has too many functions/macros and i'm sure you'd run
into unicode and font problems.

the horror, the horror ...

Re: [9fans] software quality and popularity

[rob pike]

> By the way, what is designer's opinion of porting a CUI like curses to Plan 9?

Let's ask Boyd.

-rob

Re: [9fans] software quality and popularity

[okamoto]

>with the plethora of software freely available for linux/*bsd these days, if
>A does not want to compile and looks like too much work i simply fetch B 

I'm now trying to evaluate how it is difficult to port GRASS4.1, because I 
changed it too many parts for other planet, I cann't reside on a newer version :-), 
and found it's much cumbersome to port this kind of 'old' software, particularly 
in two points, (1) X11, (2) terminal emulation such as curses!, 
termios/termio/sgtty is not though.

By the way, what is designer's opinion of porting a CUI like curses to Plan 9?

Kenji

Re: [9fans] software quality and popularity

[jmk]

On Tue May 22 17:29:25 EDT 2001, cross@math.psu.edu wrote:
> In article <20010522203105.AAA6E19A21@mail.cse.psu.edu> you write:
> >(that may change, of course, once plan 9
> >displaces windows nt and linux as the dominant server 
> >operating system.)  
> 
> You'll have to add Tsync to 9P2000 before that can happen.
> 
> 	- Dan C.
> 
> (Duck!  Run!  Hit the deck!)

 From STAT(5):

 A wstat request can explicitly avoid modifying some proper-
 ties of the file by providing explicit ``don't touch'' val-
 ues in the stat data that is sent: zero-length strings for
 text values and the maximum unsigned value of appropriate
 size for integral values.  As a special case, if all the
 entries in a Twstat message are ``don't touch'' values, the
 server may interpret it as a request to guarantee that the
 contents of the associated file are committed to stable
 storage before the Rwstat message is returned.  (Consider
 the message to mean, ``make the state of the file exactly
 what it claims to be.'')

Re: [9fans] software quality and popularity

[Eric Grosse]

> How difficult is it to port FORTRAN code to Plan9?

We use f2c (http://plan9.bell-labs.com/netlib/f2c/) to convert Fortran to C,
and don't feel a strong need for a native Fortran compiler.

Re: [9fans] software quality and popularity

[William Staniewicz]

Lately I have been in a "retro" mood and so maybe that is
why I bring up another point relating to code.

How difficult is it to port FORTRAN code to Plan9? Back a few
years ago in the archives there were inquiries into a FORTRAN
compiler and there appeared to be none available.
Would it be a good idea to have one to support some
of the applications in the number crunching world?

		-Bill

On Tue, May 22, 2001 at 10:10:37PM +0200, Boyd Roberts wrote:
> From: "Richard Uhtenwoldt" <ru@river.org>
> > ... code written for Unix is difficult to port to Plan 9
> 
> it's not that hard, but it depends on what sort of unix braindamage
> you've got to port.  i did a very rough port of 10k lines of unix
> code to plan 9 in two days.  of course, sam made the task a lot
> easier and the code was pretty modular and ran on a variety of
> unix varients -- without 'configure'!
> 

Re: [9fans] software quality and popularity

[andrey mirtchovski]

On Tue, 22 May 2001, Boyd Roberts wrote:

> From: "Richard Uhtenwoldt" <ru@river.org>
> > ... code written for Unix is difficult to port to Plan 9
> 
> it's not that hard, but it depends on what sort of unix braindamage
> you've got to port.  i did a very rough port of 10k lines of unix
> code to plan 9 in two days.  of course, sam made the task a lot
> easier and the code was pretty modular and ran on a variety of
> unix varients -- without 'configure'!

i have both good and bad experiences in trying to get unix stuff running on
p9... in my opinion it all depends on how clean and well written the unix
code is...

with the plethora of software freely available for linux/*bsd these days, if
A does not want to compile and looks like too much work i simply fetch B and
give it a try.. in most cases the differences in the actual product are
minimal..

andrey

Re: [9fans] software quality and popularity

[Dan Cross]

In article <20010522203105.AAA6E19A21@mail.cse.psu.edu> you write:
>(that may change, of course, once plan 9
>displaces windows nt and linux as the dominant server 
>operating system.)  

You'll have to add Tsync to 9P2000 before that can happen.

	- Dan C.

(Duck!  Run!  Hit the deck!)

Re: [9fans] software quality and popularity

[Russ Cox]

the "unix code is harder to port to plan 9
than plan 9 code is to port to unix" observation,
while empirically true, is not a function of
those systems so much as the code itself.
as boyd points out, there exist portable programs
written for unix.  it's more a question of 
whether the author thought about good interfaces,
and to date plan 9 software has a better history
of that.  (that may change, of course, once plan 9
displaces windows nt and linux as the dominant server 
operating system.)  

Re: [9fans] software quality and popularity

[Boyd Roberts]

From: "Richard Uhtenwoldt" <ru@river.org>
> ... code written for Unix is difficult to port to Plan 9

it's not that hard, but it depends on what sort of unix braindamage
you've got to port.  i did a very rough port of 10k lines of unix
code to plan 9 in two days.  of course, sam made the task a lot
easier and the code was pretty modular and ran on a variety of
unix varients -- without 'configure'!

hardest part was the mailbox locking protocol and the:

    From ...

    ...

    morF

stuff.

[9fans] software quality and popularity

[Richard Uhtenwoldt]

geoff.9fans@collyer.net writes:

>Popularity and quality are not related.  (A more pessimistic view is
>that they are related, but inversely.  The current state of operating
>systems, languages and software generally tends to support that view.)

William K. Josephson writes:

>In fact, in my experience, the Plan 9
>source code is far *more* portable to other environments than most
>Unix source is between Unix variants, for instance.

well, you see, if all code written for Plan 9 can be easily ported to
Unix, but the code written for Unix is difficult to port to Plan 9
(because Unix is not as well thought out and well factored as Plan 9),
then people who want to use apps without having to port/rewrite/write
them will choose  Unix, because the apps available for Unix will
tend to be a superset of the apps available for Plan 9.

so here we have a process whereby bad engineering actually 
increases a platform's popularity.  (Dijkstra noted a similar process
back in the 1970s in which DP department workers increased their job
security by choosing overly complex solutions, which IBM was happy to
sell to them.)

and even people like me, who appreciate well-engineered, well-factored
software, choose to use one of the popular, poorly-engineered
platforms, because the socioeconomic utility of a platform is
essentially proportional to the number of users of the platform.
(reasons for this omitted for space reasons.)  so, I put up with the
cost in my wasted time of the poor engineering to get the
socioeconomic benefits of the popularity.

eventually a critical mass of (millions of) users will come to
recognize the true costs of poorly-engineered software, resulting in
popular software as well-engineered as Plan 9, but that is not going
to happen this decade.

what is going happen this decade to help along the eventual popularity
of well-engineered software more than anything else is the replacement
of data formats, communications protocols, APIs with secrets and
"owners" (firms with the ability to prevent their competitors from
making full use of the data format, etc) with data formats, protocols
and APIs without secrets and owners.

so, even tho the open-source platforms like Linux are poorly
engineered, the more popular they get, the better for unpopular
platforms, and thus well-engineered platforms in the long term,
because Linux's data formats, protocols and APIs have no secrets and
no "owners" so that the unpopular platforms can hook into them more
effectively.  one example of this hooking in is the consulting of
Linux device-driver source code by Plan 9 developers.

this hooking in gives the users of the unpopular platform a bigger
fraction of the socioeconomic benefits of Linux than they could get
from the unpopular platform's trying to hook into proprietary
platforms, because the "owners" of the proprietary platforms will tend
to prevent competition from other platforms by denying those benefits.