[9fans] ports from GPL

[9fans] ports from GPL

[Fernan Bolando]

I was just wondering ...

If a port for plan9 using APE or native that where derived from from
GPL or others. Are they considered forks of the original or are they
eventually going to be merged in.

--
Public PGP/GnuPG key (http://www.fernski.com)
pub 1024D/3576CA71 2006-02-02 Fernan Bolando
Key fingerprint = FDFE C9A8 FFED C1A5 2F5C EFEB D595 AF1C 3576 CA71

Re: [9fans] ports from GPL

[Anthony Sorace]

that depends entirely on the originating project. when folks have
ported existing open-source applications in the past, results have
been mixed. some projects have been willing to merge any changes or
additions needed to support plan 9 (although in every such case i'm
aware of, the plan 9-specific stuff subsequently rotted due to lack of
exercise and/or maintenance); most, sadly, seem like they can't be
bothered.

Re: [9fans] ports from GPL

[Jack Johnson]

On 3/16/06, Anthony Sorace <anothy@gmail.com> wrote:
> additions needed to support plan 9 (although in every such case i'm
> aware of, the plan 9-specific stuff subsequently rotted due to lack of
> exercise and/or maintenance); most, sadly, seem like they can't be
> bothered.

If there are bits that are critical to people, it would probably be
worthwhile to adopt one and be responsibile for babysitting it,
contacting the developer and the Plan 9 community whenever there are
patches and/or updates in either direction.

We have this going on right now very informally, but mainly out of
mercy.  And heck, people have day jobs (I hope).  I'm just thinking
some kind of tickler in the wiki saying, "If you have problems with
python, email me at ...."

Speaking of which, do my eyes deceive me or did 9pm get updated on
Halloween?  How did I miss that?

Anyone know what might have changed?

-Jack

Re: [9fans] ports from GPL

[erik quanstrom]

i don't think that you're hitting on the main problem.

i think that open source code has a very different outlook
on the world than plan 9. it's very hard (and frustrating) to
deal with the culture clash when porting.

i don't think it's a case of laziness.

- erik

"Anthony Sorace" <anothy@gmail.com> writes

|
| that depends entirely on the originating project. when folks have
| ported existing open-source applications in the past, results have
| been mixed. some projects have been willing to merge any changes or
| additions needed to support plan 9 (although in every such case i'm
| aware of, the plan 9-specific stuff subsequently rotted due to lack of
| exercise and/or maintenance); most, sadly, seem like they can't be
| bothered.

Re: [9fans] ports from GPL

[Brantley Coile]

> i think that open source code has a very different outlook
> on the world than plan 9. it's very hard (and frustrating) to
> deal with the culture clash when porting.

That brings to mind something that I've been thinking about for a
couple of years.  In watching the stuff in Linux and poking around the
simulators and old code, I can see at least three different cultures.
Murry Hill (Bell Labs), 545 Technology Sq (MIT), and Berkeley.  These
cultures have belief systems that are mutually exclusive.  And there
must be subcultures as well.  The socket interface, for example, is
really MIT culture thru BBN to BSD.

Anyone else see this?  More cultures?

Re: [9fans] ports from GPL

[Axel Belinfante]

> > i think that open source code has a very different outlook
> > on the world than plan 9. it's very hard (and frustrating) to
> > deal with the culture clash when porting.
>
> That brings to mind something that I've been thinking about for a
> couple of years.  In watching the stuff in Linux and poking around the
> simulators and old code, I can see at least three different cultures.
> Murry Hill (Bell Labs), 545 Technology Sq (MIT), and Berkeley.  These
> cultures have belief systems that are mutually exclusive.  And there
> must be subcultures as well.  The socket interface, for example, is
> really MIT culture thru BBN to BSD.
>
> Anyone else see this?  More cultures?

Cannot help with that.

Is there a compact description of these cultures,
and/or the differences between them?

Re: [9fans] ports from GPL

[Ronald G Minnich]

Brantley Coile wrote:

> Anyone else see this?  More cultures?
>
>

One of the more interesting to me is waserror()/poperror() vs. goto.

Also, I've realized nobody in Unix understands Plan 9. It took me a
while. The worst thing ever done was to say that in Plan 9, 'everything
is a file'. It's not. It would have been much better to say 'everything
is a server', maybe. But the 'everything is a file' totally muddies the
discussion, and confuses people, to the point that you actually have to
unwind the discussion and start over -- each and every time.

ron

Re: [9fans] ports from GPL

[Dave Eckhardt]

> Also, I've realized nobody in Unix understands Plan 9.  It took
> me a while.

It's a deceptive situation, somewhat similar to infix versus postfix
calculators.  After all, both of them have + and - buttons.  "But
where's =?" "There's not supposed to be an =."  "Why would anybody
want to learn how to use a calculator that doesn't have =?".

> The worst thing ever done was to say that in Plan 9, 'everything
> is a file'.  It's not.

I try to say "Everything is a small file *system*" but it's hard
to remember every time.

Dave Eckhardt

Re: [9fans] ports from GPL

[Skip Tavakkolian]

> I try to say "Everything is a small file *system*" but it's hard
> to remember every time.

i say everything is a service, shown as a file tree.

Re: [9fans] ports from GPL

[Russ Cox]

I've never had any problem saying that
everything is a file.  I usually emphasize
that that means not just the things that
are files on Unix.  Saying everything is a
file server or a file system sounds pedantic
yet less precise.

The real problem with trying to summarize
Plan 9 with a sentence like that is that you're
missing 2/3 of the syllogism.  The rest is
there is a simple way to share files, and
therefore you can share everything.

Russ

Re: [9fans] ports from GPL

[Charles Forsyth]

> Also, I've realized nobody in Unix understands Plan 9.  It took
> me a while.

i strongly suspect that many people in Unix didn't understand Unix

Re: [9fans] ports from GPL

[ems]

I prefer "everything is accessed like a file"

-- ems
On Fri, 2006-03-17 at 08:39 -0700, Ronald G Minnich wrote:
> Brantley Coile wrote:
>
> > Anyone else see this?  More cultures?
> >
> >
>
> One of the more interesting to me is waserror()/poperror() vs. goto.
>
> Also, I've realized nobody in Unix understands Plan 9. It took me a
> while. The worst thing ever done was to say that in Plan 9, 'everything
> is a file'. It's not. It would have been much better to say 'everything
> is a server', maybe. But the 'everything is a file' totally muddies the
> discussion, and confuses people, to the point that you actually have to
> unwind the discussion and start over -- each and every time.
>
> ron

Re: [9fans] ports from GPL

[Bruce Ellis]

as it was intended.

On 3/24/06, ems <oat@iinet.net.au> wrote:
> I prefer "everything is accessed like a file"
>
> -- ems
> On Fri, 2006-03-17 at 08:39 -0700, Ronald G Minnich wrote:
> > Brantley Coile wrote:
> >
> > > Anyone else see this?  More cultures?
> > >
> > >
> >
> > One of the more interesting to me is waserror()/poperror() vs. goto.
> >
> > Also, I've realized nobody in Unix understands Plan 9. It took me a
> > while. The worst thing ever done was to say that in Plan 9, 'everything
> > is a file'. It's not. It would have been much better to say 'everything
> > is a server', maybe. But the 'everything is a file' totally muddies the
> > discussion, and confuses people, to the point that you actually have to
> > unwind the discussion and start over -- each and every time.
> >
> > ron
>

Re: [9fans] ports from GPL

[Ronald G Minnich]

ems wrote:
> I prefer "everything is accessed like a file"

I haven't seen that many files I write to that have side effects on
other files.

/dev/eia0ctl for example.

I'm still not comfortable with that phrasing. It's amazing how it gets
misinterpreted by Unix and Windows folks ...

ron

Re: [9fans] ports from GPL

[erik quanstrom]

this should be familiar to anyone who's used linux:

	cat /proc/sys/net/ipv?/ip_forward
	for(i in /proc/sys/net/*/ip_forward)
		echo 1>$i

- erik

Ronald G Minnich <rminnich@lanl.gov> writes

|
| ems wrote:
| > I prefer "everything is accessed like a file"
|
| I haven't seen that many files I write to that have side effects on
| other files.
|
| /dev/eia0ctl for example.
|
| I'm still not comfortable with that phrasing. It's amazing how it gets
| misinterpreted by Unix and Windows folks ...
|
| ron

Re: [9fans] ports from GPL

[Ronald G Minnich]

Wes Kussmaul wrote:

> I have learned that you do the new-new thing a disservice if you yield
> to the common desire to force it into a readily comprehended semantic
> box. Make 'em choose between ignoring it or doing a little mental work.
> (Disregard this advice if you're trying to sell something.)
>

I'm trying to sell something :-)

ron

Re: [9fans] ports from GPL

[Wes Kussmaul]

Ronald G Minnich wrote:

> ems wrote:
>
>> I prefer "everything is accessed like a file"
>
>
> I'm still not comfortable with that phrasing. It's amazing how it gets 
> misinterpreted by Unix and Windows folks ...

Call it a new and different operating system and leave it at that.

I have learned that you do the new-new thing a disservice if you yield 
to the common desire to force it into a readily comprehended semantic 
box. Make 'em choose between ignoring it or doing a little mental work. 
(Disregard this advice if you're trying to sell something.)

-- 
Wes Kussmaul
CIO
The Village Group
738 Main Street
Waltham, MA 02451

781-647-7178


My uncle likes to say that the world’s biggest troubles started when the serpent said, “Try this fruit, and by the way if a bunch of people collectively calling themselves Arthur Andersen signs something it’s the same as if a person named Arthur Andersen signed it.” I don’t get the serpent and fruit part. Must be some Swiss mythology thing. He can be a bit obscure. 

                         P.K. Iggy
                         _How I Like Fixed The Internet_
                           (Tales from the Great Infodepression of 2009
                           and the prosperity that followed)

Re: [9fans] ports from GPL

[Wes Kussmaul]

Ronald G Minnich wrote:

> Wes Kussmaul wrote:
>
>> I have learned that you do the new-new thing a disservice if you 
>> yield to the common desire to force it into a readily comprehended 
>> semantic box. Make 'em choose between ignoring it or doing a little 
>> mental work. (Disregard this advice if you're trying to sell something.)
>
> I'm trying to sell something :-)

Ah then it's

New! From the folks who brought you the amazing Unix! It's easy, it's 
fast, it goes down easy! Comes in three delicious flavors! Choose 
between yummy Plan 9, delicious Inferno, scrumptious OzInferno!

-- 
Wes Kussmaul
CIO
The Village Group
738 Main Street
Waltham, MA 02451

781-647-7178


My uncle likes to say that the world’s biggest troubles started when the serpent said, “Try this fruit, and by the way if a bunch of people collectively calling themselves Arthur Andersen signs something it’s the same as if a person named Arthur Andersen signed it.” I don’t get the serpent and fruit part. Must be some Swiss mythology thing. He can be a bit obscure. 

                         P.K. Iggy
                         _How I Like Fixed The Internet_
                           (Tales from the Great Infodepression of 2009
                           and the prosperity that followed)

Re: [9fans] ports from GPL

[ems]

It still is accessed as a file...

Maybe Plan 9 has surpassed the limitations of English?

-- ems
On Fri, 2006-03-24 at 10:14 -0700, Ronald G Minnich wrote:
> ems wrote:
> > I prefer "everything is accessed like a file"
>
> I haven't seen that many files I write to that have side effects on
> other files.
>
> /dev/eia0ctl for example.
>
> I'm still not comfortable with that phrasing. It's amazing how it gets
> misinterpreted by Unix and Windows folks ...
>
> ron

Re: [9fans] ports from GPL

[Jack Johnson]

On 3/20/06, Aharon Robbins <arnold@skeeve.com> wrote:
> Although in my youth I was prey to feeping creaturism, I have tried
> harder in recent years to curb the feature spread.  9fans is certainly
> an influence there.

Speaking of GNU features and 9isms, I always thought this was
interesting (though haven't messed around with it:

http://www.gnu.org/software/gawk/manual/gawkinet/gawkinet.html#TCP-Connecting

-Jack

Re: [9fans] ports from GPL

[dmr]

 > the official awk (from the aho, kernighan, weinberger book)
 > is available on the net, isn't it? i have a copy from 1993, if
 > you can't find it.

http://www.cs.bell-labs.com/cm/cs/awkbook/index.html .
It says the source was updated Apr 2005.

	Dennis

Re: [9fans] ports from GPL

[erik quanstrom]

Aharon Robbins <arnold@skeeve.com> writes

| And yes, the locale stuff is a *N*I*G*H*T*M*A*R*E*.  Much of the heavy
| lifting was done by others for the dfa and regex code, but I've done
| my share to get it working too, and I must admit it's often a PITA.

yes, and worst of all, it's done in an ad-hoc way with code that would be
nearly impossible to verify. (speaking of spin.)

- erik

Re: [9fans] ports from GPL

[erik quanstrom]

the official awk (from the aho, kernighan, weinberger book)
is available on the net, isn't it? i have a copy from 1993, if
you can't find it.

- erik

On Mon Mar 20 14:05:45 CST 2006, ggm@apnic.net wrote:
>
> what about awka? ok, so compiling awk to C and then compiling it is
> probably overkill, but its kinda cute too..
>
> NetBSD is nawk. it still carries lucent tags. and
>
> 	/* lasciate ogne speranza, voi ch'entrate. */
>
> comments..
>
> -G

Re: [9fans] ports from GPL

[Aharon Robbins]

In article <20060320021808.91DE411FC1@dexter-peak.quanstro.net> you write:
>the gnu awk folks are doing a pretty good job, given their constraints.

Thanks!  I try, I really do.

>i have not read the sed code (for a while, anyway), but i could imagine
>that it may have the same character set problems as newer versions of gnu grep.
>gnu grep calls mbtowc for each input character, even when not required.
>
>have you tried your test with LC_LANG=C?

Make that LC_ALL=C and you'll be on track. (FWIW, the CVS grep is much
better than the released version; they've been working on this problem.)

And yes, the locale stuff is a *N*I*G*H*T*M*A*R*E*.  Much of the heavy
lifting was done by others for the dfa and regex code, but I've done
my share to get it working too, and I must admit it's often a PITA.

Almost always the differences in behavior from LC_ALL=C to LC_ALL=xxx.UTF-8
are due to the locale definitions, not to gawk's handling of UTF
characters.  That all happens in the (GNU) library, below the level
where I can do anything about it.

OTOH, when I get fan mail from people in China and other such places
who are able to *get their work done* using gawk, it makes things
much more worthwhile.

And, to completely change the subject, if anyone on this list wants to
hire a telecommuter who would LOVE to finally make the jump to Plan 9
without looking back, please drop me a line...

Arnold
--
Aharon (Arnold) Robbins --- Pioneer Consulting Ltd.	arnold AT skeeve DOT com
P.O. Box 354		Home Phone: +972  8 979-0381	Fax: +1 206 350 8765
Nof Ayalon		Cell Phone: +972 50  729-7545
D.N. Shimshon 99785	ISRAEL

Re: [9fans] ports from GPL

[George Michaelson]

what about awka? ok, so compiling awk to C and then compiling it is
probably overkill, but its kinda cute too..

NetBSD is nawk. it still carries lucent tags. and

	/* lasciate ogne speranza, voi ch'entrate. */

comments..

-G

Re: [9fans] ports from GPL

[Aharon Robbins]

In article <3e1162e60603190643y169561detb46ccbf0e11be30e@mail.gmail.com> you write:
>As an aside, I was finding that later versions of GNU Awk were
>outrunning GNU Sed (Well I assume it was GNU sed.)  The authors of the
>Sed and Awk O'Reilly book saw the same behavior, which was a reversal
>of what they saw in the first edition of the book :-).
>
>I wonder who spent so much time speeding up awk and ignoring sed? :)

