On 31 Oct 2001, Michael Peddemors wrote:
>
> Lets' let this testing cycle go a little longer before making any
> changes.. Let developers catch up..
My not-so-cunning plan is actually to try to figure out the big problems
now, then release a reasonable 2.4.14, and then just stop for a while,
refusing to take new features.
Then, 2.4.15 would be the point where I start 2.5.x, and where Alan gets
to do whatever he wants to do with 2.4.x. Including, of course, just
reverting all my and Andrea's VM changes;)
I'm personally convinced that my tree does the right thing VM-wise, but
Alan _will_ be the maintainer, and I'm not going to butt in on his
decisions. The last thing I want to be is a micromanaging pointy-haired
boss.
(2.5.x will obviously use the new VM regardless, and I actually believe
that the new VM simply is better. I think that Alan will see the light
eventually, but at the same time I clearly admit that Alan was right on a
stability front for the last month or two;)
> My own kernel patches I had to stop because I couldn't keep up.... Can
> we go a full month with you just hitting us over the head with a bat
> yelling 'test, dammit, test', until this is tested fully before
> releasing another production release?
I think we're really close.
[ I'd actually like to thank Gary Sandine from laclinux.com who made the
"Ultimate Linux Box" for an article by Eric Raymond for Linux Journal.
They sent me one too, and the 2GB box made it easier to test some real
highmem loads. This has given me additional load environments to test,
and made me able to see some of the problems people reported.. ]
But I do want to make a real 2.4.14, not just another "final" pre-kernel,
and let that be the base for a reasonably orderly switch-over at 2.4.15
(ie I'd still release 2.4.15, everything from then on is Alan).
What happened to the report (see this Slashdot story from Nov. 2 [slashdot.org]) that Alan Cox
would be replaced by Marcelo Tosatti as the
stable release coordinator?
The latest Kernel Traffic suggests that Alan is considering using the AA VM anyway [zork.net]. Looks like Rik's stuff is getting dumped entirely. That is unless they can figure out how to parameterize VM's and make it a compile time option as they've been talking about.
On the contrary they are talking about doing precisely this. It would not be possible under the current build process but kbuild for 2.5 is redesigned in such a way that it supposedly does this anyway.
No, I think you're missing the point. "Version Niceness" can't have seemingly arbitrary numbers in it - that's why Microsoft ditched their scheme after Windows 3.1.
I think that 2.4.XP is a much nicer version number.
So Microsoft is now in league with those phreaking 2600 guys? I always knew....
2600 is for 2600 kHz, the carrier wave for the sounds that payphones used to signal the home office that someone dropped in a shekel or the call. All the kool kids had electronics that could make that tone and bingo, free calls. Was called phreaking at one time. Now the kids on to bigger and better things, like finding holes in telnetd.
Ack, I wouldn't try running the latest Linux distros on older hardware, as the latest distros are obviously "optimized" for newer hardware. Red Hat 6 should run fine, although there are a number of different paths you could take. I've been using Debian, and it installs on everything from a 386 to an Itanium, and runs smoothly. It's a bit harder to install, but then installing and upgrading software on it is a piece of cake later on, using apt-get.
Another route you could take would be to try FreeBSD, as even the newest versions still run very nicely on old hardware. I recently installed FreeBSD 4.4 on a P75 with 16 MB of RAM, and it has been chugging along, happily playing MP3s via NFS in our living room. I can even be compiling software while playing MP3s, and it plays flawlessly.
The issue you mentioned about Tuxracer going so slow is because the S3 Trio64+ doesn't have OpenGL hardware acceleration (to my knowledge, at least), which means that Tuxracer is going to do all of the OpenGL via software. This equates to incredibly low frame rates, until a better video card is used. Your best bet, if you're really looking into running OpenGL applications, would be 1) buy a better video card, 2) install XFree86 4.1.0 (see xfree86.org), and 3) enjoy.
I'm not sure about the SoundIII drivers you are asking about -- search google for "SoundIII and Linux" and see what comes up.
Does anyone have a link to the changelog? I'm interested to see if they've fixed any of the bugs present in 2.4.11a and previous.
I'd also be interested to know if they've fixed the Integer floating poing RAND bug that can occur on some older MMX Athlons. I've got a friend who has one of the affected processors, and he's been dying to upgrade, but can't because his tarball segfaults on compile.
Also, what's the status of that TCP/IP stack optimization that Theo De Raadt has been working on? Has this been incorporated into the new kernel? I'm getting sick of compiling my winipcfg.dll file every time I install a new kernel. Hopefully the new winmodem streaming support will take care of this problem. It shouldn't have taken as long as it already has, considering DeRaadt switched from C to VisualBasic for his new code. Any info would be helpful...
Here is the change log [kernel.org] Ironicly for a mensa memember you could have at least read the summary that included the link. What is your offical IQ anyway?
The last pre seems to be OK, but Linus is still "working" on that. Did anyone know that the VM bugs are fixed? I don't see that in the change logs after pre8...
There's so many interesting userspace apps slashdot could write about. Unless the kernel has some new feature or fixes a major secutiy hole, I personally don't see how interesting each minor release is. Slashdot isn't freshmeat.
If/. is going to write about apps, why not focus on the new and clever ones - like
* MPlayer allowing us to play WMVs under out OS of choice
* Xine, finally maturing into a solid high quality DVD player
* Partimage providng a useful and open source disk imaging system
* Ximian's setup tools beta making an X config tool that doesn't suck
OI don't have anything against the kernel, but we all know there's always goiung to be a new kernel every couple of weeks. There's so many interesting userspace Open Source projects we could be hearing about.
After all, isn't the point of an OS to run *apps*?
I don't read freshmeat. I search for things there. It isn't something I really care to see everyday.
you dont have to, you can subscribe to the linux kernel entry on freshmeat and recieve an email when a new version is out.
I don't subscribe to the kernel announce list. I don't care to read a bunch of garbage everday.
so release information is not garbage when its on slashdot but it is garbage when it comes from the actual source?
If they tell us when the release of XP is, or when the release of a new variant of Code Red or the like is out, why not the kernel.
Then by this very logic, CNN should be running stories on the latest Linux kernel release? XP is a bit different from 2.4.13 to 2.4.14 and Code Red made quite an impact on the Internet.
If you don't, tough. It obviously is going to stay no matter how many of you comment on it
That may be so, but dont expect the opposite and rely on slashdot to only run the stories you want. I bet if slashdot wasnt running stories on kernel updates that stories would still be submitted every release.
That may be so, but dont expect the opposite and rely on slashdot to only run the stories you want. I bet if slashdot wasnt running stories on kernel updates that stories would still be submitted every release.
CmdrTaco has stated on many occasions and in many interviews that the news that gets posted to slashdot is only that which interests him. Nobody else. Except maybe the other staff at/.. And it's not going to change no matter how much bitching goes on.
Unless the kernel has some new feature or fixes a major secutiy hole, I personally don't see how interesting each minor release is.
Well, the 2.4.x series has been marred by some serious and not-yet-entirely resolved virtual memory flaws that can cripple some mission-critical server applications. I'm not sure that qualifies as security hole, unless you consider that it makes DOS attacks easier, but it is a major performance problem. Until a final fix is in, every release in this branch is news.
I think you're overstating the case a bit. Linux accepted the new VM but so far reports have been pretty good. Yes, there have been some problems, but weren't we having problems with Rik's VM as well?
Linus' philosophy is usually to stick with a simple system a programmer can fully understand. Neat tricks sometimes give better performance, but simple systems are robust and tunable. Selecting right now to add the patch rather than forking off 2.5 and then backporting it doesn't seem very wise to me, but even Linus can make a mistake.
Unless the kernel has some new feature or fixes a major secutiy hole, I personally don't see how interesting each minor release is. Slashdot isn't freshmeat.
How about publishing all the news covering software releases (including kernel releases) under new topic called "software releases" and people like you can opt-out in preferences. Others, including me, can read about these from/. because we don't read both slashdot and freshmeat.
While I do enjoy all the kernel updates on slashdot, I think slashdot should also write about some of the great userspace apps as well.
All those apps you listed are most definately news for nerds, and they really are stuff that matters, specifically for Linux.
Anyone who hasn't tried out those apps, give em a whirl! Specifically, for me, mplayer is absolutely great. It is hands down the best video player for linux.
So, while freshmeat lists everything, why not list the important things on slashdot? I just think that would be so useful.
It looks like there were many fixes to the VM, which is good news. Hopefully this is the one we can all be happy with (well that will never happen, but at least be content for a bit) and let the Linux team move on to 2.5. The VM talk has seemed to calm down a bit on the LKML. [zork.net]
"I still don't know why 2.2.x had so few releases. only 17 before 2.4.0..."
why, back in my day, we got nine [kernel.org] stable kernel releases, and that was it! oh, sure, some times we'd get as much as thirteen [kernel.org] - though those cursed releases from 1.2.10 to 1.2.13 were for the ignorant masses! anyone who knows their stuff never uses a kernel with a patchlevel of 10 or above.
Since when is the Linux Kernel "The Kernel" "Kernel 2.4.14 is Out" is being highly biased towards Linux users... I thought Affirmitive Action was Illegal.. Isn't showing bias towards a Lesser Operating system in order to get it more accepted Affirmitive Action? Dammit. I run FreeBSD. My Kernel isn't at 2.4.14.... So I'm alienated.... Where's the ACLU?
We get a new release in about two months, and *we're* past 4. See, these Linux newbies haven't even caught up with that Gates character's 3.1.
While the strange affirmative actions really shouldn't happen, it's really more important that FreeBSD and our little brother Linux form a united front againat the *real* enemy we have in common: NetBSD.
Well, there was the "sorry excuse for a kernel" [slashdot.org] 2.4.11 which was withdrawn due to the symlink bug. So you could argue that we are at number 14...:)
Once again it's worth mentioning the preemptible kernel patch [tech9.net]. I've been running this for the last couple of releases, and for a developer's desktop system it give noticable results.
Case in point from yesterday: Running gnome desktop, with a kernel build going in the background, while ripping a CD, running mozilla and netscape 4.x, and running and testing a mod_perl/mysql system, all on the same machine, xmms didn't miss a beat.
No, I'm not exaggerating. This was all on a 700MHz Athlon, 256M, IDE.
Here's a quote from one of Andera's (author of the new VM) posts on LKML that may interest you:
indeed, the only thing that PE can really change is the mean latency but everbody only cares about worst case latency and nominal performance, possibly except realtime signal processing (not multimedia playback like listening mp3).
looks like this one isn't ready yet either. loop.c needs some sergery, or else the whole thing won't even compile, dying at
drivers/block/block.o: In function `lo_send':
drivers/block/block.o(.text+0x894f): undefined reference to `deactivate_page'
drivers/block/block.o(.text+0x8999): undefined reference to `deactivate_page'
make: *** [vmlinux] Error 1
it's allready been posted to the lkml, look for a 2.4.15-pre1 or at least a loop.c patch to come around soon.
It was left out... the.14 patch deleted deactivate_page from other places, but missed loop.c. Since it was a straight deletion everywhere else (not replaced with anything) that's the correct
answer.
**DISCLAIMER** I've searched google for this but couldn't find it.
Can someone tell me how to use a patch cut'n'pasted from a website? when I use the normal command patch -p1
it gives me some errors.
thanx in advance
I can't find an RPM of 2.4.14 in any of the usual places. Anyone know where one is available? I had problems compiling 2.4.13 last time and had to wait for an RPM.
I'd like to get this installed on the workstations and maybe some of the servers tomorrow morning.
Thanks in advance!
There are rpms for the Kernel-source out there (not to be confused with source rpms) which will put a linux-2.4.X-distZ directory or somesuch in a convenient place and let you compile (although i ran out of luck with some mandrake ones since it apparently mangles symbol versioning). That completely invalidates your argument about the necessity of hand-compiling a kernel, since you get to hand-compile the kernel with those. Also most distributors like to include their flavor of kernel-patches, for example supermount with mandrake, or ext3 with redhat (you can get that from the ac-patches too). Especially stuff relying on kernel-patches that didn't (yet) make it into the linus kernel (supermount, lm_sensors) will only work if you get the kernel-rpm, or apply the patches yourself (or compile the modules from a convenient package) and then you probably have to tell rpm to ignore some dependencies from kernelversions. Sometimes the rpms contain quite vital stuff, For example Debian (where it's.deb, and not.rpm) patching a hole in 2.2.xx (19 i think it was).
So there's some good reason for someone wanting to run a kernel compiled from a kernel-source-rpm, and if, for example, you use gcc3.0 as opposed to gcc2.96/gcc2.95, and also don't have those handy, you might even be better off using a precompiled version (most distris put out a server- and a desktop version) than compiling your own. The main reason why the original statement is funny, is asking for an rpm when the kernel is just out. The bashing was not appropriate, i think.
Especially stuff relying on kernel-patches that didn't (yet) make it into the linus kernel (supermount, lm_sensors) will only work if you get the kernel-rpm, or apply the patches yourself
ext3 is not in the main strain either. I'm "make menuconfig"-ing 2.2.14 right now, with experimental options enabled, and it doesn't show up. Guess RH7.2 users like me will have to wait for -ac1.
I can't hardly get a kernel compiled before the next version is released! You'd think they'd wait a little longer to go to the next version. Seems to me like the 2.4 strain got up to.14 much, much faster than 2.2 did... or is it just me?
If they don't post a lot of minor stuff the activity percentile drops like a rock on sourceforge. I don't agree with this, I feel that a CVS ci should have a reasonable chance at running on a typical machine. I'm not saying that every command combination needs to be checked, but it should reasonably work.
Everday people get realy turned off if they co the latest and greatest from CVS and the program doesn't even compile, or segfaults on first try. It makes OSs developers look real unprofessional.
It used to be that a even minor number on the kernal was considered stable, and at least was in beta status. I guess that that is out-the-window now. I can't figure out why both Linus and AC are working on 2.4, I thought Linus was supossed to jump from 2.3 to 2.5, when 2.3 was stable enough to become 2.4, then 2.4 versions increments were little details that turned up during more widespread usage, and features from 2.5 that became stable enough.
I've been waiting for a kernel that has had all-around good reports after a couple weeks of being in the wild. 2.4.14 did this time, but go figure, I can't get it to compile - it has problems with the block device section during compilation.:-/
Who's chrisd? Is that short or Christine? Finally, a female editor. But I still think this is discriminatory because a Kernel release is trivial. Let's see what Christie can really do! Let her post something real goddamnit!
I'm having serious deja vu here. I can vaguely recall an article posted previously on slashdot at sometime in the past before now, that mentioned something about a new linux kernel release. It seems that the kernel.org server(s) are unslashdottable. I'm downloading at 27kb/s. Why would they need mirrors? The server specs must be pretty good. I wonder what operating system they'd be using.
I've seen kernel.org fill up. I think it did sometime late last week, in fact. But they do have a 100Mbit/sec connection, which is pretty darn fast. 27kb/sec is kind of slow for them; they usually max out my DSL link at around 650kbit/s or 700kbit/s (== about 84kbyte/sec).
says the Linux Counter systemstats [li.org].
Granted, this has about a month's lead time, and is hardly "representative" (more enthusiasts than real users), but it shows 2.4 at 58.6% of the 1142 machines registered. 2.4.14 is 0.4%, 2.4.12 is 10.8%, beating everything but 2.2.19 (at 14.6%).
btw, the 5 registered 2.4.14 kernels are all prereleases - pre5aa1 being the most popular one.
This is a fun view - but that's no reason not to get counted!
For those wanting to try the pre-emptible kernel patch, the HP scheduler-plugin, compressed memory hardware, STP, XFS, JFS, Linux on an old VMS box, any one of a number of VME crates, serial-based network controllers, or the various latency clean-ups, then you could always try the FOLK [sourceforge.net] kernel seris. FOLK 2.3.0 is stable (gasp!) and provides more today than the first fifty 2.5.x kernels are likely to.
(And by the time those come out, FOLK will be comparable to Linux 2.7.0 in terms of features & performance.)
It's based off Alan Cox' -ac5, so the VM should be not too bad. However, if you want to be a bit more sure, I'm in the process of composing a new FOLK patch, based on 2.4.13-ac8. (Version on release may be different, as incremental patches become available.)
final:
- David Miller: sparc/scsi scatterlist fixes
- Martin Mares: PCI ids, email address update
- David Miller: revert TCP hash optimizations that need more checking
- Ivan Kokshaysky/Richard Henderson: alpha update (atomic_dec_and_lock etc)
- Peter Anvin: cramfs/zisofs missing pieces
pre8:
- Andrea: fix races in do_wp_page, free_swap_and_cache
- me: clena up page dirty handling
- Tim Waugh: parport IRQ probing and documentation fixes
- Greg KH: USB updates
- Michael Warfield: computone driver update
- Randy Dunlap: add knowledge about some new io-apics
- Richard Henderson: alpha updates
- Trond Myklebust: make readdir xdr verify the reply packet
- Paul Mackerras: PPC update
- Jens Axboe: make cpqarray and cciss play nice with the request layer
- Massimo Dal Zotto: SMM driver for Dell Inspiron 8000
- Richard Gooch: devfs symlink deadlock fix
- Anton Altaparmakov: make NTFS compile on sparc
pre7:
- me: reinstate "delete swap cache on low swap" code
- David Miller: ksoftirqd startup race fix
- Hugh Dickins: make tmpfs free swap cache entries proactively
pre6:
- me: remember to bump the version number;)
- Hugh Dickins: export "free_lru_page()" for modules
- Jeff Garzik: don't change nopage arguments, just make the last a dummy one
- David Miller: sparc and net updates (netfilter, VLAN etc)
- Nikita Danilov: reiserfs cleanups
- Jan Kara: quota initialization race
- Tigran Aivazian: make the x86 microcode update driver happy about
hyperthreaded P4's
- me: shrink dcache/icache more aggressively
- me: fix up oom-killer so that it actually works
pre5:
- Andrew Morton: remove stale UnlockPage
- me: swap cache page locking update
pre4:
- Mikael Pettersson: fix P4 boot with APIC enabled
- me: fix device queuing thinko, clean up VM locking
pre3:
- René Scharfe: random bugfix
- me: block device queuing low-water-marks, VM mapped tweaking.
pre2:
- Alan Cox: more merging
- Alexander Viro: block device module race fixes
- Richard Henderson: mmap for 32-bit alpha personality
- Jeff Garzik: 8139 and natsemi update
pre1:
- Michael Warfield: computone serial driver update
- Alexander Viro: cdrom module race fixes
- David Miller: Acenic driver fix
- Andrew Grover: ACPI update
- Kai Germaschewski: ISDN update
- Tim Waugh: parport update
- David Woodhouse: JFFS garbage collect sleep
Hm...these are always interesting, and I do like keeping up w/the Jones' -- but I'm nto a kernel hacker, and I don't know, for the most part, what they're talking about. Can anyone give some insight about what these changes mean for ordinary users? Not something like "Better, Stronger, Faster", but "this kernel call is used by GnomeFoo for reading your mail and sending it to Linus. It's now 2.5 times faster and encrypted."
Or is that not a good question -- is there, maybe, no way to dump this stuff down w/o getting to cliches like "Better, Stronger, Faster"?
The ChangeLog definitely needs some verbosity. The word to the wise is "only update if you need to", yet viewing the changelog leaves one wondering if they need the newer software.
What exactly do entries like "shrink dcache/icache more aggressively" or "random bugfix" mean? The former I'd guess has to do with data and instruction caches, but what aggressively shrinking does to them I have no clue without a more context. And the latter, "random bugfix", I hit my coworkers over the head when I see that in our CVS logs.
So is my current kernel effected? Am I missing out by not having my dcache/icache shrunk more aggressively? Or maybe those random bufixes effect me? A little more verbosity in the ChangeLog would go a long way. Having to follow the hacker's mailing list is not an option, this should be included in the release notes.
Linux has more or less zero control over data/instruction caches in the cpu. That's all done in hardware, maybe cpu microcode.
I don't know for sure, but I suspect that dcache/icache refers to dentry and inode caches, which are internal kernel structures representing files & directories, iirc.
Random bugfix really does deserve a cranial whallop, though.
It's not easy to bring the summaries down to the level of your average user; certainly, there's plenty of stuff that I don't undertand fully. But anyway, here's some additional explanations for the last two updates:
final:
- David Miller: sparc/scsi scatterlist fixes SCSI on Sparc machines is now more stable.
- Martin Mares: PCI ids, email address update The kernel now identifies some PCI hardware more precisely.
- David Miller: revert TCP hash optimizations that need more checking Remove some changes to the TCP stack, as they're not quite ready for primetime
- Ivan Kokshaysky/Richard Henderson: alpha update (atomic_dec_and_lock etc) Changes to Alpha-specific, er, stuff
- Peter Anvin: cramfs/zisofs missing pieces Properly merge the cramfs/zisofs changes
pre8:
- Andrea: fix races in do_wp_page, free_swap_and_cache Virtual memory handling is now more stable
- me: clena up page dirty handling This also improves VM
- Tim Waugh: parport IRQ probing and documentation fixes Automatic IRQ assignment for parallel ports works better
- Greg KH: USB updates USB subsystem improved
- Michael Warfield: computone driver update Erm... dunno. What's a computone?
- Randy Dunlap: add knowledge about some new io-apics Improve the kernel's handling of particular chipsets' IRQ assignment
- Richard Henderson: alpha updates Who knows?
- Trond Myklebust: make readdir xdr verify the reply packet Since it's Trond, it's probably a RAID or VFS update...
- Paul Mackerras: PPC update Bring Linus's kernel more up-to-date with respect to the PPC tree
- Jens Axboe: make cpqarray and cciss play nice with the request layer Probably RAID stuff...
- Massimo Dal Zotto: SMM driver for Dell Inspiron 8000 Make the kernel work better on a particular type of laptop
- Richard Gooch: devfs symlink deadlock fix Fix a bug in devfs's handling of symlinks
- Anton Altaparmakov: make NTFS compile on sparc Allow people to read NTFS filesystems on Sun Sparc hardware
I'm subscribed to l-k, so if I actually bothered to read the 200-odd messages coming in each day, I could probably give a better summary... anybody know how to stretch a day to 30 hours?
There's no (official) public CVS or nightly builds of the Linux kernel, so these releases (and the pre-xx ones) are all there is.
No one's forcing you to upgrade, and you really shouldn't upgraded as often as possible, you should only upgrade if you know that the new version has an imrovement / bugfix / new feature that you need or want.
And even then, in theory you should test it thoroughly on a test machine before putting it on a production box. (Though of course for desktop users this is usualy not much of an option).
Actually, A Service pack is a collection of patches and updates to a wide variety of services and applications that make up the complete system, and have been tested (in theory) to work together, and can be installed in one go.
A new kernel version would be just one small part of a service pack.
So no, it's not a service pack, and even if it were.....would that be a bad thing?
Personally, I'd rather be seeing lots of updates, which indicates that development is still being done, than to see nothing, and live under the uncertaintly of not knowing whether this meant that the system I had was perfect, or if the maintainters just didnt care.
Though you're definitely right about "if it's not broke, don't fix it" part.
Linus really, really, REALLY needs to start the 2.5.x branch.
Stable branches need to be stable. Do all of the new feature experimentation in unstable. It's gotten to the point now that "stable" has become a meaningless word in linuxland.
Next time around, let's fork off 2.7.0 at the same time 2.6.2 is released. Or maybe Linux needs to split into three branches: "flimsy" for experimentation and VM wars, "unstable" for up-to-date hardware support but no new features, and "stable" which only gets bug and security fixes.
Or maybe Linux needs to split into three branches: "flimsy" for experimentation and VM wars, "unstable" for up-to-date hardware support but no new features, and "stable" which only gets bug and security fixes.
We already have the "stable" branch, it's version number is 2.2.x.
Linus really, really, REALLY needs to start the 2.5.x branch.
Everyone is saying this, but there are issues involved. They were saying the same thing before 2.2 was even released - "give us a 2.3 so we can play". Linus doesn't work that way, because he believes (unlike, say, the Debian folks) that the resulting "brain drain" due to people hacking on the next unstable release unacceptibly hinders the bug-fixing effort in the current stable.
Sure, it's at least 80% psychological, but it does work, for all that. If you read his posts, you'll see that Linus has never been one to shy away from using psychology!
The unfortunate fact is, until recently, 2.4 did not have a usable VM. We can argue all day about whether Linus was too hasty in integrating Andrea's VM (I think he was, which is why I've switched to -ac kernels for now) but it is hard to argue that 2.5 should have forked before the 2.4 VM shaped up... at least given Linus's brain drain philosophy.
So, while the 2.4-only series has almost certainly gone on too long, there are valid reasons for it. Perhaps if you had contributed all your VM fixes six months ago, we could have had a 2.5 by now. (:
It's gotten to the point now that "stable" has become a meaningless word in linuxland.
If you truely want stability in "linuxland", then you should use the current stable version of Debian Linux [debian.org], the community based Linux Distro. It is very upsetting that the majority of Linux users haven't tried Debian Linux, considering how its one of, if not the best Linux Distro, and it is developed by the Linux community, not some corporation.
Normally I just lurk but I feel the need to disagree with Mr. Grimes.
I like many who read Slashdot am a linux enthusiast. I appriciate having a place where my OS of choice is reported on with the zeal and timeliness that Microsoft gets in the main stream press. Slashdot is one of the few sights I read on a daily basis, and I for one appriciate hearing about the new kernels. along with the rest of the pertinante Tech news.
My local paper still lists The High School football team's results on the front page every Saturday during the fall, even though most of it's readers dont have kids on the HS football team. It builds a sence of community pride wich is greater than the information that is contained or it's relevance to peoples lives.
Kernel anouncements on slashdot are appriciated by me and I hope a great many other readers. And even if there are only a few of us Linux is one of the things that form Slashdot's Community, and therefore in the interest of Community pride I encourage CT to continue to post all the kernel updates.
I like many who read Slashdot am a linux enthusiast. I appriciate having a place where my OS of choice is reported on with the zeal and timeliness that Microsoft gets in the main stream press.
I like using Windows as my primary OS, and yet I read Slashdot on a daily basis, and consider myself very knowledgable about computers and operating systems. I like you would appreciate it if Slashdot had timely reporting about Windows. Most Slashdot editors don't know the first thing about Windows and proudly claim never to touch it. I have yet to understand how people can ever claim to be in touch with the computing world without being in touch with Windows (which is different from liking it). When Windows makes news it hardly ever makes Slashdot (unless of course it's bad news). God forbid that a Windows Service Pack would ever make news on Slashdot. But a Linux kernel released... oh that's so different.
It's a matter of personal interest. The editors don't care about Windows, hence they know little about it. Offcourse they're using it from time to time -- almost everybody does, but that doesn't say they know anything about it.
THE PREVIOUS VERSION SHOULDN'T HAVE BEEN RELEASED UNTIL BUGS GOT IRONED OUT.
Looks like someone missed the point of open source development. How do you think the bugs got caught so quickly? Besides, with OSS you get what you pay for...:-)
Those who worry about production servers are not forced to upgrade. YOU are not forced to upgrade. Many others, however, are ready to take the chances and do their share of development by giving feedback to the actual hackers.
Remember, virtually every software has bugs, and if you don't like the idea of free bugfixes, you can just happily ignore them for whatever noble reason you have.
I can only run 2.4.5 or earlier, all options are the same ones I've used for about a year. I rebuild kernels from the same config file, tweaking new features when neccessary. For the most part, I have the bare minimum options/modules for my system. During the boot, I get about here and then it freezes:
....
PDC20262: IDE controller on PCI bus 00 dev 70
PCI: Found IRQ 11 for device 00:0e.0
PDC20262: chipset revision 1
PDC20262: not 100% native mode: will probe irqs later
PDC20262: ROM enabled at 0xeffe0000
PDC20262: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0xc000-0xc007, BIOS settings: hde:pio, hdf:DMA
ide3: BM-DMA at 0xc008-0xc00f, BIOS settings: hdg:pio, hdh:pio
hda: WDC WD205AA, ATA DISK drive
hdc: KENWOOD CD-ROM UCR004010 V126E, ATAPI CD/DVD-ROM drive
hdd: SAMSUNG SV2044D, ATA DISK drive
But I should be seeing these, too:
hde: Maxtor 96147U8, ATA DISK drive
hdf: Maxtor 96147H8, ATA DISK drive
I had exactly the same problem, about 1 year ago, appearently it isn't fixed yet. I did exchange a few emails with the IDE maintainer, but he could not help me:(
the sollution was not to put maxtor drives as slaves !?
... is surely C, with English coming second?
Anyway, if you can't decode a single transposition
in an English sentence you will be pretty useless
at debugging.
It's not a problem with his English skills, it's a problem with his typing.
Even if it wasn't, not everyone speaks or writes English fluently. Even those who grew up with it. And you know, nobody really cares, other than you, and nobody (I mean that, not even your mother) cares what you think. If they did, you'd have better things to do than flame Linus over a typo.
Last Linus 2.4 kernel (Score:1, Funny)
Re:Last Linus 2.4 kernel (Score:5, Informative)
CC: Kernel Mailing List
On 31 Oct 2001, Michael Peddemors wrote:
>
> Lets' let this testing cycle go a little longer before making any
> changes.. Let developers catch up..
My not-so-cunning plan is actually to try to figure out the big problems
now, then release a reasonable 2.4.14, and then just stop for a while,
refusing to take new features.
Then, 2.4.15 would be the point where I start 2.5.x, and where Alan gets
to do whatever he wants to do with 2.4.x. Including, of course, just
reverting all my and Andrea's VM changes
I'm personally convinced that my tree does the right thing VM-wise, but
Alan _will_ be the maintainer, and I'm not going to butt in on his
decisions. The last thing I want to be is a micromanaging pointy-haired
boss.
(2.5.x will obviously use the new VM regardless, and I actually believe
that the new VM simply is better. I think that Alan will see the light
eventually, but at the same time I clearly admit that Alan was right on a
stability front for the last month or two
> My own kernel patches I had to stop because I couldn't keep up
> we go a full month with you just hitting us over the head with a bat
> yelling 'test, dammit, test', until this is tested fully before
> releasing another production release?
I think we're really close.
[ I'd actually like to thank Gary Sandine from laclinux.com who made the
"Ultimate Linux Box" for an article by Eric Raymond for Linux Journal.
They sent me one too, and the 2GB box made it easier to test some real
highmem loads. This has given me additional load environments to test,
and made me able to see some of the problems people reported.. ]
But I do want to make a real 2.4.14, not just another "final" pre-kernel,
and let that be the base for a reasonably orderly switch-over at 2.4.15
(ie I'd still release 2.4.15, everything from then on is Alan).
Linus
Re:Last Linus 2.4 kernel (Score:4, Insightful)
What happened to the report (see this Slashdot story from Nov. 2 [slashdot.org]) that Alan Cox would be replaced by Marcelo Tosatti as the stable release coordinator?
Re:Last Linus 2.4 kernel (Score:4, Informative)
Alan is free to do what he wants with the kernel including pass on its maintenance to someone else
Re:Last Linus 2.4 kernel (Score:4, Informative)
Re:101 reasons not to patch and unpatch repeatedly (Score:2)
Version niceness (Score:5, Funny)
Re:Version niceness (Score:2, Funny)
I think that 2.4.XP is a much nicer version number.
Re:Version niceness (Score:2)
5.1.2600 just doesn't have the same ring to it as XP though... I think the 2600 is the build number...
I wonder what build number Linux would be if it incremented everytime Linux make a kernel change.
2600, those Microsoft hackers (Score:2)
So Microsoft is now in league with those phreaking 2600 guys? I always knew....
2600 is for 2600 kHz, the carrier wave for the sounds that payphones used to signal the home office that someone dropped in a shekel or the call. All the kool kids had electronics that could make that tone and bingo, free calls. Was called phreaking at one time. Now the kids on to bigger and better things, like finding holes in telnetd.
Re:2600, those Microsoft hackers (Score:2)
Yup, XP was codenamed "Windows Whistler" [winsupersite.com]. Captain Crunch [techtarget.com], anyone? :)
Re:[OT]Hardware requirements [was Re:Version nicen (Score:4, Interesting)
Another route you could take would be to try FreeBSD, as even the newest versions still run very nicely on old hardware. I recently installed FreeBSD 4.4 on a P75 with 16 MB of RAM, and it has been chugging along, happily playing MP3s via NFS in our living room. I can even be compiling software while playing MP3s, and it plays flawlessly.
The issue you mentioned about Tuxracer going so slow is because the S3 Trio64+ doesn't have OpenGL hardware acceleration (to my knowledge, at least), which means that Tuxracer is going to do all of the OpenGL via software. This equates to incredibly low frame rates, until a better video card is used. Your best bet, if you're really looking into running OpenGL applications, would be 1) buy a better video card, 2) install XFree86 4.1.0 (see xfree86.org), and 3) enjoy.
I'm not sure about the SoundIII drivers you are asking about -- search google for "SoundIII and Linux" and see what comes up.
Changelog? (Score:2, Funny)
I'd also be interested to know if they've fixed the Integer floating poing RAND bug that can occur on some older MMX Athlons. I've got a friend who has one of the affected processors, and he's been dying to upgrade, but can't because his tarball segfaults on compile.
Also, what's the status of that TCP/IP stack optimization that Theo De Raadt has been working on? Has this been incorporated into the new kernel? I'm getting sick of compiling my winipcfg.dll file every time I install a new kernel. Hopefully the new winmodem streaming support will take care of this problem. It shouldn't have taken as long as it already has, considering DeRaadt switched from C to VisualBasic for his new code. Any info would be helpful...
Re:Changelog? (Score:1, Funny)
Ironicly for a mensa memember you could have at least read the summary that included the link. What is your offical IQ anyway?
Re:Changelog? (Score:2)
Is Fatal VM Bugs Fixed? (Score:1)
The last pre seems to be OK, but Linus is still "working" on that. Did anyone know that the VM bugs are fixed? I don't see that in the change logs after pre8...
That's nice, but its not really news... (Score:5, Interesting)
If
* MPlayer allowing us to play WMVs under out OS of choice
* Xine, finally maturing into a solid high quality DVD player
* Partimage providng a useful and open source disk imaging system
* Ximian's setup tools beta making an X config tool that doesn't suck
OI don't have anything against the kernel, but we all know there's always goiung to be a new kernel every couple of weeks. There's so many interesting userspace Open Source projects we could be hearing about.
After all, isn't the point of an OS to run *apps*?
Re:That's nice, but its not really news... (Score:4, Flamebait)
I don't subscribe to the kernel announce list. I don't care to read a bunch of garbage everday.
A new kernel may not be news for everyone but it is certainly news for nerds.
If they tell us when the release of XP is, or when the release of a new variant of Code Red or the like is out, why not the kernel.
Sorry but I feel that the latest kernel is quite acceptable to be shown on
If you don't, tough. It obviously is going to stay no matter how many of you comment on it (remember, we have seen these posts before).
I like it.
Re:That's nice, but its not really news... (Score:4, Informative)
you dont have to, you can subscribe to the linux kernel entry on freshmeat and recieve an email when a new version is out.
I don't subscribe to the kernel announce list. I don't care to read a bunch of garbage everday.
so release information is not garbage when its on slashdot but it is garbage when it comes from the actual source?
If they tell us when the release of XP is, or when the release of a new variant of Code Red or the like is out, why not the kernel.
Then by this very logic, CNN should be running stories on the latest Linux kernel release? XP is a bit different from 2.4.13 to 2.4.14 and Code Red made quite an impact on the Internet.
If you don't, tough. It obviously is going to stay no matter how many of you comment on it
That may be so, but dont expect the opposite and rely on slashdot to only run the stories you want. I bet if slashdot wasnt running stories on kernel updates that stories would still be submitted every release.
Re:That's nice, but its not really news... (Score:2)
CmdrTaco has stated on many occasions and in many interviews that the news that gets posted to slashdot is only that which interests him. Nobody else. Except maybe the other staff at
Re:That's nice, but its not really news... (Score:2)
Well, the 2.4.x series has been marred by some serious and not-yet-entirely resolved virtual memory flaws that can cripple some mission-critical server applications. I'm not sure that qualifies as security hole, unless you consider that it makes DOS attacks easier, but it is a major performance problem. Until a final fix is in, every release in this branch is news.
Re:That's nice, but its not really news... (Score:2)
Linus' philosophy is usually to stick with a simple system a programmer can fully understand. Neat tricks sometimes give better performance, but simple systems are robust and tunable. Selecting right now to add the patch rather than forking off 2.5 and then backporting it doesn't seem very wise to me, but even Linus can make a mistake.
Re:That's nice, but its not really news... (Score:2)
How about publishing all the news covering software releases (including kernel releases) under new topic called "software releases" and people like you can opt-out in preferences. Others, including me, can read about these from /. because we don't read both slashdot and freshmeat.
hmmm... I sort of agree (Score:2)
All those apps you listed are most definately news for nerds, and they really are stuff that matters, specifically for Linux.
Anyone who hasn't tried out those apps, give em a whirl! Specifically, for me, mplayer is absolutely great. It is hands down the best video player for linux.
So, while freshmeat lists everything, why not list the important things on slashdot? I just think that would be so useful.
Re:That's nice, but its not really news... (Score:3, Funny)
incorrect mirrors link (Score:4, Informative)
VM finally there... (Score:2, Interesting)
release often (Score:4, Funny)
Re:release often (Score:2, Informative)
Ohhh, and 2.0.x was in 36 revisions when i shifted to 2.2.0
I still don't know why 2.2.x had so few releases. only 17 before 2.4.0... weird...
Re:release often (Score:2, Interesting)
Uh, maybe because it was good and didn't need that many releases? I never had any problems with any of the 2.2.x kernels I used.
obligatory old-timer post (Score:2)
why, back in my day, we got nine [kernel.org] stable kernel releases, and that was it! oh, sure, some times we'd get as much as thirteen [kernel.org] - though those cursed releases from 1.2.10 to 1.2.13 were for the ignorant masses! anyone who knows their stuff never uses a kernel with a patchlevel of 10 or above.
happily posting with 2.4.9, and you should too!
Re:release often (Score:2)
Nah, call them "feature releases" - it's the same thing, but you get to charge money for them.
(Citrix *really* sucks.)
Re:release often (Score:2)
Just kidding.
freshmeat (Score:2, Funny)
Mirrors? (Score:2)
New rules when announcing Kernels. (Score:3, Flamebait)
oh, quit whining :) (Score:2)
While the strange affirmative actions really shouldn't happen, it's really more important that FreeBSD and our little brother Linux form a united front againat the *real* enemy we have in common: NetBSD.
:)
hawk
Re:New rules when announcing Kernels. (Score:2)
Useless point... (Score:5, Informative)
We're actually at 15 (not 14) and counting - kernel version numbers are 0-based, and sequential.
Sorry moderators - I just had to
Re:Useless point... (Score:4, Funny)
Re:Useless point... (Score:3, Insightful)
Preemptible kernel patch (Score:4, Informative)
Case in point from yesterday: Running gnome desktop, with a kernel build going in the background, while ripping a CD, running mozilla and netscape 4.x, and running and testing a mod_perl/mysql system, all on the same machine, xmms didn't miss a beat.
No, I'm not exaggerating. This was all on a 700MHz Athlon, 256M, IDE.
Re:Preemptible kernel patch (Score:2)
Re:Preemptible kernel patch (Score:2)
No, I'm not exaggerating. This was all on a 700MHz Athlon, 256M, IDE.
Hm, so do you suppose it'll help my 75MHz Pentium, 32M laptop?
What excitement! (Score:2, Funny)
Re:What excitement! (Score:2)
Thinks he's so special..
2.4.14 not ready yet either (Score:5, Informative)
drivers/block/block.o: In function `lo_send':
drivers/block/block.o(.text+0x894f): undefined reference to `deactivate_page'
drivers/block/block.o(.text+0x8999): undefined reference to `deactivate_page'
make: *** [vmlinux] Error 1
it's allready been posted to the lkml, look for a 2.4.15-pre1 or at least a loop.c patch to come around soon.
here's a patch for it (Score:2, Informative)
diff -X
+linux-2.4.14-loop/drivers/block/loop.c
--- linux-2.4.14/drivers/block/loop.c Thu Oct 25 13:58:34 2001
+++ linux-2.4.14-loop/drivers/block/loop.c Mon Nov 5 17:06:08 2001
@@ -207,7 +207,6 @@
index++;
pos += size;
UnlockPage(page);
- deactivate_page(page);
page_cache_release(page);
}
return 0;
@@ -218,7 +217,6 @@
kunmap(page);
unlock:
UnlockPage(page);
- deactivate_page(page);
page_cache_release(page);
fail:
return -1;
use at your own risk, or some of that legal junk.
Great patch (Score:2)
Okay, I'm mostly joking, but have you tried rebooting with the new (patched) kernel and using the loopback device yet?
Re:Great patch (Score:2, Informative)
answer.
--Dan
Erm... I'm having a little trouble (Score:2)
Can someone tell me how to use a patch cut'n'pasted from a website? when I use the normal command patch -p1 it gives me some errors.
thanx in advance
Re:Erm... I'm having a little trouble (Score:2)
That should fix it for you.
That patch was a very long winded way of saying "remove the lines".
I helps if you can read patches.
Re:2.4.14 not ready yet either (Score:2, Informative)
as for loop.c, Linus gives this (not very detailed)answer:
http://www.uwsg.indiana.edu/hypermail/linux/kerne
(just delete the two lines were deactivate_page appear).
But what makes me worried about that is Andrea's mail:
http://www.uwsg.indiana.edu/hypermail/linux/kerne
second bug is using I2C Philips PARPORT:
http://www.uwsg.indiana.edu/hypermail/linux/kerne
it should impact that many people, but it's a great one.
so actually, that means Linus didn't try to compile the kernel enabling all modules before releasing it. waow
Schweeeeeeet! But is there an .rpm? (Score:2, Funny)
I'd like to get this installed on the workstations and maybe some of the servers tomorrow morning.
Thanks in advance!
Re:Schweeeeeeet! But is there an .rpm? (Score:2)
So there's some good reason for someone wanting to run a kernel compiled from a kernel-source-rpm, and if, for example, you use gcc3.0 as opposed to gcc2.96/gcc2.95, and also don't have those handy, you might even be better off using a precompiled version (most distris put out a server- and a desktop version) than compiling your own. The main reason why the original statement is funny, is asking for an rpm when the kernel is just out. The bashing was not appropriate, i think.
Re:Schweeeeeeet! But is there an .rpm? (Score:2)
ext3 is not in the main strain either. I'm "make menuconfig"-ing 2.2.14 right now, with experimental options enabled, and it doesn't show up. Guess RH7.2 users like me will have to wait for -ac1.
New ./ feature idea (Score:5, Insightful)
maybe major kernel release posts should go in their own category, so whiners could set their user prefs to not display them.
Good gravy! (Score:2, Redundant)
Re:Good gravy! (Score:2)
*
Re:Good gravy! (Score:2)
Everday people get realy turned off if they co the latest and greatest from CVS and the program doesn't even compile, or segfaults on first try. It makes OSs developers look real unprofessional.
It used to be that a even minor number on the kernal was considered stable, and at least was in beta status. I guess that that is out-the-window now. I can't figure out why both Linus and AC are working on 2.4, I thought Linus was supossed to jump from 2.3 to 2.5, when 2.3 was stable enough to become 2.4, then 2.4 versions increments were little details that turned up during more widespread usage, and features from 2.5 that became stable enough.
Re:Good gravy! (Score:2)
chrisd? (Score:3, Interesting)
Wondering why your shiny new P4 system won't boot? (Score:2)
- Mikael Pettersson: fix P4 boot with APIC enabled
Unslashdottable (Score:2, Interesting)
Re:Unslashdottable (Score:2)
-Paul Komarek
The 2.4 releases are the normal kernel now (Score:2)
Granted, this has about a month's lead time, and is hardly "representative" (more enthusiasts than real users), but it shows 2.4 at 58.6% of the 1142 machines registered. 2.4.14 is 0.4%, 2.4.12 is 10.8%, beating everything but 2.2.19 (at 14.6%).
btw, the 5 registered 2.4.14 kernels are all prereleases - pre5aa1 being the most popular one.
This is a fun view - but that's no reason not to get counted!
Harald, counter, compulsive.
I'll throw in my own plug, then! (Score:5, Interesting)
(And by the time those come out, FOLK will be comparable to Linux 2.7.0 in terms of features & performance.)
Re:I'll throw in my own plug, then! (Score:2)
Re:Changes/Improvements (Score:5, Informative)
final:
- David Miller: sparc/scsi scatterlist fixes
- Martin Mares: PCI ids, email address update
- David Miller: revert TCP hash optimizations that need more checking
- Ivan Kokshaysky/Richard Henderson: alpha update (atomic_dec_and_lock etc)
- Peter Anvin: cramfs/zisofs missing pieces
pre8:
- Andrea: fix races in do_wp_page, free_swap_and_cache
- me: clena up page dirty handling
- Tim Waugh: parport IRQ probing and documentation fixes
- Greg KH: USB updates
- Michael Warfield: computone driver update
- Randy Dunlap: add knowledge about some new io-apics
- Richard Henderson: alpha updates
- Trond Myklebust: make readdir xdr verify the reply packet
- Paul Mackerras: PPC update
- Jens Axboe: make cpqarray and cciss play nice with the request layer
- Massimo Dal Zotto: SMM driver for Dell Inspiron 8000
- Richard Gooch: devfs symlink deadlock fix
- Anton Altaparmakov: make NTFS compile on sparc
pre7:
- me: reinstate "delete swap cache on low swap" code
- David Miller: ksoftirqd startup race fix
- Hugh Dickins: make tmpfs free swap cache entries proactively
pre6:
- me: remember to bump the version number
- Hugh Dickins: export "free_lru_page()" for modules
- Jeff Garzik: don't change nopage arguments, just make the last a dummy one
- David Miller: sparc and net updates (netfilter, VLAN etc)
- Nikita Danilov: reiserfs cleanups
- Jan Kara: quota initialization race
- Tigran Aivazian: make the x86 microcode update driver happy about
hyperthreaded P4's
- me: shrink dcache/icache more aggressively
- me: fix up oom-killer so that it actually works
pre5:
- Andrew Morton: remove stale UnlockPage
- me: swap cache page locking update
pre4:
- Mikael Pettersson: fix P4 boot with APIC enabled
- me: fix device queuing thinko, clean up VM locking
pre3:
- René Scharfe: random bugfix
- me: block device queuing low-water-marks, VM mapped tweaking.
pre2:
- Alan Cox: more merging
- Alexander Viro: block device module race fixes
- Richard Henderson: mmap for 32-bit alpha personality
- Jeff Garzik: 8139 and natsemi update
pre1:
- Michael Warfield: computone serial driver update
- Alexander Viro: cdrom module race fixes
- David Miller: Acenic driver fix
- Andrew Grover: ACPI update
- Kai Germaschewski: ISDN update
- Tim Waugh: parport update
- David Woodhouse: JFFS garbage collect sleep
Re:Changes/Improvements (Score:2)
Or is that not a good question -- is there, maybe, no way to dump this stuff down w/o getting to cliches like "Better, Stronger, Faster"?
Re:Changes/Improvements (Score:5, Insightful)
What exactly do entries like "shrink dcache/icache more aggressively" or "random bugfix" mean? The former I'd guess has to do with data and instruction caches, but what aggressively shrinking does to them I have no clue without a more context. And the latter, "random bugfix", I hit my coworkers over the head when I see that in our CVS logs.
So is my current kernel effected? Am I missing out by not having my dcache/icache shrunk more aggressively? Or maybe those random bufixes effect me? A little more verbosity in the ChangeLog would go a long way. Having to follow the hacker's mailing list is not an option, this should be included in the release notes.
Useful Information (Score:2)
I don't know for sure, but I suspect that dcache/icache refers to dentry and inode caches, which are internal kernel structures representing files & directories, iirc.
Random bugfix really does deserve a cranial whallop, though.
Re:Useful Information (Score:2)
Re:Changes/Improvements (Score:4, Informative)
final:
- David Miller: sparc/scsi scatterlist fixes
SCSI on Sparc machines is now more stable.
- Martin Mares: PCI ids, email address update
The kernel now identifies some PCI hardware more precisely.
- David Miller: revert TCP hash optimizations that need more checking
Remove some changes to the TCP stack, as they're not quite ready for primetime
- Ivan Kokshaysky/Richard Henderson: alpha update (atomic_dec_and_lock etc)
Changes to Alpha-specific, er, stuff
- Peter Anvin: cramfs/zisofs missing pieces
Properly merge the cramfs/zisofs changes
pre8:
- Andrea: fix races in do_wp_page, free_swap_and_cache
Virtual memory handling is now more stable
- me: clena up page dirty handling
This also improves VM
- Tim Waugh: parport IRQ probing and documentation fixes
Automatic IRQ assignment for parallel ports works better
- Greg KH: USB updates
USB subsystem improved
- Michael Warfield: computone driver update
Erm... dunno. What's a computone?
- Randy Dunlap: add knowledge about some new io-apics
Improve the kernel's handling of particular chipsets' IRQ assignment
- Richard Henderson: alpha updates
Who knows?
- Trond Myklebust: make readdir xdr verify the reply packet
Since it's Trond, it's probably a RAID or VFS update...
- Paul Mackerras: PPC update
Bring Linus's kernel more up-to-date with respect to the PPC tree
- Jens Axboe: make cpqarray and cciss play nice with the request layer
Probably RAID stuff...
- Massimo Dal Zotto: SMM driver for Dell Inspiron 8000
Make the kernel work better on a particular type of laptop
- Richard Gooch: devfs symlink deadlock fix
Fix a bug in devfs's handling of symlinks
- Anton Altaparmakov: make NTFS compile on sparc
Allow people to read NTFS filesystems on Sun Sparc hardware
I'm subscribed to l-k, so if I actually bothered to read the 200-odd messages coming in each day, I could probably give a better summary... anybody know how to stretch a day to 30 hours?
Re:Changes/Improvements (Score:2)
Re:Stop it. (Score:3, Interesting)
aren't you confusing this with Mozilla...
There's no (official) public CVS or nightly builds of the Linux kernel, so these releases (and the pre-xx ones) are all there is.
No one's forcing you to upgrade, and you really shouldn't upgraded as often as possible, you should only upgrade if you know that the new version has an imrovement / bugfix / new feature that you need or want.
And even then, in theory you should test it thoroughly on a test machine before putting it on a production box. (Though of course for desktop users this is usualy not much of an option).
Re:call it what it is (Score:3, Insightful)
A new kernel version would be just one small part of a service pack.
So no, it's not a service pack, and even if it were.....would that be a bad thing?
Personally, I'd rather be seeing lots of updates, which indicates that development is still being done, than to see nothing, and live under the uncertaintly of not knowing whether this meant that the system I had was perfect, or if the maintainters just didnt care.
Though you're definitely right about "if it's not broke, don't fix it" part.
Re:call it what it is (Score:5, Insightful)
Stable branches need to be stable. Do all of the new feature experimentation in unstable. It's gotten to the point now that "stable" has become a meaningless word in linuxland.
Next time around, let's fork off 2.7.0 at the same time 2.6.2 is released. Or maybe Linux needs to split into three branches: "flimsy" for experimentation and VM wars, "unstable" for up-to-date hardware support but no new features, and "stable" which only gets bug and security fixes.
Re:call it what it is (Score:2)
We already have the "stable" branch, it's version number is 2.2.x.
Re:call it what it is (Score:4, Insightful)
Everyone is saying this, but there are issues involved. They were saying the same thing before 2.2 was even released - "give us a 2.3 so we can play". Linus doesn't work that way, because he believes (unlike, say, the Debian folks) that the resulting "brain drain" due to people hacking on the next unstable release unacceptibly hinders the bug-fixing effort in the current stable.
Sure, it's at least 80% psychological, but it does work, for all that. If you read his posts, you'll see that Linus has never been one to shy away from using psychology!
The unfortunate fact is, until recently, 2.4 did not have a usable VM. We can argue all day about whether Linus was too hasty in integrating Andrea's VM (I think he was, which is why I've switched to -ac kernels for now) but it is hard to argue that 2.5 should have forked before the 2.4 VM shaped up ... at least given Linus's brain drain philosophy.
So, while the 2.4-only series has almost certainly gone on too long, there are valid reasons for it. Perhaps if you had contributed all your VM fixes six months ago, we could have had a 2.5 by now. (:
Re:call it what it is (Score:2)
Re:call it what it is (Score:2)
Wait, put down your troll tag, take it easy... That's what Intel did, in the past, in the x86 processor development.
Re:why is this news? (Score:2)
Compile and grab a cold beer. Then join us.
Re:why is this news? (Score:5, Insightful)
I like many who read Slashdot am a linux enthusiast. I appriciate having a place where my OS of choice is reported on with the zeal and timeliness that Microsoft gets in the main stream press. Slashdot is one of the few sights I read on a daily basis, and I for one appriciate hearing about the new kernels. along with the rest of the pertinante Tech news.
My local paper still lists The High School football team's results on the front page every Saturday during the fall, even though most of it's readers dont have kids on the HS football team. It builds a sence of community pride wich is greater than the information that is contained or it's relevance to peoples lives.
Kernel anouncements on slashdot are appriciated by me and I hope a great many other readers. And even if there are only a few of us Linux is one of the things that form Slashdot's Community, and therefore in the interest of Community pride I encourage CT to continue to post all the kernel updates.
JFMILLER
Re:why is this news? (Score:2)
Re:why is this news? (Score:2)
It's a matter of personal interest. The editors don't care about Windows, hence they know little about it. Offcourse they're using it from time to time -- almost everybody does, but that doesn't say they know anything about it.
That is, if the editors are anything like me.
Re:Link error (Score:2, Informative)
Re:Link error (Score:2)
was what I did. Looks good to you?
Um not unless this is a typo - you cleaned after you dep'ed - ooops! make clean dep bzImage would be more like it!
Re:Link error (Score:2)
Re:Life on the edge is too stressful (Score:3, Interesting)
Re:Life on the edge is too stressful (Score:2)
Looks like someone missed the point of open source development. How do you think the bugs got caught so quickly? Besides, with OSS you get what you pay for... :-)
Those who worry about production servers are not forced to upgrade. YOU are not forced to upgrade. Many others, however, are ready to take the chances and do their share of development by giving feedback to the actual hackers.
Remember, virtually every software has bugs, and if you don't like the idea of free bugfixes, you can just happily ignore them for whatever noble reason you have.
Re:This is all good, but... (Score:2, Informative)
http://marc.theaimsgroup.com/?l=linux-kernel&w=2&
Other people seem to be running it OK, and there's a patch or two that might be related...
Re:This is all good, but... (Score:2)
are you using the exact same
Did you check that you aren't turning on anything different in the new kernels?
have you tried it without all the add on hardware? remove everything but the video card and ram, does it detect and work then or still blow up?
Re:This is all good, but... (Score:2)
Promise Ultra66 PDC20262
2x Maxtor 96147U8 (hde, hdf)
I can only run 2.4.5 or earlier, all options are the same ones I've used for about a year. I rebuild kernels from the same config file, tweaking new features when neccessary. For the most part, I have the bare minimum options/modules for my system. During the boot, I get about here and then it freezes:
....
PDC20262: IDE controller on PCI bus 00 dev 70
PCI: Found IRQ 11 for device 00:0e.0
PDC20262: chipset revision 1
PDC20262: not 100% native mode: will probe irqs later
PDC20262: ROM enabled at 0xeffe0000
PDC20262: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0xc000-0xc007, BIOS settings: hde:pio, hdf:DMA
ide3: BM-DMA at 0xc008-0xc00f, BIOS settings: hdg:pio, hdh:pio
hda: WDC WD205AA, ATA DISK drive
hdc: KENWOOD CD-ROM UCR004010 V126E, ATAPI CD/DVD-ROM drive
hdd: SAMSUNG SV2044D, ATA DISK drive
But I should be seeing these, too:
hde: Maxtor 96147U8, ATA DISK drive
hdf: Maxtor 96147H8, ATA DISK drive
Re:This is all good, but... (Score:2)
the sollution was not to put maxtor drives as slaves !?
A kernel hacker's first language... (Score:2, Funny)
Anyway, if you can't decode a single transposition
in an English sentence you will be pretty useless
at debugging.
Phillip.
Re:From the changelog (Score:3, Insightful)
Even if it wasn't, not everyone speaks or writes English fluently. Even those who grew up with it. And you know, nobody really cares, other than you, and nobody (I mean that, not even your mother) cares what you think. If they did, you'd have better things to do than flame Linus over a typo.
Re:From the changelog (Score:2)
I didn't know Linus's wife posted on Slashdot... :) "Good defense, honey!"
Re:From the changelog (Score:2)
Translation: "I tried to clean up dirty page handling, but also introduced a subtle bug that ocrrupts my keyboard buffer". Hope it doesn't bite me!
Re:From the changelog (Score:2)