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: <20010421145954.B2598@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> <20010421093455.D348@cackle.proxima.alt.za> <002b01c0ca53$27545b30$e0b6c6d4@SOMA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <002b01c0ca53$27545b30$e0b6c6d4@SOMA>; from Boyd Roberts on Sat, Apr 21, 2001 at 01:06:43PM +0200 Date: Sat, 21 Apr 2001 14:59:55 +0200 Topicbox-Message-UUID: 882e4320-eac9-11e9-9e20-41e7f4b1d025 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