All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aleksandar Milivojevic <amilivojevic@pbl.ca>
To: "netfilter@lists.netfilter.org" <netfilter@lists.netfilter.org>
Subject: Re: linux-2.6.9-rc1 compilation and configuration issue (fwd)
Date: Wed, 08 Sep 2004 15:46:24 -0500	[thread overview]
Message-ID: <413F6FA0.7020407@pbl.ca> (raw)
In-Reply-To: <1094672264.23966.37.camel@nostromo.bgsecm.com>

Jose Maria Lopez wrote:
> But then we won't have so many upgrades in the kernel, and some of
> this upgrades are needed, because some of them are for bugs. What
> does Sun do when they found a bug in the kernel? They probably give
> their customers a kernel upgrade. The same can be said for Linux, but
> with more frequent upgrades. You have to choose, having stability in
> the kernel structures to have third party modules easy to deliver or
> having new features more frequently.

Sun produces a patch for a bug that doesn't break existing third party 
modules (and, usually, same is true for Linux).  And it doesn't require 
you to recompile any third party modules after you install it.  Sun 
kernel patches include the kernel core itself, and if bugs were in 
modules, it also includes the modules that need to be patched (for bugs, 
not for changes in kernel core).

As for the other issue, in production environment I'd choose stability 
over bleeding edge features anytime.  Updating kernel on my home machine 
is one thing (if something gets screwed up, no web surfing for one 
afternoon, big deal).  Updating tens or hundreds or thousands of 
production machines is something completely different.  Anyhow, what I 
was aruging is that since SunOS is closed source, they were forced to do 
modularization of kernel "the right way".  Linux being open source had 
freedom of not doing it the right way (well, from developers perspective 
it might be also called the right way, but not from the end-user's 
perspective).  And Linux abused that freedom...  So now, instead of just 
getting tcp_windows_trackign.c, compiling against linux26 kernel header 
files (that would be static for entire 2.6.x tree) and dropping 
resulting tcp_window_tracking.ko into /lib/kernel26/net/ipv4/netfilter 
(with kernel26 being shared by all 2.6.x kernels), I need to recompile 
and reinstall entire damn kernel.  Not to mention downloading the entire 
kernel source that I really don't need...

In SunOS/Solaris world, Netfilter developers would be forced to use that 
approach/design.  In Linux world they unfortunately had Linux source 
code available ;-)

The way it is now, I first need to discover to which kernel version I 
can actually apply tcp_window_tracking patch.  Tried several, failed on 
all of them.  At the end I just gave up, and am waiting for stable 
kernel that will have it already applied...  Darn...

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7


  reply	other threads:[~2004-09-08 20:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-07 23:33 linux-2.6.9-rc1 compilation and configuration issue (fwd) James B. Hiller
2004-09-08  0:27 ` Jason Opperisano
2004-09-08  1:55   ` James B. Hiller
2004-09-08 14:10 ` Aleksandar Milivojevic
2004-09-08 17:39   ` Jose Maria Lopez
2004-09-08 18:23     ` Aleksandar Milivojevic
2004-09-08 18:19       ` Jose Maria Lopez
2004-09-08 19:00         ` Aleksandar Milivojevic
2004-09-08 19:37           ` Jose Maria Lopez
2004-09-08 20:46             ` Aleksandar Milivojevic [this message]
2004-09-08 20:41           ` James B. Hiller
2004-09-08 19:26       ` Cedric Blancher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=413F6FA0.7020407@pbl.ca \
    --to=amilivojevic@pbl.ca \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.