Re: BK kernel workflow

From: Larry McVoy (lm_at_bitmover.com)
Date: 10/25/04

  • Next message: Valdis.Kletnieks_at_vt.edu: "Re: Cryptoloop patch for builtin default passphrase"
    Date:	Mon, 25 Oct 2004 10:12:23 -0700
    To: Andrea Arcangeli <andrea@novell.com>
    
    

    On Mon, Oct 25, 2004 at 06:47:32PM +0200, Andrea Arcangeli wrote:
    > On Mon, Oct 25, 2004 at 09:20:22AM -0700, Larry McVoy wrote:
    > > The implication that Andrew doesn't use BK is incorrect, we see him in
    > > the logs all the time. [..]
    >
    > I assume this is great news for bitmover: one more tainted open source
    > developer that will not be allowed by law to ever compete with your
    > business, right? Anyways this is offtopic for l-k, but you can still
    > celebrate elsewhere.

    You have made this point hundreds of times, everyone knows your position
    that we're screwing over the open source world by preventing them from
    copying our work. OK, I can see that you think that, we respectfully
    disagree because we feel we have to protect our IP. Rightly or wrongly,
    we feel we did some new work that is worth protecting.

    The big flaw in your position is that you are not tainted, you are a good
    programmer, you claim to care deeply about this issue, so you could go
    solve the problem. Either by fixing arch or creating your own system.
    You should be the poster child for why the BitKeeper license is a
    flawed idea.

    We both think we care about helping the kernel. You think that we're
    screwing over a pile of people who could write a GPLed SCM system.
    We think that that is not true and you yourself prove our point. Kernel
    guys like working on the kernel. If they liked working on SCM they would
    be doing that, there would be a GPLed answer that was better than BK or at
    least good enough, and we wouldn't be arguing, we'd probably be friends.

    So who cares more about the kernel development process? The guy who took
    crap from you and your friends for years but cared enough to keep going
    because what counted were _results_, or the guy who sits around and whines
    that we are polluting the well which was already dry?

    -- 
    ---
    Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com
    -
    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: Valdis.Kletnieks_at_vt.edu: "Re: Cryptoloop patch for builtin default passphrase"

    Relevant Pages

    • Re: [patch 04/16] I/O driver for 8250-compatible UARTs
      ... > All the other kgdb stuff tends to be prefixed, ... > don't really care either way. ... friends and converts it to something compatible with ioread8and ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [patch 04/16] I/O driver for 8250-compatible UARTs
      ... >> don't really care either way. ... > friends and converts it to something compatible with ioread8() and ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: kernel BUG at drivers/usb/storage/usb.c:848
      ... > 2.6.4-mm2 is quite an old kernel. ... Care to get a newer one to see if ... crypto-loop and thus avoid having to try the mm patches. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC] Splitting kernel headers and deprecating __KERNEL__
      ... This still bears the risk that people will copy __u32 and friends ... from headers to then non-portable applications, ... that glibc types are _identical_ to the kernel types, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: From Eric Anholt:
      ... >> care to comment? ... userland and kernel, and nothing else. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)