Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!mcvax!hp4nl!phigate!nlgvax!hans From: hans@nlgvax.UUCP (Hans Zuidam) Newsgroups: comp.misc Subject: Re: The GNU Public License Message-ID: <272@nlgvax.UUCP> Date: 3 Aug 89 14:28:59 GMT References: <26@ark1.nswc.navy.mil> <26719@agate.BERKELEY.EDU> <5351@ficc.uu.net> <9655@phoenix.Princeton.EDU> <1989Jul30.210646.12194@twwells.com> <1811@hudson.acc.virginia.edu> <98@euteal.ele.tue.nl> Organization: Philips Research Laboratories, Geldrop Lines: 83 There has been a lot of debate (and some flaming) regarding the above subject both in these groups and in eunet.followup. In general the arguments split in two parts: about the morale (or ethics) and the usefulness of the GNU project. I do not want to go into the ethics of the GNU project and their COPYLEFT license: those are issues of a too political nature. But the of the GNU project is arguable. One often hears (reads?) about buggy software from suppliers and how having sources (ala GNU) allows you to go in and fix the problem if it is there too. The article below is the account of my practical experiences from yesterday and today (how actual ;-) ). All I wanted to do was to read one 6250bpi tape with both the X11R core and the user contributions and write two 1600bpi tapes, one with the X11 core and the other one with the user contributions. So, we have a Sun server with a tape drive: no problem there let's read the tape first. Only that tar should give me something like a file I/O error. Still, no problem, use the Ultrix VAX instead. And indeed, after a while the first part was on disk. Thus everything set for the next step: writing the first 1600bpi tape. Let's do it. Only after 15 minutes or so tar says: 'memory fault core dumped'. A small curse from my side and I look for the cause of the problem. It turns out the be a file with a rather long name (80 chars or so). Well, rename it, throw away the core file and go for it. As you can guess, another file with a long name and another core dump. So again rename it and start all over. That went alright until the next one (Yes I know I should have looked for them from the first time, "but alas" speeking with a well known person). Then my time was up and I had to rush of to an appointment. Today, all fresh and in a good mood I started out to finish the job. Well, as you can guess by now: after an hour or so tar informed me of a path name which was too long and quit. A somewhat bigger curse. But not all was lost: GNU TAR was here. Lets have a look: NAMSIZ is 100 bytes so make it 256. Must be enough. Compile, run. Well I was lucky this time; after only 5 files it found a illegal instruction and dumped core also. Taking another look at the source it was obvious I of course overlooked one small fact: the block size is 512 bytes and you can guess the rest. No despair: taking another look to see what it would do with long names it seems it will skip them. bitten the first time I took another look at the source. The following comment in the fileheader structure turned up: /* these following fields were added by JF for gnu */ /* and are NOT standard */ Thanks guys! Because I want to be compatible with the UNIX (Ultrix?) tar and I do *not* want to test GNU tar see if it is under all circumstances, the obvious way to go was rm -r. You see: my problem was not the inability of Ultrix's tar to handle long names, or making GNU tar compatible with Ultrix's; my problem was that of the one 6250bpi tape and getting it on two 1600bpi tapes. I was (again) caught by a most common problem which occurs in our profession: solving the wrong problem. We set out too often to solve a well defined problem which then evolves into an all together different one because of sub-problems. GNU seems to be doing exactly that. They are neither doing it good nor bad. People who want to toy around with free software have my blessing. There is a lot of good free software around (patch, perl, nn, and so on). But having source available is not necessary going to solve your problem(s). So it is not an argument in favour of GNU. Now I'm off to fill a problem report form (or whatever it is called). Doing that more often will help in the long run (I hope ;-) ), Hans The opinions ventilated above are of course my own and do not represent those of Philips. No need to tell you that. -- Hans Zuidam E-Mail: hans@pcg.philips.nl Philips Telecommunications and Data Systems, Tel: +31 40 892288 Project Centre Geldrop, Building XR Willem Alexanderlaan 7B, 5664 AN Geldrop The Netherlands