That would be David Trueman, and me.  The gawk design runs faster than
the original awk, although Mike Brennan's awk is usually faster still.

One reason gawk is faster than sed is the incorporation of the GNU grep
dfa engine for pattern matching operations, falling back to the heavier weight
regex engine only when it's necessary to know the location of the match
(think RS, FS, sub, gsub).

There are other reasons too: careful use of raw I/O for input, lots of
caching, etc.

The code is in K&R style with honest-to-goodness tabs, and IMHO fairly
readable.

Although in my youth I was prey to feeping creaturism, I have tried
harder in recent years to curb the feature spread.  9fans is certainly
an influence there.

BTW, if anyone wishes to (a) get gawk running under Plan 9, and (b) sign
the paperwork, I'll be happy to incorporate the changes.
--
Aharon (Arnold) Robbins --- Pioneer Consulting Ltd.	arnold AT skeeve DOT com
P.O. Box 354		Home Phone: +972  8 979-0381	Fax: +1 206 350 8765
Nof Ayalon		Cell Phone: +972 50  729-7545
D.N. Shimshon 99785	ISRAEL

Re: [9fans] ports from GPL

[erik quanstrom]

uriel@cat-v.org writes

|
| > the gnu awk folks are doing a pretty good job, given their constraints.
| >
| > i have not read the sed code (for a while, anyway), but i could imagine
| > that it may have the same character set problems as newer versions of gnu grep.
| > gnu grep calls mbtowc for each input character, even when not required.
| >
| > have you tried your test with LC_LANG=C?
|
| I have seen GNU awk produce different matches with LC_ALL=UTF-8 than
| with LC_ALL=C when input was plain ASCII (only digits!)

