[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ale] Fwd: Final pre-2.0.31.. Expect this to be same as real 2.0.31
- Subject: [ale] Fwd: Final pre-2.0.31.. Expect this to be same as real 2.0.31
- From: catbert at ding.mindspring.com (William Young)
- Date: Sun, 7 Sep 1997 19:11:19 -0400 (EDT)
This is a pre-release of 2.0.31. There were a nuber of problems with
2.0.30. I applied Dave Miller's final patch an noticed a couple of things
1) mm/mmap.c didn't compile. Replaced it with mmap.c from 2.029 and
everything was cool.
2) What happened to include/linux/version.h?
William Young catbert at mindspring.com|
There is a general social trend in English-speaking countries (and most
likely elsewhere) to treat technically-educated people as the social
inferiors of non-technically educated people. This is a terrible ill
affecting our society --Bruce Perens
On Sun, 7 Sep 1997, Tucker Balch wrote:
> For those who don't know (like me), why are people hacking on 2.0.31
> when 2.1.x has been released? I thought the kernel version numbers
> increased monotonically.
> Chris Ricker said this:
> > Something from Linus I thought might be of interest. Those of you who
> > want to help out can get linux-pre-2.0.31-9 from:
> > ftp://ftp.kernel.org/pub/linux/kernel/testing/linux-pre-2.0.31-9.tar.gz
> > (full source)
> > ftp://ftp.kernel.org/pub/linux/kernel/testing/pre-patch-2.0.31-9.gz
> > (patch against standard 2.0.30 tree).
> > If you've got a few minutes, download it, compile it, reboot, and pound
> > on it a bit to make sure it's stable on your particular hardware and
> > with your particular programs.
> > later,
> > chris
> > ------ Forwarded message ------>>
> > From: Linus Torvalds <torvalds at transmeta.com>
> > Subject: Final pre-2.0.31.. Expect this to be same as real 2.0.31
> > Date: Sat, 6 Sep 1997 09:55:21 -0700 (PDT)
> > Hi all and sundry,
> > I just made a final version of my pre-2.0.31 series available on
> > ftp.kernel.orn under /pub/linux/kernel/testing.
> > The kernel is available both as diffs against a clean 2.0.30, and as a
> > full kernel source (to make it easier for people who are uncomfortable
> > with patches to test it out).
> > I know some people have been hoping to have diffs between different
> > pre-patches, and it would make sense considering the huge size of the
> > patches, but I've been too lazy. If somebody with a fast connection wants
> > to make such diffs to help others (and put them up on some web/ftp site),
> > that would be appreciated.
> > Note that "final" means just that: I'm not interested in any reports
> > except for major problems. Major problems include something not working
> > (the file locking has the backwards compatibility stuff as of -8), or bad
> > kernel crashes. It definitely does not include feature requests.
> > I expect this kernel to work, and if all goes well I'll just rename the
> > files and move them to the 2.0 directory on the ftp-sites in a few days.
> > To encourage people to try out this final pre-version, I also promise that
> > _if_ there are changes between this version and the real 2.0.31 I'll make
> > those changes available as patches between the two, so you won't have to
> > download the full 2.0.31 whatever happens.
> > Thanks to everybody who have made 2.0.31 a possibility, especially the
> > guys at Suse who have been very helpful indeed in finding problems and
> > sending patches for them. I can't say that 2.0.31 has been a pleasure to
> > put together, but it seems to have worked out. It wouldn't have, without
> > the help of people who came through.
> > And finally: please _don't_ refrain from testing this pre-kernel on the
> > assumption that "the real 2.0.31 will be the same anyway, so why should I
> > bother with this?". Yes, I do hope that 2.0.31 will be the same, but if
> > there are problems you have only yourself to blame if you didn't report
> > them before the real release.
> > In fact, I'd ask even people who are running 2.1.x kernels to take the
> > time to try out this kernel if you can, if only to boot it up for 15
> > minutes and torturing it a bit. With all the work people have put into
> > this (not least of all David, thanks), this kernel deserves to be
> > tortured. A lot.
> > Give it Hell,
> > Linus "tortures small furry
> > kernels for the fun of it" Torvalds
> Tucker Balch home (404) 874-9129
> Mobile Robot Laboratory, Georgia Tech office (404) 894-9311
> http://www.cc.gatech.edu/~tucker . fax (404) 894-9846