ast@cs.vu.nl (Andy Tanenbaum) (05/07/91)
This discussion was started in beta-minix, but actually it is not related to 1.6.15 specifically, so I think it is better to move it to the main group. The question arose of where prototypes for things like std_err should go. I suggested creating a new header file, <minix/minlib.h> for the prototypes of these little MINIX-specific library routines. Bruce pointed out that putting #include <minix/minlib.h> in utility programs makes those programs nonconforming (to POSIX). This is arguable. POSIX merely defines the functionality, and does not say how the program should work. On the other hand, it is true that such a program will not be portable to a random UNIX system. However, the real problem there is the use of std_err itself, not the include for its prototype. Things like std_err and printk etc were devised to fight bloat. Using the new ANSI compiler and libraries, some programs have increased 6-fold in size due to the ANSI requirements. My solution is to avoid stdio where it is not really needed, and use things like std_err. I don't want all the binaries exploding in size because that will greatly increase the number of disks in the distribution, hence the price. Andy Tanenbaum (ast@cs.vu.nl)
klamer@mi.eltn.utwente.nl (Klamer Schutte) (05/10/91)
In <9864@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: Discussion about how to hack in some non-standard items to conforming programs. >Things like std_err and printk etc were devised to fight bloat. Using the >new ANSI compiler and libraries, some programs have increased 6-fold in >size due to the ANSI requirements. My solution is to avoid stdio where >it is not really needed, and use things like std_err. I don't want all >the binaries exploding in size because that will greatly increase the >number of disks in the distribution, hence the price. How about shared libraries? This will cut back the size of all executables. Machines without a MMU and/or a limited address space could load the requiered routines at run time as static copies. This wont save ram when running but does save disk space (which is also a valuable resource!) Klamer -- Klamer Schutte Faculty of electrical engineering -- University of Twente, The Netherlands klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamer
ast@cs.vu.nl (Andy Tanenbaum) (05/11/91)
In article <klamer.673867917@mi.eltn.utwente.nl> klamer@mi.eltn.utwente.nl (Klamer Schutte) writes: >How about shared libraries? This will cut back the size of all executables. Maybe yes, maybe no. I don't care about how big the programs are when they are in memory. What I care about is how big they are on the distribution disks. If I have to include the library in every a.out, but the system detects the existence of the shared library when the second program is executed and links to it, there is no gain. If programs do not include the library at all in their a.out's, and somehow magically find the library when they are executed, then I suspect this will require linking to the entire library, not just the routines that the individual program needs. Having the entire library in memory (even 1 copy) on a 512K original XT is likely to be a real hog. And then there is the complexity of the whole thing :-( Andy Tanenbaum (ast@cs.vu.nl)
wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu (05/12/91)
Andy Tanenbaum wrote: >Maybe yes, maybe no. I don't care about how big the programs are when they >are in memory. What I care about is how big they are on the distribution >disks. You could consider shipping object files rather then binaries for all executables not needed for the installation of the system. The installation process could then link them as it copies them over to the hard disk. For executables that have multiple object files, linking them together and resolving all references outside the standard library might be useful. I don't know if this would save space or not. It depends on the relative sizes of the symbol table vs. functions pulled in from the libarary. If only external references were left in the symbol table though, I think it would be a win. The advantage over implementing shared libraries is that it doesn't require any OS changes. Bill Bogstad
gillham@andrews.edu (Andrew Gillham) (05/12/91)
In article <9911@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > >Maybe yes, maybe no. I don't care about how big the programs are when they >are in memory. What I care about is how big they are on the distribution >disks. If I have to include the library in every a.out, but the system >detects the existence of the shared library when the second program is >executed and links to it, there is no gain. If programs do not include >the library at all in their a.out's, and somehow magically find the library >when they are executed, then I suspect this will require linking to the >entire library, not just the routines that the individual program needs. >Having the entire library in memory (even 1 copy) on a 512K original XT >is likely to be a real hog. And then there is the complexity of the whole >thing :-( > >Andy Tanenbaum (ast@cs.vu.nl) Then why not distribute then in the compressed .s format? How many full executables would be needed to link the remainder? (programs that make the linker choke could be included whole) Enough to mkfs the hard-drive, copy over the libraries and linker, etc could be already linked, and the install program would simply setup the root file system and then install/link binaries and install the source, etc.. Maybe a basic floppy minix system with some additional utilities would be enough to install to the hard drive. A lot of /usr/bin wouldn't be necessary to install minix. Anyway, just some crazy thoughts... (and yes, I'm copyrighting this technique.. ;-) ) -Andrew -- =========================================================================== Andrew Gillham "High Ideals are weighed down by Andrews University the Anchors of Reality" (gillham@andrews.edu) - myself
gillham@andrews.edu (Andrew Gillham) (05/12/91)
In article <53341@nigel.ee.udel.edu> wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu writes: > You could consider shipping object files rather then binaries for >all executables not needed for the installation of the system. The >installation process could then link them as it copies them over to the hard >disk. For executables that have multiple object files, linking them >together and resolving all references outside the standard library might be >useful. I don't know if this would save space or not. It depends on the >relative sizes of the symbol table vs. functions pulled in from the >libarary. If only external references were left in the symbol table though, >I think it would be a win. The advantage over implementing shared libraries >is that it doesn't require any OS changes. > > Bill Bogstad I posted my message before I read this one, honest! I wonder how much space this would save? -Andrew -- =========================================================================== Andrew Gillham "High Ideals are weighed down by Andrews University the Anchors of Reality" (gillham@andrews.edu) - myself
evans@syd.dit.CSIRO.AU (Bruce.Evans) (05/12/91)
In article <9911@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >executed and links to it, there is no gain. If programs do not include >the library at all in their a.out's, and somehow magically find the library >when they are executed, then I suspect this will require linking to the >entire library, not just the routines that the individual program needs. >Having the entire library in memory (even 1 copy) on a 512K original XT >is likely to be a real hog. And then there is the complexity of the whole >thing :-( It would be sufficient to put only stdio and everything it references in the shared library. Anyway my current libc.a is only 47K text for the 386 version compiled by gcc. The data space should be close to 0 once the library is made sharable (few globals). Complexity is the main problem. -- Bruce Evans evans@syd.dit.csiro.au
evans@syd.dit.CSIRO.AU (Bruce.Evans) (05/12/91)
In article <53341@nigel.ee.udel.edu> wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu writes: > You could consider shipping object files rather then binaries for >all executables not needed for the installation of the system. The Why ship object files for which the source is available? It's just as (in)convenient to build the binaries from sources as from objects. Are the binaries really that large? My /bin is now 2.6 MB, with almost every file having full-featured (large) stdio and a symbol table. I remember when it was only 1 MB. However, the extra 1.6 MB is not large compared with the rest of the system, and small compared with my collection of binaries not in the distribution (9 MB). -- Bruce Evans evans@syd.dit.csiro.au
mitchell@MDI.COM (Bill Mitchell) (05/12/91)
In article <9911@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > > I don't care about how big the programs are when they >are in memory. What I care about is how big they are on the distribution >disks. I've seen Andy express concern over the number of disks running the cost of the distribution up several times. As I recall, some useful utilities were omitted from the distribution at some point to save a disk or two. I've also seen concern about increasing the complexity of the system, and shared libraries would add complexity. How about making the distribution format a bit more flexible, offering a stripped-down distribution with minimum disks at minimum cost and offering add-ons separately. If PH doesn't want to deal with the add-ons, perhaps they could distribute just the stripped-down (PH Copyright?) material, and other distribution channels could be developed for the rest. NLMUG might cover holland and maybe other european countries. Wasn't there a similar organization in the UK which was distributing minix materials? Austin Code Works and various Shareware distributers here in the US would probably be interested in this. I think PH probably has too much inertia to handle the OS add-ons and contributed/ported applications effectively anyway. Someone other than Andy (NLMUG?) could administer "the rest" and perhaps provide one distribution channel, with other distribution channels getting master distribution kits from whoever administers them and duplicating them for further distribution. The big complication here is version control, keeping upgrades and applications which are sensitive to minix release versions in sync, and keeping universal applications separated from those which require one or more OS upgrades (eg. 386 support). That's work which the administrators and distributers have to do, and which they can be compensated for by charging for the disks. The distribution format might run something like this: Orderable from PH: OS and key utility binaries OS and key utility sources OS and key utility documentation OS and key utility binaries and sources OS and key utility binaries and documentation OS and key utility sources and documentation OS and key utility binaries, sources and documentation Orderable from PH or some other source, with ordering information provided in PH materials: 386 upgrade kit, allowing programs larger than 64+64 smart scheduler kit multi-threaded FS kit (if one appears and gains acceptance) Hard disk boot utilities (shoelace, etc.) expanded utilites selections kermit, indent, basic, pascal, forth, lisp, pcomm, crisp, elvis, eliza, wmail, smail, uucp, rn, and whatever else gains general acceptance Maybe I'm dreaming, but this seems to me a workable scheme which allows an uncomplicated minix system distributed by PH on a minimum number of disks and easily controlled by Andy and PH; plus a channel for distributing upgrades and add-ons which is not constrained by desires to keep internals simple or to minimize the number of disks and which has a chance to be more effective than the present near-anarchy. Am I dreaming, or could this work? -- mitchell@mdi.com (Bill Mitchell)
ast@cs.vu.nl (Andy Tanenbaum) (05/12/91)
In article <53341@nigel.ee.udel.edu> wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu writes: > > You could consider shipping object files rather then binaries Won't fly. You have no idea how inexpert a lot of the users are. If people have to get the whole thing installed and be able to run the compiler before using it, a substantial fraction will never manage it. The questions PH and I get all the time would amaze you. A lot of people simply do not understand things like the fact that MS-DOS is not part of the PC hardware. They think MINIX is an MS-DOS program (sort of the way it works on the Macintosh). Requiring these folks to configure everything and then run the compiler is asking too much. It has to work out of the box. There have been enough problems even getting that much to happen. Andy Tanenbaum (ast@cs.vu.nl)
ast@cs.vu.nl (Andy Tanenbaum) (05/12/91)
In article <673996083wkn20941@edmund.cs.andrews.edu> gillham@edmund.cs.andrews.edu.UUCP (Andrew Gillham) writes: >Then why not distribute then in the compressed .s format? See my earlier message. Same problem. Andy Tanenbaum (ast@cs.vu.nl)
jms@cs.vu.nl (Jan-Mark) (05/12/91)
In article <1991May12.001703.11152@syd.dit.CSIRO.AU>, evans@syd.dit.CSIRO.AU (Bruce.Evans) writes: > > It would be sufficient to put only stdio and everything it references in > the shared library. Anyway my current libc.a is only 47K text for the 386 > version compiled by gcc. The data space should be close to 0 once the > library is made sharable (few globals). > > Complexity is the main problem. > -- > Bruce Evans evans@syd.dit.csiro.au I do agree that some functions should be in a shared library, and some should not, but where IS the complexity, mentioned? (Kernel patches?) IMHO globals like ``errno'' and the environment pointer should create big problems. The compiler will have to do magic there. (Like putting them in a known place.) The kernel should only need a new system call. (eg. ``slibcall (int num);'') The kernel could send a message to a SLIB task, that will change the CS,SP and IP. (or 386, 68k, sparc equivalents.) The process can than be put back in the process queue (The function arguments will still be on the stack from the function call.) Upon return from the call, the CS,SP and IP are changed again. Are there any pitfalls here I've missed? Jan-Mark. -- (:> jms (_) ========""======
adamd@rhi.hi.is (Adam David) (05/13/91)
In <9911@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <klamer.673867917@mi.eltn.utwente.nl> klamer@mi.eltn.utwente.nl (Klamer Schutte) writes: >>How about shared libraries? This will cut back the size of all executables. >Maybe yes, maybe no. I don't care about how big the programs are when they >are in memory. What I care about is how big they are on the distribution >disks. I care about program size on working disk(s) and in execution memory. Slight savings in distribution sizes can be had by compressing most of the executables on all but one of the minix disks, requiring them to be decompressed in order to make working copies. Some people may seriously disagree with the merits of this approach. The two greatest savings in code size are from using compression and shared code (libraries). Compressed executables: There are several possibilities, in the context of minix I believe the most convenient way of achieving this is by letting the FS unpack compressed executables on the way from disk to memory. There are savings in storage space and in load time from magnetic media. Files can be unpacked with very little overhead, it is compressing files that can take a relatively long time. To implement the loading of compressed executables it is necessary to identify such files for special treatment by the FS and build an unpack feature into the FS. This is certainly a better solution than self-unpacking executables, both in terms of compression ratio and purity. Shared libraries: This can be acheived by implementing a library call table in the kernel and/or MM. Each library call has a number associated with it which indexes into the table. Each table entry has two parts, a link count and a vector to the actual code. Library routines can then be linked in when needed and removed when all processes have unlinked from any particular routine. This requires a system call to handle all library calls. Programs can either declare in advance what library routines are needed (needs a linker-loader and routines are unlinked at termination time), or the routines can be linked in during the library call and linked out on exit from the library call (and if termination occurs during a library call). Library routines with a link count of zero can continue to reside in memory until the memory is required for other puposes, at which time the vector address can be zeroed to signify that the routine is no longer present. I don't know enough about the minix system to decide where to actually load the library routines, they could in principle use any available memory slots. Any program linked with libc.a will of course continue to function normally, it will just take more space than necessary. As for how practical or desireable any of this would be for minix I will wait and see what other people think before commenting further. -- Adam David. (adamd@rhi.hi.is)
ast@cs.vu.nl (Andy Tanenbaum) (05/14/91)
In article <1991May12.143246.18877@MDI.COM> mitchell@MDI.COM (Bill Mitchell) writes: >If PH doesn't want to deal with the add-ons, perhaps they could distribute >just the stripped-down (PH Copyright?) material, and other distribution >channels could be developed for the rest. I'm not against that. I would be quite happy to have 2.0 be the current 1.6.16 plus POSIXizing as I get that done, plus maybe a few more utilities. I would be quite happy to see some other organization, such as the MINIX Centre in the U.K. make up a supplementary package with extra programs. This could be available by FTP from archives, be sold on diskette to people or something else that was suitable to all parties. More complicated are changes to the kernel, FS, and MM. I am not wild about mucking them up, as I believe I have pointed up before :-) . What might be acceptable is to have the supplementary package consist of diff listings against the then-current PH version. As long as this is not too big, it is workable. What is not ok is to have the supplementary package contain the kernel, FS, MM, or other copyrighted code, neither in source or in binary form. Thus the supplementary package has to remain a supplement, and not become an alternative to the PH version. PH's lawyers won't accept that. Saying that you wil only distribute to people who have a PH version has a low credibility. For this reason, NLMUG is perhaps not the ideal organization, since they are currently in "discussion" with PH's lawyers about various subjects of mutual interest. The lawyers want their copyright to be respected. That really isn't negotiable. If the MINIX Centre or some other organization wants to work on such a supplementary package, I think something could be worked out. Andy Tanenbaum (ast@cs.vu.nl)
dprrhb@inetg1.ARCO.COM (Reginald H. Beardsley) (05/14/91)
Rainer Orth's comments got me to thinking about this again: As a way to have your cake and eat it too, how about the following: The base distribution from PH pretty much as is. With upgrade kits in compressed tar format for a selected set of enchancements, (eg. 386, shared text, etc.) This would provide stuff for people with skill but no ftp access and at the same time not add too many disks. If the patches were done in the form of answers to a problem set we might even be able to make things like swapping palatable to Andy. I agree whole heartedly with Andy's wish to keep Minix small and simple. For people just getting started kernel hacking this is very important. At the same time if the really advanced folks would package their modifications as answers to an intermediate to advanced level problem set, "How would you add ???? to Minix?", then all who wanted would get the benefit of the enchancements and Andy would get an additional teaching tool. -- Reginald H. Beardsley ARCO Information Services Plano, TX 75075 Phone: (214)-754-6785 Internet: dprrhb@arco.com
hp@vmars.tuwien.ac.at (Peter Holzer) (05/15/91)
ast@cs.vu.nl (Andy Tanenbaum) writes: >Won't fly. You have no idea how inexpert a lot of the users are. Oh, yes, I have :-( [...] >Requiring these folks to configure everything and >then run the compiler is asking too much. It has to work out of the box. Compared to all the difficulties users have to go through to install minix now (find the right boot disk, repartition hard disk, etc.) the additional step of `cd /usr/src; make all' seems rather trivial. Besides, this step can be included into the script that copies everything from floppies to hard disks. If you want to keep disk space to a minimum, distributing the majority of the programs only as source code and building the binaries at installation time is IMHO the best idea. The tricky part is to decide which utilities you need to install the system. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |
mitchell@MDI.COM (Bill Mitchell) (05/15/91)
In article <1991May14.170021.13559@email.tuwien.ac.at> hp@vmars.tuwien.ac.at (Peter Holzer) writes: > >[...] > >Compared to all the difficulties users have to go through to install >minix now (find the right boot disk, repartition hard disk, etc.) the >additional step of `cd /usr/src; make all' seems rather trivial. >Besides, this step can be included into the script that copies >everything from floppies to hard disks. > Isn't Minix supposed to be usable out of the box on a floppy-only system? Small, simple, usable by a student on a tight budget. Or perhaps I should phrase that question "Is Minix supposed to be usable out of the box on a floppy-only based system?" Prices have come down and performance gone up over the years, and the budget which bought a floppy-only system a few years back would probably get a hard disk today. Do CS students today commonly have a personal PC with a hard disk? If so, is it reasonable to drop the floppy-only requirement and _require_ a hard disk? -- mitchell@mdi.com (Bill Mitchell)
hbetel@watserv1.waterloo.edu (Heather Betel) (05/19/91)
In article <9950@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >What is not ok is to have the supplementary package contain the kernel, FS, >MM, or other copyrighted code, neither in source or in binary form. Thus >the supplementary package has to remain a supplement, and not become an >alternative to the PH version. PH's lawyers won't accept that. Saying that >you wil only distribute to people who have a PH version has a low credibility. >For this reason, NLMUG is perhaps not the ideal organization, since they are >currently in "discussion" with PH's lawyers about various subjects of mutual >interest. The lawyers want their copyright to be respected. That really >isn't negotiable. > The following is a suggestion that might make the distribution of suplementary packages simpler. I would do it myself, but since my hard drive is riddled with bad sectors, and I can't afford a better one, (this one was free, and well worth the cost!) I don't have a stable enough system to do much of anything... Suppose at boot, you have the standard stuff, such as the serial drivers, floppy driver, hard-disk driver, and printer driver loaded with the kernel, but not INIT, fs, and mmA. Instead, you have loaded a fairly simple task that knows just enough to load all the files in some directory, say /boot. In there, you could put an implementation of mm, fs, and anything else that you might want. (I guess init would go there too). This has a nice little side effect: You don't need to rebuild your boot disk to test a new device driver. You just need to modify a 'temporary' root disk. Installing and testing new device drivers becomes slightly simpler. This won't solve any problems relating to distribution of PH copyright materials, but it would be very nice for new MMs or FSes. I guess the real difficulty would be in formalising all the hooks between FS and MM, so that you just treat them as design criteria.
waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) (05/20/91)
mitchell@MDI.COM (Bill Mitchell) wrote: > In article <9911@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >> >> I don't care about how big the programs are when they >>are in memory. What I care about is how big they are on the distribution >>disks. > > I've seen Andy express concern over the number of disks running > the cost of the distribution up several times. As I recall, some > useful utilities were omitted from the distribution at some point > to save a disk or two. > > I've also seen concern about increasing the complexity of the system, > and shared libraries would add complexity. Correct, and so it should be. Let us keep Standard MINIX small! > How about making the distribution format a bit more flexible, offering > a stripped-down distribution with minimum disks at minimum cost and > offering add-ons separately. > > If PH doesn't want to deal with the add-ons, perhaps they could distribute > just the stripped-down (PH Copyright?) material, and other distribution > channels could be developed for the rest. NLMUG might cover holland > and maybe other european countries. Wasn't there a similar organization > in the UK which was distributing minix materials? Austin Code Works > and various Shareware distributers here in the US would probably be > interested in this. I think PH probably has too much inertia to handle > the OS add-ons and contributed/ported applications effectively anyway. Forget it. Prentice Hall will not ever allow anyone but PH to sell goodies like these. I know... > Someone other than Andy (NLMUG?) could administer "the rest" and > perhaps provide one distribution channel, with other distribution > channels getting master distribution kits from whoever administers > them and duplicating them for further distribution. The big > complication here is version control, keeping upgrades and applications > which are sensitive to minix release versions in sync, and keeping > universal applications separated from those which require one or > more OS upgrades (eg. 386 support). That's work which the administrators > and distributers have to do, and which they can be compensated for > by charging for the disks. Forget it, Andy won't ever allow _me_ to administer "the MINIX collection". > The distribution format might run something like this: > > Orderable from PH: > > OS and key utility binaries > OS and key utility sources > OS and key utility documentation > OS and key utility binaries and sources > OS and key utility binaries and documentation > OS and key utility sources and documentation > OS and key utility binaries, sources and documentation I tried this (_exactly_ !!!) with Advanced MINIX. You all know what happened... > Orderable from PH or some other source, with ordering information > provided in PH materials: > > 386 upgrade kit, allowing programs larger than 64+64 > smart scheduler kit > multi-threaded FS kit (if one appears and gains acceptance) > Hard disk boot utilities (shoelace, etc.) > expanded utilites selections > kermit, indent, basic, pascal, forth, lisp, pcomm, > crisp, elvis, eliza, wmail, smail, uucp, rn, > and whatever else gains general acceptance Ahh. And who will get the royalties involved? Bruce Evans deserves a fair bit off it. That is one of the problems with creating, main- taining and _selling_ packages like these... > Maybe I'm dreaming, but this seems to me a workable scheme which > allows an uncomplicated minix system distributed by PH on a minimum > number of disks and easily controlled by Andy and PH; plus a > channel for distributing upgrades and add-ons which is not constrained > by desires to keep internals simple or to minimize the number of disks > and which has a chance to be more effective than the present near-anarchy. Correct, but not everyone is accepting this... sigh... Fred. -- MicroWalt Corporation, for MINIX Development waltje@uwalt.nl.mugnet.org Tel (+31) 252 230 205, Hoefbladhof 27, 2215 DV VOORHOUT, The Netherlands "An Operating System is what the _USERS_ think of it- me"
waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) (05/20/91)
ast@cs.vu.nl (Andy Tanenbaum) writes: >Things like std_err and printk etc were devised to fight bloat. Using the >new ANSI compiler and libraries, some programs have increased 6-fold in >size due to the ANSI requirements. My solution is to avoid stdio where >it is not really needed, and use things like std_err. I don't want all >the binaries exploding in size because that will greatly increase the >number of disks in the distribution, hence the price. Do you want decent (conforming) sources or a pile of junk? Maintaining hacks like "prints" and "std-err*" means junk. I, too, noticed the increased demand for disk space when I recompiled everything with the Estdio library. However, it is (a) faster and (b) standard, contrary to the old stuff. That is enough for me... Fred. -- MicroWalt Corporation, for MINIX Development waltje@uwalt.nl.mugnet.org Tel (+31) 252 230 205, Hoefbladhof 27, 2215 DV VOORHOUT, The Netherlands "An Operating System is what the _USERS_ think of it- me"
mitchell@MDI.COM (Bill Mitchell) (05/21/91)
In article <9105201108@uwalt.nl.mugnet.org> waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) writes: >> If PH doesn't want to deal with the add-ons, perhaps they could distribute >> just the stripped-down (PH Copyright?) material, and other distribution >> channels could be developed for the rest. > >Forget it. Prentice Hall will not ever allow anyone but PH to sell >goodies like these. I know... > >> >> 386 upgrade kit, allowing programs larger than 64+64 >> smart scheduler kit >> multi-threaded FS kit (if one appears and gains acceptance) >> Hard disk boot utilities (shoelace, etc.) >> expanded utilites selections >> kermit, indent, basic, pascal, forth, lisp, pcomm, >> crisp, elvis, eliza, wmail, smail, uucp, rn, >> and whatever else gains general acceptance > >Ahh. And who will get the royalties involved? Bruce Evans deserves >a fair bit off it. That is one of the problems with creating, main- >taining and _selling_ packages like these... > No argument that Bruce _deserves_ royalties for bcc, 386 upgrade, etc; and others _deserve_ royalties for their work writing or porting the other stuff. I was under the impression, however, that they had made the fruits of their labors freely available to the minix community (and any others who got their hands on the source) with no requirement for royalty payments. I'm also under the impression that this is the situation with most or all of the application programs distributed by PH with minix; and all of the applications not included in the PH distribution. Actually, the situation is probably messier than that, with some sources being public domain and some containing a copyright notice allowing limited copying and redistribution with some restrictions (eg. non-commercial usage allowed - whatever that means ... ). My impression is that PH has no claim on this material, and is just bundling it in with the material they do have copyright on for redistribution (and are uncomfortable about this, hence the push to regularize & formalize the copyright status of everything). The point here being that, it seems to me anyway, PH has no standing to _allow_ or to _not_allow_ distribution of the material they don't have copyright on. Other distributors have just as much (or as little ) right to distribute copies of these materials as PH does. Of course, PH has an army of hired guns (corporate attorneys) who, regardless of rights and wrongs, can make life inconvenient and expensive for anyone they choose to harrass thru the legal system. This is a common (though scummy) business tactic. I've seen references to the hard time PH is giving NLMUG, but don't know any details. I'd guess the hired guns (attorneys) are just following standard procedure and trying to eliminate their opposition by whatever means they can bring to bear. The PH management who give the attorneys their marching orders may be willing to allow some alternate distribution channel for non-PH-copyright minix related materials operate unhindered, or they may not - I'd guess Andy's support would be critical in gaining a PH acceptance of this. -- mitchell@mdi.com (Bill Mitchell)