Re: starting with 2.7

From: Willy Tarreau (willy_at_w.ods.org)
Date: 01/03/05

  • Next message: David Schwartz: "RE: Main CPU- I/O CPU interaction" 
    Date:	Mon, 3 Jan 2005 22:38:45 +0100
To: William Lee Irwin III <wli@holomorphy.com>

    On Mon, Jan 03, 2005 at 04:33:25AM -0800, William Lee Irwin III wrote:
     
    > This is bizarre. iptables was made the de facto standard in 2.4.x and
    > the alternatives have issues with functionality. The 2.0/2.2 firewalling
    > interfaces are probably ready to go regardless. You do realize this is
    > what you're referring to?
    >
    > 2 major releases is long enough.

    if it's long enough, ipfwadm should not have entered 2.6 at all. It's not
    because you don't see any use to that particular feature that you can guarantee
    that it is not used at all. At least, a large public call to get in touch with
    the potentially unique user of this feature would be a start, but generally we
    should not remove a feature from a stable kernel. What will go next ? minix,
    because someone will decide that there have been many better filesystems for a
    long time, so that's long enough ? Revert modules to modutils because someone
    will think it's simpler for everyone to use a single toolset ? I have no
    problem removing numerous feature between major releases, even breaking APIs,
    but I really hate it when something which is called "stable" constantly
    changes.

    > On Mon, Jan 03, 2005 at 06:33:04AM +0100, Willy Tarreau wrote:
    > > If the motivation to break backwards compatibility is not enough
    > > anymore to justify development kernels, I don't know what will
    > > justify it anymore. I'm particularly fed up by some developer's
    > > attitude who seem to never go outside and see how their creations are
    > > used by people who really trust the "stable" term... until they
    > > realize that this word is used only for marketting,
    >
    > Who do you think is actually banging out the code on this mailing list?

    Frankly, sometimes I'm really wondering. We see lots of very clever ideas,
    and sometimes people come up with concepts which can break existing apps, and
    simply justify by "this should not have been done in the first time." (eg:
    unexport syscall_table). But I'm certain that all these mistakes are caused
    by those too long development cycles. Some developpers get bored by things that
    irritate them, and prefer to fix the stable tree to stop what they believe is
    an error, instead of waiting for the next release to fix it there.

    > Anyway, features aren't really allowed to break backward compatibility;
    > we've effectively got 10-year lifetimes for userspace-visible interfaces.
    > If this isn't good enough, well, tough.

    All in all, I agree with you. The small differences lie in /proc files or
    oops syntax, etc... But even old syscalls are still supported and that's fine.
    I appreciate it when I read the packet(7) man page to find that even the
    interface from linux 2.0 is still supported.

    The problem is that nowadays, the userspace-visible code is not only in
    userspace anymore, but also involves modules interfaces sometimes because
    some commercial apps rely on modules (firewalls, virtual machines, etc...),
    and their userspace is nuts without those modules, so in a certain way,
    breaking some kernel internals within a stable release does break some apps.

     
    > On Mon, Jan 03, 2005 at 06:33:04AM +0100, Willy Tarreau wrote:
    > > Why do you think that so many people are still using 2.4 (and even
    > > older versions) ? This is because they are the only ones who don't
    > > constantly change under your feet and from which you can build
    > > something reliable and guaranteed maintainable. At least, I've not
    > > seen any commercial product based on 2.6 yet !
    > > Please, stop constantly changing the contents of the "stable" kernel.
    >
    > Either this is some kind of sick joke or you've never heard of SLES9.

    the later :-)

    > On Sun, Jan 02, 2005 at 05:19:35PM -0800, William Lee Irwin III wrote:
    (...)
    > You have ignored my entire argument in favor of reiterating your own.
    >
    > One more time, since this apparently needs to be repeated in a
    > condensed and/or simplified form.
    >
    > (1) the "stable" kernels are actually buggier because no one's looking
    I don't agree with you. "known" bugs become features of this particular
    release and people learn how to play with them. The MM beahaviour when one
    single user can crash the whole machine just accidentely playing with malloc()
    would be called a bug on any other decent OS. For us it's a feature we have
    been used to live with.

    It's possible that 2.6 has fewer of those known bugs, but it still has many
    yet-to-discover bugs (the first ones being all those 'my machine does not
    boot anymore' reported here and caused by those too long release cycles).

    > (2) the creation of those feature patches for stable kernels has
    > detracted from the efforts needed to get them actually into
    > the kernel, and they're not going to exist for long

    I agree with you on the first part, but not on the second one, because as a
    stable kernel implies it, it will still be possible to apply current patches
    to new releases with very few efforts. Indeed, I have already sent rediffed
    patches to different maintainers because they were easy to do. For a while
    now, on 2.4, you can easily apply jiffies64, epoll, netdev-random, preempt,
    lowlat, bme, squashfs, tux, etc... The list is long and demonstrantes what
    stable code looks like. "stable" does not mean it will not crash, but it means
    "it will not change much", eventhough this tends to imply the former.

    > On Mon, Jan 03, 2005 at 06:33:04AM +0100, Willy Tarreau wrote:
    > > At the moment, the only "serious" use I've found for a 2.6 is a kexec-based
    > > bootloader for known hardware. I've already seen that maintaining it up to
    > > date is not simple, I wonder how distro people work with it... I wouldn't
    > > have to do their work right now.
    >
    > People are already using it to run the databases their paychecks rely on.

    I feel they're brave. I know several other people who went back, either because
    they didn't feel comfortable with upgrades these size, which sometimes did not
    boot because of random patches, or simply because of the scheduler which didn't
    let them type normally in an SSH session on a CPU-bound system, or even a
    proxy which performance dropped by a factor of 5 between 2.4 and 2.6. I know
    they don't report it, but they are not developpers. They see that 2.6 is not
    ready yet, and turn back to stable 2.4.

    > Whatever else you had in mind can't be anticipated.

    agreed.

    Willy

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: David Schwartz: "RE: Main CPU- I/O CPU interaction"

    Relevant Pages

    • Re: starting with 2.7
      ... >> interfaces are probably ready to go regardless. ... > because you don't see any use to that particular feature that you can ... tightly coupled to the kernel, and those during ... > some commercial apps rely on modules (firewalls, virtual machines, ...
      (Linux-Kernel)
    • Re: Who wants to maintain KR list for stable releases?
      ... Tracking feature or implementation suggestions wouldn't make sense. ... write what they think the kernel should do but who never write a single ... 'My' Linux kernel subsystem has a long virtual TODO list, with bugs, ...
      (Linux-Kernel)
    • Re: starting with 2.7
      ... >> interfaces are probably ready to go regardless. ... > not because you don't see any use to that particular feature that you ... > userspace anymore, but also involves modules interfaces sometimes because ... > current patches to new releases with very few efforts. ...
      (Linux-Kernel)
    • Re: object system...
      ... whatever can be accessed via interfaces). ... similar feature (although, they do so by dynamically adding interfaces to ... it does simplify implementing languages like JavaScript which do have ... I don't see any need for special features to do delegation. ...
      (comp.object)
    • Re: Why has the Metrowerks sign been taken down?
      ... > IB has so many bugs I doubt one or two more would make much difference. ... > - You're basing this on the assumption that this feature would take one ... > to read 'MENU' resources and convert them into menus in a nib. ... > haven't had their menus converted to nibs yet. ...
      (comp.sys.mac.programmer.codewarrior)