can you give an example script and example input that exhibits this?

Re: [9fans] ports from GPL

[uriel]

> the gnu awk folks are doing a pretty good job, given their constraints.
>
> i have not read the sed code (for a while, anyway), but i could imagine
> that it may have the same character set problems as newer versions of gnu grep.
> gnu grep calls mbtowc for each input character, even when not required.
>
> have you tried your test with LC_LANG=C?

I have seen GNU awk produce different matches with LC_ALL=UTF-8 than
with LC_ALL=C when input was plain ASCII (only digits!)

Since then at the top of all unix shell scripts I add LC_LANG=C, not
for performance reasons, but because otherwise things often break in
subtle and very hard to debug ways, really sad.

I wonder how many more years we will have to wait until any unix
system supports UTF-8 properly.

Only thing that excuses GNU is that the locale system is not entirely
their fault, locales are probably one of the worst ideas in the
history of Unix, if not the worst.

I will ignore the subject of UTF-8 support in terminal
emulators, many books could be written about the various kinds of
braindamage in this area.  Thank God for 9term.

> | I wonder who spent so much time speeding up awk and ignoring sed? :)

A program that produces incorrect results twice as fast is infinitely slower.
    -- John Osterhout

I wonder how many thousands of man-years have been wasted due to
locale-related braindamage.

