On Thu, Dec 21, 2017 at 11:02:22AM +0100, Philipp Kern wrote:
> Source: apt
> Severity: wishlist
> X-Debbugs-Cc: ma...@debian.org
>
> At work our packages and package lists are served by a web service that
> has relatively high time to first byte latency. Once it starts
> transmitting the bytes
On Sun, Jan 14, 2018 at 06:06:28PM +0100, Philipp Kern wrote:
> That said, you just went the other way. Not that I liked the cURL https
> transport, given that it was fairly stupid^Wstraightforward. But at
^^^ you must be joking…¹
> least it used a
On 01/07/2018 07:49 PM, David Kalnischkies wrote:
> The apt team was always against doing this which eventually spawned
> stuff like the enormously hacky "apt-fast". The problem we see with this
> is that as soon we add this to mainline users will activate such options
> even if it makes no
Hi,
On Thu, Dec 21, 2017 at 11:02:22AM +0100, Philipp Kern wrote:
> An easy workaround (few lines changed) would be to just spawn multiple
> transports for a given host target, to make use of multiple connections.
The apt team was always against doing this which eventually spawned
stuff like the
Hi,
On 12/21/2017 11:02 AM, Philipp Kern wrote:
> At work our packages and package lists are served by a web service that
> has relatively high time to first byte latency. Once it starts
> transmitting the bytes are pushed in a fast way but fetching the bytes
> in the first place takes a "long"
Source: apt
Severity: wishlist
X-Debbugs-Cc: ma...@debian.org
At work our packages and package lists are served by a web service that
has relatively high time to first byte latency. Once it starts
transmitting the bytes are pushed in a fast way but fetching the bytes
in the first place takes a
6 matches
Mail list logo
