From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] Publish and be damned. Message-ID: <20010421093455.D348@cackle.proxima.alt.za> References: <20010420075428.A6221@cackle.proxima.alt.za> <007201c0c994$81ad3990$e0b6c6d4@SOMA> <20010420163931.A6978@cackle.proxima.alt.za> <011f01c0c9dd$2ccc5d40$e0b6c6d4@SOMA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <011f01c0c9dd$2ccc5d40$e0b6c6d4@SOMA>; from Boyd Roberts on Fri, Apr 20, 2001 at 11:02:13PM +0200 Date: Sat, 21 Apr 2001 09:34:56 +0200 Topicbox-Message-UUID: 8807225e-eac9-11e9-9e20-41e7f4b1d025 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