Re: [9fans] Publish and be damned.

Re: [9fans] Publish and be damned.

[rsc]

> Well, if Russ has started something, that's a place to begin
> building.  Russ?  In your copious free time, could you confirm
> or deny this allegation?

It's not true.  I've done nothing but port CVS, and even
that I didn't finish (the port is only the client).

Russ

Re: [9fans] Publish and be damned.

[Lucio De Re]

On Sun, Apr 22, 2001 at 07:52:37PM -0400, rsc@plan9.bell-labs.com wrote:
>
> > Well, if Russ has started something, that's a place to begin
> > building.  Russ?  In your copious free time, could you confirm
> > or deny this allegation?
>
> It's not true.  I've done nothing but port CVS, and even
> that I didn't finish (the port is only the client).
>
Oops, my apologies, Russ.

I thought your thoughts (I never said anything about code :-) that you
chose to code-name "stitch" would have been a starting point for
version control.  Easy enough for me to remember selectively.

I hope I did no damage.

That leaves Dan to lead the pack :-)

++L

Re: [9fans] Publish and be damned.

[Dan Cross]

In article <200104222352.TAA30994@smtp3.fas.harvard.edu> you write:
>It's not true.  I've done nothing but port CVS, and even
>that I didn't finish (the port is only the client).

Well, that's it, then.  You lose your cool license.

	- Dan C.

:-)

Re: [9fans] Publish and be damned.

[Dan Cross]

In article <20010423062627.A320@cackle.proxima.alt.za> you write:
>That leaves Dan to lead the pack :-)

Don't look at me, chief, I'm too busy to tie my shoes these days.

	- Dan C.

:-)

Re: [9fans] Publish and be damned.

[Dan Cross]

> free trial.

Yeah, but for what architectures, and/or do I get source?

>the CEO of NFR Security is Marcus J. Ranum;  implementer of
>the first commercial firewall among other things.  ches
>probably doesn't read 9fans but someone on this list must
>know who he is.

Yeah, I know who Marcus Ranum is, but I never questioned the
security of the product, rationalizing it as, even if syslog
is broken, someone has to attack it, and droppings from that
attack are likely going to end up in the protected logs.
Even if the quality of later information in the log is less
as a result of syslog being compromised, the stuff at the
beginning might be pretty juicy.  :-)

> auto append, write once stuff is trivial to implement.

And it dovetails with /n/dump rather well.  :-)

> installing openBSD is a pain in the arse.  i had it installed
> but then i thought:
>
>     ok, i'll build a kernel from the source on this cd i burnt.
>
> but to mount the cd you need the kernel source.  the pc dist
> is too big for one cd, so you can't do it at install time and
> i'm still missing my $7 cable so i could install from my adsl.

Ahh, the joys of Unix.  :-)

	- Dan C.

(Actually, I usually do FTP installs of OpenBSD or FreeBSD when
I need a Unix machine in a hurry....  I find the former easier,
but I'm not using the same hardware you are.)

Re: [9fans] Publish and be damned.

[Boyd Roberts]

> It appears as though they want money for that, and I doubt it'd
> run under Plan 9 anyway (and I'm equally doubtful that they'd
> give out the source code).

the CEO of NFR Security is Marcus J. Ranum;  implementer of
the first commercial firewall among other things.  ches
probably doesn't read 9fans but someone on this list must
know who he is.

Re: [9fans] Publish and be damned.

[Boyd Roberts]

> It appears as though they want money for that, and I doubt it'd
> run under Plan 9 anyway (and I'm equally doubtful that they'd
> give out the source code).

auto append, write once stuff is trivial to implement.

installing openBSD is a pain in the arse.  i had it installed
but then i thought:

    ok, i'll build a kernel from the source on this cd i burnt.

but to mount the cd you need the kernel source.  the pc dist
is too big for one cd, so you can't do it at install time and
i'm still missing my $7 cable so i could install from my adsl.

i only really want to use dc.  telneting to sydney is easier.

Re: [9fans] Publish and be damned.

[Dan Cross]

In article <20010422181324.L2598@cackle.proxima.alt.za> you write:
>I think rsc was looking at it, but he might not have a chance to make
>progress.  I'll be thrilled to see it all migrate to Plan 9 properly,
>but I see little to be lost by bootstrapping through CVS.  It may be
>a bitch to convert, but surely not impossible.  How likely is it that
>the newer, cleverer version will be totally incompatible with the less
>sophisticated RCS?

Well, if Russ has started something, that's a place to begin
building.  Russ?  In your copious free time, could you confirm
or deny this allegation?

It's pretty likely that something new isn't going to be compatable,
as the RCS file format isn't particularly efficient w.r.t /n/dump
and so isn't too suitable for Plan 9.  Tools to convert to the new
format might be useful, though.

My fear is that starting something off with CVS will lead to something
that stays with CVS due to the Linus factor (not Linus Torvalds, but
the one from peanuts.  Hmm, thinking about it, it's somewhat ironic
that Linux is a safety blanket to so many people...).  Anyway, I'm
responding to those years of systematic torture known as ``time served
as a system administrator'' and one of the overriding principles I
learned early on: Do something right the first time, because you
won't have time to come back later and clean up.

>Certainly, you have made a very sensible suggestion,

Thank you!

>and Boyd's
>approach to use shell scripts is equally sound.  I am quite stuck in
>the Unix paradigm, so I'm in no position to drive this particular
>project in any fashion.
>
>But I could recommend Daniel Friedman's formula for a successful
>development team: something old, something new, something borrowed,
>something blue.  Boyd will do the "blue" bit, who better than him?
>We need someone close to the CVS camp for something "borrowed", that
>leaves something "old", many will fit that bill, and rsc might be
>ideal for something "new", but there may be other fresh outlooks (your
>own, perhaps) out there.

Well, I'm all down with hearing what it is that Russ has done.  Russ?

	- Dan C.

Re: [9fans] Publish and be damned.

[Boyd Roberts]

> It appears as though they want money for that, and I doubt it'd
> run under Plan 9 anyway (and I'm equally doubtful that they'd
> give out the source code).

free trial.

Re: [9fans] Publish and be damned.

[Dan Cross]

In article <013701c0cb47$e0da3fd0$e0b6c6d4@SOMA> you write:
>already done:
>
>    http://www.nfr.com/products/SLR
>
>now why was i playing with openbsd?

It appears as though they want money for that, and I doubt it'd
run under Plan 9 anyway (and I'm equally doubtful that they'd
give out the source code).

	- Dan C.

Re: [9fans] Publish and be damned.

[Boyd Roberts]

From: "Lucio De Re" <lucio@proxima.alt.za>
> On Sun, Apr 22, 2001 at 06:18:33PM +0200, Boyd Roberts wrote:
> >
> > now why was i playing with openbsd?
> >
> So you can be reminded that syslogd uses UDP to receive log messages,
> so a secure log repository is an interesting oddity, when we have no
> idea which log messages have been dropped.

you didn't even read the url i posted.  the SLR is hardened.

i knew syslog uses UDP.  the SLR doesn't.

who is the CEO who sells SLR?

give you a hint:  whitehouse.gov

must be the silly season, but it's only april.

Re: [9fans] Publish and be damned.

[Lucio De Re]

On Sun, Apr 22, 2001 at 06:18:33PM +0200, Boyd Roberts wrote:
>
> now why was i playing with openbsd?
>
So you can be reminded that syslogd uses UDP to receive log messages,
so a secure log repository is an interesting oddity, when we have no
idea which log messages have been dropped.

<sigh>

++L

Re: [9fans] Publish and be damned.

[Boyd Roberts]

From: "Dan Cross" <cross@math.psu.edu>
>
> Something that makes use of append-only files to store log and
> delta information and provides a filesystem view of the repository
> makes more sense to me.

already done:

    http://www.nfr.com/products/SLR

now why was i playing with openbsd?

Re: [9fans] Publish and be damned.

[Lucio De Re]

On Sun, Apr 22, 2001 at 12:12:24PM -0400, rsc@plan9.bell-labs.com wrote:
>
> I was going to let this go by uncorrected, but now that it's
> come up again...
>
I agree with Russ, I think I gave a wrong impression - please
forgive my bad habit of trying to be too succint.  Nothing Russ or
anyone else said gave me the impression that Bell Labs would object,
my bit of paranoia may have leaked out.

++L

Re: [9fans] Publish and be damned.

[Lucio De Re]

On Sun, Apr 22, 2001 at 12:00:26PM -0400, Dan Cross wrote:
>
> Something that makes use of append-only files to store log and
> delta information and provides a filesystem view of the repository
> makes more sense to me.
>
I think rsc was looking at it, but he might not have a chance to make
progress.  I'll be thrilled to see it all migrate to Plan 9 properly,
but I see little to be lost by bootstrapping through CVS.  It may be
a bitch to convert, but surely not impossible.  How likely is it that
the newer, cleverer version will be totally incompatible with the less
sophisticated RCS?

Certainly, you have made a very sensible suggestion, and Boyd's
approach to use shell scripts is equally sound.  I am quite stuck in
the Unix paradigm, so I'm in no position to drive this particular
project in any fashion.

But I could recommend Daniel Friedman's formula for a successful
development team: something old, something new, something borrowed,
something blue.  Boyd will do the "blue" bit, who better than him?
We need someone close to the CVS camp for something "borrowed", that
leaves something "old", many will fit that bill, and rsc might be
ideal for something "new", but there may be other fresh outlooks (your
own, perhaps) out there.

++L

Re: [9fans] Publish and be damned.

[rsc]

I was going to let this go by uncorrected, but now that it's
come up again...

Lucio on Apr 20 10:45:
> In reply to private mail from Russ:
> I still need to spend some effort to make the CVS server accessible.
> What I feel a project like this needs is the encouragement of Bell
> Labs, at the very minimum an understanding that its purpose is not
> contrary to Bell Labs' intentions, and that there is a place where
> mutually exclusive objectives can be negotiated to some compromise.

Steve Kilbane, later:
> But either way, I don't see any conflicts here. Russ's comments on avoiding
> conflicts with BL's interests aside, I don't see a problem with Lucio setting
> up the server. Those who like the idea will join in; those who don't, won't.
> Whether it'll produce anything better than what would happen otherwise,
> I don't know.

Lucio again, later:
> I hope I didn't miss an important comment from Russ, if there are
> conflicts with Bell Labs, I would want to be amongst the first to
> know.

I said nothing of the sort.  I think Steve made a reasonable inference
from Lucio's original reply.  I don't remember exactly what I said in
the private message, but it had nothing to do with Bell Labs.  It was
more ``I'm skeptical, but doing something is better than sitting and
complaining.  Let's try it.''

Russ

Re: [9fans] Publish and be damned.

[Dan Cross]

In article <20010422152637.F2598@cackle.proxima.alt.za> you write:
>Those of us who may think of Plan 9 as the True Religion may either
>be estatic or horrified at the thought.  I, for one, am not sure
>which camp I'm in, but evangelism at least is not up my alley.

Having a network accessible repository for information will be
useful, but I'm not sure that CVS is the way, if for no other
reason than because it doesn't exploit /n/dump very well (since
log and delta data is prepended to the RCS files, meaning they're
rewritten each time I check in a change).

