On Fri, 2002-04-12 at 00:14, Anthony Towns wrote:
> No, I'm not. I'm saying that "the amount of time spent waiting for
> apt-get update" needs to count every apt-get update you run, not just
> the first. So, if over a period of a week, I run it seven times, and you
> run it once, I wait seven times
On Thu, Apr 11, 2002 at 10:40:31PM -0700, Robert Tiberius Johnson wrote:
> On Wed, 2002-04-10 at 02:28, Anthony Towns wrote:
> > I'd suggest your formula would be better off being:
> > bandwidthcost = sum( x = 1..30, prob(x) * cost(x) / x )
> I think it depends on what you're measuring. I can
On Wed, 2002-04-10 at 09:46, Erich Schubert wrote:
> What diff options do you use?
> As the diffs are expected to be applied to the correct version, they
> probably shouldn't contain the old data, but the new data only.
Good point. I used diff -ed, so I think this is not including
unnecessary con
On Wed, 2002-04-10 at 04:35, Michael Bramer wrote:
> > Scheme Disk space Bandwidth
> > ---
> > Checksums (bwidth optimal)26K 81K
> > diffs (4 days)32K
On Wed, 2002-04-10 at 02:28, Anthony Towns wrote:
> I think you'll find you're also unfairly weighting this against people
> who do daily updates. If you do an update once a month, it's not as much
> of a bother waiting a while to download the Packages files -- you're
> going to have to wait _much
> Scheme Disk space Bandwidth
> ---
> Checksums (bwidth optimal)26K 81K
> diffs (4 days)32K 331K
> diffs (9 days)71K
On Wed, Apr 10, 2002 at 08:29:49PM +1000, Martijn van Oosterhout wrote:
> On Wed, Apr 10, 2002 at 09:22:50AM +0200, Michael Bramer wrote:
> > On Wed, Apr 10, 2002 at 10:25:22AM +1000, Martijn van Oosterhout wrote:
> > > With the standard rsync algorithm, the rsync checksum files would actually
> >
On Wed, Apr 10, 2002 at 01:26:17AM -0700, Robert Tiberius Johnson wrote:
> This looks like an interesting algorithm, so I decided to compare it to
> the diff scheme analyzed in
> http://lists.debian.org/debian-devel/2002/debian-devel-200204/msg00502.html
>
> The above message also gives my analys
On Wed, Apr 10, 2002 at 09:22:50AM +0200, Michael Bramer wrote:
> On Wed, Apr 10, 2002 at 10:25:22AM +1000, Martijn van Oosterhout wrote:
> > With the standard rsync algorithm, the rsync checksum files would actually
> > be 8 times larger than the original file (you need to store the checksum
> > f
On Tue, Apr 09, 2002 at 10:58:24AM +0200, Michael Bramer wrote:
> On Tue, Apr 09, 2002 at 06:39:19PM +1000, Martijn van Oosterhout wrote:
> > I beleive this method is patented by somebody, [snip]
>
> has someone a pointer?
Here's some stuff from my mail archives - I haven't checked whether
the l
On Wed, Apr 10, 2002 at 07:28:42PM +1000, Anthony Towns wrote:
> 0 days of diffs: 843.7 KiB (the current situation)
> ...which pretty much matches what I'd expect: at the moment, just to
> update main, people download around 1.2MB per day;
Uh, obviously this should be 843KiB. (I'd been playi
On Wed, Apr 10, 2002 at 01:26:17AM -0700, Robert Tiberius Johnson wrote:
> - I tend to update every day. For people who update every day, the
> diff-based scheme only needs to transfer about 8K, but the
> checksum-based scheme needs to transfer 45K. So for me, diffs are
> better. :)
I think you'
On Tue, 2002-04-09 at 17:25, Martijn van Oosterhout wrote:
> What you are suggesting is that the server store checksums for precalculated
> blocks on the server. This would be 4 bytes per 1k in the original file or
> so. The transaction proceeds as follows:
>
> 1. Client asks for checksum list off
On Wed, Apr 10, 2002 at 10:25:22AM +1000, Martijn van Oosterhout wrote:
> On Tue, Apr 09, 2002 at 05:02:34PM +0200, Michael Bramer wrote:
> > you propose to add 'some' diff files for all files on ftp-master.d.o?
> >
> > With rsync we need only one rsync-checksum file per normal file and
> > all a
On Tue, Apr 09, 2002 at 05:02:34PM +0200, Michael Bramer wrote:
> you propose to add 'some' diff files for all files on ftp-master.d.o?
>
> With rsync we need only one rsync-checksum file per normal file and
> all apt's need only download the neededs parts.
>
> You get the point?
With the stand
> http://lists.debian.org/debian-devel/2001/debian-devel-200111/msg00757.html
Thanks for this pointer.
My debiansynch script never runs into problem "1. rsync -r" since it
always does single file transfers. And for problem "2. rsync of near
identical files" it's not astonishing using a high cpu l
Le mar 09/04/2002 à 20:13, Jason Gunthorpe a écrit :
> > -> make the check on the client site and
> > -> download the file partly per ftp/http
> > -> make the new file with the old and downloaded parts
> >
> > With this the server need only extra rsync-checksum files.
>
> Rumor around rsy
On Tue, 9 Apr 2002, Michael Bramer wrote:
> -> make the check on the client site and
> -> download the file partly per ftp/http
> -> make the new file with the old and downloaded parts
>
> With this the server need only extra rsync-checksum files.
Rumor around rsync circles is that this
On Tue, Apr 09, 2002 at 10:25:04PM +1000, Martijn van Oosterhout wrote:
> On Tue, Apr 09, 2002 at 10:58:24AM +0200, Michael Bramer wrote:
> > On Tue, Apr 09, 2002 at 06:39:19PM +1000, Martijn van Oosterhout wrote:
> > > I beleive this method is patented by somebody, which is why it's not in
> > > u
On Tue, Apr 09, 2002 at 04:34:43PM +0200, Jeroen Dekkers wrote:
> On Tue, Apr 09, 2002 at 09:09:39AM +0200, Michael Bramer wrote:
> > no. sorry. I must say this:
> >
> > We can use rsync on the client site.
> > -> get a rsync-checksum file (use a fix block size)
> > -> make the check on the
On Tue, Apr 09, 2002 at 08:02:14AM -0500, Steve Langasek wrote:
> On Tue, Apr 09, 2002 at 09:53:44AM +0200, Michael Bramer wrote:
> > On Sat, Mar 30, 2002 at 02:11:00AM +0100, Wichert Akkerman wrote:
> > > > > > - I would like to have templates with substitution fields.
> > > > >
> > > > > Alread
On Tue, Apr 09, 2002 at 09:09:39AM +0200, Michael Bramer wrote:
> hello
>
> we sould stop this and start after woody again...
>
> On Thu, Mar 28, 2002 at 08:17:46PM +0100, Jeroen Dekkers wrote:
> > On Thu, Mar 28, 2002 at 04:55:17PM +0100, Otto Wyss wrote:
> > > Sorry, diffs are simply silly! Use
On Tue, Apr 09, 2002 at 03:24:42PM +0200, Tomas Pospisek's Mailing Lists wrote:
> On Tue, 9 Apr 2002, Martijn van Oosterhout wrote:
>
> > On Tue, Apr 09, 2002 at 10:58:24AM +0200, Michael Bramer wrote:
> > > On Tue, Apr 09, 2002 at 06:39:19PM +1000, Martijn van Oosterhout wrote:
> > > > I beleive
On Tue, 9 Apr 2002, Martijn van Oosterhout wrote:
> On Tue, Apr 09, 2002 at 10:58:24AM +0200, Michael Bramer wrote:
> > On Tue, Apr 09, 2002 at 06:39:19PM +1000, Martijn van Oosterhout wrote:
> > > I beleive this method is patented by somebody, which is why it's not in
> > > use/supported.
Possib
On Tue, Apr 09, 2002 at 09:53:44AM +0200, Michael Bramer wrote:
> On Sat, Mar 30, 2002 at 02:11:00AM +0100, Wichert Akkerman wrote:
> > > > > - I would like to have templates with substitution fields.
> > > >
> > > > Already exists.
> > >
> > > Any references?
> >
> > How about the debconf manu
On Tue, Apr 09, 2002 at 10:58:24AM +0200, Michael Bramer wrote:
> On Tue, Apr 09, 2002 at 06:39:19PM +1000, Martijn van Oosterhout wrote:
> > I beleive this method is patented by somebody, which is why it's not in
> > use/supported.
> >
> > Other than that, it's very nice idea. I beleive there may
On Tue, Apr 09, 2002 at 06:39:19PM +1000, Martijn van Oosterhout wrote:
> On Tue, Apr 09, 2002 at 09:09:39AM +0200, Michael Bramer wrote:
> > > This isn't server friendly.
> >
> > no. sorry. I must say this:
> >
> > We can use rsync on the client site.
> > -> get a rsync-checksum file (use a
On Tue, Apr 09, 2002 at 09:09:39AM +0200, Michael Bramer wrote:
> hello
>
> we sould stop this and start after woody again...
>
> On Thu, Mar 28, 2002 at 08:17:46PM +0100, Jeroen Dekkers wrote:
> > On Thu, Mar 28, 2002 at 04:55:17PM +0100, Otto Wyss wrote:
> > > > > > I'd suggest using diffs, as
On Fri, Mar 29, 2002 at 11:16:44AM +0100, Eduard Bloch wrote:
> #include
> Joey Hess wrote on Wed Mar 27, 2002 um 02:21:49PM:
> > That is a rather misleading summary of the situation, which as a
> > subscriber to debian-boot, you should understand better. Have you done
> > any testing of the propo
On Thu, Mar 28, 2002 at 04:55:17PM +0100, Otto Wyss wrote:
> > > > I'd suggest using diffs, as this brings the best results and is the
> >
> > [diffs for Packages files that is]
> >
> > > wooo!!!
> > >
> > > http://people.debian.org/~dancer/Packages-for-main-i386/
> > >
> > >
> > > # Time for
On Sat, Mar 30, 2002 at 02:11:00AM +0100, Wichert Akkerman wrote:
> > > > - I would like to have templates with substitution fields.
> > >
> > > Already exists.
> >
> > Any references?
>
> How about the debconf manual?
but sorry, we have some outdated translations in debconf templates
files. N
On Sat, Mar 30, 2002 at 04:49:25AM +0900, Junichi Uekawa wrote:
> [EMAIL PROTECTED] (Otto Wyss) cum veritate scripsit:
>
> > Packages.0 from 28-March is probably the newest and the smallest upgrade
> > is problably the diff for one day (209k uncompressed, 50k gzipped). On
> > the 28th rsync's down
hello
we sould stop this and start after woody again...
On Thu, Mar 28, 2002 at 08:17:46PM +0100, Jeroen Dekkers wrote:
> On Thu, Mar 28, 2002 at 04:55:17PM +0100, Otto Wyss wrote:
> > > > > I'd suggest using diffs, as this brings the best results and is the
> > > http://lists.debian.org/debian-d
On Sun, Apr 07, 2002 at 10:28:12PM +0200, Tollef Fog Heen wrote:
> * Jeroen Dekkers
>
> | It does also other things, like making distribution creation more
> | flexible. I'm thinking of having a some kind of package file for every
> | source package. That would include the current information and
* Jeroen Dekkers
| It does also other things, like making distribution creation more
| flexible. I'm thinking of having a some kind of package file for every
| source package. That would include the current information and maybe a
| lot more things like URL of upstream, license, etc. This file wo
Adam Majer wrote:
> On Wed, Mar 27, 2002 at 01:53:00PM +0100, Eduard Bloch wrote:
> > 1) Large packages files
> > [... 3 level idea ...]
>
> I would suggest a solution that is much easier to manage. That is, packages
> should be sorted according to the date that the package was modified.
> This co
36 matches
Mail list logo