uriel

Re: [9fans] ports from GPL

[erik quanstrom]

the gnu awk folks are doing a pretty good job, given their constraints.

i have not read the sed code (for a while, anyway), but i could imagine
that it may have the same character set problems as newer versions of gnu grep.
gnu grep calls mbtowc for each input character, even when not required.

have you tried your test with LC_LANG=C?

- erik

"David Leimbach" <leimy2k@gmail.com> writes

|
| On 3/17/06, geoff@collyer.net <geoff@collyer.net> wrote:
| > > however gnu has devolved.  they seem to value compiling on anything,
| > > and efficiency, but they don't seem to value simplicity.
| >
| > It's a skewed form of concern about efficiency though.  In the case of
| > gcc, they worry about run-time of the generated program, but not about
| > the time it takes to compile it.  gcc seems to get slower with each
| > release.  I don't know if gcc 4 is the slowest C compiler on the
| > planet (I suspect that Henry Spencer's never-finished aacc, written in
| > awk, might take that title), but it's the slowest one I've used.
| >
| >
| As an aside, I was finding that later versions of GNU Awk were
| outrunning GNU Sed (Well I assume it was GNU sed.)  The authors of the
| Sed and Awk O'Reilly book saw the same behavior, which was a reversal
| of what they saw in the first edition of the book :-).
|
| I wonder who spent so much time speeding up awk and ignoring sed? :)

Re: [9fans] ports from GPL

[David Leimbach]

On 3/17/06, geoff@collyer.net <geoff@collyer.net> wrote:
> > however gnu has devolved.  they seem to value compiling on anything,
> > and efficiency, but they don't seem to value simplicity.
>
> It's a skewed form of concern about efficiency though.  In the case of
> gcc, they worry about run-time of the generated program, but not about
> the time it takes to compile it.  gcc seems to get slower with each
> release.  I don't know if gcc 4 is the slowest C compiler on the
> planet (I suspect that Henry Spencer's never-finished aacc, written in
> awk, might take that title), but it's the slowest one I've used.
>
>
As an aside, I was finding that later versions of GNU Awk were
outrunning GNU Sed (Well I assume it was GNU sed.)  The authors of the
Sed and Awk O'Reilly book saw the same behavior, which was a reversal
of what they saw in the first edition of the book :-).

I wonder who spent so much time speeding up awk and ignoring sed? :)

Re: [9fans] ports from GPL

[geoff]

You're confusing tops-10 and tops-20.  Both were pdp-10 operating
systems.

