Re: [9fans] Publish and be damned.

[Lucio De Re <lucio@proxima.alt.za>]

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