cwr@pnet01.cts.com (Will Rose) (03/25/91)
Glen Overby (overby@plains.NoDak.edu) writes: >In article <48414@nigel.ee.udel.edu> RECHTIEN%DOSUNI1.BITNET@cunyvm.cuny.edu (Jens-Heiner Rechtien) writes: >>Maarten Huisjes <mjh@cs.vu.nl> writes: >>> } -- Everyone should compress and uuencode his diff's -- >>> NO! >I agree with Maarten. I think the rest of the world is stupid to sit here >and pat BITNET people on the head. If you got a problem with your network, >either fix it yourself or GO PAY IBM TO FIX IT! You're on an IBM network; >don't they give you good technical support? Alas, I am not on an IBM network, and I cannot afford the extensive re-wiring of the west coast of America that would be needed to put me on one; however, all comp.os.minix files containing tabs/spaces still get munged on the way to my system. Checks down the feed line show no possibility of change. >It's not the net load that I really hate (not that I like it) -- it's the >manual work I have to do to decode the postings, and the additional disk >space it sucks up before I decode everything. We're talking megabytes >here... It's degrading that the whole reason for the uuencoding is to help >pacify an IBM creation. Well, I generally find that postings are under 64K (some mailers enforce this limit), so the most additional space used for uudecoding and decompressing is going to be 100K, allowing a 40% compression ratio. Not really a lot of space, and I've not found the time especially significant in the past. (Note, I don't decompress *everything*, but I do look at most of the stuff posted to comp.os.minix. Quite possibly when posting to comp.os.unix or alt.sources the rules would be different). One of the first shell scripts I wrote was a very crude file unpacker, and I now have an equally crude file packer to go with it. It even adds the footer, and drops me into the editor to add a descriptive message - the acme of user-friendliness!) When upgrading from 1.3 to 1.5.10 I finally decided, around 1.5.6, that for reliability I had to have correct crcs; having let things slide, it took me a month or so and a lot of help from my friends to get a clean set of files. Once you've added a patch with spaces substituted for tabs, that file and its descendants to the nth generation will fail crc checking. Ast once posted an important 2-line kernel patch without uuencoding; I tried for an hour to install it with the correct (new) crc, and failed. I now scarcely look at code that is *not* uuencoded; it will mostly run, but it's not reliable, and it's too difficult to patch. I realise uuencoding is a nuisance to the sender, but it's a life-saver to many recipients. Please use it if you can. Good luck - Will ----------------------------------------------------------------------- "If heaven too had passions | Will Rose even heaven would | UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!cw grow old." - Li Ho. | ARPA: crash!pnet01!cwr@nosc.mil | INET: cwr@pnet01.cts.com UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!cwr ARPA: crash!pnet01!cwr@nosc.mil INET: cwr@pnet01.cts.com
ghelmer@dsuvax.uucp (Guy Helmer) (03/26/91)
In <8177@crash.cts.com> cwr@pnet01.cts.com (Will Rose) writes: >Glen Overby (overby@plains.NoDak.edu) writes: >>In article <48414@nigel.ee.udel.edu> RECHTIEN%DOSUNI1.BITNET@cunyvm.cuny.edu >(Jens-Heiner Rechtien) writes: >>>Maarten Huisjes <mjh@cs.vu.nl> writes: >>>> } -- Everyone should compress and uuencode his diff's -- >When upgrading from 1.3 to 1.5.10 I finally decided, around 1.5.6, that for >reliability I had to have correct crcs; having let things slide, it took me >a month or so and a lot of help from my friends to get a clean set of files. >Once you've added a patch with spaces substituted for tabs, that file and its >descendants to the nth generation will fail crc checking. Ast once posted >an important 2-line kernel patch without uuencoding; I tried for an hour >to install it with the correct (new) crc, and failed. I now scarcely >look at code that is *not* uuencoded; it will mostly run, but it's not >reliable, and it's too difficult to patch. comp.os.minix has at the minimum several hundred readers that must keep exact copies of the MINIX source so that they may upgrade when the time comes. From my past experience (I've upgraded from 1.1 - 1.2 - 1.3, then purchased 1.3 and upgraded to 1.4b and 1.5.{3,6,8,9,10}), the problems that come with unreliable news and mail software cause plenty of aggravation when trying to apply patches or install new files that aren't exact copies of the original. Computers and networks should be the tools, not the source of the problems! Admittedly, now that I have a good usenet news feed, I usually don't have problems with source code. In the good old days, all I had was a subscription to MINIX-L from NDSUVM via BITNET, which is why I purchased MINIX 1.3 - my version of 1.3 that was upgraded from 1.1 was a complete mess. The patches and new sources I had were all obtained as mailed messages over IBM's infamous RSCS, which crunched on TABs, chopped lines, and changed characters in unrepairable fashion. For those who believe we shouldn't make concessions to BITNET and the other file-munging networks, here's a suggestion: Now that FTP is available over BITNET and many mail archive servers exist, maybe we should create a sources and patches group that doesn't uuencode postings, and then someone should create an archive service that automatically puts these postings out on an internet-accessible server. Then, the people who don't get reliable feeds can get sources they need by using either the BITNET FTP server or a mail archive server. The BITNET FTP server can automatically uuencode files, if you request it, and it's been very reliable when I've used it. I personally don't believe this group should drop the policy of uuencoding source and patch postings. If we must drop that policy, please plan an alternative. >UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!cwr >ARPA: crash!pnet01!cwr@nosc.mil >INET: cwr@pnet01.cts.com -- Guy Helmer | helmer@sdnet.bitnet Dakota State University | dsuvax!ghelmer@wunoc.wustl.edu (605) 256-5264, (605) 256-2788 | uunet!dsuvax!ghelmer Ahh, if weddings were as easy to design as software...