Slashdot Mirror
Linux 2.3.0
Beret was the
first to report that the new 2.3 directory that was appearing
on the kernel mirrors now contains what looks suspiciously
like a 2.3 kernel. Also includes patches from 2.2.8 if you
want 'em. No word on what is new.
← Back to Stories (view on slashdot.org)
- wait_queue changes: affect mutexes,semaphores,locks, etc.
- also a reworking of spinlock architecture.
- Netwinder support (and misc ARM updates)
- Framebuffer updates (ARM, VGA)
- an ADFS filesystem bugfix?
- ext2fs updates for better NFS support? (seems to involve mostly field renaming at this point)
- a one-line fix for quake protocol masquerading.
That's it, folks. Nothing earth-shaking yet, although the wait_queue reworking touches quite a lot of code.I really am posting this to deter people (especially "newbies") from following the 2.3.x series. MOST of us will not find following the devel series to be of any use. The devel series can be very unstable and chaotic. For example, with 2.1.44, file system corruption was possible. The only people I see with a need to follow this are kernel developers, those people whose only hope for hardware support in the new kernel, and, of course, the thrillseekers and bleeding-edgers.
But, to reiterate, MOST of us do not want to following the devel kernel.
Witness (most likely) the only time in Linux's history when the kernel patch is smaller than the PGP signature made for it!
:^)
patch-2.2.8-to-2.3.0.gz = 268 bytes
patch-2.2.8-to-2.3.0.gz.sign = 344 bytes
I know, the patch is compressed -- but who cares, right?
Slashdot's first reaction to VMware
The only difference is the version number :
-PATCHLEVEL = 2
-SUBLEVEL = 8
+PATCHLEVEL = 3
+SUBLEVEL = 0
Hopefully lots of interesting new stuff will come out in 2.3.1.
Some people have mentioned that Dev kernels should not be announced here because we shouldn't be encouraging newbies to download/use them. It's true: the people who would really care about the Dev kernels will find that information elsewhere. So I don't think that 2.3.1 or higher should be announced here on Slashdot.
However, I find it very newsworthy that the 2.3 series was *started*. This is something that I have been awaiting eagerly. I wish that a list of proposed features had been posted as well, but I'm not even sure if such a document exists.
Perhaps NFS is a priority? Maybe some more SMP work? I can't wait to see...
--Lenny
//"You can't prove anything about a program written in C or FORTRAN.
It's really just Peek and Poke with some syntactic sugar."
From my mirror ( ftp://ftp1.us.kernel.org/pub/linux/: := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/)
v2.3$ zcat patch-2.2.8-to-2.3.0.gz
diff -u --recursive --new-file v2.2.8/linux/Makefile linux/Makefile
--- v2.2.8/linux/Makefile Tue May 11 13:10:27 1999
+++ linux/Makefile Tue May 11 13:03:06 1999
@@ -1,6 +1,6 @@
VERSION = 2
-PATCHLEVEL = 2
-SUBLEVEL = 8
+PATCHLEVEL = 3
+SUBLEVEL = 0
EXTRAVERSION =
ARCH
--
Well, the first and most important one I can think of is ALSA replacing OSS as the soundsystem. FINALLY some decent, modular multimedia and MIDI functionality in Linux! :)
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
"more sane in its release schedule" assumes some universal definition of sanity. If I am running a Linux box on which my company's life depends (which I frequently have been and will be again soon), I don't want a quarterly update to fix the DoS that was announced two hours ago. I want it now. If someone has just finished a driver for a new device I've been needing access to, and it gets rolled into the kernel, I want that now. I don't want to sit on my ass for June to roll around (or whatever).
The "release early, release often" philosophy has served Linux well -- I hardly see it as a "weakness" when people are presented with the earliest possible opportunity to hammer out bugs, make their own improvements, and contribute to general stability. I don't know the FreeBSD team's particular beliefs on this matter but I hardly imagine that they're possessed of enough hubris to believe that they can spot bugs in their own kernel releases better than anybody else for a whole three months.
Sysadmins know, and have known for years, what the "stable checkpoints" in the kernel are -- 1.2.13 was the number everyone knew back when I first set up a Linux-based ISP, and it's become 2.0.3x since then.
As far as "easy to upgrade", I have yet to see an easier upgrade mechanism than autorpm and apt. If you choose to include kernel updates in either of these systems, it's a no-brainer to get the latest "pronounced stable" kernel from your particular Linux distributor without the need to compile everything for each box you run.
While I hope this thread will not degenerate into "Linux sucks, BSD rules" (or vice versa), I would like to point out that despite your personal opposition to the Linux kernel release philosophy, it has garnered support across the world and across the years. It works very well for a lot of people, and I hope it doesn't change any time soon.
Nothing worth doing is worth doing today.
2.0.X - stable series
2.1.X - development series
2.2.X - stable series
2.3.X - development series
2.4.X (future) - stable series
It is very simple to understand. 2.3.0 is a snapshot of 2.2.8. The purpose is to provide a starting point for a kernel development series.
A development series is used to test more drastic changes to the kernel (ones which would never be accepted into a stable series). In fact, the only changes usually accepted into a stable series are bug fixes.
When a development series reaches a stable condition, a snapshot is taken to begin a new even numbered series (i.e. 2.4.X).
I hope that clears things up for people.
-- UOZaphod
"The unicode stuff in the latest version is working fabulously well. My russian mafia friends are ecstatic."