Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[james]

On 01/03/2017 10:41 AM, Alice Ferrazzi wrote:
> On Wed, Jan 4, 2017 at 12:23 AM, Rich Freeman <rich0@g.o> wrote:
>> On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol <mikemol@×××××.com> wrote:
>>>
>>> For security's sake, even mature software needs, at minimum, routine auditing.
>>> Unless someone's doing that work, the package should be considered for
>>> removal. (Call that reason #    π, in honor of TeX.)
>>>
>>
>> Are you suggesting that we should ban any package from the tree if we
>> don't have evidence of it having recently being subjected to a
>> security audit?  We might literally have 3 packages left in the tree
>> in that case, probably not including the kernel (forget the GNU/Linux
>> debate, we might be neither).
>>
>> The fact that a project gets 47 commits and 100 list posts a week
>> doesn't mean that it is being security audited, or that security is
>> any kind of serious consideration in how their workflow operates.
>>
>> I tend to be firmly in the camp that a package shouldn't be removed
>> unless there is evidence of a serious bug (and that includes things
>> blocking other Gentoo packages).  If somebody wants to come up with a
>> "curated" overlay or some way of tagging packages that are considered
>> extra-secure that would be a nice value-add, but routine auditing is
>> not a guarantee we provide to our users.  The lack of such an audit
>> should not be a reason to treeclean.
>
> +1

>> Rich

Not only do I agree with those sentiments express here (Rich's 
sentiments), I have an additional prospective. I have been deeply 
following the development of clusters, particularly "in-house" clusters
run on less than a dozen systems. There are an endless number of uses
for such clusters, kinda like the modern version of when "X" servers 
were all the rage decades (and decades) ago, at the very least. In fact 
the cluster space for in-house clusters, imho, will eventually end up, 
being a collection of tarballs (stage-4s in gentoo case) that are 
customized for thousands of finely tuned, secure needs. "Unikernels" is 
the current buzzword, that docker and others have been using. [1] and 
have a tightly and minimized framework. Folks that work for "Cloud 
Vendors" should understand that if individuals and small companies are
able to build and run localize, small clusters, then is very easy and 
comfortable for them to expand into hybrid clusters and become 
comfortable with outsourcing to the cloud. Many larger companies I 
consult with or have conversations with, are still uncomfortable with
"cloud" anything. In-house clusters are the gateway to growing the 
entire cloud business, imho.


Many of those old and stable codes, that lots of folks are so keen on 
purging from the tree, are actually quite useful and easy to secure,
for such custom frameworks. Those frameworks can easily be packaged up
into a stage-4 or a forked gentoo  distro or implemented via any number 
of deployment methods, included CoreOS's fleet, recently added to 
portage. Security is the pivotal issue with clusters, whether they are 
in-house or outsourced (the cloud/Paas/Saas/etc) imho.


So keeping those old codes around makes my life easier and more 
interesting. Sure I can go to these old codes and resurrect most, as 
needed, but why be vindictive by purging things that are old? Does the 
younger and more progressive devs in gentoo really want to purge old 
C-hacks like me from the community? I do not mean to offend anyone, but 
it just seems to me to be just plain unjustified purging useful that are 
currently not popular codes, and that hurts me on a personal basis. Us 
'old farts' are the unix historians, here at gentoo; perhaps the more 
aggressive devs will consider being 'politically correct' towards old 
farts that have decades and decades of history, with these old codes?


  Newer codes are valuable too, but often they add a layer of complexity 
and many attack surfaces, that older codes do not suffer from. So, I 
would hope we err on the side of keeping ebuilds  of old codes around as 
long as possible, despite the download count. My work is liable to take 
another year or two to bear fruit, but that's not even the point. I 
would be excited if we could just move these old packages to an overlay, 
if/when they do have to be pruned from the gentoo-proper tree. Perhaps 
the new GLEP on formalizing forking gentoo, will lead to a gentoo-legacy 
fork, just for historical and nostalgic reasons?


I'm betting that these old codes are much more useful than most have 
figured, but it's going to take some time to establish this performance 
and superior security  postulate, as I use 'old-fart' methodologies.....


hth,
James

[1] http://unikernel.org/blog/2015/unikernels-meet-docker