mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Michael Rothwell <rothwell@holly-springs.nc.us>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Lars Marowsky-Bree <lmb@suse.de>, Christoph Rohland <cr@sap.com>,
	richardj_moore@uk.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
Date: Thu, 9 Nov 2000 09:23:42 -0500	[thread overview]
Message-ID: <200011091423.JAA21926@tsx-prime.MIT.EDU> (raw)
In-Reply-To: Michael Rothwell's message of Thu, 09 Nov 2000 08:43:14 -0500, <3A0AA9F2.9F76DF1@holly-springs.nc.us>

   Date: 	Thu, 09 Nov 2000 08:43:14 -0500
   From: Michael Rothwell <rothwell@holly-springs.nc.us>

   And how would a hypothetical Advanced Linux Kernel Project be different?
   Set aside the GKHI and the issue of binary-only hook modules; how would
   an "enterprise" fork be any different than RT or UC? It'll go off,
   change and add some things, and then perhaps be merged back in later. In
   the meantime, developers who want to add "enterpriseness" to Linux will
   have an outlet and won't have to simply gripe on this list anymore. And
   users who want an "enterprise" kernel can get one.

Well, there are three possibilities about how it can end up.

1)  It will be loaded with so much crap that in fact it ends up being
less performant than the mainline Linux.  No problem, we can ignore it.

2)  It will be a thing of perfect beauty, in which every single change
is thoughtfully well-considered, and scales well to both the low end and
the high end.  No problem, it's easy to merge stuff back.

3) It will be a mixture, of some stuff which is good, and some such
which is crap, and it will be very difficult hard to merge back some of
the good stuff, since it has dependencies on the crap.  In the meantime,
mainline Linux will have continued moving forward, and it will be even
harder to merge the advanced features of Linux back into the forked
version of the kernel.


One of the big reasons why many of the big companies have been looking
at Linux is because Unix OS engineering is viewed as a cost center, not
as a profit center.  The moment you fork and make an "Advanced Linux
Kernel Project", a lot of the costs involved with maintaining such a
beast come back.  And sure, you can try to solve this problem by working
in a consoritum-like fashion with other Companies ---- just like OSF/1
and Monterrey tried to do.  

So there are some real costs associated with forking.  At the same time,
if these companies need to get product out the door quickly, short-term
forks can be good things.  But nothing in life is free, and it's in
*everybody's* best interest to resolve forks as soon as possible.
Otherwise, you end up losing a lot of the advantages of the Open Source
development model.

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

  reply	other threads:[~2000-11-09 14:24 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-09  7:43 richardj_moore
2000-11-09 11:24 ` Christoph Rohland
2000-11-09 12:25   ` Michael Rothwell
2000-11-09 12:30     ` Lars Marowsky-Bree
2000-11-09 12:46       ` Michael Rothwell
2000-11-09 13:35         ` Alan Cox
2000-11-09 13:43           ` Michael Rothwell
2000-11-09 14:23             ` Theodore Y. Ts'o [this message]
2000-11-09 12:50     ` Paul Jakma
2000-11-09 12:53       ` Michael Rothwell
2000-11-09 13:39         ` Paul Jakma
2000-11-09 14:06           ` Marco Colombo
2000-11-09 14:14           ` Theodore Y. Ts'o
2000-11-09 14:26             ` Alan Cox
2000-11-09 14:37               ` Jeff Garzik
2000-11-09 20:24               ` Theodore Y. Ts'o
2000-11-09 13:31     ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2000-11-15 15:24 richardj_moore
2000-11-15 18:20 ` Matt D. Robinson
2000-11-15 15:22 richardj_moore
2000-11-14  1:34 richardj_moore
2000-11-13  5:52 richardj_moore
2000-11-12 23:27 richardj_moore
2000-11-13 10:38 ` Andi Kleen
2000-11-14  3:17   ` Andrea Arcangeli
2000-11-10 19:31 richardj_moore
2000-11-10 18:42 richardj_moore
2000-11-10 16:08 richardj_moore
2000-11-10 11:41 richardj_moore
2000-11-10 16:24 ` Theodore Y. Ts'o
2000-11-10 16:37   ` Christoph Rohland
2000-11-10 18:36     ` Matt D. Robinson
2000-11-11  0:12       ` Theodore Y. Ts'o
2000-11-11  3:29         ` Matt D. Robinson
2000-11-11  4:57           ` Keith Owens
2000-11-11 17:58         ` tytso
2000-11-13 10:30           ` Daniel Phillips
2000-11-11 21:48         ` Lars Marowsky-Bree
2000-11-11 22:12           ` Michael Rothwell
2000-11-10 16:54   ` Andi Kleen
2000-11-10 11:17 richardj_moore
2000-11-10 10:57 richardj_moore
2000-11-10 10:57 richardj_moore
2000-11-10 10:57 richardj_moore
2000-11-10 13:45 ` Alexander Viro
2000-11-10 13:51   ` Michael Rothwell
2000-11-10 14:00     ` Alexander Viro
2000-11-10 14:37   ` David Lang
2000-11-09 14:02 Jesse Pollard
2000-11-08 20:31 richardj_moore
2000-11-08 21:35 ` Michael Rothwell
2000-11-09  7:44   ` Christoph Rohland
2000-11-09  7:53     ` Larry McVoy
2000-11-09  8:08       ` Andre Hedrick
2000-11-09  8:43       ` Christoph Rohland
2000-11-09 12:20         ` Michael Rothwell
2000-11-09 12:31           ` Lars Marowsky-Bree
2000-11-09 12:40           ` Alexander Viro
2000-11-09 13:02             ` Michael Rothwell
2000-11-09 13:30               ` Alexander Viro
2000-11-09 13:39                 ` Michael Rothwell
2000-11-09 17:19                 ` Mike Coleman
2000-11-09 17:27                   ` Alexander Viro
2000-11-10 11:42                     ` Martin Dalecki
2000-11-09 13:40               ` Marco Colombo
2000-11-10  8:44           ` Christoph Rohland
2000-11-09 12:50       ` Tigran Aivazian
2000-11-09 16:03       ` Ingo Molnar
2000-11-10  8:42         ` Christoph Rohland
2000-11-09 14:28   ` Theodore Y. Ts'o
2000-11-10 15:07   ` Matti Aarnio
2000-11-10 15:24     ` Michael Rothwell

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=200011091423.JAA21926@tsx-prime.MIT.EDU \
    --to=tytso@mit.edu \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=cr@sap.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lmb@suse.de \
    --cc=richardj_moore@uk.ibm.com \
    --cc=rothwell@holly-springs.nc.us \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®