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)
2.2.x is the current stable tree. (all 2.n.x kernels are stable (where n is an odd integer)) with the advent of the 2.3.x tree, expect to see NEW unstable (beta) releases of the kernel.
Actually ive seen newbies confused about the kernel version differances and think they HAVE to upgrade. Just like all the people who think they HAVE to upgrade each time a new stable release comes out, just because it came out. Another thing,... I dont think the original poster of this thread put things right.. (or rather,... politely). A little bit reworded and a small explenation of WHY these development kernels are called development kernels and WHY some times there unstable helps a lot, otherwise you get a good deal of press from either ignorant or just anti linux writers claiming how linux changes so much and how there are allways these broken releases and etc etc... Well given the fact it was a few years from 2.0 to 2.2 I would have to say linux is one of the more stable platforms out there. (and I dont mean this considering its ability NOT to crash... but rather,.. the feature set does not radically change that often,... and when it does change the changes will stay around for a good time before moving else where.. most people (in the press...) cant grasp that)
:)
:) (THAT and I like working on code so.... :)
:)
On one of my (VERY NON PRODUCTION!!! Its just a home/test server that I dont update much anymore...) is still running one of the more stable 2.1 devel kernels... and it has not been down a single time after I upgraded,.. mind you this was also when I moved the server from 2.0... I was propairing for the changes that would need to take place when I would need to I migrate my other stuff (more production stuff) to the actuall 2.2 release..
still kickin
BTW, on THIS machine I allways have the lastest devel kernel (and lack of devel kernel I have the latest stable).. But I guess its my nature,.. I love bleading edge over leading edge.. because bleading edge you tend to lose a little blood now and then and things get a little exciting
Anyhow Im tired, Ive gone WAY beond the point of this email into rambles,.. I hope the point was understood hahaha
- 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.Perhaps major, _important_ kernel updates could (should?) still be announced, though.
- A.P.
--
"One World, One Web, One Program" - Microsoft Promotional Ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
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.
I've got one machine running 2.3.0 now, and two more that I'm planning on having on 2.2.8 before the day is up. The difference between them is that the 2.3.0 machine is my guinea pig box, and it's going to be upgraded to 2.3.1 when it comes out and follow the dev tree. The 2.2.8 machines will be upgraded to 2.2.9 and stay on the stable tree until 2.4/3.0, whichever comes first. Yeah, the only difference is the version number, but having the wrong version number will make a difference when it comes to getting the next patch applied cleanly.
And the guy who started this has done the rest of us a favor by installing 2.3.0. He found a bug (or maybe it's just a misfeature) where the version number change causes certain modules not to work. Would you rather he'd stuck with 2.2.8 and the bug had gone undiscovered until he installed 2.4.0 a year down the road, expecting something with all the bugs worked out, and discovered that his sound didn't work?
Yeah, I know, I'm sure someone else would have discovered something that blatant long before 2.4 made it out the door, but the point remains... people using dev kernels is what makes the bazaar model of development work. "Release early, release often," doesn't do much if only a select few are actually _using_ those releases.
If you want cathedral-development free-source Unix, you know where to find *BSD...
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 between 2.2.8 and 2.3.0 is what will happen to the 2 trees in the future.
2.2.x is a stable series - Only bug fixes wil happen.
2.3.x is experimental - new features will start to appear.
This is how it's always been...
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.
Check out the Linux wishlist. AFAIK, this is kind of a compilation of stuff taken from various Linux newsgroups and mailing lists about features people would like. Note that some of the things listed have already been implemented, and most things listed won't be implemented in the near future (i.e. 2.3) if at all.
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
--
Welcome to the differences between the Cathedral and the Bazaar.
Gordon
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?
Starting development on the 2.3.x kernel marks a new era. Linux is here, now people want to see where it will go. Will SMP get major attention as some have already suggested? Will distributions like Red Hat make major money off OSS or will they destroy it? Will games make inroads into Linux as it matures?
We'll see.
In fact, we'll make it happen.
Bleh!
I use FreeBSD and Linux at work, Linux at home. For a server OS where upgrades can break existing code, then FreeBSD makes sense. Linux as a workstation OS is nirvana - utter perfection for the technically competent. However, the upgrade path for FreeBSD is *far* rockier than Linux. With Linux, I only ever had problems going from libc5 to libc6 (aka glibc2). I was lucky enough to miss out on the a.out to ELF fun. But going from FreeBSD 2.1.x to 2.2.x or even worse, 3.x ... no thanks. Most sysadmins who *know* what they're talking about (and aren't just FreeBSD bigots), will agree that FreeBSD has more than its share of upgrade nightmares.
Chris Wareham
Well, according to 'finger @ftp.kernel.org' there is already a 2.3.1-pre1 patch... Perhaps it has more dangerous changes than the 2.3.0 one. ;)
If for no other reason, I hope that posts like this continue than to spawn discussions like this one has. The relative merits of the Linux kernel process, for example, are hashed and rehashed, and only in an open, ongoing forum like this (rather than a bland "new kernel" read-only message) can possible improvements to the procedure be offered.
Nothing worth doing is worth doing today.
"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.
And if BSD has kernel upgrades..they're posted here. If MacOS has kernel upgrades..they're posted here. If, don't hold your breath, Windows ever release 2000, it *will* be posted here.
Stop getting your panties in a bunch.
does not lie within the kernel so much as withing the apps. Look at the ZD tests... they consistently complain that there are very few apps that use threading, so the multiple cpus are actually getting used. The kernel handles threads fairly well, but until apps start handing the kernel threads to be spread among the processors, it doesn't matter how efficient the kernel is.
He said, "You'll be able to tell your grandchildren that you helped assemble the first NT supercomputer," and I cringed.
Only the version number has changed from 2.2.8 to 2.3.0.
This has got to be the funniest thing I've read today. Change the only thing different about 2.3.0 back to what it was in 2.2.8. I'm sure this information will be useful in the very near future, but you have to admit it sounds pretty pointless :)
Multiple processes is the way to go much of the time, but threads have an advantage when it comes to multitasking within a process. Threads make it easy to share data structures, and there is less overhead in creating a thread than in creating a process (a process needs a copy of the environment, a thread just shares an existing one). Of course there are other differences which I won't go into.
However, it would be quite correct to say that the problem with threading isn't the kernel, its the applications. Most applications just aren't written to use multiple threads *or* multiple processes, but thats not the kernels fault, but the applications. Most developers just don't want to deal with synchronization issues and stick with a sequential design model.
The real work that needs to be done in the kernel as far as SMP is concerned is scalability. The 2.2.x kernels do well up to four CPU's (judging from what I've heard, I only run two myself), but don't scale well beyond that. Contrast this with Solaris, which scales well to 64 CPU's. And I think Irix does as well or better than Solaris. If Linux wants to compete on high end machines, it will need to scale well with as many CPU's as possible without hurting single-CPU performance.
The current Linux solution is to use several midsize computers in a cluster instead of one large computer. This model has its merits, but there are problems as well. For example, Beowulf doesn't have fault tolerence. And there are a lot of people who want to use Linux on a single high-end system. (And I would just love to see what Linux could do with a Beowulf cluster of machines with 64 CPU's!)
Lets not forget that most recent benchmarks comparing Linux to other OS's use high end machines. Many people see that as a bias toward other OS's because it is comparing their strengths with Linux's weakness's, which may be true. But it also points out a valid weakness in Linux. Hopefully the 2.3 kernels will start investigating better use of high-end hardware (not only SMP, but also things like RAID support).
What we need is a way to filter out news about kernel upgrades; everybody happy then?
De lyckliga slavarna är frihetens bittraste fiender, legalisera!!!
Anyone have an idea what is on the todo list for the 2.3.x series and eventually 2.4?
In fact, the 2.3.X series is a development series. It is really intended to be used to test new additions to the kernel so that eventually a new 2.4.0 stable kernel can be released, which may be a ways down the road yet (remember the amount of time from 2.0.X to 2.2.X?)
I would discourage people from upgrading to the 2.3.X series until it has reached a stable point.
-- UOZaphod
"The unicode stuff in the latest version is working fabulously well. My russian mafia friends are ecstatic."
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."
After the Mindcraft and ZD tests, I have a feeling that SMP is going to get most of the attention for a while. M$ really blew it when they pointed out that Linux needed more work in this area. By the time the W2k bug is released Linux should be close to (If not ahead of) NT in SMP.
Quemadmodum gladius neminem occidit, occidentis telum est
Why would sysadmins want to install development kernels on production systems? I know that the 2.2.x series has been progressing a bit quickly recently, but it will settle down now a bit.
What happens in the BSD camp if a major flaw is released? Do people have to wait for the next quarter? Of course not, that would be ridiculous.
The work on Linux is just a little less opaque. With Linux, sysadmins get to review the changelogs, and upgrade if it would improve performance/reliability/etc. Compare that to FreeBSD, where the choice is made for them. I know which I prefer.