Posted
by
timothy
on Saturday March 11, 2000 @03:20PM
from the culling-wheat-from-chaff dept.

Oestergaard writes: "We're finally going pre-2.4! Linus posted this on the LKML (Linux kernel mailing list): >>I just made a 2.3.51 release, and the next kernel will be the first of the
pre-2.4.x kernels. That does NOT mean that I'll apply a lot of last-minute
patches: it only means that I'll let 2.3.51 be out there over the weekend
to hear about any embarrassing problems so that we can start the pre-2.4
series without the truly stupid stuff. There's some NFSv3 and other stuff pending, but those who have pending
stuff should all know who they are, and for the rest it's just time to say
nice try, see you in 2.5.x. The pre-2.4.x series will probably go on for a while, but these are the 'bug fixes only' trees. These are also the 'I hope a lot of people test them' trees, because without testing we'll never get to the eventual goal, which is a good and stable 2.4.x in the reasonably near future. Thanks, Linus

How stable is the current devel tree? 2.3.41 was fine for me... but later kernels either failed to compile or crashed on boot. Are we going to see a long pre- cycle, or is it relatively debugged already?

From the looks of Linus's comments, it's only a move from the (currently very slushy) pretty-much-anything-goes-if-it-compiles-feature freeze to a (slightly more frozen) already-announced-but-not-yet-fully-included-featu re freeze+bugfix stage.

I don't believe ReiserFS is included (and neither are ext3 and jfs?), and if it was, as an AC pointed out below, it would be pretty hard to take a screenshot, a benchmark or a time to reboot comparison would be more accurate.

There are about 12-15 linux users at my high school out of a total body of I believe 1000. That's pretty good considering that there were only around half that last school year. I am looking forward to burning a few cds and spreadin them around so that everyone there can get kernel 2.4 asap. 2.4 looks to be a really big step forward because I know at least another guy who wants to try Linux on his laptop, but it is afraid that PCMCIA and stuff like that might not work.

Anyone anxious to take the 2.4 plunge, but wondering what has changed might want to take a look at http://lwn.net/1999/0819/a/wwol2_4.html [lwn.net] . It somewhat dated -- August of 1999 (anyone know where to find one more recent?), but hopefully most of its content will still be valid.

