On Tue, Aug 22, 2017 at 10:53:47PM +0200, Sebastian Andrzej Siewior wrote:
> On 2017-08-16 00:21:09 [+0200], Julian Andres Klode wrote:
> > libreoffice-core (size only):
> >
> > -rw-r--r-- 1 jak jak 29M Jul 22 20:02
> > libreoffice-core_5.3.5~rc1-3_amd64.deb
> > -rw-r--r-- 1 jak jak 31M Jul
On 2017-08-16 00:21:09 [+0200], Julian Andres Klode wrote:
> libreoffice-core (size only):
>
> -rw-r--r-- 1 jak jak 29M Jul 22 20:02 libreoffice-core_5.3.5~rc1-3_amd64.deb
> -rw-r--r-- 1 jak jak 31M Jul 16 00:10 libreoffice-core_5.4.0~rc2-1_amd64.deb
> -rw-r--r-- 1 jak jak 31M Jul 28 18:29
On Wed, Aug 16, 2017 at 12:21:09AM +0200, Julian Andres Klode wrote:
> firefox (size & performance):
>
> -rw-r--r-- 1 jak jak 2.3M Aug 15 20:59 firefox_55.0-1_55.0-2_amd64.debdelta
> -rw-r--r-- 1 jak jak 2.4M Aug 15 22:13 firefox_55.0-1_55.0-2_amd64.pdeb
> -rw-r--r-- 1 jak jak 7.4M Aug 15
On Wed, Aug 16, 2017 at 01:38:11AM +0200, Julian Andres Klode wrote:
> bsdiff was specifically invented for patching binaries. See the
> evaluation I posted a (few) hour(s) ago. It's used succesfully by
> FreeBSD, Chrome, Android, Apple App Store, and other places.
[...]
> Especially for security
Hi,
Julian Andres Klode wrote:
> Today's research has shown that rolling hashes do not perform well
> on executables because of changing offsets and so on destroying the
> hashes. There were no measurable space savings when adding fairly
> similar firefox releases to either a casync or borg
On Sun, Aug 13, 2017 at 12:38:56PM +0300, Adrian Bunk wrote:
> On Sat, Aug 12, 2017 at 02:16:21PM -0400, Julian Andres Klode wrote:
> >...
> > I think delta debs are generally a thing we should aim to have,
> >...
>
> It sounds like something that would have been a cool feature 20 years
> ago
On Sun, Aug 13, 2017 at 10:53:16AM -0400, Peter Silva wrote:
> You are assuming the savings are substantial. That's not clear. When
> files are compressed, if you then start doing binary diffs, well it
> isn't clear that they will consistently be much smaller than plain new
> files. it also
On Sat, Aug 12, 2017 at 02:16:21PM -0400, Julian Andres Klode wrote:
> Hi everyone,
>
> (I CCed -devel and deity, but we probably should just discuss
> that on -dpkg)
>
> while breakfast here at DebConf, the topic of delta upgrades
> came up. I think delta debs are generally a thing we should
>
On Sun, Aug 13, 2017 at 08:24:27PM -0400, Peter Silva wrote:
> o in spite of being the *default*, it isn't that universal, and in
> any event, we can just decide to change the default, no? One can say
> to people with bandwidth limitations, that their apt settings should
> not delete packages
o in spite of being the *default*, it isn't that universal, and in
any event, we can just decide to change the default, no? One can say
to people with bandwidth limitations, that their apt settings should
not delete packages after receipt, so that they can be used as the
basis for updates. And
* Christian Seiler [170813 18:59]:
> (Setting reply-to to debian-devel@ only as I don't think this
> should continue on debian-dpkg@ and deity@)
>
> On 08/14/2017 12:29 AM, Marvin Renich wrote:
> > * Christian Seiler [170813 13:19]:
> >> On 08/13/2017
(Setting reply-to to debian-devel@ only as I don't think this
should continue on debian-dpkg@ and deity@)
On 08/14/2017 12:29 AM, Marvin Renich wrote:
> * Christian Seiler [170813 13:19]:
>> On 08/13/2017 07:11 PM, Peter Silva wrote:
apt by default automatically deletes
* Christian Seiler [170813 13:19]:
> On 08/13/2017 07:11 PM, Peter Silva wrote:
> >> apt by default automatically deletes packages files after a successful
> >> install,
> >
> > I don't think it does that.
>
> The "apt" command line tool doesn't, but traditional "apt-get"
On 08/13/2017 07:11 PM, Peter Silva wrote:
>> apt by default automatically deletes packages files after a successful
>> install,
>
> I don't think it does that.
The "apt" command line tool doesn't, but traditional "apt-get" does, as
does "aptitude". This was documented in the release notes of
> apt by default automatically deletes packages files after a successful
> install,
I don't think it does that. It seems keep them around after install,
and even multiple
versions. I don't know the algorithm for the cache, but it doesn't do
what you say.
On my debian box, I have nothing but a
On Sun, Aug 13, 2017 at 10:53:16AM -0400, Peter Silva wrote:
> You are assuming the savings are substantial. That's not clear. When
> files are compressed, if you then start doing binary diffs, well it
> isn't clear that they will consistently be much smaller than plain new
> files. it also
You are assuming the savings are substantial. That's not clear. When
files are compressed, if you then start doing binary diffs, well it
isn't clear that they will consistently be much smaller than plain new
files. it also isn't clear what the impact on repo disk usage would
be.
The most
On Sun, Aug 13, 2017 at 5:38 AM, Adrian Bunk wrote:
> It sounds like something that would have been a cool feature 20 years
> ago when I was downloading Debian updates over an analog modem.
>
> Today the required effort, infrastructure and added complexity would
> IMHO not be worth it for a
On Sat, Aug 12, 2017 at 02:16:21PM -0400, Julian Andres Klode wrote:
>...
> I think delta debs are generally a thing we should aim to have,
>...
It sounds like something that would have been a cool feature 20 years
ago when I was downloading Debian updates over an analog modem.
Today the
Hi everyone,
(I CCed -devel and deity, but we probably should just discuss
that on -dpkg)
while breakfast here at DebConf, the topic of delta upgrades
came up. I think delta debs are generally a thing we should
aim to have, but debdelta is not the implementation we want:
* It is not integrated
20 matches
Mail list logo