-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
FYI, I've removed the PATCHES file. Not because I don't think it's
useful, but because the information needed updating (now that we're
using Mercurial rather than Subversion), I expect it to be updated again
from time to time, and the Wgiki seems to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Micah Cowan wrote:
> Hrvoje Niksic wrote:
>> Micah Cowan <[EMAIL PROTECTED]> writes:
>
>>> Among other things, version.c is now generated rather than
>>> parsed. Every time "make all" is run, which also means that "make
>>> all" will always relink t
Micah Cowan <[EMAIL PROTECTED]> writes:
> FYI, I've removed the PATCHES file. Not because I don't think it's
> useful, but because the information needed updating (now that we're
> using Mercurial rather than Subversion), I expect it to be updated
> again from time to time, and the Wgiki seems to
OK, so let's go back to basics for a moment.
wget's default behavior is to use all available bandwidth.
Is this the right thing to do?
Or is it better to back off a little after a bit?
Tony
On 10/13/07, Tony Godshall <[EMAIL PROTECTED]> wrote:
> OK, so let's go back to basics for a moment.
>
> wget's default behavior is to use all available bandwidth.
>
> Is this the right thing to do?
>
> Or is it better to back off a little after a bit?
>
> Tony
IMO, this should be handled by the o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hrvoje Niksic wrote:
> Micah Cowan <[EMAIL PROTECTED]> writes:
>
>> FYI, I've removed the PATCHES file. Not because I don't think it's
>> useful, but because the information needed updating (now that we're
>> using Mercurial rather than Subversion),
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> On 10/13/07, Tony Godshall <[EMAIL PROTECTED]> wrote:
>> OK, so let's go back to basics for a moment.
>>
>> wget's default behavior is to use all available bandwidth.
>>
>> Is this the right thing to do?
>>
>> Or is it better to back off a little
On 10/12/07, Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> "Tony Godshall" <[EMAIL PROTECTED]> writes:
>
> >> My point remains that the maximum initial rate (however you define
> >> "initial" in a protocol as unreliable as TCP/IP) can and will be
> >> wrong in a large number of cases, especially on sh
On 10/13/07, Josh Williams <[EMAIL PROTECTED]> wrote:
> On 10/13/07, Tony Godshall <[EMAIL PROTECTED]> wrote:
> > OK, so let's go back to basics for a moment.
> >
> > wget's default behavior is to use all available bandwidth.
> >
> > Is this the right thing to do?
> >
> > Or is it better to back of
On 10/13/07, Tony Godshall <[EMAIL PROTECTED]> wrote:
> Well, you may have such problems but you are very much reaching in
> thinking that my --linux-percent has anything to do with any failing
> in linux.
>
> It's about dealing with unfair upstream switches, which, I'm quite
> sure, were not runni
On 10/13/07, Micah Cowan <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> > On 10/13/07, Tony Godshall <[EMAIL PROTECTED]> wrote:
> >> OK, so let's go back to basics for a moment.
> >>
> >> wget's default behavior is to use all available bandwidth.
> >>
> >> Is t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Joshua Szanto wrote:
> http://www.hlrse.net/Qwerty/wget_glitch.gif
>
> I have no idea how that happened. My theory is this...
>
> I start downloading files.tar as normal, it starts at 0 and counts up to
> ~2.5GB (so far this is true). (Here's the
On 10/13/07, Micah Cowan <[EMAIL PROTECTED]> wrote:
> Hi Joshua,
>
> There is a very strong likelihood that this has been fixed in the
> current development version of Wget. Could you try with that?
>
> If you're a Windows user, you can get a binary from
> http://www.christopherlewis.com/WGet/WGetF
13 matches
Mail list logo