I run 2.2.14 on my laptop (from which I'm posting this) and pcmcia works fine. It took a little to get everything set up (cough*X*cough) but once that's done, it runs beautifully. Have your friend check out the Linux Laptop HOWTO if he gets stuck.

I remember reading where Linus had said if he was going to put any journalling file system in 2.4, it would be Reiser, simply because it's the only one that has had a lot of testing. SusE has been including it in their distributions, hence the testing.

I'd have to disagree with this. Programming isn't really required for the pre- series if you're willing to accept failure:) However, a good knowledge of the hardware in your box, and a basic knowledge of lilo are required. Here's an LDP HOWTO [linuxdoc.org] on this. Their stuff is usually pretty good

Yes and no. Remember that even most kernel hackers aren't familiar with every part of the kernel and can't fix everything that goes wrong. There are kernels that should legitimately be avoided by everybody, and then there are those that pretty much just work. Linus is now aiming explicitly at the latter; the kernels near the end of a development cycle need to get used so that bugs can be found and fixed. With this in mind, it's time for everyone to start using 2.3/2.4pre on all the non-production machines you can find. Bugs won't get fixed if nobody is using these kernels.

In answer to the original question, the best places to look are the Documentation/Changes file, which describes what software you need to build and successfully run the latest kernel, and the mailing list, which is archived at www.kernelnotes.org and other places.

In what way will devfs remove the need for the major/minor scheme? As far as I know, devfs only provides a major cleanup of the namespace bloat in/dev. Otherwise, drivers are still referenced by major and minor numbers through the vfs layer.

As far as I remember, getting 2.4 to run with say RH 6.1 is no problem what so ever. Just make dep... and install with your favorite method. A few apps will be hit with quite substantial modifications of the layout in/proc but usually that will not prevent you from getting the system up and running. Changing to 2.4 from 2.2 is much easier compared to the transition from 2.0 to 2.2. If you want to try out devfs, read the docs and install devfsd.

If you do not know how to "get these pre2.4 kernels up and running" you should not be doing it. For those that say there needs to be as many people running these as possible, I say: if a person can't even figure out how to install the kernel, how much help are they going to be in isolating and helpfully reporting bugs?

Different devel kernels are broken and unbroken all the time. Some hardware configurations will work perfectly, while others will crash and burn. Consequently, it is not definitive that a 2.3. (x + 1) is going to be any more stable than a 2.3. (x)

I thought that was already done with oh-some-MS-supporting company (I can look up the name if somebody actualy cares), but not on open source basis:(.

As far as experimental goes, you should have seen the IE (hooked with MS implementation of COM/DCOM services) on some-NIX boxes chewing up resources faster than 1k memory leak in 1-ms timer code (and that's a lot).

I wasn't experimenting with any of the 2.3.x series kernels (last time I fiddled there was with 2.1.x series), but if you take open source definition of experimental (remember experimental ELF binary support) it will work on this kernel and not on next, and work again on next and so on... But the main point is that it WILL WORK! AND I LOVE IT!

It might be on anyones checklist (I don't care about IT drones anyway, since I'm freelancer), but it'll do magic for ME AS A PROGRAMMER. Like (probably, I hope I'm wrong) most ppl. I make my day to day buck with MS products (let's face it: MS sells no matter what you say or do -- fortunately same goes for linux/GNU/...:)). The way it'll help me because I will be able to propose more cost efficient business solutions to potential customers. If I can take their already bought MS transaction server and use it on business tier, put linux on presentation (Web) tier and connect them without much hassle (DCOM comes as a glue) that's what I LIKE. Options for this kind of close integration will be endless.

As far as dependencies go, linux already has orbit which provides component services and things depend on it. The point is no things depend on it. MS might like it a lot, people around me like it a lot (personally I hate it a lot), but if you take away (D)COM from WinNT platform you basically can't even send 'A' to ASCII printer (Win95 comes off beter by being built on top of DOS and gives you option of doing "echo A > LPT1:" but that's where it ends. You might find it a bit tricky [but not impossible] to send FF that would eject the page). I can strip linux (ANY linux) to core and put it on almost any CPU gifted with reasonable amount of RAM.

Bottom line is that this will give my kind of comunity (day to day people that happen to live off computers) power of choice and this is what's all about! GNU is about choice, Linux is about choice, open source is about choice. I like having choices, options, brain food and http://www.userfriendly.org/! If 2.4.x kernel will give me that or any other choise to think about, I'll be first in line to grab it from nearest mirror!

Sorry about the blatant self-promotion here, but if you want to run the new kernel, but don't have a spare machine and are worried about what it might do, check out my user-mode port [sourceforge.net]. It is the 2.3.51 kernel running in a set of Linux processes. No need for a spare machine, and it doesn't have access to your hardware or filesystems, so it's less worrisome than a native kernel. Downloads are available here [sourceforge.net]. Jeff

I was under the impression that COM/DCOM was some sort of an object-oriented system for remote procedure calls (I guess if you're using objects that should be 'remote method calls'..)CORBA and RPC don't need kernel support. (well, aside from requiring some sort of network layer, but the kernel doesn't have to know about them) What's special about COM that requires it to go in the kernel? Why not put an NFS server and an httpd in the kernel while you're at it..er, nevermind..

Does anyone know what the state of e2compr support in 2.4 will be? I read in Kernel Traffic that it's not ready for the official kernels, but that someone finally explained to the e2compr maintainer how to port it to the new buffer-cache system..but I haven't heard anything that indicates that such porting is actually occuring. I'm starting to think that I may have to decompress my whole hard drive to try this..which may be difficult given that I'm operating close to capacity;-)

I don't know about ReiserFS and ext3 file systems, but jfs (if you're referring to IBM's jfs) is at such stage that it might appear in 2.5.x series, but probably not at the start of the cycle. Last time I checked the porting page, they were just able to read directories, no chances of even reading files in very-close-future.

It was even mentioned that jfs will cause some major changes deep in kernel and that will probably make it candidate for 2.7.x series more likely than 2.5.x.

I have an old 486SX laptop that I use as a terminal to my main Linux box over an ethernet link. It runs mulinux using kernel 2.0something and drives a PCMCIA ethernet card with no problems (well it did until my 12 month old son dropped it on the floor, but that's another story.)

There should be PCMCIA support in 2.2 kernels, unless it's a winmodem (i think most laptop modems are?), which isn't suported by anything except Windows AFAIK.

At the begining of this cycle it was made very clear, in lots of mediums from/. to the 'normal' press that the developement cycle was too long. Less features were added to the kernel, and some that are 'almost' ready that would have held up 2.4 just diddnt get in. This will give everybody some new feature now, and make the upgrade less painful.

For you to have gone to the effort of finding those date but missed this philosiphy change.. well I wonder:)

I got 2.3.50 working just great on Slackware 7. Holy crap what a difference there was in NFS. I NFS mount SCO servers. It went from slug-like to lightning! I plan on building me up a Slackware 7/Xfree86 4.0/Linux 2.3.51 system this weekend. Woohoo....

A) I could really care less. I use Windows for any 3D stuff. B) The new kernel better not have nVidia support. OpenGL in the kernel would not be a good thing. (Or are you talking about the hardware independant DRI driver?)

It could be argued what is right and what is wrong way to do it. I (for nice example) used to be C/C++ freak programmer (I still prefer C for personal stuff, that I try to write cross platform) and hated all those VB/Delphi/Builder "babies". With time I was forced to use other programming environments and languages and I found out each and every one of them has distinct advantages and handicaps (you just don't get REAL caffeine by drinking de-caf, no matter if you're in NYC or in Calcuta).

At the moment I'm on project involving MS backends, MS tools, MS components,... basically all MS. It's just the policy of customer to use MS only stuff. I can't go to the customer and say that all his systems are piece of crap, since I've been working with them for some 8 years now, I can't tell him to trash all his existing solutions so I can bring in one open source solution, I can't make a product that won't interoperate with existing software. That is privilege of MSs, IBMs, Suns and others.

What I learned is that nothing can be done by hitting your head against the wall. Yes, it might be rotten publicity, but are we employing PR people to take care of our "faces" (used in japanese sense of the word) or are we trying to do something for ourselves! -- Exclamation, not question mark.

I think we're trying to do something for ourselves. KDE has it's licencing quirks, but it's still popular. It obviously didn't die of bad publicity. Gnome has no licencing quirks and it's popular. What's the catch... I can have Corba, I can have DCOM, I can have my own protocols running around wild... The point is that user doesn't care what does it run on as long it runs well. COM, DCOM, Corba,... are just tools to achieve that. Nothing more. No bad PR. If MS doesn't want to comunicate with other solutions, it's their problem. Right now it's my problem as well... If DCOM/Linux takes off, it won't be my problem any more [I still like MS DevStudio though... No Linux viable counterpart yet:(].

I think that those people running the dev kernels could enlighten us about a few things. (Those of use who don't use Linux or don't feel like DLing 12 megs of source and ripping out our current kernel.) 1) Is it an FASTER? 2) How is the stability? Since this is a pre release, it better be pretty stable. The 2.2.0pre series laster 10 kernels or so, so this is fairly close to release. 3) Any new features that would warrent upgrading (aside from the afformentioned speed/stability) I also have another question. What kind of resource usage are we looking at in this kernel compared to the 2.2x series? I say this because I have yet to see a major OS vendor pull a Be and actually make an already memery efficiant systems use even less memory at the same time it added a bunch of features.

