bcronje at gmail
Dec 18, 2009, 1:42 AM
Post #10 of 10
(1413 views)
Permalink
|
Well said Jaime!
On Fri, Dec 18, 2009 at 11:19 AM, Jaime Nebrera <jnebrera [at] eneotecnologia
> wrote:
> Hi Mick,
>
> > 2.6.18 from redhat was just updated about 10 days ago.
>
> Thats true. RH kernel is the most stable, best supported most extended
> in business in the world, but ...
>
> > its based on a kernel thats 3 years old, but its entirely modern and
> > for those using rhel, centos or oracle linux its basically the defacto
> > standard in enterprise linux, and the centos/rhel/oracle kernels are
> > probably the most deployed linux kernels out there in non-desktop
> > roles.
>
> I fully agree with this but i didnt say its kernel was outdated, I
> said "their kernel becomes quite outdated in some areas (like
> networking)" and you have to fully agree with me on that.
>
> If you want proper multiqueue in both RX and TX, if you want latest
> netfilter with the xt_ stuff, if you want ... you cant use RH. Of course
> they DO backport specific features into their kernel (fe. they
> backported RX multiqueue or in their latest release GRO) but again not
> all of them. Specifically they wont backport anything that means
> changing the way the kernel used to work. If it means an alternative way
> then they might consider but if it means breaking existing stuff, they
> wont.
>
> Precisely thats their beauty, rock solid environment, no nasty
> surprises. For example, we just tried to compile a particular card
> driver in Ubuntu 9.10 (2.6.31) and discover they have changed some data
> structures and wont compile. With RH, if it compiled in 5.0 you can
> pretty much swear it will compile in .1 .2 .3 .4 and .whatever :)
>
> > kernel-2.6.18-164.9.1.el5 (Dec-9-2009) is the STANDARD enterprise
> > linux kernel, its everywhere I look in datacenters that I have contact
> > with.
>
> I agree
>
> > I strongly discourage ignoring the 2.6.18 based kernel, and this also
> > happens to be the kernel that xen-source is written against at the
> > moment.
>
> I'm not against not supporting it, if you recall my first email I
> particularly said I would like it supported precisely for the same
> reasons you are making.
>
> At the same time I understand not all the features could work.
>
> I just saw Luca reply on this topic to you, and you see the point.
> Even more, even if he was willing to do so it would be hard to do it
> "the Red Hat way". I mean, to try to solve this most surely you would
> need to patch and compile the kernel which means loosing warranted
> compatibility with all their ecosystem and more important, support.
> Those are precisely the reasons you are using RH so it makes very few
> sense.
>
> Again, maybe the docs should just say: "RH whatever is supported BUT
> the following capabilities wont work ..." either in pf_ring or tnapi or
> whatever. "To fully exploit this software capabilities you need at least
> the klernel X.Y.Z and the following hardware capabilities ..."
>
> I see a lot of questioning to Luca on respect to RH and as he has
> said, he should not loose its very precious time in trying to discover
> what is going on with something that doesnt match its minimum
> requirements. He should be focused on adding new capabilities !!! :D
> that by the way are much more fun.
>
> --
> Jaime Nebrera - jnebrera [at] eneotecnologia
> Consultor TI - ENEO Tecnologia SL
> Pol. PISA - C/ Manufactura 6, P1, 3B
> Mairena del Aljarafe - 41927 - Sevilla
> Telf.- 955 60 11 60 / 619 04 55 18
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
|
