modprobe audit/check-list

[Rob Landley]

On Thursday 24 November 2005 13:16, John Kelly wrote:
> On Thu, 24 Nov 2005 06:20:46 -0600, Rob Landley <rob at landley.net>
>
> wrote:
> > As long as 2.4 can be made to work, I'm happy.  People choose to deploy
> > it because it's smaller and it's tested ... I personally think nobody
> > should be using it for _new_ projects, but that's my opinion.
>
> I was browsing gcc bugs and noticed one where some udel folks were
> benchmarking gcc 2.95 against current, and current was 10 times worse,
> on this particular test.  Every time I browse gcc bugs I see some
> report like that, where gcc 2.95 is the gold standard of performance,
> and current does not measure up.

Agreed.  gcc 2.95 was the result of several years of optimizing specifically 
for x86.  (The whole egcs fork and pgcc and all that went into there, and all 
of it was completely outside the purview of the FSF, so it wasn't badly 
bloated.)

> Same with the kernel.

The FSF ain't touching the kernel.

> When I read the 2.6 changelogs, the developers 
> sound like keystone cops all stumbling into each other.

I've read the changelogs and I didn't get this impression.  It's sounds like a 
completely meaningless statement of opinion to me, based on seeing what you 
expect to see in the tea leaves.

> In 2.6.15, they are making significant changes to the VM!

As opposed to yanking Rik's vm for Andrea's in 2.4.10, you mean?

"to the VM!" is irrelevant in your objection.  In 2.6, they are making 
signficant changes.  Meanwhile, 2.4 has been in maintenance mode for over 
three years (2.5.1 launched in 2001), and Marcelo stopped even accepting 
backports in 2004 (http://kerneltrap.org/node/3980).

> How anyone considers that stable is a wonder to me.

With gcc 2.95 you were talking about performance, now with the 2.6 kernel 
you're talking about stability, and it's all the same to you?

Some of my windows-using friends vastly prefer Windows 98 to XP because they 
consider 98 more stable.  This was _not_ the case when it shipped, but in the 
past 7 years they've learned where the bugs are and how to avoid them to the 
point where they don't even _see_ them anymore.  This says nothing about the 
quality of the code.  On the Linux side, if your primary criteria is 
stability, using 5 year old code makes sense.  Nothing but bugfixes has gone 
into that codebase for what, 3 years now?

Of course I haven't personally seen the stability problems you're talking 
about because my laptop is still running Ubuntu "horny hedgehog" with the 
original out of the box 2.6.10 kernel (out of sheer inertia and reluctance to 
deal with getting radeon video or centrino wireless with a side order of 
firmware working again in a new system).  Yeah, I expect it's got security 
holes out the wazoo but it also has no open network ports, and if it starts 
having trouble I reformat to flatulent badger or whatever release is current 
at the time.  It's never paniced on me once.  I can throw the VM into a swap 
storm it takes it 30 seconds to work its way out of, but under 2.4 my record 
swap storm involved going to lunch and coming back and the sucker still 
wouldn't let me move the darn mouse cursor with a latency of less than 15 
seconds.  (It was powered off at that point.)

This is not advocating 2.6, I'm just saying that using 5 year old software 
you're likely to get what you expect, and if you want a 2.6 fork maintained 
with bug fixes only and no new features, the vendor kernels have been doing 
that for quite some time.  (Has Red Hat Enterprise moved off of 2.6.9 yet?)

> Good thing 2.4 is actively maintained, and relatively stable, in an
> honest sense of the word.

There's an old saying, "The patient's condition has stabilized: he's dead."

> That's something to be thankful for.  :-)

*shrug*.  I test stuff before I ship it.  It's sort of a habit with me.

I don't care how stagnant the tools I'm using are, that doesn't guarante that 
the 5 year old dhcp client will actually authenticate against the strange new 
bugs in the dhcp servers at the client's ISP.  (I get at _least_ as much 
grief from applications as from the kernel, and most of the grief I get from 
the kernel side of things is from drivers.)

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.