What, you don't use Be for 3d stuff? You use Windows for 3d and you could [sic] care less? Why then do you use any other operating system at all?

Just talking DRI here. As of 2.3.4X only 3dfx and 3DLabs boards may use DRI. However the specs to implement DRI are available for Ati and possibly Matrox. DRI is necessary to give user space processes using Mesa or real OpenGL direct access to the video hardware. When you build a 2.3 kerrnel you'll see what I'm talking about. There's currently no support for Nvidia boards to use the DRI interface. Only Nvidia can enable this because of their hostility regarding open source hardware support. And they haven't been very timely with working Glx modules (try their latest? ugh!) or DRI.

I'd like to know what Nvidia boosters think about the route Nvidia has taken with regard to Linux and open source--are we happy campers? Do we love our closed spec, obfuscated source buddy Nvidia NOW ??? And how do you imagine you'll feel when 2.4.50 comes around enabling, say fast journalling and other goodies, but changes to the DRI interface break direct rendering for Nvidia hardware again? And no one but Nvidia can remedy the situation ? Well Be-fan you may go back to using Windows and be happy, but Windows has no place on my drives.

Are they going to integrate the code for the Netfilter [samba.org] modules into Linux 2.4 or do people need to download/compile/install separate Netfilter modules if they want to do some NAT'ing? Somewhere I read that the Netfilter team goal is to get it into 2.4 but the current version (0.1.18) doesn't even compile with kernel 2.3.51 source. I guess they have to hurry up if we want to have NAT support out-of-the-box for 2.4...

