u31b3hs@cip-s01.informatik.rwth-aachen.de (Michael Haardt) (05/23/91)
Hello world,
after reading comp.os.minix this morning, I want to suggest a solution
for the AM problem. If I am right, PH does not like that a third party
distributes a *complete* MINIX version, even if the recipients bought
original MINIX from PH. In my opinion Fred van Kempen has centralised
things too much for PH. This makes administration easier, but PH does
not like it. I do not believe that they can be convinced. Another
point is that I do not like a 20 meg tape without having the choice
what extensions should be made.
Fred's argument was that applying packages of diffs for everything will
be too difficult for a lot of people. I don't think so, because most
people do not want all extensions. There are a some MINIXers who have
problems with upgrades, but most of us are connected to a network...
We will help them in future like we do now - and it works.
My suggestion is to set up a list of MINIX programs (complete set of diffs,
standalone programs, interesting documents, drivers etc) which should
be administrated like the MINIX information sheet and posted regularly.
Each point should take about 20 lines describing contents, version number,
author, *one* reference ftp adress and a unique filename or directory
for it. The advantages are obvious:
- You will find things you are looking for in archives, due to
unique file/directory names
- You always know the current version of a project
- People do not waste time on inventing wheels twice, as happens
very often at the moment
- Reduction of network traffic (Where can I get xyz, Is there a newer
version, Is there something like xyz for MINIX, ftp'ing big files to
investigate them etc...)
- No second-hand things, patched by someone who do not know where
to send diffs to
We should discuss this. If the result is positive, I would administrate
such a list.
Namaskaar
Michael Haardt
BTW: This is not a flame against anybody.dprrhb@inetg1.ARCO.COM (Reginald H. Beardsley) (05/23/91)
The main problem with patches is that after a while there simply are too
many conflicts and patch begins to fail more than it succeeds. There is a way
around this.
If we can agree (probably hopeless, but worth a try :-) ) on
a set of feature sets we can have base Minix from PH. NLMUG AM Phase 1 patches
on base PH, NLMUG AM Phase 2 patches on Phase 1, etc. If someone wants to
put the effort into creating the patches for a different set of Phases we
can have FUBAR AM Phase 1, etc. Then instead of arguing about PH policy we
can spend out time flaming each other on the relative merits of NLMUG AM Phase
20 vs. FUBAR AM Phase 10 :-)
Incidentally, one of the main reasons for having multiple phases is to keep
cdiff from getting confused and dumping two complete copies of everything into the output and producing a cdiff file PH would not accept.
--
Reginald H. Beardsley
ARCO Information Services
Plano, TX 75075
Phone: (214)-754-6785
Internet: dprrhb@arco.com klamer@mi.eltn.utwente.nl (Klamer Schutte) (05/24/91)
In <1991May23.132757.13578@Arco.COM> dprrhb@inetg1.ARCO.COM (Reginald H. Beardsley) writes: >Incidentally, one of the main reasons for having multiple phases is to keep >cdiff from getting confused and dumping two complete copies of everything >into the output and producing a cdiff file PH would not accept. This won't work. 1) When the cdiff is as big as the whole file it is likely to be rewritten completely. Why not send the new file in that case? 2) When a cdiff to a file gives the whole file, than the partial cdiffs to this file also give the whole file. When PH really make a point from this (are they that low?) you should device a scheme in which the original file is neeeded for getting the new file, without making it possible to get the new (or old) file without the old one. Perhaps adding the ascii values will do? Klamer -- Klamer Schutte Faculty of electrical engineering -- University of Twente, The Netherlands klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamer
dprrhb@inetg1.ARCO.COM (Reginald H. Beardsley) (05/25/91)
In article <klamer.675071816@mi.eltn.utwente.nl>, klamer@mi.eltn.utwente.nl (Klamer Schutte) writes: > In <1991May23.132757.13578@Arco.COM> dprrhb@inetg1.ARCO.COM (Reginald H. Beardsley) writes: [text deleted] > This won't work. > 1) When the cdiff is as big as the whole file it is likely to be rewritten > completely. Why not send the new file in that case? This is the source of the problem with Fred's stuff. It's what we need to fix. > Perhaps adding the ascii values will do? If we adopt the convention of padding the end of the old file with nulls to make it as long as the new file this could be done. We'd have the problem of the files always growing longer, but since this would be embedded blanks where old code was removed, it could be deleted by running through a beautifier after patching. The real point is to accomodate both Andy and Fred without causing conflicts. This group spans the range from very naive to very sophisticated. By breaking the extensions to Minix up into several phases someone can start out with the base PH distribution and add features as they learn more about operating systems. -- Reginald H. Beardsley ARCO Information Services Plano, TX 75075 Phone: (214)-754-6785 Internet: dprrhb@arco.com
mitchell@MDI.COM (Bill Mitchell) (05/25/91)
In article <1991May24.184035.21247@Arco.COM> dprrhb@inetg1.ARCO.COM (Reginald H. Beardsley) writes: >In article <klamer.675071816@mi.eltn.utwente.nl>, klamer@mi.eltn.utwente.nl (Klamer Schutte) writes: >> In <1991May23.132757.13578@Arco.COM> dprrhb@inetg1.ARCO.COM (Reginald H. Beardsley) writes: > >[text deleted] > >> This won't work. >> 1) When the cdiff is as big as the whole file it is likely to be rewritten >> completely. Why not send the new file in that case? > >This is the source of the problem with Fred's stuff. It's what we need to fix. > Seems it should be workable to define and use an alternative patch file format something like the following: 1. CRC of the file to be patched. Don't patch it unless the CRCs match User must have an exact copy of the file-to-be-patched. 2. list of ranges of lines to be deleted from the original file something like "1,4,7-96,112" this would include all lines which the changes either delete or modify 3. line number in the resulting file after which an insertion is to be made use a line number of zero to insert at the head of the file 4. count of lines to be inserted at that point 5. the lines of text to be inserted at that point 6. zero or more repetitions of items 3 thru 5 7. CRC of patched file (as a doublecheck) Seems this file ought to be free of copyrighted information from the original file. Seems it shouldn't be too tough to implement a program to convert diffs and cdiffs into this format, and to write a program to use patch information in this format to patch files. -- mitchell@mdi.com (Bill Mitchell)
gt0178a@prism.gatech.EDU (Jim Burns) (05/26/91)
in article <1991May25.144403.318@MDI.COM>, mitchell@MDI.COM (Bill Mitchell) says: > 1. CRC of the file to be patched. > Don't patch it unless the CRCs match > User must have an exact copy of the file-to-be-patched. This will cause havoc trying to keep straight 'official patches' from net supplied patches. Net patches can be supplied relative to some well known, official patch, but then all net patches after that will fail on the CRC. Won't be too bad if the number of CRC checking patches are kept to a minimum; otherwise there will be a lot of hand editing. Of course, since this is being proposed as a solution to massive re-writes including gobs of copyright code in the cdiff, all future patches would be difficult to apply anyway, so this would be the obvious case that CRC checking patches would be limited to. -- BURNS,JIM (returned student & Technology Dynamics staff member, an ATDC co.) Georgia Institute of Technology, 30178 Georgia Tech Station, Atlanta Georgia, 30332 | Internet: gt0178a@prism.gatech.edu uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a
mitchell@MDI.COM (Bill Mitchell) (05/27/91)
In article <29875@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (Jim Burns) writes: >in article <1991May25.144403.318@MDI.COM>, mitchell@MDI.COM (Bill Mitchell) says: > >> 1. CRC of the file to be patched. >> Don't patch it unless the CRCs match >> User must have an exact copy of the file-to-be-patched. > >This will cause havoc trying to keep straight 'official patches' from net >supplied patches. Net patches can be supplied relative to some well known, >official patch, but then all net patches after that will fail on the CRC. >Won't be too bad if the number of CRC checking patches are kept to a >minimum; otherwise there will be a lot of hand editing. Of course, since >this is being proposed as a solution to massive re-writes including gobs >of copyright code in the cdiff, all future patches would be difficult to >apply anyway, so this would be the obvious case that CRC checking patches >would be limited to. >-- I thought I had followed this up, but haven't seen the article appear. I suspect that I mistakenly responded by mail instead of posting a followup to the net. Oops. Agreed, the CRC check would cause a real administrative pain. All patches would have to start relative to a known source version, and would have to be applied strictly in sequence. That pretty much forces patches to be applied in this way distributed by one single central administrator. How about another suggestion, then...... I think it is legally permissible to quote portions of a copyrighted work, up to about ten percent. That's probably enough to allow the context-establishing quotes produced by cdiff(1), but not enough to allow each line of the file-to-be-patched which is to be deleted or modified to be quoted in the patch file. How about modifications to cdiff(1) so that instead of literally quoting each line from the file-to-be-patched which is to be deleted or modified, it would compute a signature value for those lines (something like checksum, but less prone to falsing) and provide that value in the patch file in place of the quoted lines? patch(1) could then be modified to compute the same signature value for corresponding lines of the file-to-be-patched, and alert the user when it detected differences. -- mitchell@mdi.com (Bill Mitchell)