Versioning at the level of CVS et al is a good thing, but it'd
be nice to see a Plan 9 based solution instead of using CVS just
because it's already there.

Something that makes use of append-only files to store log and
delta information and provides a filesystem view of the repository
makes more sense to me.

	- Dan C.

Re: [9fans] Publish and be damned.

[Software Repository]

> http://mapage.noos.fr/~repo

just click on a mailto, put the url in the message and hit send.

no extra s/w, passwords, security issues or stuff to install.

just mail the url that points at the current version you want visible
and i'll add it to the page.  idem for removals, or you can just blow
away the url you mailed yourself.

i'm hungry.  time for something to eat.

enough stupidity for one day.

Re: [9fans] Publish and be damned.

[Boyd Roberts]

http://mapage.noos.fr/~repo

Re: [9fans] Publish and be damned.

[Lucio De Re]

On Sun, Apr 22, 2001 at 04:51:11PM +0200, Boyd Roberts wrote:
>
> jmk was right about one thing:  drivel; this thing has been thrashed
> to death and NOBODY has done anything.
>
Wrong.  The CVS repository has restricted access for rsc and boyd (and
me, naturally).  Your password under separate envelope.

The stuff I published earlier may work, there's only so much I can
test when I'm inside the same firewall as the server.

Briefly:

	$ CVSROOT=:pserver:boyd@cvs.proxima.alt.za:/export/repository
	$ export CVSROOT
	$ cvs login
	... prompt for password
	$ cvs import boyd/code BOYD_0_9 CODE_0_9 ...

where boyd/code _should_ be the destination directory, based on your
published URLs, the capitalised strings are version numbers, and the
... is a list of files, directories, whatevers, you want to publish.

Anyone else wants write access, all I ask for is some consideration
that resources are limited (including my availability) and that we
need to work together, not competitively to make progress.  If I need
to correct someone's behaviour, please accept it in good faith.

++L

Re: [9fans] Publish and be damned.

[Boyd Roberts]

From: "Steve Kilbane" <steve@whitecrow.demon.co.uk>
> Boyd wrote:
> >
> > bullshit.
>
> Which bit? You're talking about different things, you know this,
> or you don't want to listen?

it was in response to not wanting to listen.

i went to some trouble to reply; citing doctrine, a paper and
personal experience of distributed software repositories.

total waste of my energy and /n/dump.

if i could be bothered, which now i can't, i coulda set up
the url solution in the time it took me to write the damn
message.

yeah, i just checked it out, i have the window open,
i can create the a/c and the page.

hell, think of a good name for it and I'LL DO IT.  naming
conventions are important.  no CVS though.  that's too
complex -- at this stage.

simple stuff works.  see how it works, learn, improve, loop.

design top down, implement bottom up.

just like NASA used to do until that shuttle thing they DESIGNED.
the engineers told feynman that the SRB problem was well known and
that the probability of an accident was 1 in 300.  turned out
to be a lot less than that because NASA management wouldn't listen
to them.

jmk was right about one thing:  drivel; this thing has been thrashed
to death and NOBODY has done anything.

Re: [9fans] Publish and be damned.

[Lucio De Re]

On Sat, Apr 21, 2001 at 02:08:42PM +0100, Steve Kilbane wrote:
>
> Boyd's talking about each original author maintaining a package. Lucio's
> talking about an amorphous mass of people hacking on several packages,
> at whim. Boyd's starting point is simpler, because it's present-day.
> Lucio's reason for changing things is so that a package doesn't stagnate
> because the original author lacks time or inclination.
>
I sure as hell didn't express my views this well.  Thank you, Steve.

> Boyd suggests reading the code. That's fine if the code's good. If Lucio's
> suggestion takes off, the code will be less predictable, and having a
> change comment is more important, because the reason for the change may not
> be deducible from the change itself.
>
The granularity of changes, not only the comments, would be different.
I may work on a single issue for days, across a number of modules,
and only "check in" the result.  That in itself adds information,
if not documentation.  By the same token, I may make numerous
unrelated changes between dumps, which would require effort to
investigate separately.  And reversals (undo/redo) would also be
lost.

Within Bell Labs, I would assume that daily is a coincidentally
happy medium.  I could also believe that development there would
have adjusted to the daily rhythm, otherwise the interval would be
different.  But conditions outside Bell Labs are unlikely to be as
fortunate.

> But either way, I don't see any conflicts here. Russ's comments on avoiding
> conflicts with BL's interests aside, I don't see a problem with Lucio setting
> up the server. Those who like the idea will join in; those who don't, won't.
> Whether it'll produce anything better than what would happen otherwise,
> I don't know.
>
I hope I didn't miss an important comment from Russ, if there are
conflicts with Bell Labs, I would want to be amongst the first to
know.

My prediction is that success really lies with Bell Labs buy-in
(I'm very fond of that term, for my own philosophical reasons),
and some dedication by one or more project facilitators.  I would
assume that anything "published" on the CVS repository is as readily
available to Bell Labs as if it was published in any other form,
in terms of the licence.  Any other restriction or relaxation may
have to be discussed and agreed upon by a multitude of parties,
not a rosy option.

But volume of publication (shudder, what do I do when resources
start becoming tight?) may be the most significant factor.  If
there is enough out there to bring Plan 9 closer to the desires of
prospective users, then it is possible to reach critical mass.

Those of us who may think of Plan 9 as the True Religion may either
be estatic or horrified at the thought.  I, for one, am not sure
which camp I'm in, but evangelism at least is not up my alley.

++L

Re: [9fans] Publish and be damned.

[Steve Kilbane]

Boyd wrote:
> From: "Steve Kilbane" <steve@whitecrow.demon.co.uk>
> > Lucio and Boyd are talking about different things. Furthermore, Boyd
> > knows this, but doesn't want to listen to it. :-)
>
> bullshit.

Which bit? You're talking about different things, you know this,
or you don't want to listen?

Re: [9fans] Publish and be damned.

[Boyd Roberts]

From: "Steve Kilbane" <steve@whitecrow.demon.co.uk>
> Lucio and Boyd are talking about different things. Furthermore, Boyd
> knows this, but doesn't want to listen to it. :-)

bullshit.

Re: [9fans] Publish and be damned.

[Boyd Roberts]

From: <jmk@plan9.bell-labs.com>
> Think about whether we might find it relevant
> and/or interesting before you post to the mailing list).