So we've run about the typical time elapsed between dev kernel versions but the current kernel version is half that of normal so it makes me wonder if we're ready yet.

the amount of changes from one verion point to the next is not always the same. you should rather compare times versus changes. considering that the changes from 2.0 to 2.2 where a lot more than what will happen from 2.2 to 2.4 those times just seem reasonable...

I started using the devel kernels on three of my machines at 2.3.42. It ran fine, a few of the later versions had compile problems for me, so I just skipped them. I'm currently on 2.3.49, and it runs fine. 2.3.50 fails with a compile error. I'll give 2.3.51 a shot.

I think they're more than good enough for non-critical boxes. YMMV, of course.

What are you worried about? If 2.3 looks totally different from 2.1 and 1.3 we must be in good shape! 1.3 was plagued by the release-a-day syndrome (remember the YAGWRs, yet another greased weasel releases?) and 2.1 just bit off more than it should chew in a release. It seems to me that in 2.3 we have a nice set of new features and best of all, we get to see them in a reasonable amount of time.

One of the things that was a big headache for a lot of people going from 2.0 to 2.2 was firewalls.

Well one of the changes that people don't appear to be aware of was that it was completely rewritten again.

But relax, the new stuff was designed to be something to be easy to develop stuff on top of. So 2.4's firewall code will transparently work both like 2.2 and like 2.0 did, and there are hooks to do virtually anything you want.

But still if you want to find out what changed, wander on over to the Netfilter [kernelnotes.org] page.

