sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] SKS debian package


From: Christoph Anton Mitterer
Subject: Re: [Sks-devel] SKS debian package
Date: Sun, 29 Apr 2012 22:59:52 +0200

On Mon, 2012-04-23 at 18:59 -0400, Jeffrey Johnson wrote:
> And your opinion is contrary to what was recommended.
Well this is not just my opinion but decades of lectures learned in
software design...

I'm not generally against static linking, but there must be really
really really strong reasons to do so...

Making life a bit easier for packaging is definitely not a reason.


A reason could be, if that would make usage of a BDB much faster, but
even this would IMHO only count, if we already see severe performance
problems (and actually one should then discuss whether it's not time to
go to a more powerful DBMS),... but even my really small crappy server
with basically no RAM, still runs just fine.


> The tradeoff is whether you want to maximize application
> independence from Berkeley DB or minimize efforts when updating everything
> that uses "system" Berkeley DB.

I don't want to step on anyone's toes,.. but sks is probably not the
project with the highest activity in the world (actually it has no need
to be, because it rund fairly well)... so I doubt that there would be
updates "immediately" when new BDB versions are out.
In general,.. static linking sounds always fishy when it comes towards
security.


> Statically linking Berkeley DB was claimed to be ~175K 
> when tuned for a minimal memory footprint without all
> the bells and whistles. The code footprint in memory is
> certainly small.
Yeah,.. of course,... but that's not the point, IMHO.
Even if it would add 10MB,... who cares...



After all,... the best thing for users was, if they have sks available
in their distro's official repositories,... and at least in the Debian
case I can tell you, that they'll surely dislike if you statically link
against something with not really strong reason.


Cheers,
Chris.

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]