Wow! Lots of responses. Thanks to all for your comments. Rather than write about 15 separate replys, I'm going to address most of the points in this one mail.
Greg Madden <[EMAIL PROTECTED]> wrote: > Two programs that from a user perspective cause workarounds are > xcdroast/cdrecord/mkisofs & vmware. Each one is compiled for one kernel > version. Switching causes them to not work until recompiled or new > modules generated (vmware) If you are using Woody the 2.4 series works > well, smp support is better. VMWare isn't an issue; cdrecord and mkisofs are. I just installed them a couple of days ago on a 2.2 kernel, so I've already rebuilt them for 2.2. I guess I can just swap those packages in and out, but that's kind of a hassle. Still, once I install 2.4, I only really intend to go back to 2.2 in an emergency. When you say SMP support is better: are you referring to the fact that 2.4 scales to a higher number of processors, or will I actually experience a performance boost on my dual Athlon? dman <[EMAIL PROTECTED]> wrote: > If you use the packages provided by Herbert Xu, you'll find that apm > and the cd driver are modules now. Add them to /etc/modules to > restore their functionality. The Deps will ensure your modutils is > new enough to handle it. The other difference is using an 'initrd' in > the boot sequence. I don't know how to configure lilo for it, but > grub is trivial. Thanks for the warning about the CD driver; that would have been a surprise. Does APM work for SMP systems on 2.4? You can enable it under 2.2; it just doesn't do anything. I used to do initrds under lilo when my root partition was on a SCSI disk, so I can handle that part with no problems. (I've also been meaning to investigate grub for a while, but that's a separate issue.) > For your firewall, load the 'ipchains' modules (or whatever it is > called) to continue to use "ipchains". You can't mix ipchains and > iptables, though. I have a separate firewall machine running potato, so I can play with iptables until I get used to it. (In fact, that's one of the main reasons I have a separate firewall machine.) Paul 'Baloo' Johnson <[EMAIL PROTECTED]> wrote: > I would highly recommend ext3 at this point, just make sure your > e2fstools are the current version (in woody? sid?), and once you've > recompiled, tune2fs -j /dev/(your partition goes here). Edit fstab so > ext2 is now est3, and viola! You're using a journaled, fast > filesystem. I think I'll keep my filesystems at ext2 for now, since I may need to reboot under 2.2 in a pinch. When I'm reasonably satisfied that 2.4 is OK, I'll probably move up to ext3. In another message, Paul also said: > Moderately faster (YMMV) virtual memory system (>2.4.10), better > hardware support, and compile times stretching into the weeks on a > 386. 8:o) Well, I have a dual Athlon 1900+; do you think compile times will be a problem? :-) (make -j is your friend.) Paul Smith <[EMAIL PROTECTED]> wrote, in response to my question about /dev changing: > That is only if you enable the dev filesystem, which is still beta, > not enabled by default, and probably not recommended. This is probably the biggest issue; I've gotten several conflicting recommendations about devfs/devfsd. What are the advantages of going to the new devfs/devfsd? I haven't really paid much attention to the buzz about this issue, although I gather it generated some controversy early in the 2.4 series. FWIW, the hardware on this machine doesn't change all that often; USB currently isn't an issue, as I don't have any USB devices. So: stick with the old dev, or use the devfs with devfsd running in compatibility mode? Jeffrey W. Baker <[EMAIL PROTECTED]> said that in his experience, devfsd in compatibility mode didn't create the necessary devices for SCSI hard drives. I've got one of those, although nothing critical is on it at this point. What would I need to do in order to get these devices back? Thanks again, Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