Yes, although requests to the majordomo in charge do need to be authenticated (I.e. you send your request, and then reply to it's authentication request it sends you, or it ignores you). This prevents you maliciously subscribing all your enemies to this, somewhat high-traffic mailing list.

I do join from time to time, although I'm not listening at the moment, mainly because I'm currently snowed under doing other things, and my work mailbox is pushing back the boundaries of disk space mathematics as it is...

The problem is, using the current version numbering scheme, it'll take forever to get to Linux 1776.0, which of course is when the revolution really begins.:) (Yes, I realize that was extremely US-centric, not to mention historically inaccurate...)

just take a look at the Linux on Laptops [utexas.edu] page. it was vastly helpful setting up my thinkpad (of course, most IBM's are easy, becasue they use pretty standard hardware -- there's even a Linux driver for the Lucent Winmodem). in any case, you'll get an idea of how hard/easy/impossible it'll be to set up. in most cases, it's pretty easy, especially if there's a CDROM drive built in, (I don't have one -- ftp install is your friend) except for X.

and of course, there are all these helpful/. people around... everyone I emailed about my thinkpad was very helpful (thank you, if you're reading this). nice thing about the Linux community -- there is a Linux community, and people are really nice about helping.

I think that those people running the dev kernels could enlighten us about a few things. (Those of use who don't use Linux or don't feel like DLing 12 megs of source and ripping out our current kernel.)

You don't need to rip out your current kernel - I have 2.2.14 sitting around as a backup on some of my systems that run 2.3.

1) Is it an FASTER?

Visibly, especially if you have an SMP system.

2) How is the stability? Since this is a pre release, it better be pretty stable. The 2.2.0pre series laster 10 kernels or so, so this is fairly close to release.

I haven't had problems, although things newer than 2.3.48 have been unusable for me for various reasons (not stability related, though). YMWV (your mileage *will* vary), of course.

3) Any new features that would warrent upgrading (aside from the afformentioned speed/stability) I also have another question. What kind of resource usage are we looking at in this kernel compared to the 2.2x series? I say this because I have yet to see a major OS vendor pull a Be and actually make an already memery efficiant systems use even less memory at the same time it added a bunch of features.

The biggest non-speed related advantage is netfilter (a replacement for ipchains that's quite a bit more efficient). Everything else is for performace, scaleability, or both.

On the memory front, it's a mixed bag between taking up less memory or taking up more. The kernel marks more memory as unusable in 2.3 than 2.2 (dmesg indicates that that memory is where ACPI sits, even though I have ACPI disabled on the motherboard).

If you don't care about Linux, and you don't know what XFree86 is, then what kind of nerd are you supposed to be? Tell us WHAT YOU would want to see on Slashdot. and if you don't want to hear stories on certain subjects, there are ways of moderating them down in the preferences, so stop whining. If you don't like it, go someplace else. yeesh

So 2.4's firewall code will transparently work both like 2.2 and like 2.0 did.

Yes--If. That is if you have installed Netfilter and configured it for backwards compatibility. Trying to run ipchains rules on 2.3.xx kernels will just return messages like "The use of Ipchains is not supported by this kernel." Enabling packet filtering (which is the replacement for ipchains according to the kernel menuconfig help file) isn't sufficient to allow ipchains to work transparently. Or it wasn't, ca. 2.3.42

I am just a user out there in TVLand, and I've been kind of hoping/petitioning certain sites like Linux.com to to run an article on transitioning from 2.2 ->2.4::ipchains -> netfilter+iptables. It would make a great newbie HOWTO for someone who's smarter than me. Which is an open invitation for lots of you geeks out there to show us how brilliant you are! So far i've just gotten polite refusals from the sites I've contacted.

Will the need to have firewalling for 2.3xx overcome my innate laziness and stupidity before some perspicacious, valiant soul writes a guide for the netfilter-perplexed? Lord I hope not. That shit be hard to read you know what I'm sayin'?. Will I be hacked meanwhile? (If you want know what it's like to be buggered with Comet cleanser lube, just try it.)

Most current version of netfilter is 0.90.4. It seems that they are currently meging the stuff into the kernel tree. The last kernel known to work with 0.90.4 ist 2.3.48 (2.3.49 can be made working with a patch from the netfilter list).

And MS-Windows 98 has had it for over a year. What is your point? This is a Linux article, talking about features in current Linux development is on-topic. Starting "My OS is better then your OS" flamewars is not.

This probably isn't good enough for Linus, but I've ran with Ext3 for a good four or more months without a hitch. Maybe one, but I blame it on a HD's last days. I replaced it and all is well since. For heavy duty testing, I'd say rpmfind.net would qualify, though I'm not sure how old the message is on the front page. If any of you know what you're doing, and wondered about ext3, I'd say give it a whirl, no more 15-minute fscks when the power to my apartment goes out.;)

A) I don't use Be for 3d stuff because it doesn't have HW accelerated 3D for anything but 3dfx; Just like Linux. B) I don't like using windows for 3D, but it has the only usable 3D modlers out there. (BTW the guy who designed the Blender interface was on crack.) C) I love our closed spec obfuscated source buddy nVidia still. I'm a pretty happy camper. My card runs fast as hell, and I have no religious attachment to Linux/Be/etc. D) I think you missed the subtlety abou the DRI thing. They only DRI compenent that goes in the kernel is the DRI kernel driver. That is accelerator non-specific. Thus it will work with any card, it is just a system for the DRI driver to communicate through the kernel. It is a symantical thing, no DRI support for a particular card acutally goes in the kernel, it is loaded by the X server which uses the hardware independant kernel driver to talk to the hardware. I really don't care if Linux has no place on your drive. If you aren't willing to use a GeForce just because it doesn't run on your precious Linux, thats your problem. Don't, however, blame nVidia for it. Their product kicks ass. Have you ever run 3D Studio on a GeForce? You'd think you were on an SGI! They will have accel. OpenGL on Linux soon. If you have some problem with it being closed source and propriotry, fine. But I'm just sitting here waiting for Redhat 7 and nVidia's super tweeked OpenGL support. (BTW nVidia's drivers won't use DRI.)

