[SGVLUG] debian linux kernel -- jump 2.2 to 2.4 instead of 2.6?

[Robert]

For what it is worth:

I still run Debian stable quite satisfactorially using 2.4.31... perhaps
going from 2.2 to 2.4 would be less painful then jumping from 2.2 to 2.6?



>
> If an older module was written in a way that was marginally acceptable
> in the past but is now incompatable, then I'd support the "upgrade or
> die" philosophy [of course, I don't know offhand the quality of the
> module in question nor what actually "broke" between 2.2.20 and now, but
> I suspect that any fix to the 2.2.20 version would be significant.
> Also, I just realized what you're saying (or implying?) is that you're
> trying to load a 2.2 version of a module in a 2.6 kernel -- that sounds
> extremely suspect to me.  Is there no "version 2.6" of this module?]
>

>
> My previous comment about the "price of progress" is the fact that the
> kernel [should be] doing /significantly/ more now than in the past.
> Overall strategies and methods may have changed, so it's not surprising
> to see different (and generally longer) times to accomplish the same
> thing as in the past.  The article I referrenced did point out, however,
> that something as simple as an "fopen" was being performed some 80,000+
> times!  Each fopen, in turn, would end up calling a "walk the directory
> tree" routine, which then gets down to (possibly un-cached) disk reads
> and associated I/O.  Some investigation into this revealed that things
> like .conf files were being repeatedly opened, parsed, and closed by the
> same process (as opposed to perhaps caching the information retrieved to
> avoid further fopens), so there was an underlying philosophy problem [of
> referrencing a file on disk /every time/ to evaluate a configuration
> parameter instead of storing the result locally] that is now bordering
> on the "extreme" when spread across /every/ kernel initialization
> process.
>
> But, as pointed out elsewhere on this thread, there is a trade off being
> taken into consideration: if the /only/ time a procedure ends up being
> "wasteful" is during startup, then it is unlikely to be optimized or
> "repaired" because the net effect of fixing that process is negligable
> over the "uptime" of a given system.  OTOH, if improving some kernel
> startup process /also/ improves day-to-day operation of that process,
> then by all means optimizing or "fixing" that process should become a
> priority.
>
>


-- 
"Knowledge is Power" -- Francis Bacon

Robert Leyva
mrflash818 at geophile.net