Slashdot Mirror
Linux v2.6 Begins Testing
xose quotes Linus from the kernel list: "the naming should be familiar - it's the same deal as with 2.4.0.
One difference is that while 2.4.0 took about 7 months from the pre1 to
the final release, I hope (and believe) that we have fewer issues facing
us in the current 2.6.0. But very obviously there are going to be a
few test-releases before the real thing.
The point of the test versions is to make more people realize that they
need testing and get some straggling developers realizing that it's too
late to worry about the next big feature. I'm hoping that Linux vendors
will start offering the test kernels as installation alternatives, and
do things like make upgrade internal machines, so that when the real
2.6.0 does happen, we're all set." You all know what to do ;) Update: 07/14 17:49 GMT by S : OverNeith writes "Joe Pranevich has done it again! He's written another summary document on what to expect in the new and upcoming 2.6 Kernel!"
For us newbies here, what are the relevant differences in the new kernel? Better performance? New hardware support?
OK, yesterday I was testing 2.5.75. Helpfully, the computer locked up and gave me an opportunity to send a bug report. So far so good. Only that I was in X, I wasn't doing anything particularly interesting or demanding (was playing kbounce), the panic report (if there was one) probably went to tty1 and I have no idea why the computer locked up. How do you report a bug when you can't see what went wrong with the kernel?
Gentlemen, you can't fight in here, this is the War Room!
And ive just compiled it. I was quite surprised I managed to get it to boot without it panicing. I'm even typing from the new kernel now. But there is a word of warning though. The layout of the /dev folder has been rearranged. As a result some of my programs have broke.
/dev/hda, /dev/hdb/, /dev/hdc now become /dev/discs/disc0, /dev/discs/disc1, /dev/discs/disc2. So you will need to edit /etc/fstab to reflect the changes.
For example.
Steve French:
o NTLMv2 password support and NTLMSSP signing part 1
o ntlmssp signing
o More NTLMv2
I don't understand - why is this in the kernel? No entiendo.
Get your own free personal location tracker
Should mention that the sound capture seems to cause the problem -- without sound, the capture is smooth under Linux, but adding either ALSA or OSS to the mix guarantees problems.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
Downloaded, compiled and installed. Working since 4 hours on a Slackware-9.0-current, asus L8460K notebook (p3/1000, 256mb ram, i440bx, S3 savage/MX, ess allegro) and quite standard compilation options (acpi, alsa, pcmcia, usb, netfilter, no ipv6, preemptible kernel). Applied patch as seen on LKML (see here) for vfsmount.
Happy testing!
I'm fat, you're ugly. I can get slimmer, and you?
You know, the firewire disk driver. Man that thing has never worked 100%.
Just try corrupting a large (mine was 90GB) partition on a firewire HD and then fschk it. Eventually it'll start getting timeout errors and all sorts of crap, and will eventually trash the filesystem even worse. Then you can't mount the drive at all.
I usually end up having to go to Windows because it's the only place that I can force a massively corrupted partition to mount (and it has better SBP2 support). From there I can copy everything that is still good off and reformat the drive.
This hasn't just happened once. More like 3 or 4 times (both EXT3 and Reiser partitions) over the last year or so.
The ratio of people to cake is too big
If I remember correctly there's a new Block IO (BIO) layer included too, which should enable IDE CD burning without the need for SCSI emulation. Should speed things up somewhat.
I'm not exactly sure if this is correct - I believe I heard it a the Linux Forum in Denmark back in march. The speaker was Jens Axboe, the current cdrom subsystem maintainer.
zWhat would an EWOULDBLOCK block, if an EWOULDBLOCK could block would? -- me
Two possibly dumb questions (but this is slashdot, after all). (1) Can you change the scheduler default timeslice (10 msec seems a bit long for a multi-GHz CPU). (2) does it do the right thing for hyperthreading? (for hyperthreading, the scheduler needs to understand that one of the CPUs is sorta crippled, so jobs should flop back & forth between both CPUs).
--- Often in error; never in doubt!
Technical achivements aside, the most amusing thing about the 2.6 series of kernels is seeing all the large corporate entities with vested interests deal with the release schedule.
That is to say, there isn't one. I especially liked the quote from Torvalds I recently saw in a CNet news.com that basically said, "it'll be done when it's done - deal with it".
The dangers of knowledge trigger emotional distress in human beings.
Let's hope this supports USB 2.0 "Full Speed" or "High Speed", whichever is faster..
LINUX 2.6 KEY CHANGES
Faster, more predictable performance and new APIs are on tap
[Yay]
Desktop improvements
[Whatever that means]
Universal Serial Bus 2.0 and production Bluetooth support
[Yay]
Pre-emptible kernel with low-latency kernel patches for more user responsiveness and better multimedia performance, even under heavy loads
[Like Windows XP!]
Server improvements
[Whatever that means]
Updated I/O and memory subsystem for faster throughput and scalability
[Yeah, like blast processing]
Faster, more scalable process scheduler
[Pfft]
User-mode Linux to allow multiple system images running on the same box to aid server consolidation and application separation
[Sounds like the minutes of a business meeting]
Asynchronous I/O and completion events--a big improvement for Web servers and databases
[I'll take your word for it]
Support for disks larger than 2 terabytes and for SGI's XFS enterprise file system
[OK]
Faster, POSIX-compliant threading library
[Redundant]
and it still shows nothing on screen if i pass vga=normal during boot, and it took me several atempts before I relized that regular ps/2 keyboard can be left out or compiled as a module. well, this kind of changes were expected.
after i managed to get it working (booting, with keyboard, framebuffer console, et. all) surprise... no DRM on X.
happens that for some reason X doesn't detect working agp when a Radeon 8500LE in inserted in my kt266 based mobo. even with agpgart and radeon modules loaded.
so here's a few sugestions:
leave ps/2 kboard selected by default for x86 architectures, same for a way to display the console on text mode vga and check this radeon issue.
except those minor stuff, the new kernel is great. really fast for regular use.
What ? Me, worry ?
It will be nice to see some articles in the mainstream press showing that Linux is still marching on regardless of SCO's drum beating.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
I know Slashdot isn't a support forum, but could someone point out a good tutorial for compiling and installing a new kernel? I'd like to give 2.6 a try, but I don't know where to begin.
What's wrong with Mandrake or Suse offering a clearly labelled "testing kernel"?
As I'm sure you have seen, many people blindly go around asking questions without RTFM, so what makes you sure people will take the "testing" label seriously? People may notice the testing kernel label, but when their computer starts having problems, they might not assiciate this with the development kernel and start getting made at KDE/Gnome or whatever for making crappy software, even when the real problem is the kernel.
> Most distros use DevFS + devfsd these days
Name a few... debian? suse?
Although many people have reviewed and fixed notable bugs in the development branch, there are many environments, situations, and hardware can cause bugs. For example, when I installed Redhat Linux on my computer, it would not work with my Linksys NIC. I thought that was odd considering Redhat and Linksys are used heavily in the Linux world. What I found was that my version of Redhat (7.3) was not compatible with version of the Linksys NIC (LNE100TX V4.0). If I had used an older or newer version of Redhat or a newer or older version of the NIC, there would not have been problems. That's why testing needs to be done. This is something that many eyeballs may not have noticed.
Well, there's spam egg sausage and spam, that's not got much spam in it.
FWIW, 2.6 has ksymoops built in now. Not sure about a full-on debugger - I lost track of where that idea went. Last I checked, anyway (yesterday). The thing that will get most people (I bet) is needing to have the right config options enabled for the console and for kernel debugging.
C|N>K
Gentoo uses devfs by default, but only half-assedly. The default devfsd configuration has it generate symlinks to emulate the old device names (i.e., /dev/hda, /dev/tty1, etc.), defeating the purpose of having devfs in the first place. There are a few apps in Gentoo that use the old names, starting with sysvinit (the default inittab uses /dev/tty[1-6]).
In Soviet Russia, Jesus asks: "What Would You Do?"
Well, that's good - 2.6 is testing. That means that it will only be, what, like 4 or 5 years until Debian puts 2.6 in their stable tree? :P And yet, I still won't switch to something else. It's just too good (plus, I have the advantage of not necessarily needing to be 100% stable :).
Therefore I would very much suspect an error in sawfish, that for some timing reason was not causing the problem with earlier Linux. Most likely other X events are coming in at unexpected times and due to some bug it is interpreting them as repeats of the keystroke. I would also suspect the reason xterm does not appear is not because it didn't launch, but because sawfish is busy getting confused by these events and is not bothering to map the window. Try making a shortcut that prints a message to a console before running xterm so you can tell exactly when sawfish decided to launch the program.
It's not true, as the article claims, that making one process look like two doesn't buy you much. The reason is that cache misses are getting more and more expensive: without hyperthreading, a cache miss might cause the processor to wait a hundred cycles. With hyperthreading, we simply switch to the other process, and pay a far smaller cost.