In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum) writes: >As an aside, for those folks who don't read news headers, Linus is in Finland >and I am in The Netherlands. Are we reaching a situation where another >critical industry, free software, that had been totally dominated by the U.S. >is being taken over by the foreign competition? Will we soon see >President Bush coming to Europe with Richard Stallman and Rick Rashid >in tow, demanding that Europe import more American free software?
Actually, the U.S. is more likely to have you arrested for selling restricted software to unfriendly powers (not that anyone in the C.I.S. can afford software this winter -- they're probably burning their PCs for heat). I remember that they jailed some poor computer vendor in the U.K. a couple of years ago.
Seriously, you must have run into this problem with crypt and Minix distribution in and out of the U.S.
David
################################################################# David Megginson meg...@epas.utoronto.ca Centre for Medieval Studies da...@doe.utoronto.ca University of Toronto 39 Queen's Park Cr. E.
In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum) writes: >While most people can talk rationally about kernel design and portability, >the issue of free-ness is 100% emotional. You wouldn't believe how much >[expletive deleted] I have gotten lately about MINIX not being free. MINIX >costs $169, but the license allows making two backup copies, so the effective >price can be under $60. Furthermore, professors may make UNLIMITED copies >for their students. Coherent is $99. FSF charges >$100 for the tape its "free" >software comes on if you don't have Internet access, and I have never heard >anyone complain. 4.4 BSD is $800. I don't really believe money is the issue. >Besides, probably most of the people reading this group already have it.
The distribution cost is not the problem. As you've noted, nobody complains about the FSF's distribution fee being too high. The problem, as I see it, is that there is only one legal source for for the software for people that simply want a working release. And from watching the minix group since minix first became available, my impression is that nobody enjoys dealing with PH for a whole host of reasons.
>I think the real issue is something else. I've been repeatedly offered virtual >memory, paging, symbolic links, window systems, and all manner of features. I >have usually declined because I am still trying to keep the system simple >enough for students to understand. You can put all this stuff in your version, >but I won't put it in mine. I think it is this point which irks the people who >say "MINIX is not free," not the $60.
If PH was not granted a monopoly on distribution, it would have been possible for all of the interested minix hackers to organize and set up a group that was dedicated to producing enhanced-minix. This aim of this group could have been to produce a single, supported version of minix with all of the commonly requested enhancements. This would have allowed minix to evolve in much the same way that gcc has evolved over the last few years. Sure there are variant versions of gcc, but most of the really good enhancements, bug fixes, etc are eventually folded back into a master source base that future distributions derive from. Thus you would have been left in peace to continue your tight control over the educational version of minix, and everyone else that wanted more than an educational tool could put their energies into enhanced-minx.
The primary reason I've never gotten into using minix, after the initial excitement of hearing about it's availability way back when, is that I have no interest in trying to apply random patches from all over the place, sort out the problems, and eventually end up with a system that does what I want it to, but which I can't pass on to anyone else.
>The >test comes when a sizable group of people want to evolve LINUX in a way Linus >does not want. Until that actually happens the point is moot, however.
Where is the sizeable group of people that want to evolve gcc in a way that rms/FSF does not approve of?
Where is the sizeable group of people that want to evolve emacs in a way that rms/FSF doesn't approve of?
I'd say that if the primary maintainers of a large piece of useful, freely redistributable, software are at all responsive to incorporating useful enhancements and acting as the central repository and clearing house for the software, then these splinter groups simply do not have sufficient motivation to form. Having a single source for the software, and having the primary maintainer(s) be unresponsive to the desires of a large group of users, is the catalyst that causes these sorts of pressures; not the freedom of the software.
-Fred -- |\/ o\ Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA |/\__/ 1-602-491-0048 {asuvax,mcdphx,cygint,amix}!fishpond!fnf
>>>>> On 4 Feb 92 20:57:40 GMT, f...@fishpond.uucp (Fred Fish) said:
fnf> If PH was not granted a monopoly on distribution, it would have been fnf> possible for all of the interested minix hackers to organize and set fnf> up a group that was dedicated to producing enhanced-minix. This aim fnf> of this group could have been to produce a single, supported version fnf> of minix with all of the commonly requested enhancements. This would fnf> have allowed minix to evolve in much the same way that gcc has evolved fnf> over the last few years. Sure there are variant versions of gcc, but fnf> most of the really good enhancements, bug fixes, etc are eventually fnf> folded back into a master source base that future distributions derive fnf> from. Thus you would have been left in peace to continue your tight fnf> control over the educational version of minix, and everyone else that fnf> wanted more than an educational tool could put their energies into fnf> enhanced-minx.
I don't get it. What's preventing people from doing this? The quoted paragraph doesn't give any reasons for its assertions.
-- Vladimir -- Vladimir G. Ivanovic Sun Microsystems, Inc (415) 336-2315 MTV12-33 vladi...@Eng.Sun.COM 2550 Garcia Ave. {decwrl,hplabs,ucbvax}!sun!Eng!vladimir Mountain View, CA 94043-1100 Disclaimer: I speak for myself.
I've been getting a bit of mail lately from unhappy campers. (Actually 10 messages from the 43,000 readers may seem like a lot, but it is not really.) There seem to be three sticking points:
1. Monolithic kernels are just as good as microkernels 2. Portability isn't so important 3. Software ought to be free
If people want to have a serious discussion of microkernels vs. monolithic kernels, fine. We can do that in comp.os.research. But please don't sound off if you have no idea of what you are talking about. I have helped design and implement 3 operating systems, one monolithic and two micro, and have studied many others in detail. Many of the arguments offered are nonstarters (e.g., microkernels are no good because you can't do paging in user space-- except that Mach DOES do paging in user space).
If you don't know much about microkernels vs. monolithic kernels, there is some useful information in a paper I coauthored with Fred Douglis, Frans Kaashoek and John Ousterhout in the Dec. 1991 issue of COMPUTING SYSTEMS, the USENIX journal). If you don't have that journal, you can FTP the paper from ftp.cs.vu.nl (192.31.231.42) in directory amoeba/papers as comp_sys.tex.Z (compressed TeX source) or comp_sys.ps.Z (compressed PostScript). The paper gives actual performance measurements and supports Rick Rashid's conclusion that microkernel based systems are just as efficient as monolithic kernels.
As to portability, there is hardly any serious discussion possible any more. UNIX has been ported to everything from PCs to Crays. Writing a portable OS is not much harder than a nonportable one, and all systems should be written with portability in mind these days. Surely Linus' OS professor pointed this out. Making OS code portable is not something I invented in 1987.
While most people can talk rationally about kernel design and portability, the issue of free-ness is 100% emotional. You wouldn't believe how much [expletive deleted] I have gotten lately about MINIX not being free. MINIX costs $169, but the license allows making two backup copies, so the effective price can be under $60. Furthermore, professors may make UNLIMITED copies for their students. Coherent is $99. FSF charges >$100 for the tape its "free" software comes on if you don't have Internet access, and I have never heard anyone complain. 4.4 BSD is $800. I don't really believe money is the issue. Besides, probably most of the people reading this group already have it.
A point which I don't think everyone appreciates is that making something available by FTP is not necessarily the way to provide the widest distribution. The Internet is still a highly elite group. Most computer users are NOT on it. It is my understanding from PH that the country where MINIX is most widely used is Germany, not the U.S., mostly because one of the (commercial) German computer magazines has been actively pushing it. MINIX is also widely used in Eastern Europe, Japan, Israel, South America, etc. Most of these people would never have gotten it if there hadn't been a company selling it.
Getting back to what "free" means, what about free source code? Coherent is binary only, but MINIX has source code, just as LINUX does. You can change it any way you want, and post the changes here. People have been doing that for 5 years without problems. I have been giving free updates for years, too.
I think the real issue is something else. I've been repeatedly offered virtual memory, paging, symbolic links, window systems, and all manner of features. I have usually declined because I am still trying to keep the system simple enough for students to understand. You can put all this stuff in your version, but I won't put it in mine. I think it is this point which irks the people who say "MINIX is not free," not the $60.
An interesting question is whether Linus is willing to let LINUX become "free" of his control. May people modify it (ruin it?) and sell it? Remember the hundreds of messages with subject "Re: Your software sold for money" when it was discovered the MINIX Centre in England was selling diskettes with news postings, more or less at cost?
Suppose Fred van Kempen returns from the dead and wants to take over, creating Fred's LINUX and Linus' LINUX, both useful but different. Is that ok? The test comes when a sizable group of people want to evolve LINUX in a way Linus does not want. Until that actually happens the point is moot, however.
If you like Linus' philosophy rather than mine, by all means, follow him, but please don't claim that you're doing this because LINUX is "free." Just say that you want a system with lots of bells and whistles. Fine. Your choice. I have no argument with that. Just tell the truth.
As an aside, for those folks who don't read news headers, Linus is in Finland and I am in The Netherlands. Are we reaching a situation where another critical industry, free software, that had been totally dominated by the U.S. is being taken over by the foreign competition? Will we soon see President Bush coming to Europe with Richard Stallman and Rick Rashid in tow, demanding that Europe import more American free software?
First of all I want to say, that I like to support the idea of Andy to keep minix small. If you want something large go for GNU. I'm also against featurism. However, undoubtly my wanted set of features differs from Andy's set. Therefore what I would like to see, is something which allows it to add features easily. If for instance device drivers are loadable, or easier to add as they are now, then the core and some drivers can be the standard PH minix. If people want to add something, then it is nice to have a mechanism with which you can do so, without having to meddle with things like fs/table.c kernel/table.c include/minix/config.h (for NR_TASKS) etc.
a...@cs.vu.nl (Andy Tanenbaum) writes: >Suppose Fred van Kempen returns from the dead and wants to take over, creating
Just a remark for the readers. As far as I know Fred is not physically dead. If english is not your native language (just like mine) you might conclude otherwise from ast's words. Fred is only electronically dead.
-- Frans Meulenbroeks (meule...@prl.philips.nl) Philips Research Laboratories
>>>>>> On 4 Feb 92 20:57:40 GMT, f...@fishpond.uucp (Fred Fish) said:
>fnf> If PH was not granted a monopoly on distribution, it would have been >fnf> possible for all of the interested minix hackers to organize and set >fnf> up a group that was dedicated to producing enhanced-minix. This aim >fnf> of this group could have been to produce a single, supported version >fnf> of minix with all of the commonly requested enhancements. This would >fnf> have allowed minix to evolve in much the same way that gcc has evolved >fnf> over the last few years. Sure there are variant versions of gcc, but >fnf> most of the really good enhancements, bug fixes, etc are eventually >fnf> folded back into a master source base that future distributions derive >fnf> from. Thus you would have been left in peace to continue your tight >fnf> control over the educational version of minix, and everyone else that >fnf> wanted more than an educational tool could put their energies into >fnf> enhanced-minx.
>I don't get it. What's preventing people from doing this? The quoted >paragraph doesn't give any reasons for its assertions.
As I understand it PH takes the position that the copyright must be observed, and that distribution of modified copies of their copyrighted code is in violation of the copyright. I think that they are required to defend the copyright against such violations if they want it to remain legally valid.
Diffs against the baseline are allowed. But diffs have to be applied in strict order. This would be difficult to administer in a tight-knit organization with well defined distribution channels. In net.anarchy it's all but unworkable.
The fact that the Minix-386 variant of PC Minix 1.5 has managed to remain stable as a set of diffs suprises me. I recall that the NLMUG Minix variant was distributed as modified baseline code instead of as diffs, and that PH copyright lawyers put a stop to that.
>>>>> On 3 Feb 92 22:46:40 GMT, a...@cs.vu.nl (Andrew "Dice" Tanenbaum) said:
Andy> As an aside, for those folks who don't read news headers, Linus is Andy> in Finland and I am in The Netherlands. Are we reaching a Andy> situation where another critical industry, free software, that had Andy> been totally dominated by the U.S. is being taken over by the Andy> foreign competition?
I prefer to think of it as indicative of the fact that the U.S. is still the pioneer when it comes to new ideas and technologies. The rest of the world just follows along, trying to refine and capitalize upon our new developments. :^)
Andy> Will we soon see President Bush coming to Europe with Richard Andy> Stallman and Rick Rashid in tow, demanding that Europe import more Andy> American free software?
Be glad software isn't as important as oil. ;^)
-- /************************************************************************** / /* Kent Dalton * EMail: Kent.Dal...@FtCollinsCO.NCR.COM */ /* NCR Microelectronics * CIS: 72320,3306 */ /* 2001 Danfield Ct. MS470A * */ /* Fort Collins, Colorado 80525 * (303) 223-5100 X-319 */ /************************************************************************** / I've got an IDEA!! Why don't I STARE at you so HARD, you forget your SOCIAL SECURITY NUMBER!!
In article <VLADIMIR.92Feb4203...@ronnie.Eng.Sun.COM> vladi...@Eng.Sun.COM (Vladimir Ivanovic) writes: >>>>>> On 4 Feb 92 20:57:40 GMT, f...@fishpond.uucp (Fred Fish) said: >fnf> If PH was not granted a monopoly on distribution, it would have been >fnf> possible for all of the interested minix hackers to organize and set
>I don't get it. What's preventing people from doing this? The quoted >paragraph doesn't give any reasons for its assertions.
My understanding is that PH is the only one that is allowed to distribute a complete minix distribution. All others are restricted to the "2 copy limit" or by the educational provision for classroom use.
There is apparently no place where I can send a check for $50 - $150 and receive a complete, ready to install, copy of an enhanced minix that has most of the common enhancements that are floating around as diff kits, already installed and tested. When I run into a problem, I can't post a message saying that eminix version 15.4 does mumble-foo when it should do mumble-bar, and expect other people to be easily able to reproduce the problem. Except for people that are running strictly vanilla minix as received from PH, I doubt that there are any two minix sites anywhere in the world, that are not directly in touch with each other, that are running the same set of binaries. This is bug heaven, and a maintenance nightmare.
If I'm wrong, and there is such a place to get a full 32 bit minix with VM, hardware supported memory protection, and other assorted enhancements such as GNU gcc, g++, emacs, etc, with full sources and binaries for the entire system, preferably for an Amiga 3000, then please tell me. Directions that go "well first order minix X.X from PH, and then apply patch kit xxx from ftp site yyy and patch kit zzz from ftp site kkk, and write to John Doe for his patch kit www, and pick up patch kit ddd from the minix usenet archives" will be cheerfully ignored.
-Fred -- |\/ o\ Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA |/\__/ 1-602-491-0048 {asuvax,mcdphx,cygint,amix}!fishpond!fnf
In article <2...@fishpond.uucp> f...@fishpond.uucp (Fred Fish) writes: >If PH was not granted a monopoly on distribution, it would have been possible >for all of the interested minix hackers to organize and set up a group that >was dedicated to producing enhanced-minix. This aim of this group could have >been to produce a single, supported version of minix with all of the commonly >requested enhancements. This would have allowed minix to evolve in much the >same way that gcc has evolved over the last few years.
This IS possible. If a group of people wants to do this, that is fine. I think co-ordinating 1000 prima donnas living all over the world will be as easy as herding cats, but there is no legal problem. When a new release is ready, just make a diff listing against 1.5 and post it or make it FTPable. While this will require some work on the part of the users to install it, it isn't that much work. Besides, I have shell scripts to make the diffs and install them. This is what Fred van Kempen was doing. What he did wrong was insist on the right to publish the new version, rather than diffs against the PH baseline. That cuts PH out of the loop, which, not surprisingly, they weren't wild about. If people still want to do this, go ahead.
Of course, I am not necessarily going to put any of these changes in my version, so there is some work keeping the official and enhanced ones in sync, but I am willing to co-operate to minimize work. I did this for a long time with Bruce Evans and Frans Meulenbroeks.
If Linus wants to keep control of the official version, and a group of eager beavers want to go off in a different direction, the same problem arises. I don't think the copyright issue is really the problem. The problem is co-ordinating things. Projects like GNU, MINIX, or LINUX only hold together if one person is in charge. During the 1970s, when structured programming was introduced, Harlan Mills pointed out that the programming team should be organized like a surgical team--one surgeon and his or her assistants, not like a hog butchering team--give everybody an axe and let them chop away.
Anyone who says you can have a lot of widely dispersed people hack away on a complicated piece of code and avoid total anarchy has never managed a software project.
>Where is the sizeable group of people that want to evolve gcc in a way that >rms/FSF does not approve of?
A compiler is not something people have much emotional attachment to. If the language to be compiled is a given (e.g., an ANSI standard), there isn't much room for people to invent new features. An operating system has unlimited opportunity for people to implement their own favorite features.
In article <1992Feb4.201722.20...@epas.toronto.edu>, meggin@epas (David Megginson) writes: >Actually, the U.S. is more likely to have you arrested for selling >restricted software to unfriendly powers (not that anyone in the >C.I.S. can afford software this winter -- they're probably burning >their PCs for heat). I remember that they jailed some poor computer >vendor in the U.K. a couple of years ago.
Around here a few years ago they had a trial against a couple of guys who sold old VAXes to the Soviet Union. They were charged with treason because they were breaking some export rules. They weren't convicted, though, I think it was something about the export rules not being a law in Finland.
For some reason the U.S. troups didn't come to Finland to kill a few thousand people and take these guys to USA for a trial like they did with another person in another country.
In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum) writes:
(most stuffs omitted)
> If you don't have that journal, you can FTP the paper from > ftp.cs.vu.nl (192.31.231.42) in directory amoeba/papers as comp_sys.tex.Z > (compressed TeX source) or comp_sys.ps.Z (compressed PostScript).
I am so much interested in this paper, but I cannot get it. The ftp server of ftp.cs.vu.nl rejects my connection because the IP address of machines in my site (and most sites in Japan), from machines outside of Japan, cannot be resolved by ptr. Is there anyone who has fetched it and placed it in annonymous ftp? Archie servers seem to have no idea.
Thanks in advance.
-HAMADA Naoki Naoki is my first name. n...@sala.sony.co.jp
In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum) writes:
>If Linus wants to keep control of the official version, and a group of eager >beavers want to go off in a different direction, the same problem arises.
This is the second time I've seen this "accusation" from ast, who feels pretty good about commenting on a kernel he probably haven't even seen. Or at least he hasn't asked me, or even read alt.os.linux about this. Just so that nobody takes his guess for the full thruth, here's my standing on "keeping control", in 2 words (three?):
I won't.
The only control I've effectively been keeping on linux is that I know it better than anybody else, and I've made my changes available to ftp-sites etc. Those have become effectively official releases, and I don't expect this to change for some time: not because I feel I have some moral right to it, but because I haven't heard too many complaints, and it will be a couple of months before I expect to find people who have the same "feel" for what happens in the kernel. (Well, maybe people are getting there: tytso certainly made some heavy changes even to 0.10, and others have hacked it as well)
In fact I have sent out feelers about some "linux-kernel" mailing list which would make the decisions about releases, as I expect I cannot fully support all the features that will /have/ to be added: SCSI etc, that I don't have the hardware for. The response has been non-existant: people don't seem to be that eager to change yet. (well, one person felt I should ask around for donations so that I could support it - and if anybody has interesting hardware lying around, I'd be happy to accept it :)
The only thing the copyright forbids (and I feel this is eminently reasonable) is that other people start making money off it, and don't make source available etc... This may not be a question of logic, but I'd feel very bad if someone could just sell my work for money, when I made it available expressly so that people could play around with a personal project. I think most people see my point.
That aside, if Fred van Kempen wanted to make a super-linux, he's quite wellcome. He won't be able to make much money on it (distribution fee only), and I don't think it's that good an idea to split linux up, but I wouldn't want to stop him even if the copyright let me.
>I don't think the copyright issue is really the problem. The problem is >co-ordinating things. Projects like GNU, MINIX, or LINUX only hold together >if one person is in charge.
Yes, coordination is a big problem, and I don't think linux will move away from me as "head surgeon" for some time, partly because most people understand about these problems. But copyright /is/ an issue: if people feel I do a bad job, they can do it themselves. Likewise with gcc. The minix copyright, however, means that if someone feels he could make a better minix, he either has to make patches (which aren't that great whatever you say about them) or start off from scratch (and be attacked because you have other ideals).
Patches aren't much fun to distribute: I haven't made cdiffs for a single version of linux yet (I expect this to change: soon the patches will be so much smaller than the kernel that making both patches and a complete version available is a good idea - note that I'd still make the whole version available too). Patches upon patches are simply impractical, especially for people that may do changes themselves.
>>Where is the sizeable group of people that want to evolve gcc in a way that >>rms/FSF does not approve of? >A compiler is not something people have much emotional attachment to. If >the language to be compiled is a given (e.g., an ANSI standard), there isn't >much room for people to invent new features. An operating system has unlimited >opportunity for people to implement their own favorite features.
Well, there's GNU emacs... Don't tell us people haven't got emotional attachment to editors :)
In article <1992Feb5.154726....@nntp.hut.fi> j...@cs.HUT.FI (Jyrki Kuoppala) writes:
>Around here a few years ago they had a trial against a couple of guys >who sold old VAXes to the Soviet Union.
In their book, Cyberpunk, Katie Hafner and John Markoff report that a group of hackers tried to sell MINIX to the KGB claiming it was the VMS source code. The KGB didn't buy.
Andy Tanenbaum writes: > >Where is the sizeable group of people that want to evolve gcc in a way that > >rms/FSF does not approve of? > A compiler is not something people have much emotional attachment to. If > the language to be compiled is a given (e.g., an ANSI standard), there isn't > much room for people to invent new features. An operating system has unlimited > opportunity for people to implement their own favorite features.
Try posting an announcement in one of the gnu groups about porting FSF software to the Macintosh... ;-)
People will be emotional about anything they make, and more so if others try to do unexpected things with it. Software is no exception.
If I remeber well, the only real attempt at global coordination of Minix projects has been Glen Overby's Projects directory at plains. Problem is that usually people don't want to announce all of their projects, because they are not sure about whether or when they will finish it. Fred was ready, and he told me he even set up big plans for only sending out his stuff to people who could prove they owned an original. PH was sceptical about his ability to check this, and their ability to check Fred. They were even less enthausiastic about his using the name "Minix" in the name of the final product. sigh. I've seen some of his code. Too bad he only works on PCs. Some of the ideas and comments floating around in the course of the current discussion were fixed by Fred; centralized system call server, dynamically added servers who can then serve new system calls. He ran TCP/IP as an added server. Sure, Fred has an unusual personality, and sometimes an attitude that smells of simply liking to run into a brick wall (not literally, please), but he is one hell of a programmer, and when he was still unemployed he had just the dynamism needed to get a large Minix rework done. I'ld allmost feel sorry for the fact that he has a job now. ;-)
Perhaps we can use all this shouting and selfreflecting caused by the Linux wars to some good end. Glen Overby had the right idea in setting up a central site for collecting project info and ideas. What actually is needed is someone to volunteer maintaining such a database. Just saying "dump it here" will only transform anarchy to organized anarchy. Also portability of patches is currently far from ideal. As the recent sighup/init/getty activity shows, we have several packages, some of which are PC only, while others are ST only, and again others have simply never been tested on a wider range of machines.
We have for the FS: - symbolic links, multi-threading For mm: - ?? kernel: - virtual consoles (standard on ST, addon on PC), sighup, the kub scheduler tools: - new init, boot packages, shoelace lib: - ?? commands: - zillions of programs
I would like to suggest to those that built a patch set, to try and collect as much as possible info on portability, interference with other major patch sets, reliance on other major patch sets, and include this info with their patch sets. It would greatly help if an enthausiastic ST owner, having found a nice feature for his system, would not be (unpleasantly) surprised by the fact that the patch is only for PCs. Or vice versa of course.
Greetings, Bert --- #include <std/disclaimer>
Bert Laverman, Dept. of Computing Science, Groningen University Friendly mail to: laver...@cs.rug.nl The rest to: /dev/null
-- #include <std/disclaimer>
Bert Laverman, Dept. of Computing Science, Groningen University Friendly mail to: laver...@cs.rug.nl The rest to: /dev/null
>>Suppose Fred van Kempen returns from the dead and wants to take over, creating
>Just a remark for the readers. As far as I know Fred is not physically dead. >If english is not your native language (just like mine) you might >conclude otherwise from ast's words. Fred is only electronically dead.
He's not electronicly dead any longer either. I and several others involved with MUGNET have received electronic communications from him, that is unless our hosts are haunted by Fred's electronic spirit. -- Mike Dobson, Sys Admin for | Internet: rd...@nmrdc1.nmrdc.nnmc.navy.mil nmrdc1.nmrdc.nnmc.navy.mil | UUCP: ...uunet!mimsy!nmrdc1!rdc30 AT&T 3B2/600G Sys V R 3.2.2 | BITNET: dobson@usuhsb or nrd0mxd@vmnmdsc WIN/TCP for 3B2 | MCI-Mail: 377-2719 or 0003772...@mcimail.com
In article <2...@fishpond.uucp> f...@fishpond.uucp (Fred Fish) writes: >My understanding is that PH is the only one that is allowed to distribute >a complete minix distribution.
Fred,
To the best of my knowledge, PH has no such restriction. In fact, as of a year ago, PH had an active program to license MINIX to anyone who wants to use it for whatever purpose. This specifically includes building variants of the MINIX system such as "enhanced" MINIX.
>There is apparently no place where I can send a check for $50 - $150 and >receive a complete, ready to install, copy of an enhanced minix that has >most of the common enhancements that are floating around as diff kits, >already installed and tested.
Although I didn't explore this specifically, I saw nothing that would preclude someone or some company from signing a license agreement with PH, building an "enhanced" version of MINIX, and then selling as many as the market will bear. The only rule is that this licensee (Company X) would have to behave like a business: report each sale and collect a license fee.
The license fees depend upon the quantity Company X believes can be sold, and require some amount of prepayment. License fees appear to be fairly reasonable, for example, perhaps US $50 at quantity 1000. But for this license fee, Company X must duplicate its own diskettes and produce its own release notes. And answer its own phones, and handle customer gripes, and strike its own licensing agreements with the individuals who wrote the various add-on packages that make up eminix. And so on..
>If I'm wrong, and there is such a place to get a full 32 bit minix with >VM, hardware supported memory protection, and other assorted enhancements >such as GNU gcc, g++, emacs, etc, with full sources and binaries for the >entire system, preferably for an Amiga 3000, then please tell me.
I don't know of anyone who sells this, but that's not PH's fault..
>>Suppose Fred van Kempen returns from the dead and wants to take over, creating
> Just a remark for the readers. As far as I know Fred is not physically dead. > If english is not your native language (just like mine) you might > conclude otherwise from ast's words. Fred is only electronically dead.
From what little I understand, the reason Minix needs to use a second class encryptor for its passwd file is because of the export restrictions. You can't export or transmit the algorhthym (sp).
In article <66...@ut-emx.uucp> ja...@fiskville.mc.utexas.edu (James Hammett) writes: >From what little I understand, the reason Minix needs to use a second >class encryptor for its passwd file is because of the export restrictions. >You can't export or transmit the algorhthym (sp).
Not even to hostile nations like Canada, apparently. I'm pretty sure that the Dictionary of Old English in Toronto received its Suns sans the crypt utilities.
David
################################################################# David Megginson meg...@epas.utoronto.ca Centre for Medieval Studies da...@doe.utoronto.ca University of Toronto 39 Queen's Park Cr. E. #################################################################
>>From what little I understand, the reason Minix needs to use a second >>class encryptor for its passwd file is because of the export restrictions. >>You can't export or transmit the algorhthym (sp).
>Not even to hostile nations like Canada, apparently. I'm pretty sure >that the Dictionary of Old English in Toronto received its Suns sans >the crypt utilities.
This is the perfect example of the rediculous export restriction. The algorhythm is publicly available, and source to implement is is all over the network. Who is the restriction intended to affect?
-- Brian McBee mcb...@jacobs.cs.orst.edu or bria...@opac.UUCP "The strongest reason for the people to retain the right to keep and bear arms is, as a last resort, to protect themselves against tyranny in government." Thomas Jefferson
in comp.os.minix, mcb...@jacobs.CS.ORST.EDU (Brian Mcbee) said:
>>>From what little I understand, the reason Minix needs to use a second >>>class encryptor for its passwd file is because of the export restrictions. >>[...] >This is the perfect example of the rediculous export restriction. The >algorhythm is publicly available, and source to implement is is all over >the network. Who is the restriction intended to affect?
I wouldn't characterize this as an example of paranoia. I think it's simply bureaucracy running amok, as usual. We've got a badly worded regulation being taken literally and applied zealously by enforcers.
mcb...@jacobs.CS.ORST.EDU (Brian Mcbee) writes: > This is the perfect example of the rediculous export restriction. The > algorhythm is publicly available, and source to implement is is all over > the network. Who is the restriction intended to affect?
I'm currently using RSA encryption to chat to someone in Russia. You tell me!
mathew
-- Hail Eris! / "Our whole economy's based on fear and death; how long can we get away with this?" --- Jello Biafra / Message for Kodak: Bring back Dan Bredy! / PGP RSA public key available on request / Desperately seeking Negativland's U2 CD / Just another would-be Mac owner put off by Apple's monopolistic practices
In article <1992Feb9.163024.16...@mdd.comm.mot.com> mitch...@mdd.comm.mot.com (Bill Mitchell) writes: }>>>From what little I understand, the reason Minix needs to use a second }>>>class encryptor for its passwd file is because of the export restrictions. }>>[...] }>This is the perfect example of the rediculous export restriction. The }>algorhythm is publicly available, and source to implement is is all over }>the network. Who is the restriction intended to affect? } }I wouldn't characterize this as an example of paranoia. I think it's }simply bureaucracy running amok, as usual. We've got a badly worded }regulation being taken literally and applied zealously by enforcers. }
Well, I disagree here. I think that the original intent was to do exactly that - to prevent the algoritm from being exported to anywhere outside the US. However, that intenet has since been relaxed, but the fact that the restriction is still in effect is due to laziness - not paranoia. Bruce
-- -How long must we fight? How long Courtesy of Bruce Varney until we can live in peace. a...@sage.cc.purdue.edu -Until the madmen are dead my son, Or until they realize that they cannot count on us to do nothing
>In article <1992Feb9.163024.16...@mdd.comm.mot.com> mitch...@mdd.comm.mot.com (Bill Mitchell) writes: >}>>>From what little I understand, the reason Minix needs to use a second >}>>>class encryptor for its passwd file is because of the export restrictions. >}>>[...] >}>This is the perfect example of the rediculous export restriction. The >}>algorhythm is publicly available, and source to implement is is all over >}>the network. Who is the restriction intended to affect? >} >}I wouldn't characterize this as an example of paranoia. I think it's >}simply bureaucracy running amok, as usual. We've got a badly worded >}regulation being taken literally and applied zealously by enforcers. >}
>Well, I disagree here. I think that the original intent was to do exactly >that - to prevent the algoritm from being exported to anywhere outside >the US. However, that intenet has since been relaxed, but the fact that >the restriction is still in effect is due to laziness - not paranoia. > Bruce
I admit to not being an expert in this area but, as I remember it, the algorithm was made public pretty much from the start. My understanding is that the restriction was/is against export of working implementations, not against export of the already-public algorithm. Seems to me it never did make much sense, but there it is.
My own personal opinion about the reason the restriction is still in place is that it's (1) bureaucratic inertia, and (2) probably considered a useful tool to have in your toolbox if it's your job to find a way to stop export shipment of some designated item or to find charges which can be brought against some person or organization your superiors feel needs some expensive court time to make him see the error of his ways.
Think it's worth wasting more bandwidth on this? I think we're just lowering the S/N ratio in comp.os.minix. I debated about posting this and decided to go ahead, but I'm not planning to post again on this thread.