Jim Wright <[EMAIL PROTECTED]> writes:
>> - --limit-rate will find your version handy, but I want to hear from
>> them. :)
>
> I would appreciate and have use for such an option. We often access
> instruments in remote locations (think a tiny island in the Aleutians)
> where we share bandwidth wi
I think there is still a case for attempting percent limiting. I agree
with your point that we can not discover the full bandwidth of the
link and adjust to that. The approach discovers the current available
bandwidth and adjusts to that. The usefullness is in trying to be
unobtrusive to other u
> > >> - --limit-rate will find your version handy, but I want to hear from
> > >> them. :)
> > > I would appreciate and have use for such an option. We often access
> > > instruments in remote locations (think a tiny island in the Aleutians)
> > > where we share bandwidth with other organization
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jim Wright wrote:
> I think there is still a case for attempting percent limiting. I agree
> with your point that we can not discover the full bandwidth of the
> link and adjust to that. The approach discovers the current available
> bandwidth and
> ... I worry that that might be more harmful to those sharing channel in cases
> like Hvroje's ...
Sorry, Hvroje, Jim, I meant Jim's case.
Tony
> Jim Wright wrote:
> > I think there is still a case for attempting percent limiting. I agree
> > with your point that we can not discover the full bandwidth of the
> > link and adjust to that. The approach discovers the current available
> > bandwidth and adjusts to that. The usefullness is in
Jim Wright <[EMAIL PROTECTED]> writes:
> I think there is still a case for attempting percent limiting. I
> agree with your point that we can not discover the full bandwidth of
> the link and adjust to that. The approach discovers the current
> available bandwidth and adjusts to that. The usefu
Hrvoje Niksic wrote:
> Measuring initial bandwidth is simply insufficient to decide what
> bandwidth is really appropriate for Wget; only the user can know
> that, and that's what --limit-rate does.
The user might be able to make a reasonable guess as to the download rate if
wget reported its ave
On 10/10/07, Tony Lewis <[EMAIL PROTECTED]> wrote:
> Hrvoje Niksic wrote:
>
> > Measuring initial bandwidth is simply insufficient to decide what
> > bandwidth is really appropriate for Wget; only the user can know
> > that, and that's what --limit-rate does.
>
> The user might be able to make a re
Indeed.
On 10/10/07, Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> Jim Wright <[EMAIL PROTECTED]> writes:
>
> > I think there is still a case for attempting percent limiting. I
> > agree with your point that we can not discover the full bandwidth of
> > the link and adjust to that. The approach disc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
(We don't have reply-to's set; I've re-included the list on this.)
Ray Phillips wrote:
> Thanks for your reply Micah.
>
>
>> Ray Phillips wrote:
>>> I thought I'd report my experiences trying to install wget 1.10.2 on
>>> NetBSD/i386 3.1. I'll
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hrvoje Niksic wrote:
> Jim Wright <[EMAIL PROTECTED]> writes:
>
>> I think there is still a case for attempting percent limiting. I
>> agree with your point that we can not discover the full bandwidth of
>> the link and adjust to that. The approac
On Wed, 10 Oct 2007, Micah Cowan wrote:
It appears from your description that Wget's check in http-ntlm.c:
#if OPENSSL_VERSION_NUMBER < 0x00907001L
is wrong. Your copy of openssl seems to be issuing a number lower than
that, and yet has the newer, capitalized names.
I don't think that check
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Daniel Stenberg wrote:
> On Wed, 10 Oct 2007, Micah Cowan wrote:
>
>> It appears from your description that Wget's check in http-ntlm.c:
>>
>> #if OPENSSL_VERSION_NUMBER < 0x00907001L
>>
>> is wrong. Your copy of openssl seems to be issuing a numbe
> >> I think there is still a case for attempting percent limiting. I
> >> agree with your point that we can not discover the full bandwidth of
> >> the link and adjust to that. The approach discovers the current
> >> available bandwidth and adjusts to that. The usefullness is in
> >> trying to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tony Godshall wrote:
> The scenario I was picturing was where you'd want to make sure some
> bandwidth was left available so that unfair routers wouldn't screw
> your net-neighbors. I really don't see this as an attempt to "be
> unobtrusive" at all.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ray Phillips wrote:
>> Ray, if you add the line
>>
>> #include
>>
>> along with the other openssl #includes, does it fix your problem wrt
>> openssl-9.7d?
>
> I made this change:
>
> % diff -u http-ntlm.c.orig http-ntlm.c
> --- http-ntlm.c.orig
> It would be nice if wget 1.10.2 would compile on NetBSD without having
to install a second version of openssl.
Well, it's too late to change Wget 1.10.2;
Yes, sorry Micah--I really meant any future versions.
Ray, if you add the line
#include
along with the other openssl #includes, d
18 matches
Mail list logo