Newsgroups: comp.os.linux
Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!malgudi.oar.net!caen!destroyer!news.iastate.edu!pv141b.vincent.iastate.edu!sheldon
From: shel...@iastate.edu (Steve Sheldon)
Subject: Re: Stabilizing Linux
Message-ID: <sheldon.713197562@pv141b.vincent.iastate.edu>
Sender: n...@news.iastate.edu (USENET News System)
Organization: Iowa State University, Ames IA
References: <1992Aug6.125441.22427@klaava.Helsinki.FI>
Date: Fri, 7 Aug 1992 14:26:02 GMT
Lines: 73
In <1992Aug6.125441.22...@klaava.Helsinki.FI> wirze...@klaava.Helsinki.FI (Lars Wirzenius) writes:
>Kenneth Falck raises the question of whether Linux should
>stabilize a bit when 1.0 is released. The same concern has been
>raised by others earlier, as well. (Another related question is
>what exactly 1.0 should include, but I shan't go into that very
>much, I'm currently more interested in more general qualities.)
I have to agree with Lars completely on this. He brings up some
very good points.
>We'll let the kernel evolve towards what we want 1.0 to be, at
>least featurewise. After we reach a point where all the features
>we want are present, we freeze that version of the kernel as 0.99,
>and refuse to put in new features (unless they are essential).
Yes, we need to specify what features would be nice in this v1.0.
And then not deviate too much from the feature list, just perform
bug fixes, to help stablize it.
Obviously, people should be encouraged to work on new featureful
ideas, but keep these as a parallel development to be included in
v1.1, or whatever.
I'd like to see something out by Jan93, maybe. I think it advisable
that we not get into a situation like Commodore's AmigaDOS 2.04. This
started out as a v1.4 which will be out by Spring '89, and then into
a v2.0 for final release in '90, and ended up as 2.04 and didn't get
released to the general public until fall '91. While I was not an
Amiga developer, it sounded like it had a creeping feature syndrome, and
they kept adding stuff and testing became quite a burden.
The problem with this scenario, is that while people are waiting and waiting
for the stabilized release, they are more likely to loose interest, and go
do something else. I'd like to bait & hook a few more people, and show
them the wonders of *nix, which I am just now getting to know myself.
>After the kernel has been tested thoroughly, for a few weeks or
>so, and all the major bugs have been fixed, we release it as 1.0.
>Then we consider this as the baseline, and create one official
>release that is easy to install, easy to administer, contains
>everything necessary and a lot of unnecessary but probably widely
>useful things and package everything neatly.
test...test...test... It's a tough job, but necessary.
>This package is what should be called Linux, not just the kernel.
>Compare with, say, SVR4: it is not just a kernel, but a whole
>bunch of software. Also the whole package is given its own
>version number, instead of using the kernel's version number as is
>currently done.
Yes, most definitely. A package which all you need to do is stick a
boot disk into the machine, and walk you thru the install. Much like
any of these commercial Unixes, SCO, Dell, etc.
I'd love to see a full package which included the administration utilities,
the documentation, manual pages, networking software, X386, etc. Only
install what you want/need.
I'd also like to see as part of this "release" a couple of "manuals"
which the user could print out from the DOS side. Something that
is nicely formatted, and ready to copy to the printer. An "installation
guide", and a "user's guide". The installation guide would go step
by step thru the installation, and the user's guide would describe just
what is included in the package, and go over some of the basics of unix,
as well as basic setup and administration. There are thousands of pages
already written on Unix, and I don't expect we could cover everything.
But certainly the basics, and the things specific to Unix.
Perhaps it would be a good idea to continue a discussion on what features
we should realistically expect to include in v1.0? And work towards that
goal.
Path: sparky!uunet!dtix!mimsy!ra!tantalus!eric
From: e...@tantalus.dell.com (Eric Youngdale)
Newsgroups: comp.os.linux
Subject: Linux CDROM (Was stabilizing Linux)
Message-ID: <3248@ra.nrl.navy.mil>
Date: 8 Aug 92 03:50:06 GMT
References: <1992Aug6.125441.22427@klaava.Helsinki.FI> <sheldon.713197562@pv141b.vincent.iastate.edu>
Sender: use...@ra.nrl.navy.mil
Organization: Naval Research Laboratory
Lines: 94
In article <sheldon.713197...@pv141b.vincent.iastate.edu> shel...@iastate.edu (Steve Sheldon) writes:
> I'd like to see something out by Jan93, maybe. I think it advisable
>[...]
> Perhaps it would be a good idea to continue a discussion on what features
>we should realistically expect to include in v1.0? And work towards that
>goal.
I have one bit of news that would certainly be relevant, and could help
to ensure that we do not dawdle too much. Robert Bruce, from Walnut Creek
CDROM wants to make a Linux/386BSD/GNU/X11 CDROM (They currently have a GNU/X11
disc (source + sparc binaries), among others). He indicated to me that it will
contain Linux binaries and source code, 386bsd binaries and source code, GNU
source code, and the X11 distribution, all on one disc (provided that it all
fits). I am not sure of the exact timetable, but I think that he is looking
toward the fall sometime for a release date.
To me this sounds like an excellent opportunity to get our collective
acts together and get a 1.0 release out the door. About a month ago, I asked
the question "What is left to be done for 1.0", and we got a fairly spirited
discsussion going. There were a couple of major points, and an abbreviated
list was:
(1) The new extfs being considered well-tested and no known bugs.
(2) Sharable libraries that are downward compatible(jump tables).
(3) dosfs being reliable enough to be considered well tested .
(4) All kernel/library hooks required for TCP/IP. (post 1.0??).
(5) Filesystem with larger block sizes (4Kb).
(6) An isofs to read the ISO9660 CD-ROM format.
(7) Some kind of logo to print on the cdrom disc :-)
As I look at the list, 1-3 are all being tested, and are well on the way to
becoming stable. Number 4 was in the post 1.0 list, but apparently the hooks
are already present in 0.97pl2. Number 5 is in the works, but is not really
essential for a 1.0 release. Number 6 was also in the post 1.0 list, but if we
are going to have a linux cdrom for linux 1.0, then we sure as heck need the
filesystem for the 1.0 release (the CDROM code is in beta-testing). Where does
this leave us? In general I think we are in pretty good shape on the kernel
end. We just need to continue testing. It is not clear to me that we really
*need* any features other than those I have already mentioned for a 1.0
release. The cdrom code is not part of the official distribution yet, but this
is not a big issue.
I threw in item 7 as sort of a joke, but I am only half kidding. I
have the GNU/X11 disc in front of me (the one with sparc binaries), and it has
the X logo, the Sun users group logo, and the GNU logo (basically a Gnu :-)).
It would be neat to have a Linux logo of some kind for the disc, although we
really do not need it. I suspect that there are people with some graphics arts
skills who can design a really neat logo of some kind and translate it into the
postscript language. If anyone wants to give this a shot, describe your idea
to the list, and see how the rest of us like it. If we get more than one, we
might even vote on it. It would be best to keep it to one or two colors. The
only reason that I said postscript was so the rest of us could easily see it
:-).
On a more serious note, one area of concern that I have is the status
of the archives. A cdrom distribution will probably just be a snapshot of one
of the archives, and since we are losing banjo, I suppose that tsx-11 will be
'it'. If there are components (i.e. man pages, mcc) that should be included
but are not on tsx-11, then I should be informed of this, so that I can pass
this along to Robert Bruce. We should make an effort to make sure that *all*
stale binaries have been expunged from tsx (or wherever), and replaced with
something current. We should make sure that all stale readme files on tsx are
updated. My feeling is that the archive maintainers already do enough, and we
should not have to ask them to take on this additional burden by themselves.
Instead, we should each be diligent about finding and reporting stale materials
in the archives. It might even be a good idea to create a parallel tree, and
only move over those things that are known to be good.
While we are on the subject of cdroms under linux, I will release
beta-2 of the Linux CDROM distribution sometime over the weekend. I basically
want to try out the kernel patches with 0.97pl1. There have been a number of
improvements:
*) SCSI error handling/correction bugs fixed.
*) SCSI cdrom code now uses scatter/gather.
*) Rock Ridge extensions to ISO9660 standard are now in place
The RR extensions allow for:
- Longer filenames. My filesystem limits to 256 characters.
- Filenames can have mixed case, standard unix syntax.
- Values supplied for file modes, nlinks, uid/gid.
- different times for atime, ctime, mtime.
- Symbolic links.
- Block and character devices.
- Deep directories (iso9660 limits depth to 8).
(Robert Bruce has indicated that he intends to use Rock Ridge when
making the Linux/386BSD disc).
-Eric
--
Eric Youngdale
e...@tantalus.nrl.navy.mil
Path: sparky!uunet!olivea!mintaka.lcs.mit.edu!bloom-picayune.mit.edu!daemon
From: ty...@ATHENA.MIT.EDU (Theodore Ts'o)
Newsgroups: comp.os.linux
Subject: Re: Stabilizing Linux
Message-ID: <1992Aug9.192757.27571@athena.mit.edu>
Date: 9 Aug 92 19:27:57 GMT
Sender: dae...@athena.mit.edu (Mr Background)
Reply-To: ty...@ATHENA.MIT.EDU (Theodore Ts'o)
Organization: The Internet
Lines: 55
There has been an awful lot of discussions about ways to "Stablize
Linux" --- whether this is good or bad --- the need for an "Official
Release", and talk about a "Linux Committee". I've seen some stuff I
agree with, and some stuff that I disagree with. Not surprisingly, the
people with whom I agree with tended to be the people who were putting a
lot of hard work into Linux already --- and the people whom I disagreed
with were people whom, by and large, their names I did not recognize as
Linux developers.
You should all keep in mind that the people who have been putting in
their time to make Linux better do so out of a labor of love; Linux is
freeware, and it is relatively rare for freeware to be of the quality
that Linux already is. I hear a lot of calls about ways people think
Linux should be made better; but what I don't hear is anyone
volunteering to actually do the work.
This is why a Linux committee would not terribly productive; if it's
composed of people who do nothing more than demand that volunteers spend
even more of their time working on it, so that it becomes "acceptable"
--- it won't work, and it will only breed resentment on both sides. If
it is composed of those who are actually doing the work --- well, those
who are already doing the work currently have the say about what their
work produces; why have a committee to formalize such things?
What we're seeing is the results of Linux's success. It has proven to
be so successful that people are forgetting that it is freeware, and
STILL IN BETA TEST; that it is rare for you to even get what you pay
for, let alone exceed what you paid for it (which is what Linux has
clearly done). Instead, people are assuming that it should be a
turn-key system; and Someone should put together better system
administration tools than what currently exists on the market.
Guys (and Gals) ---- release engineeering is hard work, and in general
no fun. You should be thanking those people who have been putting
together the MCC release, the TAMU release, or the MJ release, not
complaining about how the maintainers should be putting even more of
their free time into it. If you're not satisifed with the quality of
those releases, put one together yourself! If it's better than all the
others, everyone will start using it.
As for system administration tools --- that is still an unsolved
problem; I have yet to see a general purpose system administrator's tool
that works in all environments; handles everything that a potential
sysadmin might want to do; and doesn't get in the way of an experienced
administrator. Why are people demanding that Linux provide a solution
to an unsolved research problem?
In summary, if you're not satisfied with how Linux is progressing, put
in the time and effort to improve the areas you are complaining about.
If you can't do that, rest assured that many of us are aware of the
shortcomings of Linux, and some of us are wondering how to find the time
to address the deficiency. Flaming about it, however, isn't going to
help. Talk is cheap; actually doing something about it is harder.
- Ted
Newsgroups: comp.os.linux
Path: sparky!uunet!van-bc!bhenning
From: bhenn...@wimsey.bc.ca (Bill Henning)
Subject: Re: Linux CDROM (Was stabilizing Linux)
Organization: Wimsey
Date: Wed, 12 Aug 1992 02:02:46 GMT
Message-ID: <1992Aug12.020246.22166@wimsey.bc.ca>
References: <3274@ra.nrl.navy.mil> <1992Aug11.004325.9409@unislc.uucp> <3284@ra.nrl.navy.mil>
Lines: 6
3.75Gb/process would be great! I am not likely to need that ofcourse, nor will
I likely have a swap partition much greater than 10-20Mb, but fewer limitations
are allways welcome.
Now if the number of processes are also increased from 64 to say 1024 that would
be great! (yes, I can see running out of 64 processes)
Path: sparky!uunet!crdgw1!rdsunx.crd.ge.com!ariel!davidsen
From: david...@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.os.linux
Subject: Re: Linux CDROM (Was stabilizing Linux)
Message-ID: <1992Aug12.164546.13304@crd.ge.com>
Date: 12 Aug 92 16:45:46 GMT
References: <3274@ra.nrl.navy.mil> <1992Aug11.004325.9409@unislc.uucp> <3284@ra.nrl.navy.mil> <1992Aug12.020246.22166@wimsey.bc.ca>
Sender: use...@crd.ge.com (Required for NNTP)
Reply-To: david...@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY
Lines: 16
Nntp-Posting-Host: ariel.crd.ge.com
In article <1992Aug12.020246.22...@wimsey.bc.ca>, bhenn...@wimsey.bc.ca (Bill Henning) writes:
| 3.75Gb/process would be great! I am not likely to need that ofcourse, nor will
| I likely have a swap partition much greater than 10-20Mb, but fewer limitations
| are allways welcome.
|
| Now if the number of processes are also increased from 64 to say 1024 that would
| be great! (yes, I can see running out of 64 processes)
I can see running out of 64 processes a lot faster than running out of
64MB address space. I certainly am not running that much memory and
swap. Actually, with 12MB I can compile the kernel while reading mail
and still not swap. I know, because I don't even have a swap area,
haven't run out of memory yet.
--
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
I admit that when I was in school I wrote COBOL. But I didn't compile.
Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
From: torva...@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Linux CDROM (Was stabilizing Linux)
Message-ID: <1992Aug13.095529.18687@klaava.Helsinki.FI>
Date: 13 Aug 92 09:55:29 GMT
References: <3284@ra.nrl.navy.mil> <1992Aug12.020246.22166@wimsey.bc.ca> <1992Aug12.164546.13304@crd.ge.com>
Organization: University of Helsinki
Lines: 18
In article <1992Aug12.164546.13...@crd.ge.com> david...@crd.ge.com (bill davidsen) writes:
>In article <1992Aug12.020246.22...@wimsey.bc.ca>, bhenn...@wimsey.bc.ca (Bill Henning) writes:
>| 3.75Gb/process would be great! I am not likely to need that ofcourse, nor will
>| I likely have a swap partition much greater than 10-20Mb, but fewer limitations
>| are allways welcome.
>|
>| Now if the number of processes are also increased from 64 to say 1024 that would
>| be great! (yes, I can see running out of 64 processes)
>
> I can see running out of 64 processes a lot faster than running out of
>64MB address space. I certainly am not running that much memory and
>swap.
The things are related: the 64 process maximum will be gone the same day
the 64MB limit is gone. It will just take a bit of coding on my part,
so don't expect it tomorrow..
Linus
Newsgroups: comp.os.linux
Path: sparky!uunet!decwrl!world!dsb
From: d...@world.std.com (David Boyce)
Subject: Re: Stabilizing Linux
Message-ID: <Bt1u3u.3zv@world.std.com>
Organization: The World Public Access UNIX, Brookline, MA
References: <1992Aug6.125441.22427@klaava.Helsinki.FI>
Date: Sat, 15 Aug 1992 23:47:53 GMT
Lines: 118
In article <1992Aug6.125441.22...@klaava.Helsinki.FI> wirze...@klaava.Helsinki.FI (Lars Wirzenius) writes:
>What I propose is this (getting to the point already, are we?):
>We'll let the kernel evolve towards what we want 1.0 to be, at
>least featurewise. After we reach a point where all the features
>we want are present, we freeze that version of the kernel as 0.99,
>and refuse to put in new features (unless they are essential).
>
>After the kernel has been tested thoroughly, for a few weeks or
>so, and all the major bugs have been fixed, we release it as 1.0.
>Then we consider this as the baseline, and create one official
>release that is easy to install, easy to administer, contains
>everything necessary and a lot of unnecessary but probably widely
>useful things and package everything neatly.
>
>This package is what should be called Linux, not just the kernel.
>Compare with, say, SVR4: it is not just a kernel, but a whole
>bunch of software. Also the whole package is given its own
>version number, instead of using the kernel's version number as is
>currently done.
>
>The whole package will then be put into all the major Linux ftp
>sites, and those sites are cleaned up so that there are no old
>releases that confuse people. This is then announced and
>advertised as the official released version of Linux which should
>be used by everybody but hackers and others who like to have
>problems. It is also advertised to remain that way for at least a
>few months...
Two prolific threads lately have been this "Stabilizing Linux"
series and the discussions of the coming commercial CDROM/floppy releases.
It seems to me that there's a natural way to put them together:
The upshot of Lars' article seems to be that "we need to create
a stable, reliable Linux 1.0 version" and thus that we (using the term
loosely, I haven't contributed much) should go through the usual
integrate/test/document/release process that most commercial software
goes through. While I agree with most of Lar's article and the followups,
my disagreement with the above is rooted in the fact that commercial
software developers go through the painful release process because
they have paying customers, who are understandably upset when bugs or
incompatibilities show up or when promised features don't. But linux
per se has no paying customers, just users.
Now, at the same time we're reading that there are for-profit
organizations getting ready to issue CDROM or floppy editions
of linux as soon as it stabilizes. While I'm not one of those
people that has a problem with this (I understand the GNU concept
etc.) I do have trouble understanding why the companies that propose
to have paying linux customers shouldn't be the ones to do the
integration and testing.
So this is my proposal: instead of doing the integration and testing
for (the entire system) Linux 1.0, we should spend the intervening time
between now and (kernel) 1.0 discussing and developing a document
in the spirit of SVID or POSIX*, i.e. something which says
"you can't call your product Linux unless it conforms to the
following specifications". This wouldn't need to be a big thing,
just an invocation of the appropriate POSIX etc. specs where
applicable, a description of filesystem layout and utility
features ("... the utility suite is that provided by FSF,
with the exception of the following which are in the BSD
distribution, and such-and-such special cases...").
Note that this document doesn't concern itself with versions;
it simply says that the following files will exist in the following
places with the following modes and will exhibit the following behavior....
Once we've issued release 1.0 of that document and Linus has
blessed version 1.0 of his kernel, we can sit back and wait for
the CDROM company(s) to put together a package that satisfies
this Linux Interface Document (LID). If the makers of mcc-interim,
MJ, etc. can do this without a spec in their spare time, I assume
it can be done commercially without too much trouble, given the spec.
Actually, this document or something like it is probably already
being worked on by the linux-standards people.
And then as soon as the CDROM is issued, the people at one of the
big linux ftp sites can acquire one (taking donations as appropriate,
I'm sure they'd be gladly given) and mount it
for ftp access (it will be freely distributable, after all).
Other sites can do the same or mirror it, and voila! there is
a stable Linux 1.0 available for ftp by the core linux community,
and hackers can go on issuing a release a day if they like.
And we'll let the for-profit issuers decide when releases 1.1, 2.0,
etc. are required. They can pick fixes from the stream and issue
them as floppy updates to their customers or make whole new releases.
As a customer, the ftp site(s) would get these updates and make
them available for ftp.
I don't think this would be an undue burden on linux sellers.
Anybody selling software has to test it first; they owe that to
their customers. And they'll probably decide to rebuild all the binaries
with the released version of gcc, just for the sake of sanity.
At least, that's what every commercial system vendor I've ever
worked for does. So given that they'll probably go through
a build/integrate/test/release process anyway, why not piggyback
off them? Let them do what they hope to be paid for and let
the linux developers go on being the geese that lay golden eggs.
Also, we need to recognize that whatever version is issued on
floppy/CDROM is going to become a de facto standard, just by the nature
of things. This is why I think that rather than issuing a standard
release and then hoping it's what gets shipped on CDROM, we should
issue only a document and wait for it to be instantiated in CD.
Anyway, this seems, to me at least, to solve everyone's problems:
the hackers can go on hacking and acquiring new software as quickly
as they can ftp it, the "users" buy the CDROM or floppies. The
"Keep Linux FREE!!!!!" contingent will sleep better at night knowing
those commercial vendors are doing some work for their money,
the vendors get exclusive access to the non-internet community,
and those who have ftp access get the best of both worlds
by being able to ftp the CDROM bits for "free". And those of
us on c.o.l who have opinions galore but lack either the time
or the talent to contribute anything else, can get to work
on wrangling over the LID.
To summarize: issuing releases is an incredible drag. Especially
the ones after the first. The problems are caused by the requirements
of paying customers. Thus, I think the burden is best left to
those who have said customers. Let them also take charge of when new
releases are required, release nomenclature, packaging, etc.
Since Linux is freely distributable, we can "steal" their work
right backs for our purposes.
--
David Boyce d...@world.std.com 617-576-1540
Newsgroups: comp.os.linux
Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!danielce
From: danie...@mullian.ee.mu.OZ.AU (Daniel AMP Carosone)
Subject: Linux Standards (was: Stabilizing Linux)
Message-ID: <danielce.713926038@munagin>
Followup-To: gnu.misc.discuss
Sender: n...@cs.mu.OZ.AU
Organization: Computer Science, University of Melbourne, Australia
References: <1992Aug6.125441.22427@klaava.Helsinki.FI> <Bt1u3u.3zv@world.std.com>
Date: Sun, 16 Aug 1992 00:47:18 GMT
Lines: 84
+------(David Boyce)----------------------------------------
|
| Anyway, this seems, to me at least, to solve everyone's problems:
| the hackers can go on hacking and acquiring new software as quickly
| as they can ftp it, the "users" buy the CDROM or floppies. The
| "Keep Linux FREE!!!!!" contingent will sleep better at night knowing
| those commercial vendors are doing some work for their money,
| the vendors get exclusive access to the non-internet community,
| and those who have ftp access get the best of both worlds
| by being able to ftp the CDROM bits for "free". And those of
| us on c.o.l who have opinions galore but lack either the time
| or the talent to contribute anything else, can get to work
| on wrangling over the LID.
|
Thankyou. This is an excellent suggestion. And well put.
Even ignoring the factions and parties building releases, it is an
excellent idea to have a standards document to which releases must
conform rather than a release to which the standard must conform. I
have not been following the discussions on the Linux Standards list, I
wonder if the current efforts there are this ambitious? This is surely
the best place to direct followup conversation on this matter.
+------(David Boyce)----------------------------------------
|
| To summarize: issuing releases is an incredible drag. Especially
| the ones after the first. The problems are caused by the requirements
| of paying customers. Thus, I think the burden is best left to
| those who have said customers. Let them also take charge of when new
| releases are required, release nomenclature, packaging, etc.
| Since Linux is freely distributable, we can "steal" their work
| right backs for our purposes.
|
Cygnus seems to be doing quite well. And the world is doing quite well
out of Cygnus, in pretty much exactly the way you describe above.
Anyone who has built gcc, gdb, libg++, or any of the number of other
GNU programs that come with the Cygnus `configure' script can attest
to this (especially if you are on a known system).
All of this is not only within the limits of what is allowed by the
GNU Copyleft -- it is sound proof of one of the basic tenets of the
philosophy behind it: You don't need to force people into restrictions
on how they use software (or any information) in order to make money
from it.
What many people miss is that GNU is an alternative economy for the
software industry, not an alternative to the software industry.
I've actually been wondering whether or when Cygnus will pick up
Linux, perhaps they're working on it, perhaps they are waiting for
some more development, quite possibly they are too busy with the
wealth of other Free Software. They are certainly aware of Linux, and
must be considering taking it up. Commercially-minded people take
note.
Followups on this matter, as always, to gnu.misc.discuss. The headers
for this article point there.
One other point: In all this discussion, we have been referring to the
aims and rules of the GNU copyleft. While the license conditions for
Linux are the same as for the GNU copyleft, they have not always been.
The original license conditions forbade any money to change hands over
Linux. (perhaps in those early days Linus thought it wasn't worth the
money? :-) And copyright is held by Linus, not by the FSF. We should
abide by the aims of The Grand Wizard Torvalds, out of respect and
gratitute if for none of the other good reasons.
May one presume that if Linus has any objections to what someone is
doing with his work (and, by proxy, the work others have contributed)
he will make them known and clear? If he does have some objection, and
that is not heeded, he is free to change the terms of the License for
later releases if he deems it necessary.
Followups on this issue are pointless, unless Linus wishes to make
some statement.
_______________________________________________________________________________
Daniel AMP Carosone. email: danie...@ee.mu.oz.au snail: 37 Wandin Road
Computer/Software Eng, IRC: Waftam Camberwell 3124
University of Melbourne. Vox: +61 3 882 8910 Australia
Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
From: torva...@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Linux Standards (was: Stabilizing Linux)
Message-ID: <1992Aug16.073340.11418@klaava.Helsinki.FI>
Date: 16 Aug 92 07:33:40 GMT
References: <1992Aug6.125441.22427@klaava.Helsinki.FI> <Bt1u3u.3zv@world.std.com> <danielce.713926038@munagin>
Organization: University of Helsinki
Lines: 43
In article <danielce.713926038@munagin> danie...@mullian.ee.mu.OZ.AU (Daniel AMP Carosone) writes:
>
>May one presume that if Linus has any objections to what someone is
>doing with his work (and, by proxy, the work others have contributed)
>he will make them known and clear? If he does have some objection, and
>that is not heeded, he is free to change the terms of the License for
>later releases if he deems it necessary.
Well, I've answered this by email and earlier in the newsgroup, but I
guess it won't hurt to say it once more: I have no objection whatsoever
to any commercial use of linux that abides by the copyright. Not only
because I wouldn't have a legal leg to stand on, but simply because
there isn't any point in it. I'm not making any money off linux, so I
cannot lose anything by letting others do it - it's not as if they were
competing in the same market-place.
Also, if people sell linux, it certainly won't hurt the "free" status of
linux: it won't make all the free releases go away. So there isn't
really anything to get excited about - a commersial linux won't hurt the
linux users in the slightest, and might make linux available to people
that otherwise didn't have the possibility of getting it.
The earliest versions of linux had a more restrictive copyright: any
commercial activity was prohibited by it. That was mostly due to (a) an
overreaction to the price I had to pay for minix ($169 may not be much,
but it's still more than I can afford: I'm still paying monthly
installments on my machine) and (b) protection: linux wasn't well-known
then, and I didn't think it was ready for commercial use anyway.
(a) is silly, (b) went away with 0.12 - the copyright essentially
changed when I got the first query about selling linux (with just a
small delay to make sure there were no objections from people that had
made patches available. There weren't).
And as to the price: it doesn't really matter. If somebody wants to
make linux availabe for $ 995.95 ("special price just for you, amigo"),
I'd certainly be interested to hear how well it sells, but it won't
bother me. And bickering over whether $60 is too much is silly: people
buy it if they feel it's worth it. Actually, a nicely priced product
may sell better than a cheap one: it's illogical, but some people feel
that a product cannot be very good if it's cheap.
Linus
Newsgroups: comp.os.linux
Path: sparky!uunet!munnari.oz.au!trlluna!titan!medici!mcf
From: m...@medici.trl.OZ.AU (Michael Flower)
Subject: Re: Linux Standards (was: Stabilizing Linux)
Message-ID: <1992Aug18.070709.16015@trl.oz.au>
Sender: r...@trl.oz.au (System PRIVILEGED Account)
Organization: Telecom Research Labs, Melbourne, Australia
References: <1992Aug16.073340.11418@klaava.Helsinki.FI>
Date: Tue, 18 Aug 1992 07:07:09 GMT
Lines: 20
From article <1992Aug16.073340.11...@klaava.Helsinki.FI>, by torva...@klaava.Helsinki.FI (Linus Benedict Torvalds):
> ......
> overreaction to the price I had to pay for minix ($169 may not be much,
> but it's still more than I can afford: I'm still paying monthly
> installments on my machine) and (b) protection: linux wasn't well-known
> .....
Ok guys, what say someone organises a whip around to pay off this beast.
It seems to me that there are an awful lot of people around that are
using Linux, and getting a lot of fun and interest out of it, and for a
small trouble we could pay off the machine, and allow Linus's mind
fuller scope to spend on the problem in hand rather than the monthly payments
on the box. Perhaps as a gesture of saying 'thanx'. I realise that there are many
other people that also contribute, but after all, Linus started this game.
Michael Flower
Artificial Intelligence Systems Email: m.flo...@trl.oz.au
Telecom Research Laboratories Voice: +61 3 541 6179
Melbourne, AUSTRALIA Fax: +61 3 543 8863
Newsgroups: comp.os.linux
Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!sdd.hp.com!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!casbah.acns.nwu.edu!hpa
From: h...@casbah.acns.nwu.edu (H. Peter Anvin N9ITP)
Subject: Re: Paying off Linus' PC (was: Linux Standards)
Message-ID: <1992Aug19.162616.3357@news.acns.nwu.edu>
Sender: use...@news.acns.nwu.edu (Usenet on news.acns)
Reply-To: h...@nwu.edu (H. Peter Anvin)
Organization: You must be kidding!
References: <1992Aug16.073340.11418@klaava.Helsinki.FI> <1992Aug18.070709.16015@trl.oz.au>
Date: Wed, 19 Aug 1992 16:26:16 GMT
Lines: 49
In article <1992Aug18.070709.16...@trl.oz.au> of comp.os.linux,
m...@medici.trl.OZ.AU (Michael Flower) writes:
> From article <1992Aug16.073340.11...@klaava.Helsinki.FI>, by torva...@klaava.Helsinki.FI (Linus Benedict Torvalds):
>
> > ......
> > overreaction to the price I had to pay for minix ($169 may not be much,
> > but it's still more than I can afford: I'm still paying monthly
> > installments on my machine) and (b) protection: linux wasn't well-known
> > .....
>
> Ok guys, what say someone organises a whip around to pay off this beast.
> It seems to me that there are an awful lot of people around that are
> using Linux, and getting a lot of fun and interest out of it, and for a
> small trouble we could pay off the machine, and allow Linus's mind
> fuller scope to spend on the problem in hand rather than the monthly payments
> on the box. Perhaps as a gesture of saying 'thanx'. I realise that there
> are many
> other people that also contribute, but after all, Linus started this game.
>
Okay people, don't you think this is fair?
Since I have fixed my address problem, I hereby volunteer to collect money
from Linuxers in the USA. Send checks to:
Linus collection
c/o Peter Anvin
EECS department
Tech Institute rm 2657
2145 Sheridan Road
Evanston, IL 60208-3118
Please make checks out to me (Peter Anvin) so I can transfer them. I
*will* transfer all money I get, minus bank transfer charges, to Linus, no
matter how much or how little I get. If there is anything over when he has
paid off his 'puter I suggest he buys himself some nice hardware to soup up
his system, or just have some fun.
Also, please put your e-mail address on the checks so I can send you a
confirmation. Once I have sent the money I'll post a breakdown here so
everyone can check that I have sent the right amount.
/hpa
--
INTERNET: h...@nwu.edu TALK: h...@casbah.acns.nwu.edu
BITNET: HPA@NUACC IBMNET: 16334@IBMX400
HAM RADIO: N9ITP NeXTMAIL: h...@lenny.acns.nwu.edu
This is a test of the emergency USENET system.
Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
From: torva...@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Paying off Linus' PC (was: Linux Standards)
Message-ID: <1992Aug21.065950.8463@klaava.Helsinki.FI>
Date: 21 Aug 92 06:59:50 GMT
References: <1992Aug16.073340.11418@klaava.Helsinki.FI> <1992Aug18.070709.16015@trl.oz.au> <1992Aug19.162616.3357@news.acns.nwu.edu>
Organization: University of Helsinki
Lines: 39
I hate to follow up to a thread that might actually be profitable for
me, but I felt I had to clarify a few points - especially if there are
new linux users out there reading the thread.
If people feel they want to send me money (indirectly or directly) as a
token of appreciation, that's very much ok by me (surprise, surprise),
but a token of appreciation is all it is going to be. Yes, I'll be able
to pay off my machine more quickly or even get a bigger harddisk or
whatever, but sending me money won't get you any better service - this
is definitely not a "registration fee" or anything like that.
The above just means that (a) even if you don't send any money I won't
mind in the least that you use linux, and when I answer questions etc I
won't check if you sent me money first. And (b) even if you sent me
money, any features you propose/want will get no extra priority. In
fact, trying to make me feel guilty over money ("after all, I paid you
$20 for this") is likely to get the exact opposite reaction.
Finally, I won't give any guarantees of what the money will be used for:
if you add some kind of message giving preferences ("use it to pay off
your computer"), I'll naturally follow them within reasonable limits,
but I might just use them to pay off my "beer&pizza"-debts (*), which
might be against your religion or whatever.
So, the result of all this? If somebody thought I was despairing about
my monthly payments, that's not true, and frankly, I'll get the computer
paid off even if nobody sends me a cent, even if it might take me a bit
longer. Also, there are others that have contributed to linux, and I
won't give them anything (not because I'm a selfish bastard, but simply
due to practical reasons).
If any of the above reasons made you decide I don't really need the
money, I just ask you not to mail me about it. I /don't/ want to know
about any money I might have gotten, but didn't.
Linus
(*) Yes, beer is reasonably costly over here in Finland, but no, my
debts aren't really that big. Quite small, in fact, considering..
Newsgroups: comp.os.linux
Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!casbah.acns.nwu.edu!hpa
From: h...@casbah.acns.nwu.edu (H. Peter Anvin N9ITP)
Subject: Re: Paying off Linus' PC (was: Linux Standards)
Message-ID: <1992Aug21.164837.25745@news.acns.nwu.edu>
Sender: use...@news.acns.nwu.edu (Usenet on news.acns)
Reply-To: h...@nwu.edu (H. Peter Anvin)
Organization: You must be kidding!
References: <1992Aug18.070709.16015@trl.oz.au> <1992Aug19.162616.3357@news.acns.nwu.edu> <1992Aug21.065950.8463@klaava.Helsinki.FI>
Date: Fri, 21 Aug 1992 16:48:37 GMT
Lines: 40
In article <1992Aug21.065950.8...@klaava.Helsinki.FI> of comp.os.linux,
torva...@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
> I hate to follow up to a thread that might actually be profitable for
> me, but I felt I had to clarify a few points - especially if there are
> new linux users out there reading the thread.
>
> If people feel they want to send me money (indirectly or directly) as a
> token of appreciation, that's very much ok by me (surprise, surprise),
> but a token of appreciation is all it is going to be. Yes, I'll be able
> to pay off my machine more quickly or even get a bigger harddisk or
> whatever, but sending me money won't get you any better service - this
> is definitely not a "registration fee" or anything like that.
>
> The above just means that (a) even if you don't send any money I won't
> mind in the least that you use linux, and when I answer questions etc I
> won't check if you sent me money first. And (b) even if you sent me
> money, any features you propose/want will get no extra priority. In
> fact, trying to make me feel guilty over money ("after all, I paid you
> $20 for this") is likely to get the exact opposite reaction.
>
> Finally, I won't give any guarantees of what the money will be used for:
> if you add some kind of message giving preferences ("use it to pay off
> your computer"), I'll naturally follow them within reasonable limits,
> but I might just use them to pay off my "beer&pizza"-debts (*), which
> might be against your religion or whatever.
I am *glad* to hear this... and as I said before, I am *not* going to ask
*at all* what the money is being used for. Still, being a student and
being from Scandinavia I know it is not that easy all the time to stay
liquid. In short, DON'T SEND MONEY IF YOU EXPECT ANYTHING IN RETURN. I
would refuse to have anything to do with this if Linus were to start
treating Linux like shareware.
/hpa
--
INTERNET: h...@nwu.edu TALK: h...@casbah.acns.nwu.edu
BITNET: HPA@NUACC IBMNET: 16334@IBMX400
HAM RADIO: N9ITP NeXTMAIL: h...@lenny.acns.nwu.edu
while ( 1 ) ; cp /dev/zero /dev/null & end