Geez, sorry. I'm using someone else's weird trackball, and I thought I had clicked it down and had not. Combined with the fact that Slasdot was actually being responsive, I didn't have time to cancel when I saw that. Maybe +1 should not be default.

Your email host is probably in the ORBS database of public relays (which are happily used by spammers to hide their traces). In this case vger ignores you. See http://www.orbs.org/ to find out if you're in the blacklist.

2.4 will be the first stable release with UDMA66 support included with the source. 2.3.x (I don't know what the earliest version that had it was) also has it included. There is also a patch [kernel.org] for 2.2.x. Make sure to check the documentation there.

As for four IDE buses, yes, they will be supported. I've used both 2.2.14+patch and the 2.3.x with a Promise UDMA66 add-in controller along with the 2 controllers on my motherboard with no problems. The ABIT motherboards are also supported by the drivers.

So we've run about the typical time elapsed between dev kernel versions but the current kernel version is half that of normal so it makes me wonder if we're ready yet.

Yes.

Linus set out to only include a limited set of stuff in the new kernel, so that that thumping huge 27-month gap wouldn't happen again. The fact that there have only been 51 blockpoints is a reflection of the decreased new-feature count. As it is, he'd have liked to have been done by December, but you know how things go... as it is we're getting one a year and being lucky to do so, at this rate.

It's still a helluva job, and everyone hacking on it deserves every scrap of recognition they get, in the form of long green or otherwise.

There's a UDMA patch available for the 2.2 kernels. It's linked to in the UDMA mini-howto (see ldp.org). It's basically the same as what's going into 2.4 (aka, in 2.3 right now). However, I haven't had any luck getting it to work on my ABIT BE6.

They've had that for a while now. If you look in the Makefile, you'll see that `uname -r`=2.3 gets mapped to the 2.4 defines, so for a while there I was compiling a module for a 2.4 kernel! I went back to the stable because I had some very serious filesystem corruption (like stuff in/lib... ick!), giving me a good excuse to change distros to Debian.

On the subject of sound, I noticed that Debian does not have a save/load of sound settings (volume in particular) like Red Hat and company do. So I wrote my own little script to do that. If you want it, e-mail me, but it's really very simple so you could probably write it yourself. Another Debian quirk -- ahem, feature -- is that the sound module is not loaded automatically like in RH, but if you put it in/etc/modules with all other modules you want loaded at boot time, there it will be. If you have to give the module any parameters, you can do it there or put them in/etc/modutils/$modulename (I have in./ne, 'options ne io=0x200', to match my isapnp setting it to io 0x200, for example).

If a person cannot figure out how to read and assimiliate the abundance of information regarding the downloading, configuration, and installation of either the Stable or Development kernels, what I said above still applies. If they can figure out how to do that, then they know how to compile and install a development kernel, and consequently, what I originally said would not apply to them anyway.

The LKML is very high volume - you might want to look at the archives first. Another *EXCELLENT* site is Kernel Traffic, http://kt.opensrc.org, where the main topics are summed up each week. Do yourself a favour and start over there.

The package you are after is called "gom", and once you manage to configure it properly, it will load/save mixer settings on reboot.

I had it working with my old SB16, but since i upgraded to an sb-live i havent been bothered getting the module "installed" correctly. (ie i insmod -f/usr/local/src/emu10k/emu10k.o every reboot by hand..)

On that subject... anyone know the status of an SB-Live driver ever being included in the kernel? Its no longer a binary only module, and I know Alan (cox) has been working on the driver a bit... Its just a pain to recompile/re-download it every time you upgrade kernels...

Hans Reiser very recently posted the following in response to Linus pre-2.4 announcement. This announcement created a largish problem for reiserfs, as this implies a true feature-freeze when reiserfs is so close to 2.3.

I do hope Linus accepts this last minute reiserfs addition. This is one component that would be of great benefit to Linux.

We now have a working port of reiserfs for 2.3.49, and I am not sure whether you consider us pending. Can reiserfs get in? Putting us in as an experimental file system until we are accepted by the community as known stable is just fine. Our 2.2 version seems to be accepted by the users on our reiserfs mailing list as stable.

We'll port it to the new 2.3.51 starting immediately, the 2.3.49 version will hit our webserver in a few hours.

Sorry we tweaked longer than we should have, and created inconvenience for you.

I really don't see your point in your.sig "Hiroshima '45 Chernobyl '86 Windows '95". Surely any true blooded American redneck should be proud of these glorious defeats of, in order, the Japanese Importers (danged $#@$ car, no trucks), the Bears in the Woods (for not being Beers in the Woods)(*) and the Computer Hackers. Are you insulting our flag?

;-);-)

