charles@hp-sdd.hp.com (Charles Keith) (03/20/90)
Some weeks ago, a well meaning poster complained about the "busywork" of
everyone doing upgrades. Having done 1.2 -> 1.3 on a floppy only system,
I was interested, but not concerned. Now, having patched (but not compiled)
1.5.5, I am not only concerned, but a little upset. There seem to be two
problems at work here:
1. The upgrade process is long, tedious and error prone. Once you are out
of sync or have lost a file, endless time can be wasted trying to recover.
If you get out of sync and lose the path back, the only recourse is to
whine on the net (could somebody send me...), wasting bandwidth.
2. The upgrade postings were riddled with defects and errors. Each problem
requires diagnosis and manual attention, and sometimes fiddling of the most
desperate variety (perhaps if I add this line the crc will come out right).
Andy's surprise that people could be having problems (the postings are all
automated) are reminescent of the electric company's attitude when you get
a $10,000 electric bill (but it's all computerized!:). Seriously, this kind
of stuff is driving people away from minix, and soon only the captive audience
(academics and students) will be left.
The proposed solution was to identify and register Real Licensees and give
them an easier way to upgrade. But unless administration suddenly becomes
free, this will not work (think about the government).
Rather than just whine about the sad state of affairs, I would prefer to
propose solutions to the problems that bedevil us. Here are my (modest)
proposals:
1. If the readership of this group is 10,000 as Andy suggests, perhaps we
should all shout a suggestion in Andy's ear: TEST! Promise an undergraduate
some extra credit and lock him/her up in a room with the old version and
some upgrade postings. Remember, it is undergraduates that are supposed to
suffer, not the world at large :). I certainly would be willing to wait an
extra week or two if I were promised that things would go smoothly later.
Problems with shar'ed binaries and empty files should never get out of the
Netherlands.
2. Lift the ban on posting certain parts of the system in their entirety.
For example, commands (which already has a high PD content) and lib (which
is a chronic problem area). If this means they fall into the public domain,
so be it. This will help enormously when someone gets out of sync, and the
only recourse is to go back to P-H (we know how much fun that is:). The
kernel/mm/fs has been less of a problem for upgrades, primarily because of
limited size and the lavish attention paid to these areas. If these remain
off-limits, it will be less likely for someone to (gasp) build a system
from upgrades.
3. Create (graduate project) an automated upgrade system to compliment the
automated posting system. This must be robust and well tested, and try to
anticipate problems that would torpedo the process in midstream. Start with
full crc checks on the old revision, make sure enough disk space is available,
make the process restartable (or at least recoverable) if it crashes.
Charles Keith
Hewlett-Packard Co. UUCP: {hplabs|ucsd|hpfcla}!hp-sdd!charles
16399 W. Bernardo Dr. Internet: charles%hp-sdd@hplabs.HP.COM
San Diego, CA 92127 Disclaimer: I am not a qualified spokesperson.
--
Charles Keith
Hewlett-Packard Co. UUCP: {hplabs|ucsd|hpfcla}!hp-sdd!charles
16399 W. Bernardo Dr. Internet: charles%hp-sdd@hplabs.HP.COM
San Diego, CA 92127 Disclaimer: I am not a qualified spokesperson.nmutsaer@ruunsa.fys.ruu.nl (Peter Mutsaers) (03/20/90)
In article <3450@hp-sdd.hp.com> charles@hp-sdd.hp.com (Charles Keith) writes: >2. The upgrade postings were riddled with defects and errors. Each problem >requires diagnosis and manual attention, and sometimes fiddling of the most >desperate variety (perhaps if I add this line the crc will come out right). >Andy's surprise that people could be having problems (the postings are all >automated) are reminescent of the electric company's attitude when you get >a $10,000 electric bill (but it's all computerized!:). Seriously, this kind >of stuff is driving people away from minix, and soon only the captive audience >(academics and students) will be left. Yes I agree, I was very enthousiastic with minix on my ST in the beginning (especially the ST, which has patches on the patches on the updates for the PC is awful) but I have been driven away from minix, I would have to spend hours a day just to keep up to date! I'll wait until another solution comes available. Peter Mutsaers
ast@cs.vu.nl (Andy Tanenbaum) (03/21/90)
In article <3450@hp-sdd.hp.com> charles@hp-sdd.hp.com (Charles Keith) writes: >Rather than just whine about the sad state of affairs, I would prefer to >propose solutions to the problems that bedevil us. Here are my (modest) >proposals: > >Promise an undergraduate >some extra credit and lock him/her up in a room with the old version and >some upgrade postings. Won't fly. MINIX is not really part of my regular work. It is kind of a hobby that I work on only in the evenings. I don't have the authority to lock up undergraduates and force them to test MINIX on pain of flunking out if they don't. Before making new versions, I post a local message to our 400 students to see if anybody wants to help. Typically 1 or 2 students show up, mostly because I give them 17 free diskettes. Maybe they make a couple of remarks later; maybe they don't. Either way, there is little I can do. Undergraduates do not form a large pool of free labor. >2. Lift the ban on posting certain parts of the system in their entirety. I have posted whole files from time to time, and even whole directories (e.g., /usr/include). Given that many of the postings, certainly the recent ones, have only been bits and pieces of files, that won't help much. Also, I don't think P-H would approve. >3. Create (graduate project) an automated upgrade system to compliment the >automated posting system. This must be robust and well tested, and try to >anticipate problems that would torpedo the process in midstream. Start with >full crc checks on the old revision, make sure enough disk space is available, >make the process restartable (or at least recoverable) if it crashes. We do have graduate projects, but this is not a suitable one. Such projects must have a high research component. Automating updating is not a good choice. Typical projects have been redoing a new 'make-like' program that runs all its compilations in parallel on a distributed system using Amoeba, writing a parallel chess program in Orca (our new parallel programming language), or writing a very fast C compiler for the SPARC using ACK. In short, I do not have a lot of captive manpower (in fact, none) at my disposal. It's just me, and then only in the evenings. This is kind of different than companies that have rooms full of programmers working for them. If you or anyone else in Netland wants to work on a system that takes two source trees and posts the diffs along with another system that installs them, I am not averse to it. Andy Tanenbaum (ast@cs.vu.nl)
emv@math.lsa.umich.edu (Edward Vielmetti) (03/21/90)
perhaps minix should look at ``cvs'', the concurrent version system. to get it to work you need to have a working RCS, I don't know if that's been ported yet. CVS is based on the idea that multiple people may be hacking the same sources, so it seems ideal to a project like minix. ftp'able from prisma.com or from prep.ai.mit.edu. RCS is from arthur.cs.purdue.edu. --Ed Edward Vielmetti, U of Michigan math dept. emv@math.lsa.umich.edu
gert@targon.UUCP (Gert Kanis) (03/21/90)
In article <3450@hp-sdd.hp.com> charles@hp-sdd.hp.com (Charles Keith) writes: > >1. The upgrade process is long, tedious and error prone. Once you are out >of sync or have lost a file, endless time can be wasted trying to recover. > >2. The upgrade postings were riddled with defects and errors. Each problem >requires diagnosis and manual attention, and sometimes fiddling of the most >desperate variety (perhaps if I add this line the crc will come out right). >Seriously, this kind >of stuff is driving people away from minix, and soon only the captive >audience (academics and students) will be left. I will not deny but I think doing an upgrade (and finding problems) also has a educational aspect. Please don't get me wrong, I didn't say that having something that doesn't work after an upgrade is a blessing. But it pushes you (or whoever upgrades) to delve deeper into Minix. Remember the upgrades posted here on the net are ONLY for those who would *LIKE* to go (voluntary) through the upgrade process. If you're happy with Minix 1.3, stay with it :-) or wait for new versions to come out by P.H. >Rather than just whine about the sad state of affairs, I would prefer to >propose solutions to the problems that bedevil us. Here are my (modest) >proposals: > >1. If the readership of this group is 10,000 as Andy suggests, perhaps we >should all shout a suggestion in Andy's ear: TEST! Promise an undergraduate >some extra credit and lock him/her up in a room with the old version and >some upgrade postings. Yeah, lock'm up :-). No seriously I think at the moment we (on the net) are those `undergraduates'. My guess is that the main reason that we get all the updates is to let a big group test the stuff on a variety of hardware. The situation now somewhat improved with the `referees'. >Problems with shar'ed binaries and empty files should never get out of the >Netherlands. > Oh please, we want to get rid of them :-) :-) >[rest deleted] >Charles Keith Although I do not disagree with your suggested changes I like to stress `Upgrade from the net is voluntary'. BTW I have a somewhat related question to Dr. Tanenbaum: You indicated that 1.5.x will come available from Prentance Hall, will there also be a Atari ST 1.5.x from PH? (If ,as rumours go, there will be Amiga 1.5 and MacMinix 1.5 it would be a good idea to have ST 1.5 also). Gert Kanis. +-----------------------------------------------------------------+ | No more jokes they | Gert Kanis, ASW BS SWP | | take to much space. | Nixdorf Computer BV, Postbus 29 | |----------------------| 4130 EA Vianen, Netherlands. | | I do not represent | E-mail : ... nluug.nl!targon!gert | | anyone elses opinion.| or {..uunet!mcsun!}hp4nl!targon!gert | +-----------------------------------------------------------------+
Peter_Van_Epp@cc.sfu.ca (03/22/90)
It seems to me that the answer to people how don't like the network upgrade with the associated problems is quite simple: wait until the bugs are worked out of the upgrade and PH releases the new version and buy a new copy, no upgrade problem (but a delay in when you get the upgrade but you can't have your cake and eat it too!). Take a minite and think about what other software packages you own that give you free upgrades (if you are willing to do some work) to say nothing of including source code and allowing multiple copies to be in use at once. Remember that Andy could make and test the changes and make them only availible for a fee from PH. You can also join the MINIX beta test group and work towards making the upgrades error free!
ast@cs.vu.nl (Andy Tanenbaum) (03/22/90)
In article <1083@targon.UUCP> gert@targon.UUCP (Gert Kanis) writes: >You indicated that 1.5.x will come available from Prentance Hall, >will there also be a Atari ST 1.5.x from PH? The tentative plan is as follows. P-H will release 5 packages around August 1, 1990 (if all goes well). They will be: 1. PC/XT/AT/386 version on 5.25 inch disks 2. PC/XT/AT/386 version on 3.5 inch disks 3. Atari ST 4. Amiga 5. Macintosh They will all contain the same basic files, but will vary slightly in the sense that there will be no TOSREAD for the Macintosh and no routine to read the IBM clock on the Atari. Other than that sort of stuff, they will be pretty much alike. Most files will be identical, in fact. The 3 68000 versions will use the same binaries so you can compile a program on an Amiga and execute it on an Atari, etc. The 2 IBM versions will differ only in the layout of the disks. Both IBM packages will contain the PC boot disk, the AT boot disk, and the BIOS boot disk, and both will require only 512K (but will use whatever is available). This will eliminate a lot of problems. Tentative price is $140 for first time buyers, with a $40 discount to people who are upgrading from a previous version (and prove it by sending in their old P-H boot diskette). P-H is definitely committed to bringing out 1.5 as a product, but the dates and prices are tentative. Don't call them now since the people who answer the phone know nothing about this and will vigorously deny all of it. Andy Tanenbaum (ast@cs.vu.nl) P.S. With much trepidation, I posted the Amoeba announcement here, but please don't ask me for a copy unless you are with a university or company that has an Ethernet full of Suns or VAXes and is seriously interested. Almost all the papers in the book have been published, so you can read them in the library if you are just a bit curious. The list is given below. .nr PS 12 .nr VS 14 .nr LL 5.5i .LP .tr ~ .de Hd . .bp 0 .ti -0.5i .B . .ce 1 \\$1 .R .br .. .ce 1 .ta 6.5iR \fB TABLE OF CONTENTS\fR .sp 2 .in +0.5i .Hd "INTRODUCTION" .IP \fB\0\02\fR Tanenbaum, A.S. and Mullender, S.J.: "An Introduction to Amoeba" .Hd "OVERVIEW OF AMOEBA" .IP \fB\0\09\fR Mullender, S.J., Rossum, G. van, Tanenbaum, A.S. Renesse, R. van, Staveren, H. van: "Amoeba\(emA Distributed Operating System for the 1990s," (To be published in \fIIEEE Computer Magazine\fR, May 1990). .IP \fB\026\fR Tanenbaum, A.S., Renesse, R. van, Staveren, H. van., Sharp, G.J., Mullender, S.J., Jansen, A.J., and Rossum, G. van: "Experiences with the Amoeba Distributed Operating System," (Accepted for publication in Communications of the ACM). .IP \fB\055\fR Mullender, S.J.: "Distributed Operating Systems: State-of-the-Art and Future Directions" Proc. of the EUTECO 88 Conf., R. Speth (ed.), North-Holland, Vienna, Austria, pp. 57\-66, 1988 .Hd "DESIGN ASPECTS" .IP \fB\063\fR Tanenbaum, A.S., Mullender, S.J., and van Renesse, R.: "Using Sparse Capabilities in a Distributed Operating System" .I "Proc. Sixth International Conf. on Distr. Computer Systems" , IEEE, pp. 558-563, 1986. .IP \fB\069\fR Renesse, R. van, Tanenbaum, A.S., and Wilschut, A: "The Design of a High-Performance File Server" .I "Proc. Ninth Int'l Conf. on Distr. Comp. Systems" , IEEE, pp. 22-27, 1989. .IP \fB\074\fR Rossum, G. van: "AIL \- A Class-Oriented Stub Generator for Amoeba" Proceedings of the Workshop on Experience with Distributed Systems, Springer Verlag, 1989 .Hd "PERFORMANCE" .IP \fB\082\fR Renesse, R. van, Staveren, H. van, and Tanenbaum, A.S.: "Performance of the Amoeba Distributed Operating System," .I "Software\(emPractice and Experience" , vol. 19, pp. 223-234, March 1989. .Hd "AMOEBA OVER WIDE-AREA NETWORKS" .IP \fB\095\fR Renesse, R. van, Tanenbaum, A.S., Staveren, H., and Hall, J.: "Connecting RPC-Based Distributed Systems using Wide-Area Networks," .I "Proc. Seventh Int'l Conf. on Distr. Comp. Systems" , IEEE, pp. 28-34, 1987. .IP \fB102\fR Renesse, R. van, and Staveren: "Wide-Area Communication under Amoeba," Report IR-117, Dept. of Mathematics and Computer Science, Vrije Universiteit, Dec. 1986. .Hd "MULTIPROCESSOR AMOEBA" .IP \fB113\fR Moergestel, L.J. van, Bal, H.E., Kaashoek, M.F., Renesse, R. van, Sharp, G.J., Staveren, H. van, Tanenbaum, A.S.: "Amoeba on a Multiprocessor," Report IR-206, Dept of Mathematics and Computer Science, Vrije Universiteit, Dec. 1989 (accepted for publication in \fIForce File\fR). .Hd "BROADCASTING" .IP \fB124\fR Kaashoek, M.F., Tanenbaum, A.S., Flynn Hummel, S., and Bal, H.E.: "An Efficient Reliable Broadcast Protocol," .I "Operating Systems Review" , vol. 23, pp. 5-19, Oct. 1989. .Hd "DISTRIBUTED PROGRAMMING" .IP \fB138\fR Bal, H.E., and Tanenbaum, A.S.: "Distributed Programming with Shared Data" .I "IEEE Conf. on Computer Languages" , IEEE, pp. 82-91, 1988. .IP \fB148\fR Bal, H.E., Kaashoek, M.F., Tanenbaum, A.S., Jansen, J.: "Replication Techniques for Speeding up Parallel Applications on Distributed Systems," Report IR-202, Dept of Mathematics and Computer Science, Vrije Universiteit, Oct. 1989 (submitted for publication). .IP \fB164\fR Bal, H.E., Tanenbaum, A.S., Kaashoek, M.F.: "Orca: A Language for Distributed Programming," Report IR-140, Dept of Mathematics and Computer Science, Vrije Universiteit, Dec. 1987 (submitted for publication). .IP \fB172\fR Bal, H.E., Kaashoek, M.F., and Tanenbaum A.S.: "A Distributed Implementation of the Shared Data-object Model," .I "Proc. First USENIX/SERC Workshop on Experiences with Building Distributed and Multiprocessor Systems" , IEEE, pp. 1-19, Oct. .IP \fB190\fR Bal, H.E., Kaashoek, M.F., and Tanenbaum, A.S.: "Experience with Distributed Programming in Orca," .I "Proc. Int'l Conf. on Comp. Languages '90" , IEEE, 1990. .Hd APPLICATIONS .IP \fB215\fR Baalbergen, E.H., Verstoep, K., and Tanenbaum, A.S.: "On the Design of the Amoeba Configuration Manager," .I "ACM SIGSOFT Software Engineering Notes" , vol. 17, Nov. 1989 (\fIProc. 2nd Int'l Workshop on Software Configuration Management\fR) ACM, 1989. .IP \fB223\fR Baalbergen, E.H.: "Parallel and Distributed Compilations in Loosely-Coupled Systems: A Case Study," .I "Proc. Workshop on Large Grain Parallelism" , 1986. .IP \fB227\fR Baalbergen, E.H.: "Design and Implementation of Parallel Make," .I " Computing Systems" vol. 1, pp. 135-158, Spring 1988. .IP \fB242\fR Bal, H.E., Renesse, R. van, and Tanenbaum, A.S.: "Implementing Distributed Algorithms using Remote Procedure Call," .I "Proc. National Computer Conference" , AFIPS, pp. 499-505, 1987.\fR .Hd THEORY .IP \fB249\fR Mullender, S.J. and Vit\o'\'a'nyi, P.M.B.: "Distributed Match-Making", Algorithmica, vol. 3, pp. 367\-391, 1988 .IP \fB273\fR Renesse, R. van, and Tanenbaum, A.S.: "Voting with Ghosts," .I "Proc. Eighth International Conf. on Distr. Computer Systems" , IEEE, pp. 456-461, 1988. .bp 0 .ce 1 .B .nr PS 24 .nr VS 26 .LP THE AMOEBA DISTRIBUTED OPERATING SYSTEM
nall@sun8.scri.fsu.edu (John Nall) (03/22/90)
In article <14589@nigel.udel.EDU> Peter_Van_Epp@cc.sfu.ca writes: >It seems to me that the answer to people how don't like the network upgrade >with the associated problems is quite simple: wait until the bugs are worked > [deleted material] >make them only availible for a fee from PH. You can also join the MINIX beta >test group and work towards making the upgrades error free! Now wait a minute! I started this thread in the first place, with my "useless busywork" message, so a comment seems in order. As it happens, I've upgraded through the Net since Minix 1.1, and AM a member (a charter member, as a matter of fact) of the minix beta-test club. So smile when you call me all that! :-} And I STILL maintain that it is pitiful to see a note that says, in effect, "I have Minix 1.2 and want to go to 1.5" or something similar. I would venture that for every 10 that start down that road, eight drop off somewhere along the way. And they're probably eight people that we would like to keep aboard. It is BECAUSE I've been down that road that I know how rocky it is....and most of it is not a meaningful learning process (if it were, then I would be all in favor). 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 problem with P-H getting a profit from the upgrade - that should not be any problem so long as the upgrade is through an approved source. A mere matter of putting serial numbers of Minix boot disks should take care of who is genuine and who is not... -- John W. Nall | Supercomputation Computations Research Institute (nall@nu.cs.fsu.edu - Internet) | Florida State University #include <clever.h> | Tallahassee, FL 32306
cagney@chook.ua.oz (Andrew Cagney - aka Noid,285,5585,3362395) (03/22/90)
From article <589@fsu.scri.fsu.edu>, by nall@sun8.scri.fsu.edu (John Nall): > And I STILL maintain that it is pitiful to see a note that says, in > effect, "I have Minix 1.2 and want to go to 1.5" or something similar. I'd say there are two problems 1. People wanting to do an upgrade from a stable to a new sable platform (eg 1.2 -> 1.3) and 2. Those trying to catch up to the leading edge (1.3 -> 1.5.5) The first problem can be solved either by 1. Buy the PH upgrade kit (money) or 2. fetch an upgrade kit from an ftp site (time). It's the second case that is the headache. Ast has made the upgrade process heaps easier than last time, but it does still need a little more work. I don't expect it to ever be perfect :-(. The thing that is missing is an easier path (ie direct upgrade kit) to the version currently being tested. If some one falls behind/misses a posting then they could fetch the relevent part, apply its patches to the official starting point and be up to date. I'm working on making such a kit available for ftp. Sorry this won't help people that don't have ftp access. Andrew Cagney
pcolsen@super.ORG (Peter C Olsen) (03/23/90)
I am one of the people who dropped out of the upgrade process along
the way.
I purchased Milast year to experiment at home when my employer shifted
to Unix. While Minix 1.2 works fine from floppies, it will not
recognize my hard disk. Without a hard disk, I soon reached the limit
of what I could do. While I have a substantial amount of work I'd
{\em like} to do under Minix, I can't do it on floppies, and I have no
confidence that --- if I am able to complete an upgrade --- I will be
able to use my hard disk with the upgraded version. I am an
applications programmer --- doing engineering and mathematical
modeling --- not a Systems Wizard. I have posted requests for help to
the net before, but my only responses have been from other disgruntled
drop-outs. I {\em can} work productively under DOS, and so I continue
to do so. I follow this group only out of habit and in the (slim)
hope that a fix will flash by.
Eventually, I'll replace my XT clone with a -386 box, and I'll
probably try again. Until then, I have about $80 worth of useless
software and a high level of ``upgrade frustration.''
+-------------------------------+--------------------------------------------+
| Peter Olsen | ``Engineering is the art of using |
| pcolsen@super.super.org | mathematics and the physical sciences |
| uunet!super!pcolsen | to improve the quality of life.'' |
+-------------------------------+--------------------------------------------+
paula@bcsaic.UUCP (Paul Allen) (03/24/90)
In article <853@ruunsa.fys.ruu.nl> nmutsaer@ruunsa.fys.ruu.nl (Peter Mutsaers) writes: >In article <3450@hp-sdd.hp.com> charles@hp-sdd.hp.com (Charles Keith) writes: > [... about how hard upgrading is ...] > >Yes I agree, I was very enthousiastic with minix on my ST in the beginning >(especially the ST, which has patches on the patches on the updates >for the PC is awful) but I have been driven away from minix, I would have to >spend hours a day just to keep up to date! I'll wait until another >solution comes available. I don't think it's that bad. I spend some time each day keeping up with the newsgroup. (And that time goes up if I feel a need to stick my oar into the conversation. :-) ) The 1.3 to 1.5.5 upgrade has been fairly smooth, and I got here via 1.5.0, 1.5.2, 1.5.3, and 1.5.4! I tend to do upgrades in big marathon sessions on weekends, and there aren't that many upgrades over the course of a year. In between upgrades, I can choose which patches to apply. Unless there's some specific problem I want to solve, I generally don't take the time to apply any patches. So, while I'm sorry to hear some people are discouraged, my enthusiasm is as high as ever! Paul Allen -- ------------------------------------------------------------------------ Paul L. Allen | pallen@atc.boeing.com Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen
overby@plains.UUCP (Glen Overby) (03/24/90)
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 >problem with P-H getting a profit from the upgrade - that should not be >any problem so long as the upgrade is through an approved source. A >mere matter of putting serial numbers of Minix boot disks should take >care of who is genuine and who is not... Since P-H holds the strings (Copyright) on Minix, I doubt anyone will want to summon their lawyers by selling a full copy of a newer version of Minix than what P-H themselves are selling. The truth of this will only be told when someone asks, and how are you going to explain to their lawyers where you got a newer release of Minix than they have? That'll take some explaining on Andy's part, and I doubt the answer will be looked highly upon, nor may the results be that desirable (i.e. we probably won't get free upgrades over the net anymore!). OK, maybe this is jumping to quick conclusions, but keep it in mind -- you're dealing with business types and (worse) lawyers. It takes a while to move things thru big companies, which is apparently why releasing new versions takes so long. Other than the delay, what is the objection of waiting for P-H? The money involved isn't (relatively) that much; I can name a lot of products which want as much as P-H was selling the upgrade kit (sources only) for. I think upgrades of most Unix systems are more than the purchase cost of Minix. Updating from the net is a "sink or swim" technique (sounds a lot like going to college). Either you figure it out (pay in your time) or wait and buy it after it's released (pay in iddle time and money). And if you sink, the rest of the stuff on the net won't help you much, either, since it's the same kind of cdiffs. And it's not as well organied! OK, so let's work on improving what we have. What are the problems with the upgrades? Why is it difficult? Andy posts uuencoded, compressed shars of context diffs for each directory. The prospective upgrader has to learn : (1) how to get the upgrade (if you're not on the internet, you'll find dealing with listserv to be an, uh, enlightening experience). (2) how to get the file to wherever you're going to work on it (like downloading it to Minix) (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. What problems remain? (1) new files (2) eliminated files (3) moved files a solution to this would be to have "release notes" which detail exactly what to mv or rm. 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?). Some people (of which I am one of) have shell scripts wich can execute a full upgrade rather painlessly (and mindlessly). But everybody likes doing things "their own way" wich makes a universal solution impractical. After the dust settles, some kind person collects everything and puts together a nice net-package (Vincent Broman did this for 1.1-1.2 and 1.2-1.3, and Andrew Cagney is working on it for 1.3-1.5.5). So what are some possible solutions? (1) Distribute all the sources (and new boot disks) This will require dealing with Prentice-Hall. This is left as an exercise for the entreprenure :-) (2) Distribute a cleaned-up diff set has been done (maybe not extremely clean, but "better") (3) Redistribute what Andy posts we've been doing this all along 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. -- Glen Overby <overby@plains.nodak.edu> uunet!plains!overby (UUCP) overby@plains (Bitnet)
nall@sun8.scri.fsu.edu (John Nall) (03/24/90)
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 <overby@plains.nodak.edu> > uunet!plains!overby (UUCP) overby@plains (Bitnet) -- John W. Nall | Supercomputation Computations Research Institute nall@nu.cs.fsu.edu | Florida State University #include <clever.h> | Tallahassee, FL 32306
SHARKEY@osu-20.ircc.ohio-state.edu (Scott A. Sharkey) (03/25/90)
Well, I must make one comment about those who choose to wait for Prentice Hall. Their "1.3 Upgrade Kit" was WORSE than any of the kits I got off the net. No instructions on how to go about installing the upgrade, and several missing header files. If I had not had access to this newsgroup, the 1.3 upgrade kit would have been USELESS! There is no real excuse for the long ( >6 months) delay between when Andy posts to the net and P-H (maybe) decides to offer a new version. Perhaps someone should propose a "service arrangement" with P-H, where a small company takes over handling of MINIX upgrades and support, and cut's P-H in for a percentage of the business. Andy-- Do you think that P-H would be open to such a discussion? -Scott
ghelmer@dsuvax.uucp (Guy Helmer) (03/25/90)
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 > [...] > > OK, so let's work on improving what we have. What are the problems with the > upgrades? Why is it difficult? > > Andy posts uuencoded, compressed shars of context diffs for each > directory. The prospective upgrader has to learn : > > (1) how to get the upgrade (if you're not on the internet, you'll > find dealing with listserv to be an, uh, enlightening experience). > (2) how to get the file to wherever you're going to work on it > (like downloading it to Minix) > (3) how to decode the file (uudecode | uncompress | unshar) > (4) how to apply the diffs (patch <*.cdiff) Not only this, but upgrading essentially requires (1) a _lot_ of free disk space for old source, patches, and then new source (2) a h*ll of a lot of patience and luck (for pre-1.5 patches) > 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. > -- > Glen Overby <overby@plains.nodak.edu> > uunet!plains!overby (UUCP) overby@plains (Bitnet) I suppose I whine too much, but even though I am a hacker-type, I don't have much time to spend on Minix. Thank goodness I have my VAX now to handle Minix upgrades on! -- Guy Helmer ...!cs.texas.edu!bigtex!uudell!loft386!dsuvax!ghelmer DSU Computing Services ghelmer@dsuvax.uucp, helmer@sdnet.bitnet "... the quickest way to kill any business is to let the government take it over." - Alan Abelson
ast@cs.vu.nl (Andy Tanenbaum) (03/25/90)
In article <12576281204007@osu-20.ircc.ohio-state.edu> SHARKEY@osu-20.ircc.ohio-state.edu (Scott A. Sharkey) writes: >Well, I must make one comment about those who choose to wait for Prentice >Hall. Their "1.3 Upgrade Kit" was WORSE than any of the kits I got off >the net. No instructions on how to go about installing the upgrade, and I guess I agree. 1.5 will come with 200+ pages of documentation including very detailed installation instructions closely keyed to the diskettes. >There is no real excuse for >the long ( >6 months) delay between when Andy posts to the net and P-H (maybe) >decides to offer a new version. It takes months to arrange the manufacturing. On the net, we only deal with the intellectual content. P-H has to find companies that can make plastic boxes to measure. I could solve the "delay" problem by not posting anything until the week before P-H has the boxes in stock. Software companies also have long delays between test versions and the final product. The difference here is that I am prepared to air all my dirty laundry in public. Andy Tanenbaum (ast@cs.vu.nl)
bill@chinet.chi.il.us (Bill Mitchell) (03/26/90)
I (thankfully) missed out on the 1.4.x upgrades. Like many others,
I've done 1.3->1.5.0->1.5.3->1.5.5 working nights and weekends. I've
cursed and sweated through it all, probably making more silly
mistakes than most, and having trouble recovering from each silly
mistake because of my inadequate checkpointing during the upgrade
process.
I don't know how Andy manages to produce all these improvements
working nights and weekends, even with help from the band of prolific
implementors whose names keep showing up on the net. I barely have
time to keep up with the postings and try to get the current crop of
upgrades installed before the next crop obsoletes them. I've easily
spent more than 20 hours on each upgrade - I'd guess I've spent quite
a bit more.
How many active members does this newsgroup have? I've seen a figure
of 16,000. I've seen a figure of 10,000. Let's say it's really
5,000. Of this, how many are following upgrades? let's say 1 in 5,
or 1,000. Let's say I'm abnormally slow and everyone else completes
upgrades 10 hours.
10 hours * 3 upgrades * 1000 persons = 30,000 manhours
(person-hours for gender-sensitive fellow Americans)
Figuring 40 hours per week and 50 weeks per year, a manyear is 2,000
hours. 30,000/2,000 = 15 manyears spent doing minix upgrades. Can
this be right? Could this time have been spent more productively?
Could P-H be persuaded to allow limited distribution on disk of fully
upgraded interim minix releases to owners of a prior version?
Considering the time I've spent doing my own, I'd happily pay for
each such upgrade and still buy the next major release and
cross-referenced source listing from P-H.
Let's say such a packaged upgrade is worth $20 or so to half of the
1000 upgraders (would be worth at least that much to me). That's
$10,000. This shouldn't be enough to panic P-H, but should be enough
to get something done.
Could someone package upgrade kits for designated upgrade providers
on each continent? Could these upgrade providers copy and distribute
the upgrades? $5 to cover disk and distribution costs, $5 retained
by the upgrade provider to cover the hassle of copying and mailing,
$5 sent by the upgrade provider to whoever puts together and tests
the upgrade package before distribution, and $5 to cover incidentals.
(maybe $5 sent to PH? maybe an upfront fee to PH for a license
allowing these upgrades?).
Does this make sense? Can something like this be made to work?
Anybody got a better idea about how we can save all those manyears
we've been spending duplicating each others efforts upgrading
manually and complaining to one another about all the upgrade
problems?
cjeffery@cs.arizona.edu (Clinton Jeffery) (03/26/90)
From an article by bill@chinet.chi.il.us (Bill Mitchell): > 10 hours * 3 upgrades * 1000 persons = 30,000 manhours > (person-hours for gender-sensitive fellow Americans) > Anybody got a better idea about how we can save all those manyears > we've been spending duplicating each others efforts upgrading > manually and complaining to one another about all the upgrade problems? Speaking as one who gave up on Minix due to its distribution mechanism quite awhile ago, but still reads comp.os.minix out of morbid curiosity, I have Yet Another Silly Suggestion (YASS): "Clearly", Minix should be a subscription product, not a one-time-sale product. Bill is right that P-H could not only justify their ridiculous prices but also RAKE IN EVEN MORE by selling Minix in units of, say, 3 releases. -- | Clint Jeffery, U. of Arizona Dept. of Computer Science | cjeffery@cs.arizona.edu -or- {noao allegra}!arizona!cjeffery --
nall@sun8.scri.fsu.edu (John Nall) (03/26/90)
In article <6120@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >boxes to measure. I could solve the "delay" problem by not posting >anything until the week before P-H has the boxes in stock. Software >companies also have long delays between test versions and the final product. >The difference here is that I am prepared to air all my dirty laundry in >public. > >Andy Tanenbaum (ast@cs.vu.nl) Please don't not post until P-H has the boxes in stock! In spite of negative comments regarding the upgrade process (some of which have come from me), it is far, far better than waiting for the official release! And it really is not that bad, once it has been done once. The ones that I worry about are the huddled masses, longing to be free from 1.1, that try the upgrade path. So I think the moral of this whole Re: The Upgrade Process thread is as follows: (a) If you are not at least up to 1.3, then don't try it. Just buy 1.3 from P-H. (b) If you are at 1.3 or higher, then get the upgrade files from one of the archives. (c) someone should come up with a "helpful hints" which allow first-time upgraders to fix the most common problems (libc.a out of order, chmem's needed, etc) By the way, I noted a negative comment on the net the other day about how the P-H charge is high. Don't remember who made it, and it doesn't matter anyway. But check the prices on *every other* brand of Unix! With the exception of Gnu, they're all higher. And not near so good. Minix 1.5, on my 8-megabyte 386 with an 80-meg hard disk, does everything that I want. -- John W. Nall | Supercomputation Computations Research Institute nall@nu.cs.fsu.edu | Florida State University #include <clever.h> | Tallahassee, FL 32306
gert@targon.UUCP (Gert Kanis) (03/27/90)
In article <12576281204007@osu-20.ircc.ohio-state.edu> SHARKEY@osu-20.ircc.ohio-state.edu (Scott A. Sharkey) writes: > >There is no real excuse for >the long ( >6 months) delay between when Andy posts to the net and P-H (maybe) >decides to offer a new version. In article <6120@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > >I could solve the "delay" problem by not posting >anything until the week before P-H has the boxes in stock. > >Andy Tanenbaum (ast@cs.vu.nl) I don't think you can, well at least not with the same result or am I wrong? Posting new releases to the net has proved to help a lot in getting bugs out. Even if you double check everything there would be smaller or bigger glitches that only show up when {you have a such size of disk partion| use protected mode|must do everthing under minix :-) |have a brand x controller |you compile on [ST|Amiga|Mac|etc] }. You will get the idea... So those who upgrade from the net suffer more to make sure the P-H release will be a stable one. (but comes much later :-) Gert Kanis +-----------------------------------------------------------------+ | Everything I said | Gert Kanis, ASW CB SWP | | is my own opinion. | Nixdorf Computer BV, Postbus 29 | |----------------------| 4130 EA Vianen, Netherlands. | | I do not represent | E-mail : ... nluug.nl!targon!gert | | anyone elses opinion.| or {..uunet!mcsun!}hp4nl!targon!gert | +-----------------------------------------------------------------+
bob@lion.inmos.co.uk (Bob Green) (03/29/90)
In article <1108@targon.UUCP> gert@targon.UUCP (Gert Kanis) writes: > >So those who upgrade from the net suffer more to make sure the P-H release >will be a stable one. (but comes much later :-) > >Gert Kanis This is oviously some strange usage of the word "suffer" that I havn't come across before: suffer (verb): to obtain free updates to software, along with very good technical support. To obtain all of this long before many other people, who, when they do eventually get it are expected to pay. Oh well, I do so like to expand my vocabulary. Seriously though, I do wonder why people like Andy, Bruce, Frans et al bother when I see some of the postings in this newsgroup. Upgrading from the net is not mandatory. Nobody's forcing you to improve the performance of your OS. Incidentally, if you think some of the minix upgrades are painful, try upgrading some of the commercially available OS (RSX-11 is one that springs to mind). Then you MIGHT have something to complain about. A message to all of the people out there who have been moaning about the upgrade process: STOP IT ! Share and enjoy Bob. P.S. I realise there is a difference between complaining and constructive criticism, can anyone tell me what it is ;-) | Bob Green Inmos Ltd, Bristol | EMail(UK) ukc!inmos!bob |---------------------------------------| or bob@inmos.co.uk |The opinions above are my personal | Internet: bob@inmos.com |views and do not reflect Inmos policy. | UUCP:(US) uunet!inmos.com!bob
ken@minster.york.ac.uk (03/29/90)
There seems to be a lot of traffic about "PH own the Copyright, and they are Legal/Business Types", or "Why can't someone decent sell proper upgrades?". It seems to me that this state of affairs is slowing converging towards the "AT&T won't let people have the sources to Unix cheaply anymore because they are Legal/Business types".. just the sort of thing Minix was written to avoid. Also, how can PH have copyright over all the sources when a lot of them have been written by netlanders all over the world? -Ken
jaap+@andrew.cmu.edu (Jaap Akkerhuis) (03/30/90)
Excerpts from netnews.comp.os.minix: 29-Mar-90 Re: The Upgrade Process ken@minster.york.ac.uk (518) > Also, how can PH have copyright over all the sources when a lot of them > have been written by netlanders all over the world? PH can claim the copyrights over the compilation (not the compilation you do with ACK, but as in ``something compiled; esp: a book composed of materials gathered from other books or documents''). That is also the way how a publisher can claim copyright over Shakespear's Plays. Although he (the bard) is dead long enough not to be able to claim copyrights himself, the publisher can. jaap
dobson@usuhsb.ucc.usuhs.nnmc.navy.mil (BCP LT MICHAEL DOBSON) (05/05/90)
I started with Minix 1.1 way back when and have upgraded solely from the net. This upgrade (1.3->1.5.9) has been the smoothest yet! Thanks to AST and all the beta folks for removing much of the pain. I think I now have a complete crc matching source tree and have made two working 1.5.9 systems, ome for an XT with RLL hd and one for an AT with MFM hd. I had trouble with only 6 or so files solely due to not having a 1.3 crc match to begin with. A friendly local Minixer and I swapped files we needed to get in sync with AST so that wasn't much trouble either. I will admit to doing all the patching on a "big" Unix machine, an AT$T 3B2/600G running Sys V R 3.2. The only tools I needed were L Wall's patch and compress 4.0which I obtained from comp.sources.unix. I also compiled the mew uud and uuefor use on the 3B2. TO get the original Minix 1.3 files to the Unix box I created compressed tar files for each direcrtory, used doswrite to put them on my DOS partition then ftp'd them to the Unix machine. I reversed the process to get tehm back to Minix. I was pleasntly surprised to find that Minix tar could read Sys V tar files! One other trick I used, I delayed building a working Minix system until 1,5.6, that way I avoided many of the early troubles. You can easily go from 1.3->1.5.9 in one step. Again thanks to AST and the beta folks, this has been the easiest upgrade I have ever done, on all types of systems!! Mike Dobson Internet: rdc30med@nmrdc1.nmrdc.nnmc.navy.mil\Bitent: Bitnet: dobson@usuhsb.bitnet