think about deleting it before 0500 EST.

thanks.

Re: [9fans] Publish and be damned.

[jmk]

On Sat Apr 21 09:44:29 EDT 2001, boyd@planete.net wrote:
> 6. my apologies to the list/group for this waste of time and bandwidth.

It's not just time and bandwidth being taken up by this drivel, it's
irreplaceable space on /n/dump. You can apologise all you want but it
doesn't get the space back (in fact, it just compounds the problem, so
don't bother to respond). Think about whether we might find it relevant
and/or interesting before you post to the mailing list).

Thanks.

Re: [9fans] Publish and be damned.

[Lucio De Re]

On Sat, Apr 21, 2001 at 03:43:25PM +0200, Boyd Roberts wrote:
>
> From: "Lucio De Re" <lucio@proxima.alt.za>
> > Make peace with the world instead of doing things to spite mankind,
>
> 1. don't lecture me.
>
You're right, I should not lecture you.  But you're @#$%&*
irresistible.  I'm sure I'm not the only one tempted, I just yield
more easily, must be the ex-catholic in me.

> 2. you have no idea of my situation.  make peace?  when you're
>    under attack?  real life stuff, not this mailing list nonsense.
>
Boyd, come stay here in Joburg for a little while, you can sleep at
the end of a V32 link to "the Internet", I'll supply coffee and
ammunition (and a loading press).

And when you've deleted the criminal element, we can go and expose
ourselves to real "nature" in nearby nature reserves (real lions
eating live people, elephants stomping them, etc).

> 5. i'm still waiting (3 days to get a $7 component from the uk to paris
>    when it took 5 days to get my Public Enemy [a us rap band] baseball
>    cap from the us, by ordinary mail).
>
Where were you brought up?  Europe, Africa and the US have very
different perceptions of time scales, and technology seems to
emphasise these differences.  I do sympathise, but whereas I may be
luckier, many around me would not even understand the nature of your
problem.  Not much good to either of us, but it is important to them
:-)

> 6. my apologies to the list/group for this waste of time and bandwidth.
>
Mine too.

++L

PS:  I really wish I could wait for a reply, but I have already
stretched someone else's patience, got to go make amends.

Re: [9fans] Publish and be damned.

[Boyd Roberts]

From: "Lucio De Re" <lucio@proxima.alt.za>
> Make peace with the world instead of doing things to spite mankind,

1. don't lecture me.

> then focus your anger on what is obviously a very sharp sense of
> humour.  We'll all enjoy your contributions, then.

2. you have no idea of my situation.  make peace?  when you're
   under attack?  real life stuff, not this mailing list nonsense.

> If you need to develop something, by all means do it, but it would
> take something along the lines of:
>
> $ export CVSROOT=:pserver:boyd@cvs.proxima.alt.za:/export/repository
> $ cvs login
> $ cvs import boyd/code "BOYD-V_0_9" "CODE-V_0_9"

3. i couldn't even if i wanted to.

