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
"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.