Linus Torvalds announced version 2.4.2, and gave the Changelog:

He also said:

Several folks ran into problems compiling this version, and at one point Andrzej Krzysztofowicz remarked, It seems that Linus didn't fully merge some stuff from Alan patches. apparently 2.4.2 broke Minix partition support; Alan Cox and others posted patches, and Alan also suggested as an alternative, simply disabling Minix support in this kernel.

Elsewhere, John Heil asked, Which -ac series patch does this match up with or superceed? ie should this be considered superior to -ac19 ? Linus replied, There is no 1:1 comparison to _any_ of the -ac patches, I'm afraid. The two series are fairly disparate, as they have different intentions. Alan accepts some stuff that I would be nervous about, and sometimes I say "to hell with it, we need to fix this" and make Alan nervous. Alan also added, I'll be merging most of the 2.4.2 changes if there are any I dont have with Linus for the next -ac which will be a 2.4.2-ac1 and thus somewhat shorter. Also in reply to John, Peter Samuelson explained:

Regarding Peter's idea that Linus' tree had stability, Alan remarked, I think the key word is actually probably 'predictability'. The Linus tree is conservative. (IMHO too conservative and probably in his not conservative enough 8)) Werner Almesberger asked, given that there are several patches in your tree that never seem to make it to Linus' tree, would it make sense to flag patches that should go into 2.4 as "Not for Alan; Linus _please_ pick it up" (and to keep on pushing until Linus does) ? Alan replied, Im trying to push stuff to Linus in a reasonably controlled way. That tends to mean the less important or more obscure hardware comes later.

Folkert van Heusden announced a patch against 2.2.18 and 2.4.1, to cause the kernel to randomize process ID creation, instead of use the current incremental approach. Bert Hubert objected that the incremental approach tended to lower the chances that a new PID would be the same as one that had been used recently. In cases of reusing a PID very soon after its previous use, Bert said, the possibility existed that a signal intended for the earlier process would be received by the new one instead. Using an incremental PID assignment, the kernel would have to cycle very quickly through all available PIDs in order to trigger that potential race condition.

Bert went on to say that he approved of the the idea of making PIDs unpredictable, but suggested, What would work is to have cryptographically randomly generated PIDs which would then guarantee not to return a previously returned number within 32000 tries, and also not be predictable H. Peter Anvin replied, It depends on the size of your number space. If you have a 31-bit pid_t (since it apparently must be sign-safe) then you can take random 16-bit numbers from the /dev/urandom code and add to the last used value instead of simple increment.

Folkert told Bert that his code already checked to make sure it didn't use any existing PID, but Bert explained that the code didn't check for recent PIDs, which he felt was the main problem. This made sense to Folkert, and he suggested something along H. Peter's idea, saying, I think random increments (instead of last_pid+1) would be the best thing to do then? Matt Johnston mentioned that OpenBSD had a working implementation of this, and that folks might want to check it out. At this point Sean Hunter pointed out, I have already written a 2.2 implementation which does not suffer from these problems. It was rejected because Alan Cox (and others) felt it only provided security through obscurity. Folkert agreed with that assessment, though he felt that on any given system, taking those kind of precautions would improve security somewhat, or at least protect against the script-kiddies who lacked the knowledge to adjust their attacks to changing circumstances.

Alexander Viro announced:

Peter J. Braam was very impressed, and added that he and Ron Minnich had built a similar feature, though with slightly different semantics. In their implementation:

Christoph Hellwig replied, These changes can be used separately, can't they? I'd really like to use them with Al's more generic namespaces concept. Once thing that worries is that his patch want special privilegs for creating a new namespace and I wonder if we really want that...

Norbert Nemec reported system lockups, when a ramdisk filled to the point that the system would start swapping. Alan Cox replied, RAMfs doesnt use swap. It also in 2.4.2 doesnt have limits. The -ac one uses limits so will stop you totally running the box out of ram. 2.4ac also has the true tmpfs with swap backing. Nicolas Pitre asked which of these kernel would be best under swapless systems, but there was no reply.

Russell King reported that running rsync over ssh would hang the process under 2.2.18 and 2.4.2; Rasmus Andersen gave a link to a similar report, in which rsync would complete but then fail to terminate. He added that he could reproduce this himself under 2.4 by giving rsync a big job, but that he couldn't reproduce it under 2.2; Bert Hubert remarked, rsync problems of this type abound across several UNIX platforms - I had problems like this on FreeBSD, but never under Linux. I suspect that rsync bends or at least stretches certain limits.

Several folks offered possible explanations, but Russell felt he had shown all those possibilities to be incorrect. Eugene Crosser also confirmed the problem for 2.3 kernels, adding, I had a feeling that it was triggered by certain data patterns because it often stopped at the same spot after restart (and therefore I attributed it to a bug in rsync).

