lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44BE9620.9080400@wolfmountaingroup.com>
Date:	Wed, 19 Jul 2006 14:29:20 -0600
From:	"Jeff V. Merkey" <jmerkey@...fmountaingroup.com>
To:	Valdis.Kletnieks@...edu
CC:	Tilman Schmidt <tilman@...p.cc>,
	Pekka Enberg <penberg@...helsinki.fi>,
	linux-kernel@...r.kernel.org,
	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	Matthias Andree <matthias.andree@....de>,
	Grzegorz Kulewski <kangur@...com.net>,
	Diego Calleja <diegocg@...il.com>, arjan@...radead.org,
	caleb@...ebgray.com
Subject: Re: Reiser4 Inclusion

A big ego thing I guess. 

Keeping a lot of FS's and code out of tree has a lot of advatanges (like 
not getting targeted by folks
claiming IP issues suing Linus and Co.).    I am still distributing NWFS 
out of the tree, and there's still 2000+ downloads per month from
three separate locations -- code I have not touched in three years.   

Projects I have taken commercial are big money makers and obviously will 
not be submitted to the tree.  Reiser is shipped in Suse
Linux as the default, so who cares whether its in the tree or not -- it 
still has succeeded.  You guys should keep the stuff out of the tree
(in fact most of the FS's and other code should not be in the tree).

The whole Linux base is too big as it is and becoming larger.  Only 
minimal drivers and FS's should be in the tree.  Less broken stuff
and dependencies.  I have been watching development cycles take longer 
and longer to get Linux kernels out -- Red Hat is STILL
shipping 2.6.9-22 with ES4 (update kernels have various issues of 
stability).

The smaller the better.    You have more control if you keep it out, and 
greater opporutnities for serious folks to do business
deals to promote your stuff.

Jeff

Valdis.Kletnieks@...edu wrote:

>On Wed, 19 Jul 2006 17:32:48 +0200, Tilman Schmidt said:
> 
>  
>
>>Well, that doesn't make sense. You can't have your cake and eat it
>>too. Either you have out-of-tree code or you haven't. Documents
>>like stable_api_nonsense.txt explicitly discourage out-of-tree code,
>>which is formally equivalent to saying that all kernel code should
>>be in-tree. Therefore an attitude which says "go on developing that
>>code out-of-tree, it's not ready for inclusion yet" is in direct
>>contradiction with the foundations of the no-stable-API policy.
>>    
>>
>
>Which part of "read Documentation/SubmittingPatches.txt and do what it says,
>or it doesn't get into the kernel" do you have trouble understanding?
>
>It isn't a case of "out of tree code or you haven't". There's actually
>*three* major categories:
>
>1) Code that's already in-tree and maintained.  These guys don't need to
>worry about the API, as it will usually get handled free of charge.
>
>2) Code that's out-of-tree, but a potential (after possible rework) candidate
>for submission (for instance, the hi-res timers, CKRM, some drivers, etc).
>These guys need to forward-port their code for API changes as they work
>towards getting their code into the tree.
>
>3) Code that's out-of-tree, but is so far out in left field that there's
>no way it will ever go in.  For instance, that guy with the MVS JCL emulator
>better not be holding his breath waiting.  And quite frankly, nobody else
>really cares whether they forward port their code or not.
>  
>

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