On Tue, 2002-01-15 at 08:30, Benjamin Scott wrote: > On Mon, 14 Jan 2002, Ken Ambrose wrote: > > Indeed. But this has held true for ages. Go read the 1.x ethernet notes > > on the 3c501 ethernet card ... > > Okay, this is starting to get ridiculous, but as far as *that* goes, the > 3C501 was shunned not because of the kernel driver, but because it was a > lump of sh*t. We're talking an 8-bit programmed I/O Ethernet card with a > *SINGLE*, *SHARED* TX/RX buffer. It was designed to receive data at the > rate a PC-XT could transmit it, and got overwhelmed for just about anything > else.
Okay, okay -- so I picked an "interesting" example. I was using it to illustrate, though, and I think I made the point. Other vendors have either been dropped from the kernel, or never been well supported, for lack of docs -- just like Adaptec. Ask me how often the embeded ATA-66 controller on my BP-6 motherboard (under 2.2, no less) caused my system to crash. Enough that I finally had to go out and buy a different card (and this was after I did something I'd never done before, or since: I e-mailed Alan, and that was his official opinion). These things (a la the Adaptec fiasco) happen. Sometimes they get fixed, sometimes they don't. > > Ask me how I felt when XFree86 4.0 dropped support for my spiffy > > SGI flatpanel digital display video card... > > Which begs the question: Then why did you run XFree 4.0? :-) Because various DVD-playing software required it, and I wasn't about to back-port. Not to mention that, once it was dropped from 4.0, I'd assumed (incorrectly, thankfully) that it would never be seen again, and figured I'd have to have some sort of solution to go forward with. > > ... rather the fact that for the vast majority of users, it's likely to > > be pretty much as stable as 2.2... > > Perhaps the new VM will help in that department, but prior to the new VM, > I can say that 2.4 was *not* suitable for the vast majority of users. It > would randomly go into swap storms that left the system unusable for > minutes at a time. If so, I am yet to see this happen. Of course, I am using RH kernels, which have been heavily massaged by AC (who was a strong proponent of stabilizing the VM), which might explain why. Perhaps I should have been more explicit -- I don't really trust the Linus/Marcello non-Alan-ized kernels... leastwise, not yet, though apparently .14 and above is doing much better. > > ... 2.4 has some pretty nifty features, to boot. > > As near as I can tell, the only legitimately useful feature is the better > firewalling code. How do you define "legitimately useful?" I certainly consider merged native JFS code, native wireless support, native PCMCIA (which hadn't been native since 2.0.x), etc., to be "legitimately useful." Not to mention, as you point out, stateful firewalling code... though I haven't yet gotten that under my belt. ;-) > > If you want a kernel that takes better advantage of multi-processor > > hardware ... > > The "vast majority of users" have an eight CPU box? ;-) No... but even on my dual-processor boxen, I have seen bettter benchmarks on kernel compiles. A quick sidenote: I *love* MP boxes. Even a substantially slower (say, dual 500 MHz Celeron, my first MP box) can *appear* faster than a more powerful (eg. 1 GHz Athlon) box. Why? Because one processor can be sitting there, munching on your DivX ;-) playback, and the other will happily say, "Oh! Look! Ken's mouse has an interrupt to process! I'll go do that right now." So, unless you're doing intensive number crunching (in which case one fast CPU definitely wins out over two slower ones), I highly recommend MP boxen. And 2.4 is demonstrably better at MP functionality. Granted, it becomes more obvious with "N" processors, where N is fairly large -- but I won't overlook it for "where N equals two", thanks. If I did that, "I'd run NT :-)". > > ... larger filesizes ... > > The "vast majority of users" have single files larger than 2 GB? ;-) No... leastwise, not usually. But more than once, I've been tarring some directory or other... and found that my tar finished at 2147483647 bytes. Whereupon I had to go and find some other way to do what I was doing. Go ahead and tell me that this hasn't happened to you. With 2.4, it suddenly becomes a non-issue, which is *very* nice. > > ... in-kernel HTTP server of static pages ... > > Oh, come on. The only reason *that* was put in was to increase benchmark > scores. If I wanted crap like that, I'd run NT. :-) Yes, it was *driven* by benchmark scores... this doesn't, however, invalidate it as a cool feature. > > ... a somewhat flakier VM ... > > Not that anyone uses the memory manager anyway. ;-) See earlier comments re: -ac/Red Hat kernels. -Ken ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