Elsewhere, under the Subject: Another rsync over ssh hang (repeatable, with 2.4.1 on both ends), Scott Laird reported a repeatable case of an rsync stall over ssh, between two machines running 2.4.1; running strace on the process would actually get it going again, although it would stall again shortly thereafter, with strace running.

He posted some strace output and various folks tried to get to the bottom of it, but the thread ended inconclusively. By the time it petered out, the general concensus was that there was indeed a kernel bug involved.

Zack Brown asked if the Mosix kernel patches would ever be included in the standard kernel, perhaps in 2.5; Christopher Chimelis mentioned that as far as he knew, Mosix hadn't been ported anywhere but the i386, and Zack replied that this didn't seem like a barrier to entry.

Elsewhere, David L. Nicol replied to Zack's initial post, saying that a better approach might be to create some general kernel clustering features that might be useful to more than one clustering system. Rik van Riel created the linux-cluster@nl.linux.org mailing list and said, To subscribe to the list, send an email with the text "subscribe linux-cluster" to: majordomo@nl.linux.org. He added, I hope that we'll be able to split out some infrastructure stuff from the different cluster projects and we'll be able to put cluster support into the kernel in such a way that we won't have to make the choice which of the N+1 cluster projects should make it into the kernel... Elsewhere, Alexander Viro offered to help with any filesystem work that might be needed by clustering implementations.

Daniel Ridge objected to the whole idea of putting clustering in the kernel. He said:

Albert D. Cahalan replied, You are basically suggesting the often-rejected "split up the kernel" idea. I think the linux-kernel FAQ covers this. Daniel replied:

There was no reply.

Someone had heard that it would be possible to port Wine into the kernel, thereby gaining a lot of speed. They asked about this, and Dan Kegel replied, It's not ready for prime time yet. There is some discussion of the issues at news://news.winehq.com/wine.devel. David Howells added:

The idea of putting Wine into the kernel was considered so ludicrous in , that the proposal itself was made as a joke demonstrating the flaws of trying to put the wrong things into the kernel. However, by , the subject was taken more seriously, and Linus Torvalds indicated that he'd be willing to create kernel calls that would help speed up Wine. Apparently work has continued since then.

Tim Walberg asked if anyone had succeeded in getting either a PCMCIA SmartMedia Adapter (specifically the Viking Components one) or a FlashPath floppy SmartMedia adapter, working under 2.2 or 2.4; Steffen Grunewald replied, http://www.smartdisk.com has a driver (which includes a binary-only library) for FlashPath that you can compile for your kernel. Works fine here (2.2.16) Andre Hedrick replied that he disapproved of the terms of agreement to access that driver, but invited anyone to send it to him for dissection. Elsewhere Andre added, That is going to be a SDA device and will have another form of content protection like CPRM and Linux will not support that superset of features at this time or in the future. SMA's are on the hit list for music by the SDMI. If you want to use it as as standard ATA device cool, but the 0xD{0123} opt-codes are not public yet and fall under CFA.

Brad Douglas announced:

Christian Worm Mortensen announced:

He gave a link to his WRR and WIPL page, but there was no discussion.

Miles Lane gave a link to a NYT article on Unisys, which said that Unisys had no plans to port Linux to their cellular multiprocessor machines. Miles asked if anyone had been working on an independant port, and David Weinehall suggested that several folks might volunteer if Miles would give them the hardware to work on. Joanne Dow also replied to Miles, if these babies are the 32 processor monsters that UniSys has been making recently there IS interest to get Linux on it. But the people I know who have mentioned "interest", mostly from a curiosity standpoint, have their hands neatly tied by Microsoft. Ya see, the developers at UniSys have NT source licenses so they can develop the HALs for the monsters. Microsoft insists that they spend a considerable time away from OS development before working on another OS. So, no Linux port is in the offing, I suspect. The people who KNOW the machine are not allowed to do it. And I can guarantee you that the machines are not well documented at the level a person making an NT port would need. There was no reply to this, but elsewhere, J Sloan replied to Miles, saying, unisys is an example of brain damage and it's easiest to ignore/work around them rather than trying to get them out of bed with microsoft. Nature will eventually take it's course with unisys as it did with Dec. Joanne agreed with this assessment, and Gerhard Mack remarked, Given Unisys' reputation you would think compaq and HP would leave them alone to avoid being dirtied. I think after the gif fiasco most people on the net hate that company.

Zach Brown announced:

Tom Sightler suggested, I'd love to test this on my Dell 5000e (Maestro 2E) but it's pretty impractical for me to return to the 2.2.x kernels. I know you said you'll wait before making the changes to 2.4, but I think you'll get more testers if you turn it out sooner rather than later. There was no reply.