tops-10 was a fairly ordinary timesharing system, built by DEC and
probably with contributions from MIT in the early days.  It started
out as the operating system for the pdp-6.  Each login session was one
process (a `job'), there was no fork system call and the command
interpreter was wired into the kernel.

tops-20 was DEC's evolution of BBN's Tenex, which was a much more
interesting system, inspired by Multics.  It had a fork system call
and the command interpreter was an ordinary program, named `exec'.  A
fairly common host on the ARPAnet in the 1970s was a pdp-10 running
Tenex or tops-20.  It looks (to me at least) like Joy et al at
Berkeley were familiar with Tenex and it influenced their thinking
about how to do networking in 4.2BSD.

David N. Cutler created RSX-11M by severely editing RSX-11D, thus
creating the system that DEC's pdp-11 customers thought of as DEC's
timesharing system, though it was nominally a multi-user real-time
system (without typeahead) and DEC also offered RSTS, if you could
live with BASIC as the only programming language.

Cutler was the architect of VMS for the VAX, which looked to me like
RSX on steroids.  Indeed, the early VMS utilities were RSX pdp-11
binaries running in hardware and software compatibility modes.  I
don't see much tops-10 or tops-20 influence in VMS, though I didn't
use VMS much.  It sure didn't learn much from Unix.  Process creation
was a big deal, requiring an act of congress and sacrifice of goats.

Cutler left DEC for Microsoft, and was the architect of Windows NT
(WNT = VMS + 111).  Process creation continued to require acts of
congress and goats.

Re: [9fans] ports from GPL

[Brantley Coile]

> I'm not trying to say sockets were 'right' -But that in context, if you
> came from a tops-10 world, or a VMS world (mailbox I/O..) that they
> were certainly no more awful than things you'd had to do, and compared
> to eg /dev/tty (which WAS the network for many people) were
> considerably better.

Someone once commented that the socket interface was a lot like the
tops-10 interfaces for things.  A collection of such techniques and
methods is what I'm calling a culture.  People from the tops-10
influenced VMS who influenced WindowsNT (or implemented it).  Tops-10
started at BBN.  TCP was, as Dr. Ritchie points out, started at BBN
and was filtered into BSD.  The CTSS and Multics influenced the
culture of of Unix.

>
> Stallmans gnu manifesto emerged at around the same time. I remember
> getting both the AT&T getopt and this manifesto off UUCP news at leeds
> at broadly contemporay times.

Somewhere I should still have my getopt card from the 1981 (I think) Usenix.


Which culture produced the 10,000 line manual page for the C compiler?
The whole V6 C Reference Manual was only 2,500 lines.

Re: [9fans] ports from GPL

[erik quanstrom]

interesting.  off the top of my head i saw two similar sorts on
the tiac.net (below). there was one that picked a random i, j
to compare.  but you have the added advantage of computing each
full solution in advance.  there was at least one O(N^3) algorithm
that used an auxillary bit array to keep track of itself.

- erik

On Sat Mar 18 12:48:23 CST 2006, 9nut@9netics.com wrote:
> has anyone done a lotterysort? something like:
>
> array lotterysort(array a) {
> 	forever {
> 		array b = randomize(a)
> 		int i = 1
> 		while (b[i] > b[i-1] && i < size(b))
> 			i++
>
> 		if (i >= size(b)) return b
> 	}
> }
>
> > references:
> > 	http://home.tiac.net/~cri/2001/badsort.html
> > 	http://www.iq0.com/duffgram/silly.c
> >
> > - erik
> >
> > On Sat Mar 18 08:05:10 CST 2006, quanstro@quanstro.net wrote:
> >
> >> actually i think rtl ends up doing this: (quoted from tom duff's
> >> sillysort)
>

Re: [9fans] ports from GPL

[Skip Tavakkolian]

has anyone done a lotterysort? something like:

array lotterysort(array a) {
	forever {
		array b = randomize(a)
		int i = 1
		while (b[i] > b[i-1] && i < size(b))
			i++

		if (i >= size(b)) return b
	}
}

> references:
> 	http://home.tiac.net/~cri/2001/badsort.html
> 	http://www.iq0.com/duffgram/silly.c
>
> - erik
>
> On Sat Mar 18 08:05:10 CST 2006, quanstro@quanstro.net wrote:
>
>> actually i think rtl ends up doing this: (quoted from tom duff's
>> sillysort)

Re: [9fans] ports from GPL

[George Michaelson]

On Fri, 17 Mar 2006 21:03:04 -0500

> I'm reasonably sure that the socket interface was Berkeley's.
> BBN was tasked by ARPA to develop the TCP/IP stack for BSD,
> but UCB's CSRG was quite resistant to incorporating the BBN
> work in favor of their own.  This was the major subject of
> several somewhat messy meetings of ARPA's BSD advisory board.
> I no longer remember what the BBN ideas were for the
> programming interface to networks; they may have contained
> the germ of the socket scheme.

As initially released in 4.2, it didn't work. You could crash the host
with a unix domain socket, and we did at leeds until they sent the
patch. Since there were no ethernet drivers yet, we had ludicrously
huge S-100 backplane crates which interfaced the ethernet as serial
protocol, and we did tip and cu between the unix host and the VMS host.

I think I can sort of relate to what they were thinking of. At one
level, a file handle is very very local. its hard to divorce yourself
from the idea its a nexus between code, the kernel and blocks on a
disk. Making a separate abstraction provided some sense it might be a
persistent object which had state either end, changing in ways which
were different to you having a file open, moving to a filepos and
writing bytes.

The tty interface being so wierd, it hurt like hell sometimes to do
file i/o over /dev/tty. you had to understand ioctl() hell to make
things work. Having a totally clean abstraction (ok, so it wasn't
totally clean, but it FELT cleaner) with an explicit -setsockopt()
looked ok.

I'm not trying to say sockets were 'right' -But that in context, if you
came from a tops-10 world, or a VMS world (mailbox I/O..) that they
were certainly no more awful than things you'd had to do, and compared
to eg /dev/tty (which WAS the network for many people) were
considerably better.

>
> On the other hand, the --longoption convention (mod the -- vs -)
> espoused by all recent GNU stuff is a reversion to Multics
> conventions that were taken out of early Unix with its mostly 1-char
> options, and which were generally followed by BSD.

You're eliding a lot of history over the release of getopt code here. I
seem to recall about 3 different versions of this floating around, all
offering a 'new way' to specify commandline args.

Stallmans gnu manifesto emerged at around the same time. I remember
getting both the AT&T getopt and this manifesto off UUCP news at leeds
at broadly contemporay times.

-George

>
> 	Dennis
>

Re: [9fans] ports from GPL

[erik quanstrom]

references:
	http://home.tiac.net/~cri/2001/badsort.html
	http://www.iq0.com/duffgram/silly.c

- erik

On Sat Mar 18 08:05:10 CST 2006, quanstro@quanstro.net wrote:

> actually i think rtl ends up doing this: (quoted from tom duff's
> sillysort)

Re: [9fans] ports from GPL

[erik quanstrom]

hey, i don't think that old assumptions about inline are the
reason that gcc is slow and large.

the major reason is design. gcc takes many passes over the data,
transforming it first into a parse tree, then into rtl and then
optimizes the rtl. (i think they do strength reduction, &c
in rtl, using some arch-specific tables to compute costs.)

the problem is that rtl must handle every arch and every
language that gcc supports, making it slow and cumbersome.

actually i think rtl ends up doing this: (quoted from tom duff's
sillysort)

/*
 * The time complexity of this thing is O(n^(a log n))
 * for some constant a. This is a multiply and surrender
 * algorithm: one that continues multiplying subproblems
 * as long as possible until their solution can no longer
 * be postponed.
 */

- erik

On Sat Mar 18 07:32:05 CST 2006, brantley@coraid.com wrote:
> > their major mistake, apart from not thinking before coding, is that all
> > of those stupid inlines blow your cache and ken is clever.
>
> This is a big deal.  Assumptions learned early in our careers had very
> hard to change.  A few years back I wrote a DES implementaiton that on
> 0 loops.  Ran like a dog because it pretty much filled the cache.  Hard
> to stop thinking that memory isn't flat.
>

Re: [9fans] ports from GPL

[Brantley Coile]

> indeed .. the newer x86 are optimized to essentially use
> the cache as register windows and call/ret to be fast.

So I guess all that register coloring is a waste.

Re: [9fans] ports from GPL

[Brantley Coile]

> their major mistake, apart from not thinking before coding, is that all
> of those stupid inlines blow your cache and ken is clever.

This is a big deal.  Assumptions learned early in our careers had very
hard to change.  A few years back I wrote a DES implementaiton that on
0 loops.  Ran like a dog because it pretty much filled the cache.  Hard
to stop thinking that memory isn't flat.

Re: [9fans] ports from GPL

[Bruce Ellis]

indeed .. the newer x86 are optimized to essentially use
the cache as register windows and call/ret to be fast.

rms and his clan don't read the books.

brucee

On 3/18/06, Tim Wiess <tim@nop.cx> wrote:
> > their major mistake, apart from not thinking before coding, is that
> > all of those stupid inlines blow your cache and ken is clever.
>
>    this is very true. i'm always amazed to see how often that
>    keyword is abused these days.

Re: [9fans] ports from GPL

[Tim Wiess]

> their major mistake, apart from not thinking before coding, is that
> all of those stupid inlines blow your cache and ken is clever.

    this is very true. i'm always amazed to see how often that
    keyword is abused these days.

Re: [9fans] ports from GPL

[Bruce Ellis]

i can compile the entire plan9 distribution in less time that it
takes to compile the newest and best GCC.

i'm sure that 5.0 won't even fit on my disk (when the monkeys
stop typing).

and kenc produces better code under most non-contrived programs.
their major mistake, apart from not thinking before coding, is that all
of those stupid inlines blow your cache and ken is clever.

brucee

On 3/18/06, dmr@plan9.bell-labs.com <dmr@plan9.bell-labs.com> wrote:
> Coile remarked
>
>  > ...  I can see at least three different cultures.
>  > Murry Hill (Bell Labs), 545 Technology Sq (MIT), and Berkeley.  These
>  > cultures have belief systems that are mutually exclusive.  And there
>  > must be subcultures as well.  The socket interface, for example, is
>  > really MIT culture thru BBN to BSD.
>
> There were two markedly different groups on different
> floors of 545 Tech Sq:
> the ITS crowd (emacs, eventually GNU), vs. CTSS then
> Multics. Unix itself was influenced much more by the
> second group.
>
> I'm reasonably sure that the socket interface was Berkeley's.
> BBN was tasked by ARPA to develop the TCP/IP stack for BSD,
> but UCB's CSRG was quite resistant to incorporating the BBN
> work in favor of their own.  This was the major subject of
> several somewhat messy meetings of ARPA's BSD advisory board.
> I no longer remember what the BBN ideas were for the
> programming interface to networks; they may have contained
> the germ of the socket scheme.
>
> On the other hand, the --longoption convention (mod the -- vs -)
> espoused by all recent GNU stuff is a reversion to Multics
> conventions that were taken out of early Unix with its mostly 1-char
> options, and which were generally followed by BSD.
>
>        Dennis
>

Re: [9fans] ports from GPL

[dmr]

Coile remarked

 > ...  I can see at least three different cultures.
 > Murry Hill (Bell Labs), 545 Technology Sq (MIT), and Berkeley.  These
 > cultures have belief systems that are mutually exclusive.  And there
 > must be subcultures as well.  The socket interface, for example, is
 > really MIT culture thru BBN to BSD.

There were two markedly different groups on different
floors of 545 Tech Sq:
the ITS crowd (emacs, eventually GNU), vs. CTSS then
Multics. Unix itself was influenced much more by the
second group.

I'm reasonably sure that the socket interface was Berkeley's.
BBN was tasked by ARPA to develop the TCP/IP stack for BSD,
but UCB's CSRG was quite resistant to incorporating the BBN
work in favor of their own.  This was the major subject of
several somewhat messy meetings of ARPA's BSD advisory board.
I no longer remember what the BBN ideas were for the
programming interface to networks; they may have contained
the germ of the socket scheme.

On the other hand, the --longoption convention (mod the -- vs -)
espoused by all recent GNU stuff is a reversion to Multics
conventions that were taken out of early Unix with its mostly 1-char
options, and which were generally followed by BSD.

	Dennis

Re: [9fans] ports from GPL

[George Michaelson]

if you want to cheat, any 2-phase optimizer which analyses the output
of post compile state and/or run state to re-optimize the next compile
will take as long as you want to pause between run (a) and run (b) ...

-G

Re: [9fans] ports from GPL

[Lyndon Nerenberg]

On Mar 17, 2006, at 4:39 PM, geoff@collyer.net wrote:

> I don't know if gcc 4 is the slowest C compiler on the
> planet (I suspect that Henry Spencer's never-finished aacc, written in
> awk, might take that title), but it's the slowest one I've used.

This winner (?) has to be the Mipspro compilers with multipass code
path analysis and branch optimization turned on.  Back when I was
doing the Irix builds of the distributed.net client I would routinely
see compile times in the 10's of minutes.  Well, I tell a lie.  All
the magic happened during the link phase, but even then, it took a
loooong time.  And we had reasonably fast machines (for the day,
anyway).

--lyndon

Re: [9fans] ports from GPL

[erik quanstrom]

exactly. and my point is that the resulting code (after all that waiting),
isn't a lick faster. gcc is even slower than tcc for most of the tests that
i ran the last time i tried.

- erik

p.s. awk-cc?! ... man.

geoff@collyer.net writes

|
| > however gnu has devolved.  they seem to value compiling on anything,
| > and efficiency, but they don't seem to value simplicity.
|
| It's a skewed form of concern about efficiency though.  In the case of
| gcc, they worry about run-time of the generated program, but not about
| the time it takes to compile it.  gcc seems to get slower with each
| release.  I don't know if gcc 4 is the slowest C compiler on the
| planet (I suspect that Henry Spencer's never-finished aacc, written in
| awk, might take that title), but it's the slowest one I've used.

Re: [9fans] ports from GPL

[geoff]

> however gnu has devolved.  they seem to value compiling on anything,
> and efficiency, but they don't seem to value simplicity.

It's a skewed form of concern about efficiency though.  In the case of
gcc, they worry about run-time of the generated program, but not about
the time it takes to compile it.  gcc seems to get slower with each
release.  I don't know if gcc 4 is the slowest C compiler on the
planet (I suspect that Henry Spencer's never-finished aacc, written in
awk, might take that title), but it's the slowest one I've used.

Re: [9fans] ports from GPL

[erik quanstrom]

yes. gnu really did loose their way.

too bad. the early stuff was quite good. gnu
grep, (hi mike) for example, didn't have the limitations of
grep on sunos or xinu bsd.

now gnu grep is so broken that
	LC_LANG=utf8 grep fu j-random-file
is 80x slower than
	LC_LANG=C grep fu j-random-file

this is not entirely gnu's fault. posix confuses
locale and character set.

coreutils (which includes /bin/cp) has a 40k-line library
with over 1k preprocessor conditionals. even with that
library:

; wc -l /var/tmp/coreutils/coreutils-5.2.1/src/cat.c $home/9.cd/sys/src/cmd/cat.c
  861 /var/tmp/coreutils/coreutils-5.2.1/src/cat.c
   36 /home/quanstro/9.cd/sys/src/cmd/cat.c
  897 total

no wonder it's not very portable.

- erik

On Fri Mar 17 09:48:19 CST 2006, rminnich@lanl.gov wrote:
> erik quanstrom wrote:
>
> > however gnu has devolved.
>
> degenerated.
>
> It occured to me the other day that tex has way more useful things to
> say about portability than, say, gnu /bin/cp.
>
> Tex seems to run on anything that has an ALU and a program counter and
> more than 20 bits of address space.
>
> ron

Re: [9fans] ports from GPL

[Ronald G Minnich]

erik quanstrom wrote:

> however gnu has devolved.

degenerated.

It occured to me the other day that tex has way more useful things to
say about portability than, say, gnu /bin/cp.

Tex seems to run on anything that has an ALU and a program counter and
more than 20 bits of address space.

ron

Re: [9fans] ports from GPL

[erik quanstrom]

On Fri Mar 17 09:22:42 CST 2006, 9fans@ducky.net wrote:
>
> Emacs and Info clearly originated on MIT's "ITS" operating system,
> and were originally written by Richard Stallman, as was today's
> widely used GNU Emacs.  GCC had its roots in a "portable optimizer"
> paper written by someone at Arizona (I think), but GCC itself was
> coded in a heavily Lisp-influenced style, again by Richard Stallman.
>

it seems that gcc rtl would discredit the "portable optimizer" idea.

- erik

Re: [9fans] ports from GPL

[Mike Haertel]

>Wouldn't at least gcc be from the MIT culture given its originator was
>from the mit ai lab?  Where's readline and info from originally?
>Not to mention emacs.
>
>Where did the --option syntax originate?  Maybe they wanted to say /option
>but that's not possible under Unix.  Wouldn't the -o vs --very-long-option-name
>count as a MH vs. MIT artifact?
>
>These are real questions.  I would like to know.

Emacs and Info clearly originated on MIT's "ITS" operating system,
and were originally written by Richard Stallman, as was today's
widely used GNU Emacs.  GCC had its roots in a "portable optimizer"
paper written by someone at Arizona (I think), but GCC itself was
coded in a heavily Lisp-influenced style, again by Richard Stallman.

The --option syntax is also due (as far as I know) to Stallman and
resulted from a search for ways to add long-named options to existing
Unix programs without breaking POSIX 1003.2 compatibility.  Stallman
originally tried to use +option, but found that was directly
incompatible with POSIX, which pretty much says that anything not
beginning with - is a regular argument.  POSIX had inherited the
old System V getopt() convention that "--" ends the list of options,
and never specifically said what "--stuff" means, so Stallman stole
it for long-named options.

Re: [9fans] ports from GPL

[erik quanstrom]

On Fri Mar 17 08:25:34 CST 2006, brantley@coraid.com wrote:
> Wouldn't at least gcc be from the MIT culture given its originator was
> from the mit ai lab?  Where's readline and info from originally?
> Not to mention emacs.

stallman left the mit lab in 1983/4.  this was before gcc, readline,
or (tex)info.  i think gnu has to be considered seperately because rms
started with the gnu manifesto before he wrote any (much) code for gnu.

i'm not sure when readline started but i believe that it started life
as part of bash. this is from the readline-2.0 ChangeLog.

Wed Jun 28 20:20:51 1989  Brian Fox  (bfox at aurel)

	* Made readline and history into independent libraries.

there are also some references to bash in the readline-2.0 source.

>
> Where did the --option syntax originate?  Maybe they wanted to say /option
> but that's not possible under Unix.  Wouldn't the -o vs --very-long-option-name
> count as a MH vs. MIT artifact?
>

i don't know who invented the --gnu-system-long-option-syntax-option
but i'm pretty sure it was invented to disambguated betwen a multicharacter
option and a sequence of single character options. imho, just trying to
parse the long option first and a little common sense could have been enough.

- erik

Re: [9fans] ports from GPL

[Brantley Coile]

Wouldn't at least gcc be from the MIT culture given its originator was
from the mit ai lab?  Where's readline and info from originally?
Not to mention emacs.

Where did the --option syntax originate?  Maybe they wanted to say /option
but that's not possible under Unix.  Wouldn't the -o vs --very-long-option-name
count as a MH vs. MIT artifact?

These are real questions.  I would like to know.


> oh ya. i think the gnu culture was seperate from the start.
> i started out by necessity. they needed to get their software
> to run on all kinds of unix varients, which were highly incompatable.
> and for a while it was pretty good stuff.
>
> (for example, the infamus mt xinu tools were suffering from bit
> rot when gnu tools started to become usable. for example,
> xinu grep had a really short line limit. gnu grep didn't (thanks mike.)
> the xinu shell was the original bourne shell, and would exit if you
> hit ^C at the wrong time and had signal-related memory
> issues because of its infamous memory management.)
>
> however gnu has devolved. they seem to value compiling on anything,
> and efficiency, but they don't seem to value simplicity. gcc is a good
> example of how getting as far out-of-balance as gnu seems to be
> can undermine one's primary goals.
>
> - erik
>
> On Fri Mar 17 05:35:36 CST 2006, brantley@coraid.com wrote:
>> > i think that open source code has a very different outlook
>> > on the world than plan 9. it's very hard (and frustrating) to
>> > deal with the culture clash when porting.
>>
>> That brings to mind something that I've been thinking about for a
>> couple of years.  In watching the stuff in Linux and poking around the
>> simulators and old code, I can see at least three different cultures.
>> Murry Hill (Bell Labs), 545 Technology Sq (MIT), and Berkeley.  These
>> cultures have belief systems that are mutually exclusive.  And there
>> must be subcultures as well.  The socket interface, for example, is
>> really MIT culture thru BBN to BSD.
>>
>> Anyone else see this?  More cultures?
>>
>>

Re: [9fans] ports from GPL

[erik quanstrom]

oh ya. i think the gnu culture was seperate from the start.
i started out by necessity. they needed to get their software
to run on all kinds of unix varients, which were highly incompatable.
and for a while it was pretty good stuff.

(for example, the infamus mt xinu tools were suffering from bit
rot when gnu tools started to become usable. for example,
xinu grep had a really short line limit. gnu grep didn't (thanks mike.)
the xinu shell was the original bourne shell, and would exit if you
hit ^C at the wrong time and had signal-related memory
issues because of its infamous memory management.)

however gnu has devolved. they seem to value compiling on anything,
and efficiency, but they don't seem to value simplicity. gcc is a good
example of how getting as far out-of-balance as gnu seems to be
can undermine one's primary goals.

- erik

On Fri Mar 17 05:35:36 CST 2006, brantley@coraid.com wrote:
> > i think that open source code has a very different outlook
> > on the world than plan 9. it's very hard (and frustrating) to
> > deal with the culture clash when porting.
>
> That brings to mind something that I've been thinking about for a
> couple of years.  In watching the stuff in Linux and poking around the
> simulators and old code, I can see at least three different cultures.
> Murry Hill (Bell Labs), 545 Technology Sq (MIT), and Berkeley.  These
> cultures have belief systems that are mutually exclusive.  And there
> must be subcultures as well.  The socket interface, for example, is
> really MIT culture thru BBN to BSD.
>
> Anyone else see this?  More cultures?
>
>