> (hm, don't try it yet :-)
> to post your stuff on the repository from your OpenBSD notebook.  I
> will assign you CVS write access if you find it useful.

4. read this:

----- Original Message -----
From: "Boyd Roberts" <boyd@planete.net>
To: <English_NICSupport@eur.3com.com>
Sent: Tuesday, April 17, 2001 8:30 PM
Subject: Re: RE:Re: Tr: 3CCFE574BT [#49466]


> I am still waiting for the exchange that was agreed on February 21, 2001.
>
>
> Regards.
>
>
> I sent you my address:
>
> From: Boyd Roberts <boyd@planete.net>
> To: <Valerie_Bilodeau@Stream.com>
> Sent: Wednesday, February 21, 2001 4:15 PM
> Subject: Re: Tr: 3CCFE574BT
>
>
> > Now I can't use the card at all.
> >
> > My address is:
> >
> >     Boyd ROBERTS
> >     246 rue St Martin
> >     75003 Paris
> >     FRANCE
> >
> > I'm sending this mail via planete.net net with my V.90 modem [RTC].
> >
> >
> > Thanks.
> >
> > ps.  I have a bad feeling the card will have to be replaced too.
> >
> > ----- Original Message -----
> > From: <Valerie_Bilodeau@Stream.com>
> > To: Boyd Roberts <boyd@planete.net>
> > Sent: Wednesday, February 21, 2001 3:06 PM
> > Subject: Re: Tr: 3CCFE574BT
> >
> >
> > >
> > > Dear Mr. Roberts,
> > >
> > > Could you please provide us with your address, the product will be send
> to
> > > you as an advance replacement.
> > >
> > > With kind regards,
> > >
> > > Valerie Bilodeau
> > > 3Com Helpdesk
> > >
> > >
> > >
> > >
> > >
> > > "Boyd Roberts" <boyd@planete.net> on 20-02-2001 04:08:31 PM
> > >
> > > To:   <valerie_bilodeau@stream.com>
> > > cc:
> > > Fax to:
> > > Subject:  Tr: 3CCFE574BT
> > >
> > > Bonjour,
> > >
> > > Voici, ci-dessous, le message dont on a parl�.
> > >
> > > Merci de votre aide.
> > >
> > >
> > > Bonne journ�e.
> > >
> > > ----- Original Message -----
> > > From: Boyd Roberts <boyd@planete.net>
> > > To: <english_nicsupport@3com.com>
> > > Sent: Tuesday, February 20, 2001 3:28 PM
> > > Subject: 3CCFE574BT
> > >
> > >
> > > > I bought this card in June 2000, in France.  I live in Paris.
> > > >
> > > > Recently it has developed an intermittant fault.  I believe
> > > > the connector between the PCMCIA card and the cable to the
> > > > RJ-45 socket is faulty.  It could be the card, but I believe
> > > > it to be the connector.  The connector is not an X-Jack
> > > > connector.
> > > >
> > > > The card is:
> > > >
> > > >     3CCFE574BT
> > > >
> > > >     EA  0050DAE9B6AF
> > > >     S/N 6ZR1E9B6AF
> > > >     P/N 16-0229-000 Rev: A
> > > >
> > > > What I would like is a new connector/cable/RJ-45 socket
> > > > without having to return the currect one as it works,
> > > > but is intermittent.  Should I return it to be exchanged
> > > > I will not be able to use my ADSL for weeks or maybe months.
> > > >
> > > > Should a new connector/cable/RJ-45 socket fix the problem
> > > > I will return the one that has the intermittant fault.  Should
> > > > it not fix the problem then the socket in the PCMCIA card
> > > > must be faulty.  In that case I'd like a new card and I will
> > > > return the old card once I have installed the new one.
> > > >
> > > > Being not able to use my ADSL for weeks or months is not
> > > > an option.
> > > >
> > > > From reading the user guide I see the card has a 'Lifetime'
> > > > guarantee.
> > > >
> > > > This message will be sent by the card, via my ADSL.
> > > >
> > > >
> > > > Regards.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > ----- Original Message -----
> > From: <English_NICSupport@eur.3com.com>
> > To: <boyd@planete.net>
> > Sent: Wednesday, March 28, 2001 2:11 PM
> > Subject: RE:Re: Tr: 3CCFE574BT [#49466]
> >
> >
> > >
> > > Dear Mr. Roberts
> > >
> > > Thank you for contacting 3Com Online support.
> > > Could you please provide us  your address where we need to send the
> > product to.
> > > It will be send to you as an advance replacement.
> > >
> > > With kind regards,
> > > Sophie
> > >
> > >
> > >
> > > If the response we have provided does not meet with your satisfaction,
> > please reply to this message with your reason why.
> > >
> > > Thank you.
> > >
> > >
> > > 3Com Online Support
> > >
> > > ** Please keep all history when replying to this email.
> > >
> > > --Original Message--
> > >
> > >
> > >
> > > More than a month later and I have received nothing.
> > >
> > > Where is my connecter?
> > >
> > > ps.  I see you can buy them in the US for $7 [50 FF].
> > >
> > > ----- Original Message -----
> > > From: <Valerie_Bilodeau@Stream.com>
> > > To: Boyd Roberts <boyd@planete.net>
> > > Sent: Wednesday, February 21, 2001 4:06 PM
> > > Subject: Re: Tr: 3CCFE574BT
> > >
> > >
> > > >
> > > > Dear Mr. Roberts,
> > > >
> > > > Could you please provide us with your address, the product will be send
> > > to
> > > > you as an advance replacement.
> > > >
> > > > With kind regards,
> > > >
> > > > Valerie Bilodeau
> > > > 3Com Helpdesk
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > "Boyd Roberts" <boyd@planete.net> on 20-02-2001 04:08:31 PM
> > > >
> > > > To:   <valerie_bilodeau@stream.com>
> > > > cc:
> > > > Fax to:
> > > > Subject:  Tr: 3CCFE574BT
> > > >
> > > > Bonjour,
> > > >
> > > > Voici, ci-dessous, le message dont on a parl�.
> > > >
> > > > Merci de votre aide.
> > > >
> > > >
> > > > Bonne journ�e.
> > > >
> > > > ----- Original Message -----
> > > > From: Boyd Roberts <boyd@planete.net>
> > > > To: <english_nicsupport@3com.com>
> > > > Sent: Tuesday, February 20, 2001 3:28 PM
> > > > Subject: 3CCFE574BT
> > > >
> > > >
> > > > > I bought this card in June 2000, in France.  I live in Paris.
> > > > >
> > > > > Recently it has developed an intermittant fault.  I believe
> > > > > the connector between the PCMCIA card and the cable to the
> > > > > RJ-45 socket is faulty.  It could be the card, but I believe
> > > > > it to be the connector.  The connector is not an X-Jack
> > > > > connector.
> > > > >
> > > > > The card is:
> > > > >
> > > > >     3CCFE574BT
> > > > >
> > > > >     EA  0050DAE9B6AF
> > > > >     S/N 6ZR1E9B6AF
> > > > >     P/N 16-0229-000 Rev: A
> > > > >
> > > > > What I would like is a new connector/cable/RJ-45 socket
> > > > > without having to return the currect one as it works,
> > > > > but is intermittent.  Should I return it to be exchanged
> > > > > I will not be able to use my ADSL for weeks or maybe months.
> > > > >
> > > > > Should a new connector/cable/RJ-45 socket fix the problem
> > > > > I will return the one that has the intermittant fault.  Should
> > > > > it not fix the problem then the socket in the PCMCIA card
> > > > > must be faulty.  In that case I'd like a new card and I will
> > > > > return the old card once I have installed the new one.
> > > > >
> > > > > Being not able to use my ADSL for weeks or months is not
> > > > > an option.
> > > > >
> > > > > From reading the user guide I see the card has a 'Lifetime'
> > > > > guarantee.
> > > > >
> > > > > This message will be sent by the card, via my ADSL.
> > > > >
> > > > >
> > > > > Regards.

----- Original Message -----
From: "GLS Admin Eur" <GLS_Admin_Eur@eur.3com.com>
To: <boyd@planete.net>
Sent: Wednesday, April 18, 2001 3:40 PM
Subject: Connector for 3CCFE574BT


>
>
> Dear Sir,
>
> In reference to our telephone discussion earlier today, I can confirm that I
> have a 100Base-TX cable for your card 3CCFE574BT.  Part number is
3C-PC-TX-CBL.
>
> I can send this directly to you if you provide me with your shipping address
and
> details.
>
> If you have any further queries, please do not hesitate to contact me.  Please
> also forward on your mails you have received and sent to Stream, in order for
me
> to escalate this issue and bad service that you have received.
>
> I do apologise for all of the inconvenience this has caused you.
>
> Kind regards
> Natasha

5. i'm still waiting (3 days to get a $7 component from the uk to paris
   when it took 5 days to get my Public Enemy [a us rap band] baseball
   cap from the us, by ordinary mail).

6. my apologies to the list/group for this waste of time and bandwidth.

Re: [9fans] Publish and be damned.

[Steve Kilbane]

Lucio and Boyd are talking about different things. Furthermore, Boyd
knows this, but doesn't want to listen to it. :-)

Boyd's talking about each original author maintaining a package. Lucio's
talking about an amorphous mass of people hacking on several packages,
at whim. Boyd's starting point is simpler, because it's present-day.
Lucio's reason for changing things is so that a package doesn't stagnate
because the original author lacks time or inclination.

/n/dump is okay if you've got a reasonable level of self-discipline, and
your group is small. As the (project size)/(amount of discipline) figure
rises, a more comprehensive control system becomes more important.

Boyd suggests reading the code. That's fine if the code's good. If Lucio's
suggestion takes off, the code will be less predictable, and having a
change comment is more important, because the reason for the change may not
be deducible from the change itself.

But either way, I don't see any conflicts here. Russ's comments on avoiding
conflicts with BL's interests aside, I don't see a problem with Lucio setting
up the server. Those who like the idea will join in; those who don't, won't.
Whether it'll produce anything better than what would happen otherwise,
I don't know.

steve

Re: [9fans] Publish and be damned.

[Lucio De Re]

This is a rambling rant, I should really not think of 9fans as
alt.folklore.computers, but I have no Usenet access to speak of,
anyway :-)

Also, I can only re-read it so many times before I consign it to the
list.  So please don't blame me if it annoys you.

On Sat, Apr 21, 2001 at 01:06:43PM +0200, Boyd Roberts wrote:
>
> no, i use revision control religiously (automated by make).  i prefer
> RCS for text files.  SCCS is a catastrophe.  never used CVS; do you
> think they find me contracts where i could?
>
No idea.  But CVS was just a bunch of RCS-automating shell scripts,
until someone had the (brilliant, in my opinion) idea of rewriting it
in C.  They carried the RCS baggage all the way, but bad habits die
hard.  Not to say that I don't like RCS, quite the contrary, but CVS
diverged in scope/intent from RCS and should have been re-engineered
at that point.  It's never too late, but now there's too much
unlearning to do.

But seeing that anything Open Source has a public CVS repository, I
should imagine the only reason you won't get a contract involving CVS
is because you insist in getting paid.

> the url should point at the current version.  the author uses whatever
> revision control with the master version of the source, which is the
> url does not point to.  new releases are shipped to the url.
>
Give CVS a bit of your time.  It could look a whole lot like RCS,
except you can point the CVS "shell" to a remote repository and it
discourages locking.  I personally like the
	cvs cvs-opts rcs-command rcs-opts
syntax  (where cvs is in effect a command dispatcher) in preference to
RCS's namespace pollution, but YMMV.  Then you get all the revision
freezes and other options that make life a misery (hard to track, no
easy way to figure out what it is you're after, but powerful when you
do) and one thing I know I miss: the ability to duplicate the
repository for caching purposes.  Geoff Collyer would no doubt prefer
to remote mount it, but there are permission problems with that; and I
may be missing something, too - for all I know it lurks in the
undocumented bits.

> > Different schools.  A friend and I once tackled a moderately simple
> > text processing task in AWK and C respectively.  We were all
> > experienced programmers, but not proficient in AWK or C, just
> > differently so, hence the choice.
>
> text processing in C?  are you mad?  C is dreadful when it comes
> to smashing strings about.  you wind up building some library
> so that you don't have to worry about it or you declare:
>
>     char buf[N];
>
> which is all very fine until n > N bytes get stuffed into buf.
>
I like C and feel even more at home in some assemblers.  I don't
undertake monumental tasks and panic when 64Gig RAM is mentioned (I
wonder if GCC will grow segmentation for super-servers, so we can go
back to small- and large-model programming on the Intel architectures
:-)

> i go for the former, if i have to use C.  ~15 years ago i'd
> have to do it in C, 'cos a 1 mip 11/780 wasn't that fast
> (well, our's were).
>
Hey, you could use Snobol (never understood it, myself).  I use Awk a
lot, TCL even more, but I rattle off small C idioms in my sleep and I
just don't notice the waste of time.  Give or take inserting items at
the beginning of linked lists, I seldom have to spend much time
debugging my small endeavours.  And I still do development for MS-DOS.

> this is a bit painful to use, but is doesn't break, until
> you run out of memory [it's old, this code]:
>
What does it do?  Do I really have to read that?

> > We finished at about the same time, with identical results, and we
> > were both surprised :-)
>
> yeah, but they were toys:
>
>     ``a moderately simple text processing task''
>
Sure, but how hard does anything have to be?

> after the reading the 150 or so pages of the 4 MIME RFC's [in near
> despair] i was faced with the choice of C or awk to 'parse' who
> was sending what to whom.  C would've been months of work, but
> i worked out a way to give them [the rat squad] what they wanted
> with awk.  so it was days of reading mime rfc's, with thoughts
> varying between:
>
>     - they did WHAT!?!
>     - i'll gonna hunt 'em down and shoot 'em
>     - kill me NOW
>
> and then a coupla hours with awk.
>
I tried to convert RFC-822 stuff to Novell's messaging service (early
nineties, when the Internet was becoming viable, but enterprise e-mail
seemed to be heading for a number of proprietary protocols) and back
again, never could get that to work.  But another difference between
us was that Unix did not exist in my environment until I sought out a
copy of Xenix (heavens, I'm not even sure how to spell it anymore) and
blew most of our budget on a 286AT clone.

My earliest encounter with Unix tools in a useable PC environment was
the MKS stuff.  Things were small and simple then.  My love of Plan 9
may well be nostalgia for those days.  But I wasn't confronted by
signals, ioctls and other ugliness until much later.

As for MIME, a better alternative will have to surface before the end
of this year, if we're not to lose the Internet to SPAM.  And that
applies to RFC-821 and RFC-822, too.  Why don't you distil your
dislike of MIME into a constructive proposal for a working
alternative?

Note that MIME handling tools are available, even down to the MS-DOS
platform, and have been stable now for years.  Without quite wanting
to sound sacriligeous, it is a poor platform that can't handle MIME
without blood, sweat and tears.

> > That's fine where conversation is the primary communication channel.
>
> nope.  you have the code.  read it.  that's what it's there for.
>
But code has no memory.  Previous versions do.  And when contributions
are allowed to be undisciplined, it is advisable to be able to compare
versions.  There's no guarantee that the latest version is better than
all predecessors, quite the contrary, in fact.

> at SRC (in Palo Alto) and PRL (in Paris) we used a package
> management system [The Siphon] and this was back in the
> early 1990s:
>
>     Francis J. Prusker and Edward P. Wobber. The Siphon: Managing
>     distant replicated repositories. In Proceedings of the IEEE
>     Workshop on the Management of Replicated Data. IEEE, April 1990,
>     Also appeared as PRL Research Report 7. (PostScript).
>
>     ftp://ftp.digital.com/pub/DEC/PRL/research-reports/PRL-RR-7.ps.Z
>
> distributed bug fixing.  now if engineering could have just listened.
> i could tell you a story about ULTRIX engineering, but then i'd have
> to shoot you or compaq would have me for breech of confidentiality.
>
Again, we all know of better ways, we all can pick on weaknesses, but
we leave to the Linux community to produce useable tools (we _do_ copy
their device drivers, don't we?) while we criticise them for not
following the True Faith (TM).  The crux of the matter is that RCS and
CVS are readily available (RCS in all *BSDs and CVS from CVS.ORG).
Where is a practical implementation of Siphon?  Why is no-one using
it?

> > You could have been well rewarded for that, ...
>
> i was: got treated like shit by one of the researchers for
> weeks on end and then small thank you when he blew away
> some file or other.  a PhD in comp sci but can't master rm(1)?
>
Isn't that what you asked for?  Forgive me sounding off, but you
sure sound like you couldn't handle thanks, you would have to bitch
about the magnitude, as you do above.  I have a rather hermitical
friend I could easy model your personality on.  Neither of you want
to be liked in a conventional fashion, mankind has to figure out
your good points the hard way.  Unfortunately, we all have enough
trouble managing our own lives not to consume effort on really
challenging personalities like yours, and at the end of the day we're
all losers as a result.  But there 4 billion people on this planet,
each potentially as deserving as you, even if many of them use
Windows.

> > the first crisis the DOS
> > user encounters when moving to Unix is the inability to recover
> > deleted files, and a facility as you provided would have been a
> > godsend to many like me who had to learn the discipline of
> >
> > alias rm="rm -i"
>
> these people should be all given loaded, hair trigger .357 magnum
> colt pythons shipped with windows.  it'd either teach them a lesson
> about confirmations or improve the gene pool.  do knives come with
> a -i option?
>
Quite the contrary, as Bill Gates has demonstrated.  Or do you
believe in "final solutions"?  It is weird to compare Bill as the
exact opposite of some unmentionable dictator, but he's got the public
very well sussed.  Pity about those in the "emerging nations" who
could emerge if technology weren't becoming ever more demanding
instead of more accessible.

> for our needs IIRC we needed about 4Gb for 30 days and then it'd
> cycle.  slowly i 'stole' RA-90's [1Gb] by shifting stuff around.
> now 4Gb is nothing.
>
It isn't nothing.  It isn't even cheap, when you have to back it up in
preparation for certain failure possibly even within its warranty.  I
have the Inferno floppy-image release that won't run on a PC with an
IDE adapter, two 3B1s that could teach a lot to a schoolful of eager
children with a single 40Meg, MFM drive.  But what can I teach them
when entry level in society today is a knowledge of a Win9x version of
Word?

> ever heard of running vi(1) on an 11/23 with 7th Ed and RL-02s?
>
No, by the time I encountered vi(1), 20Meg MFM drives and 1Meg of RAM
were available.  But the best word processor I remember (very vaguely)
using, was WordPro 4 on the commodore, 8K RAM?

What about supercalc in 64K?  Unix spreadsheets never even grew to
that sophistication, and that would have sufficed to slow M$'s growth.
I believe that the PC's launch was caused by Lotus 1-2-3, the killer
application of the time.  Others disagree.  But "lack of vision" would
be the AT&T trademark, not M$'s.  Hell, Win 3.1 was written by Pascal
programmers!  But it matched expectations a lot better than anything
else on the market at the time.  The point is, theoretical tools may
be very well, but people want to _use_ the toy they spend money on.
Linux's momentum came from being able to play graphic games early in
its life.  Its antichrist (as in anti-microsoft) image also helped,
naturally, but that's a religious issue.

> i think you better check that 'cos IIRC:
>
>     SCCS came out of USG: a dreadful piece of junk
>
That's an opinion.  Yes, I didn't like it either, and I embraced RCS
as soon as I discovered it, but something needed to pioneer the field,
and nothing better caught on in between, perhaps because of
"intellectual property" issues.  SCCS wasn't even bundled in SCO
Xenix, if memory serves, but then SCO were certainly at odds with the
universe.

>     RCS was 'BSD' based: raw, small and kinda neat but useless for
>                          DNS zone file version #'s.
>
Yep, its single biggest flaw.  And a bitch to change.  I tried to
change the $RCSfile:$ keyword to $Logfile:$ (to be able to exchange
files with PVCS which a client had bought) and never, ever found out
where to do it (and I'm normally pretty good at this type of thing).

> i have a selective memory:
>
>   173000g
>
MS-DOS explains it all: command.com and fc.exe are plain useless, you
had to write your own tools, without the benefits of research Unix to
guide you.  So I still do it as my favourite revenue earning
occupation.  But, like you, I'm fast becoming obsolete.  And I resent
it as much as you do.

> > Please write a book!
>
> ``that's not been un-thought of...
>
So, @%#$!* get on and do it.

> so do what the subject line says.  get a rapid prototype, see how it goes,
> fix/improve it, loop.
>
No, I don't see why I can't just use existing tools.  CVS (sourceforge
notwithstanding) is the conventional wisdom, all we need to add is a
bunch of URLs and a few ACME programs to translate them to CVS
requests.  And, as I mentioned to rsc, a librarian and publisher, as
recommended by Fred Brooks.  I would prefer a more competent CVS user
than I, but I'll do it while it needs me.

> if i get some peace in the next few days, i might do some real work.
> 10 years, 7 days, ~20 hours in this 'police action'.  i have a firefight
> to attend to first, so the rest is on hold.
>
Make peace with the world instead of doing things to spite mankind,
then focus your anger on what is obviously a very sharp sense of
humour.  We'll all enjoy your contributions, then.

If you need to develop something, by all means do it, but it would
take something along the lines of:

	$ export CVSROOT=:pserver:boyd@cvs.proxima.alt.za:/export/repository
	$ cvs login
	$ cvs import boyd/code "BOYD-V_0_9" "CODE-V_0_9"

(hm, don't try it yet :-)
to post your stuff on the repository from your OpenBSD notebook.  I
will assign you CVS write access if you find it useful.

++L

Re: [9fans] Publish and be damned.

[Boyd Roberts]

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

From: "Lucio De Re" <lucio@proxima.alt.za>
> I don't hold anything against using the web as an interface, but it
> sucks as historical records go.  It is firmly stuck in the present.
>
> > this is a lot faster to write and use than some random piece of
> > junk on windows/unix/linux etc and is reasonably portable across
> > bourne shells that support shell functions.
> >
> I take this to mean that SCCS, RCS and CVS are all unsuitable, in your
> opinion, for source management?  Here I think our opinions diverge:  I
> wish to retain a convenient record of changes.  More about that in a
> moment.

no, i use revision control religiously (automated by make).  i prefer
RCS for text files.  SCCS is a catastrophe.  never used CVS; do you
think they find me contracts where i could?

the url should point at the current version.  the author uses whatever
revision control with the master version of the source, which is the
url does not point to.  new releases are shipped to the url.

> Different schools.  A friend and I once tackled a moderately simple
> text processing task in AWK and C respectively.  We were all
> experienced programmers, but not proficient in AWK or C, just
> differently so, hence the choice.

text processing in C?  are you mad?  C is dreadful when it comes
to smashing strings about.  you wind up building some library
so that you don't have to worry about it or you declare:

    char buf[N];

which is all very fine until n > N bytes get stuffed into buf.

i go for the former, if i have to use C.  ~15 years ago i'd
have to do it in C, 'cos a 1 mip 11/780 wasn't that fast
(well, our's were).

this is a bit painful to use, but is doesn't break, until
you run out of memory [it's old, this code]:

echo flex.h
sed 's/.//' >flex.h <<'//GO.SYSIN DD flex.h'
-/*
- *	Flexible string definitions.
- *
- *	@(#)flex.h	1.31
- */
-
-#define FLEXZ	128
-
-typedef struct
-{
-	char	*f_str;
-	char	*f_end;
-	char	*f_ptr;
-}
-		flex;
-
-#define flex_char(f, c)	(*((f)->f_ptr == (f)->f_end ? flex_fill(f) :
(f)->f_ptr++) = (c))
-
-extern void	flex_end();
-extern char	*flex_fill();
-extern void	flex_init();
-extern void	flex_str();
-extern void	flex_nstr();
//GO.SYSIN DD flex.h
echo flex.c
sed 's/.//' >flex.c <<'//GO.SYSIN DD flex.c'
-/*
- *	Flexible string handling.
- */
-
-#ifndef	lint
-static char	sccsid[]	= "@(#)flex.c	1.31";
-#endif	lint
-
-#include	"mace.h"
-#include	"flex.h"
-
-void
-flex_init(f)
-register flex	*f;
-{
-	f->f_str = f->f_ptr = salloc(FLEXZ);
-	f->f_end = f->f_ptr + FLEXZ;
-}
-
-char	*
-flex_fill(f)
-register flex	*f;
-{
-	register int	s;
-
-	s = f->f_end - f->f_str + FLEXZ;
-
-	f->f_str = srealloc(f->f_str, s);
-	f->f_end = f->f_str + s;
-	f->f_ptr = f->f_end - FLEXZ;
-
-	return f->f_ptr++;
-}
-
-void
-flex_end(f)
-register flex	*f;
-{
-	f->f_ptr = f->f_str;
-}
-
-void
-flex_str(f, s)
-register flex	*f;
-register char	*s;
-{
-	while (*s != '\0')
-		flex_char(f, *s++);
-}
-
-void
-flex_nstr(f, s, n)
-register flex	*f;
-register char	*s;
-register int	n;
-{
-	while (n-- > 0 && *s != '\0')
-		flex_char(f, *s++);
-}
//GO.SYSIN DD flex.c

> We finished at about the same time, with identical results, and we
> were both surprised :-)

yeah, but they were toys:

    ``a moderately simple text processing task''

after the reading the 150 or so pages of the 4 MIME RFC's [in near
despair] i was faced with the choice of C or awk to 'parse' who
was sending what to whom.  C would've been months of work, but
i worked out a way to give them [the rat squad] what they wanted
with awk.  so it was days of reading mime rfc's, with thoughts
varying between:

    - they did WHAT!?!
    - i'll gonna hunt 'em down and shoot 'em
    - kill me NOW

and then a coupla hours with awk.

> > IIRC plan 9 was an experiment that came out of a research
> > lab and in response to the question what they for version
> > control, well was:
> >
> >     /n/dump
> >
> That's fine where conversation is the primary communication channel.

nope.  you have the code.  read it.  that's what it's there for.

> Rob can walk up to Dave and ask a question and get a reasonable
> answer.  But with the advent of geographically remote development, the
> knowledge has to be embedded in the source code.  RCS (more than CVS,
> all I like about CVS is the client-server model, other things I accept
> intellectually, but have no emotional ties to) and SCCS held in a
> nutshell batches of changes that are related to each other in a
> fashion that /n/dump cannot do.  Or am I still not making sense?

at SRC (in Palo Alto) and PRL (in Paris) we used a package
management system [The Siphon] and this was back in the
early 1990s:

    Francis J. Prusker and Edward P. Wobber. The Siphon: Managing
    distant replicated repositories. In Proceedings of the IEEE
    Workshop on the Management of Replicated Data. IEEE, April 1990,
    Also appeared as PRL Research Report 7. (PostScript).

    ftp://ftp.digital.com/pub/DEC/PRL/research-reports/PRL-RR-7.ps.Z

distributed bug fixing.  now if engineering could have just listened.
i could tell you a story about ULTRIX engineering, but then i'd have
to shoot you or compaq would have me for breech of confidentiality.

> > on that topic i built a version of /n/dump using a program
> > (to call ftw(3) and stat(2)) and some scripts (to select and
> > copy the files) when i was at PRL.  as fast as i could free up
> > RA90's [1GB] i was headed to have the last ~30 days of all the
> > user's home directories on mag disc.  presented it as a WIP at a
> > USENIX -- hell, ken, with phil in tow, walked in.
> >
> You could have been well rewarded for that, ...

i was: got treated like shit by one of the researchers for
weeks on end and then small thank you when he blew away
some file or other.  a PhD in comp sci but can't master rm(1)?

> the first crisis the DOS
> user encounters when moving to Unix is the inability to recover
> deleted files, and a facility as you provided would have been a
> godsend to many like me who had to learn the discipline of
>
> alias rm="rm -i"

these people should be all given loaded, hair trigger .357 magnum
colt pythons shipped with windows.  it'd either teach them a lesson
about confirmations or improve the gene pool.  do knives come with
a -i option?

> > on top of that ran the normal backups.  my version of /n/dump
> > was there for when someone blew away a file that they'd created
> > recently so they could go and get it themselves with cd, ls and cp.
> >
> Very cool, as I was saying.  But only viable once disk space stopped
> being the most expensive computing resource (or second, whatever, when
> it was no longer as critical).

for our needs IIRC we needed about 4Gb for 30 days and then it'd
cycle.  slowly i 'stole' RA-90's [1Gb] by shifting stuff around.
now 4Gb is nothing.

> For curiosity's sake, when I was at
> university in the early seventies, admin and research (just under
> 10000 students) shared a Univac 1106, later Univac 1110, with 50Meg of
> disk space.

ever heard of running vi(1) on an 11/23 with 7th Ed and RL-02s?

> CVS was a bunch of scripts, and RCS was very much based on SCCS, which
> I presume was a mature product, at least be the time RCS was being
> undertaken.  I think your points are sound, but I'm really not aiming
> at immature technology, although no doubt it still has rough edges.

i think you better check that 'cos IIRC:

    SCCS came out of USG: a dreadful piece of junk

    RCS was 'BSD' based: raw, small and kinda neat but useless for
                         DNS zone file version #'s.

> As I said, it is a matter of comfort zones.  I have to refer to man
> pages even for rudimentary shell commands, whereas I think I have a
> good memory for C idioms (some of which I get wrong without fail :-)

i have a selective memory:

  173000g

> Please write a book!

``that's not been un-thought of...

so do what the subject line says.  get a rapid prototype, see how it goes,
fix/improve it, loop.

if i get some peace in the next few days, i might do some real work.
10 years, 7 days, ~20 hours in this 'police action'.  i have a firefight
to attend to first, so the rest is on hold.

    obradovitch takes his war kinda serious

        -- Pettibone's Law, John, Keene


[-- Attachment #2: 3.jpg --]
[-- Type: image/jpeg, Size: 16624 bytes --]

Re: [9fans] Publish and be damned.

[Lucio De Re]

On Fri, Apr 20, 2001 at 11:02:13PM +0200, Boyd Roberts wrote:
>
> no, the 'owner' of the code gives you the url.  the url points at the
> version that the 'owner' is prepared to release.  the url should point
> at a 'portable' single file.  no 5k tarred (sic) zipped nonsense.
>
I don't think I explained myself very well, but I suppose it is not
entirely clear to me what it is I'm trying to achieve.

> use bundle:
>
>     http://www.planete.net/~boyd/code/bundle.html
>
> and if it's large, and only then, then compress it.
>
Let me see how well I understand _your_suggestion.

> you just maintain a chunk of pages with a chunk of urls.  you could
> code it in a few hours with the shell of your choice.  look at:
>
>     http://www.planete.net/~boyd/code/mkthumb
>
> it doesn't do what you want, but its exhibits the principle.
>
I don't hold anything against using the web as an interface, but it
sucks as historical records go.  It is firmly stuck in the present.

> this is a lot faster to write and use than some random piece of
> junk on windows/unix/linux etc and is reasonably portable across
> bourne shells that support shell functions.
>
I take this to mean that SCCS, RCS and CVS are all unsuitable, in your
opinion, for source management?  Here I think our opinions diverge:  I
wish to retain a convenient record of changes.  More about that in a
moment.

> see how it goes, and then, and only then go for a more
> complex solution.  there's no point wasting time writing
> 3 zillion lines of C for something that turned out to
> be a bad idea, when you could of worked it out with a
> rapid prototype.
>
Different schools.  A friend and I once tackled a moderately simple
text processing task in AWK and C respectively.  We were all
experienced programmers, but not proficient in AWK or C, just
differently so, hence the choice.

We finished at about the same time, with identical results, and we
were both surprised :-)

> IIRC plan 9 was an experiment that came out of a research
> lab and in response to the question what they for version
> control, well was:
>
>     /n/dump
>
That's fine where conversation is the primary communication channel.
Rob can walk up to Dave and ask a question and get a reasonable
answer.  But with the advent of geographically remote development, the
knowledge has to be embedded in the source code.  RCS (more than CVS,
all I like about CVS is the client-server model, other things I accept
intellectually, but have no emotional ties to) and SCCS held in a
nutshell batches of changes that are related to each other in a
fashion that /n/dump cannot do.  Or am I still not making sense?

> on that topic i built a version of /n/dump using a program
> (to call ftw(3) and stat(2)) and some scripts (to select and
> copy the files) when i was at PRL.  as fast as i could free up
> RA90's [1GB] i was headed to have the last ~30 days of all the
> user's home directories on mag disc.  presented it as a WIP at a
> USENIX -- hell, ken, with phil in tow, walked in.
>
You could have been well rewarded for that, the first crisis the DOS
user encounters when moving to Unix is the inability to recover
deleted files, and a facility as you provided would have been a
godsend to many like me who had to learn the discipline of

	alias rm="rm -i"

the hard way.

> on top of that ran the normal backups.  my version of /n/dump
> was there for when someone blew away a file that they'd created
> recently so they could go and get it themselves with cd, ls and cp.
>
Very cool, as I was saying.  But only viable once disk space stopped
being the most expensive computing resource (or second, whatever, when
it was no longer as critical).  For curiosity's sake, when I was at
university in the early seventies, admin and research (just under
10000 students) shared a Univac 1106, later Univac 1110, with 50Meg of
disk space.  I reckon I have in my office more computing resources
(and software tools) than it took NASA to put man on the moon (one of
my lectureres had been in the control room at the time of the recovery
of Apollo 13 - I don't know if he got religion then or had it already
:-)

> if i had decided to write this thing in C it woulda taken months
> and months more to debug; stuff that plays with time breaks when
> it's time for it to break.
>
CVS was a bunch of scripts, and RCS was very much based on SCCS, which
I presume was a mature product, at least be the time RCS was being
undertaken.  I think your points are sound, but I'm really not aiming
at immature technology, although no doubt it still has rough edges.

In private mail, rsc rightly criticises sourceforge's web interface,
that bit _is_ the immature part.  CVS as a tool is quite robust enough
for the purpose I have in mind.

> fixing a broken 'case' statement is a lot easier than wading
> through hundreds or more lines of C.  speed was not an issue,
> 'cos it was basically i/o bound.  anyway, you can fix that
> later.
>
As I said, it is a matter of comfort zones.  I have to refer to man
pages even for rudimentary shell commands, whereas I think I have a
good memory for C idioms (some of which I get wrong without fail :-)

> been there, seen that, got the bowling shirt ...
>
Please write a book!  I promise to donate a copy to everyone I have
occasion to discuss computing philosophy with.  And keep it full of
opinions and anecdotes.  Also, if Daniel Friedman (anthropologist and
computer rabbi at SUNY, Buffalo, in 1975) is still around, consult
him, he has/had the most wonderful way to concatenate anecdotes into
useful lessons.  Those were the days!

++L

Re: [9fans] Publish and be damned.

[Boyd Roberts]

From: "Lucio De Re" <lucio@proxima.alt.za>
> I have an unfinished game (mastermind or bulls and cows) for Plan
> 9 I threw together to get a feeling for the graphics.  I am reluctant
> to post it as it stands because of the personal involvement, possible
> criticism, any number of embarrassments due to the unfinished nature
> of the program.

no, the 'owner' of the code gives you the url.  the url points at the
version that the 'owner' is prepared to release.  the url should point
at a 'portable' single file.  no 5k tarred (sic) zipped nonsense.

use bundle:

    http://www.planete.net/~boyd/code/bundle.html

and if it's large, and only then, then compress it.

you just maintain a chunk of pages with a chunk of urls.  you could
code it in a few hours with the shell of your choice.  look at:

    http://www.planete.net/~boyd/code/mkthumb

it doesn't do what you want, but its exhibits the principle.

this is a lot faster to write and use than some random piece of
junk on windows/unix/linux etc and is reasonably portable across
bourne shells that support shell functions.

see how it goes, and then, and only then go for a more
complex solution.  there's no point wasting time writing
3 zillion lines of C for something that turned out to
be a bad idea, when you could of worked it out with a
rapid prototype.

IIRC plan 9 was an experiment that came out of a research
lab and in response to the question what they for version
control, well was:

    /n/dump

on that topic i built a version of /n/dump using a program
(to call ftw(3) and stat(2)) and some scripts (to select and
copy the files) when i was at PRL.  as fast as i could free up
RA90's [1GB] i was headed to have the last ~30 days of all the
user's home directories on mag disc.  presented it as a WIP at a
USENIX -- hell, ken, with phil in tow, walked in.

on top of that ran the normal backups.  my version of /n/dump
was there for when someone blew away a file that they'd created
recently so they could go and get it themselves with cd, ls and cp.

if i had decided to write this thing in C it woulda taken months
and months more to debug; stuff that plays with time breaks when
it's time for it to break.

fixing a broken 'case' statement is a lot easier than wading
through hundreds or more lines of C.  speed was not an issue,
'cos it was basically i/o bound.  anyway, you can fix that
later.

been there, seen that, got the bowling shirt ...

Re: [9fans] Publish and be damned.

[Christopher Nielsen]

On Fri, Apr 20, 2001 at 04:39:31PM +0200, Lucio De Re wrote:

> > the web is well established, but CVS?
> >
> I appreciate that CVS is only a partial solution.  It is, to my
> mind, as good as we've been able to make readily available; better
> solutions may exist, but they're not in the realm of free software.
> I'm also aware of forsyth's comment that the DUMP filesystem in
> Plan 9 is adequate, but somehow I can't be convinced that it provides
> all the benefits of CVS.  And, quite honestly, I could use more
> features than CVS offers, although I'd be hard put to explain
> exactly what features I miss.

CVS is broken in many ways. Take a look at subversion.

http://subversion.tigris.org

It's not done yet, but it's getting pretty close. It
fixes much of the brokenness in CVS.

--
Christopher Nielsen - Metal-wielding pyro techie
cnielsen@pobox.com
"Any technology indistinguishable from magic is
insufficiently advanced." --unknown

Re: [9fans] Publish and be damned.

[Boyd Roberts]

From: "Eric Lee Green" <eric@badtux.org>
>
> >     plan to throw one away, you will anyway ...
>
> Huh? CVS is the standard Unix source control system. Most major software
> development projects on Unix are managed either using CVS or one of its
> commercial competitors. FreeBSD, Apache, etc. all have publically
> accessible CVS archives for their developers (CVS has a couple of
> different Internet protocols so that unlike, say, Microsoft SourceSafe,
> you can use it over the Internet).
>
> ...

nice auto-flame.  read what i wrote (above) -- again.

start with a prototype.  work it out.  then turn it
into a production system.  it takes time.  simple
solutions work.

>               Cruisin' the USENET since 1985

is this some sort of joke?

Re: [9fans] Publish and be damned.

[Lucio De Re]

On Fri, Apr 20, 2001 at 04:52:12PM +0200, nemo@gsyc.escet.urjc.es wrote:
>
> :  To Nemo:
> :
> :  I've been reading your commentary, and would like to feed back to you
>
> Please do.
>
I'll actually wait till the end of April, as I'll be in Cape Town
then and I can use a postscript printer (I can't get used to reading
manuals exclusively on a monitor - can't take it into my favourite
reading places :-)

> :  some corrections, as well as obtain the most recent copy, in one form
>
> it's always at http://gsyc.escet.urjc.es/~nemo/9.{ps,txt,us.ps}.gz
>
> :  or another.  Would you consider making it CVS-accessible in source
> :  form?
>
> sure.

The .txt form is presumably an output format.  Once I've set up the
CVS server, you can decide the preferable form for the source.  I'll
mail you with the details.

++L

PS: I tried to build a new (cpu+disk) kernel from a pristine April 2001
distribution, and got an undefined PREAD.  What are the most likely
kernel components I should not have removed from the pccpudisk config
file?  Or is the subsequent addendum from Dave Presotto what I'm
missing?  Somehow I missed the discussion on that item.

Re: [9fans] Publish and be damned.

[nemo]

:  To Nemo:
:
:  I've been reading your commentary, and would like to feed back to you

Please do.

:  some corrections, as well as obtain the most recent copy, in one form

it's always at http://gsyc.escet.urjc.es/~nemo/9.{ps,txt,us.ps}.gz

:  or another.  Would you consider making it CVS-accessible in source
:  form?

sure.

Re: [9fans] Publish and be damned.

[Lucio De Re]

On Fri, Apr 20, 2001 at 02:22:02PM +0200, Boyd Roberts wrote:
> why not just manage a web page with links to the originals
> as a first cut.  then if it works out move on to a more
> complex solution?

In reply to Boyd...

I suppose I'm trying to take ownership away from the originators,
because I see it as slowing down development.  Let me try to explain
by example:

I have an unfinished game (mastermind or bulls and cows) for Plan
9 I threw together to get a feeling for the graphics.  I am reluctant
to post it as it stands because of the personal involvement, possible
criticism, any number of embarrassments due to the unfinished nature
of the program.  This way, it will never be anything more than a
curiosity.  It is my prerogative to keep it hidden, but it would
probably be a lot better if I dumped it on a CVS archive (I'll come
back to your question in a moment) and worked on it in moments of
interest, let anyone else also contribute to it.

>     plan to throw one away, you will anyway ...
>
If I remember correctly Brooks also emphasised the need to store
program documentation with the program text, and CVS adds historical
information, which I certainly value (and so do Bell Labs inmates,
it would seem :-)

> the web is well established, but CVS?
>
I appreciate that CVS is only a partial solution.  It is, to my
mind, as good as we've been able to make readily available; better
solutions may exist, but they're not in the realm of free software.
I'm also aware of forsyth's comment that the DUMP filesystem in
Plan 9 is adequate, but somehow I can't be convinced that it provides
all the benefits of CVS.  And, quite honestly, I could use more
features than CVS offers, although I'd be hard put to explain
exactly what features I miss.

The nice bit about CVS is that it is a useful tool on which to base
improvements, which makes a pleasant change from the more common
approach on this list of criticising (we all do it, it's not my
intention to offend anyone) without offering a better alternative,
at least not an immediately practical one.

In reply to private mail from Russ:

I still need to spend some effort to make the CVS server accessible.
What I feel a project like this needs is the encouragement of Bell
Labs, at the very minimum an understanding that its purpose is not
contrary to Bell Labs' intentions, and that there is a place where
mutually exclusive objectives can be negotiated to some compromise.
I suppose we could draw up a mission statement or memorandum of
understanding that all participants could accept and work to.

To Nemo:

I've been reading your commentary, and would like to feed back to you
some corrections, as well as obtain the most recent copy, in one form
or another.  Would you consider making it CVS-accessible in source
form?

To everyone :-)

There may be intellectual property issues and personal interest issues
I have overlooked as I perceive intellectual property as purely a
reflection of my own barely controlled need to _own_ things.  Please
be encouraged to make suggestions.  I am tempted to call this CVS idea
the "plan 9 software forge", and perhaps we should just be using
sourcefourge anyway (I didn't think of that earlier).  If people think
we should head in that direction, I have no objection.

++L

Re: [9fans] Publish and be damned.

[Eric Lee Green]

Boyd Roberts wrote:
> From: "Lucio De Re" <lucio@proxima.alt.za>
> > I have raised that cry before, but I seem to be just a voice in
> > the wilderness.  However, I can offer a public CVS repository for
> > those who, like me, think that incomplete source is nothing to be
> > ashamed of.
>
> why not just manage a web page with links to the originals
> as a first cut.  then if it works out move on to a more
> complex solution?
>
>     plan to throw one away, you will anyway ...
>
> the web is well established, but CVS?

Huh? CVS is the standard Unix source control system. Most major software
development projects on Unix are managed either using CVS or one of its
commercial competitors. FreeBSD, Apache, etc. all have publically
accessible CVS archives for their developers (CVS has a couple of
different Internet protocols so that unlike, say, Microsoft SourceSafe,
you can use it over the Internet). In fact, you can go to their web site
and browse the CVS archives with your web browser -- click on a file in
the directory tree, and you can see its complete revision history all
the way back to the beginning of time (or 1992, whichever is first :-),
and can click on any of those revisions to see what was that program
looked like at any one of those points in time. CVS also has all the
usual branch management stuff etc., though they are unnecessarily
difficult to use (sigh, at work we have a page on our intranet web site
that tells our engineers nothing except what convulated gibberish CVS
commands to use to create branches, tag releases, and merge changes from
a stable branch into the current development branch).

It puzzles me why you would be opposed to using a standard source
control system to, err, control source? Especially the source control
system that is standard for Internet software (virtually all of the
standard Internet software, such as Apache and Sendmail, are managed via
CVS). Now, I don't know what source control program is used by Bell Labs
internally to manage the Plan 9 sources. If it's a free one, and there's
a web front end to it, that might be the better alternative. I think
Lucio threw out CVS as a possibility because that's what he has, and
would be open to other alternatives -- if anybody offered one, rather
than simply carping that they don't understand standard software
development tools.

There's a right way to do things, and there's an easy way to do things,
and usually the two are completely different ways :-}. The deal is,
though, that in the long term the right way is always easier. As I've
learned to my regret in the past, when 6 months after the project is
released I'm called back to fix it the right way instead of the
quick'n'dirty easy way that I rigged it due to sheer laziness :-}. If
you're going to do a web browser for source code, doing it the right way
(via a web front end into a real source code management system) is,
well, the right way (sigh).

