Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!uakari.primate.wisc.edu!uflorida!stat!fsu!sun8!nall From: nall@sun8.scri.fsu.edu (John Nall) Newsgroups: comp.os.minix Subject: Re: The Upgrade Process Message-ID: <601@fsu.scri.fsu.edu> Date: 24 Mar 90 13:14:07 GMT References: <14589@nigel.udel.EDU> <589@fsu.scri.fsu.edu> <3867@plains.UUCP> Sender: news@fsu.scri.fsu.edu Reply-To: nall@sun8.scri.fsu.edu (John Nall) Organization: Florida State University Lines: 73 In article <3867@plains.UUCP> overby@plains.UUCP (Glen Overby) writes: >In article <589@fsu.scri.fsu.edu> nall@sun8.UUCP (John Nall) writes: >>So the original thesis still holds: there should be an easier method for >>someone who is a bona-fide purchaser of Minix to upgrade without having >>to wait for P-H to officially begin selling a new version. I have no > [deleted for brevity] >releasing new versions takes so long. Other than the delay, what is the >objection of waiting for P-H? None. But the delay between the present P-H version (1.3) and the current contender for new P-H version (1.5) is quite long. I don't know exactly how long, but certainly more than a year. (Time flies by when you're having fun. :-)) >OK, so let's work on improving what we have. What are the problems with the >upgrades? Why is it difficult? Yes, I tend to tilt at windmills. :-) And most certainly Glen is one of the people who have put a lot of time and energy into helping others upgrade. > > Andy posts uuencoded, compressed shars of context diffs for each > directory. The prospective upgrader has to learn : I hope to goodness that nothing that I said was interpreted as a flame at Andy! He does his part far above and beyond anything to be expected. Plus I suspect that many a struggling upgrader has received a helping help from ast in the form of suggestions. > (3) how to decode the file (uudecode | uncompress | unshar) > (4) how to apply the diffs (patch <*.cdiff) > > and there's no way about it. A tutorial could help a few people. Yes. > a solution to this would be to have "release notes" which detail > exactly what to mv or rm. Yes >Then there are the glitches, most of which can be tracked down to human or >program failure. We have the same programs Andy uses to create the >releases, yet there are still unexplainable problems (remember mined1.c?). I have no problem with those - that's part of the learning process. >It's always going to take some brainpower and time to upgrade from the net, >not to mention using non-AST stuff from the net. There will also always be >people asking for special hand-holding, even if you tell them EXACTLY what >commands to type in. Yup. Agreed. I think perhaps the tutorial mentioned is the proper method of easing the pain. Something akin to the "Introduction to Minix" document which can be sent to a new user. Such a tutorial might list the archives available, common problems (libc.a ordering, for example), and perhaps even some names of volunteers familiar with specific area who might be willing to help via e-mail. (I wonder how many of us see a note asking for help, know the answer, but don't reply because (a) it is something that EVERYONE knows so the guy will get 1,000 answers (but he gets none), or (b) we have answered other notes and are tired of it, or (c) we THINK we know the problem, but are not absolutely certain, so don't want to guess. > Glen Overby > uunet!plains!overby (UUCP) overby@plains (Bitnet) -- John W. Nall | Supercomputation Computations Research Institute nall@nu.cs.fsu.edu | Florida State University #include | Tallahassee, FL 32306