Please, no one take offense, not even (or perhaps especially, given the size of that gun) the American Far Right.;-)

Please note that in the Real World (Patent Pending), both Chernobyl and, I suppose, (some of) Hiroshima/Nagasaki have my sympathy.

Though I agree with some of your points, I want to make one of my own...

It makes me laugh to think that a humanities journal would have reviewers. To do what? What makes for a good article? Once again, what does "good" mean for humanities papers? Yes, I said humanities not just postmodernism.

I don't see why a humanities journal shouldn't have reviewers, if only for the simple reason that it'd be silly to pull the top twelve papers off the incoming pile and call it a journal. Maybe the reviewers wouldn't necessarily play the same "objective" role that they do in a more technical journal, but no one that I know of (except the postmodernists, which was the point of Sokal's stunt) is making any such pretenses to "objectivity".

Going to 2.4 is all well and good (a wonderful accomplishment, don't get me wrong), but can we anticipate a stable 2.3, so some of us non-devel wusses out there in the world can get usb support on our machines? I'm frothing at the mouth at the thought of 2.4's full USB support, as well as all the networking goodies in store, but i'd like to see a stable 2.3 come out sometime soonish.

Now if they can just get the crypto support working, I might upgrade. The last working kerneli patch was for 2.2.13.

Agreed. Encryption support should be in the base kernel, and it's a pain that it can't be because of politics/paranoia. I've upgraded anyway to fiddle around with USB and the improved firewall support.

Does anyone want to comment on doing the modifications to a new kernel themselves? In general, does it require detailed knowledge of the kernel or is it mostly a cut-and-paste operation?

(Yes, I realize that it depends on the kernel...I'm interested in knowing the general case.

> If a person cannot figure out how to read and assimiliate the abundance of information regarding the downloading, configuration, and installation of either the Stable or Development kernels, what I said above still applies. If they can figure out how to do that, then they know how to compile and install a development kernel, and consequently, what I originally said would not apply to them anyway.

Agreed. One should first understand the basics of downloading, configuring and installing the Stable or Development kernels before fooling around with them. People have to realize that fooling around with a Development kernel isn't some kind of game, and if you think it is, you've have no business messing with them.

The trouble with that plan is that the whole reason to bang on these pre-release kernels is so that faults can be caught and squashed when the real one is released.

If you tried to log a fault with a user-mode kernel you'd not get very far on the lkml. Worse, you're going to cause confusion and dilute the testing process.

The only benefit would be if you were an absolute testing god, and could weed implementation bugs out from the inherant kernel bugs, do some fancy debugging from the working system to the broken one and send the lkml a proper fault analysis and patched code. THEN I'd be impressed.

This question does not make any sence. 2.3 is a development tree (much like 2.1). 2.2 and 2.4 are the stable trees.

By convention, Linux kernels with the odd minor number (as in 2.1, 2.3, etc.) are development kernels (read: not stable, constantly changing). Kernels with even minor number (as in 2.0, 2.2, etc.) are stable (only changed due to bug fixes). So the "stable 2.3" is 2.4.

If I had any mod points I'd mod this up... whoever moded this comment down needs their head examined. COM and DCOM are one of few technologies to come out of MS that are actually quite good - even tho they take a bit of setting up.

Do you have to load the soundcore module first in debian? Just a bit curious. Basically I added this to my/etc/conf.modules

alias sound soundcore post-install sound insmod emu10k1

And my sound starts up fine. I would like to look at that script though cause right now I just load gmix when I start X and it restores settings just fine but it would be nice to have it done after the module is loaded.

There is a reason Matrox, ati and 3dfx have taken the pledge to be open. They are either tiny in the case of Matrox, or dying in the case of ATI and 3Dfx. A market leader has no real incentive to support Linux until it becomes big. And when it does, they still won't need to open the source. Corperate users really don't have the time/resources to hack a graphics driver. Second, I'm pretty sure the nVida GL will not use DRI. They made a statement that DRI was not exactly appropriate for their graphics pipelines. Most likely, it wil just be a patch to the kernel. I don't play Quake that often. I do, however, have a problem with not using my hardware to its 100% just because some OSS guys want their precious, divinly inspired idea to succeed. Hey, there is nothing ethically ambigious about my point. I could care less if their wasn't a single Open Source driver on Linux. You may, and I have nothing against that. I just want my hardware to work, and work at 100%.

Just because it's a pre does not mean that it is stable at all. It merely means that there will be no more non-pending features added. In other words, the focus will be on making it stable, rather than on adding new features. Consequently, this pre/2.3.51 should not be expected to be any more stable than 2.3.50 or any other 2.3.x It is merely the beginning of making the kernel stable for 2.4

All minor-odd numbered kernels are designated Development, a tree where new features can be added to the kernel without sacrificing stability. All minor-even numbered kernels are designated Stable. Consequently, by the very definition of the numbering of Linux kernel's, a 2.3.x kernel cannot be Stable.

Regardless, the very process by which one would make the 2.3 kernel stable would produce a kernel for the 2.4 kernel tree, and consequently be a Stable kernel.

If all you want is USB support, there are patches to add USB support to the current Stable kernel, if you just look around for them.

This definitely is an interesting phenomenon, but I don't think it indicates that the new kernel might not be ready to see the light of day. If you think back to who was using Linux in 1994, and who's using it now, or, rather, who was aware of it then and now, there is significantly increased awareness now. I think the shortened development time is due to more eyeballs.

1. All changes to/etc/conf.modules get wiped out when you do a update-modules (some package installations may do that, possibly the kerenel package; I don't know). Make all local changes in/etc/modutils/(whatever file is appropriate). It does what is equivalent to a run-parts in that directory, except it filters by architecture. 2. Depmod should handle all module dependancies, and when modprobe comes and loads the sound module, it'll see the dependancy, and automagically load the depended-on module first. Instead, in/etc/modutils/aliases: alias sound emu10k1 and in/etc/modules (this does not get update-modules-ized AFAIK): sound And you should be set. 3. See the other response to my comment for a real Debian package that does the same thing as my script.