--
Eric Lee Green  http://www.badtux.org  mailto:eric@badtux.org
     Phoenix Branch -- Eric Conspiracy Secret Labs
              Cruisin' the USENET since 1985

Re: [9fans] Publish and be damned.

[Boyd Roberts]

From: "Lucio De Re" <lucio@proxima.alt.za>


> I have raised that cry before, but I seem to be just a voice in
> the wilderness.  However, I can offer a public CVS repository for
> those who, like me, think that incomplete source is nothing to be
> ashamed of.

why not just manage a web page with links to the originals
as a first cut.  then if it works out move on to a more
complex solution?

    plan to throw one away, you will anyway ...

the web is well established, but CVS?

[9fans] Publish and be damned.

[Lucio De Re]

I have raised that cry before, but I seem to be just a voice in
the wilderness.  However, I can offer a public CVS repository for
those who, like me, think that incomplete source is nothing to be
ashamed of.

 From monitoring this list, both forsyth and rsc have an endless
supply of unfinished tools that I would be thrilled to examine for
examples of interesting programming in Plan 9.

I'd also like to see publication of those bits of second edition
Plan 9 that can be made available without additional licence
restrictions.

Basically, I'll give anonymous read access to the CVS repository
to anyone who's interested, and write access to anyone willing to
contribute and monitor a particular module.  I'll configure CVS to
suit these "moderators", even provide mailing list capabilities
where required (I'd rather use private C News groups and gateways,
but I need to set things up properly first).

Anyway, if there is enough interest I'll set the CVS repository up
and make occasional noises about it on this list (or leave it to
the Plan 9 FAQ to make the relevant noises).

I know this sounds terribly Open Source-ish, but I am a firm believer
that knowledge best builds on knowledge and I wish I could quote
Dijkstra where he bemoans the fact that too often in programming
only the end results of the thinking processes are disclosed, where
the important and more useful details lie with how the results were
reached.

++L

PS: the bandwidth to the CVS repository is not on par with what US
Internet users may be comfortable with; unfortunately, that is beyond
my ability to influence.