Re: [Tails-dev] Fallback download URL outside of DAVE [Was: …

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: The Tails public development discussion list
Old-Topics: Re: [Tails-dev] Fallback download URL outside of DAVE [Was: Dynamically changing ISO URL in DAVE]
Subject: Re: [Tails-dev] Fallback download URL outside of DAVE [Was: Dynamically changing ISO URL in DAVE]
Hi,

sajolida wrote (14 Feb 2016 15:01:17 GMT) :
> intrigeri:
>> sajolida wrote (13 Feb 2016 12:49:46 GMT) :
>>>  B. People with no JavaScript, wget, etc. It seems like we need the
>>>     minimal DNS pool if we want to support these anyway.

>>
>> Sure, we will need this pool anyway.
>>
>> But the less we rely on that DNS pool, the better: the less load we
>> put on it (i.e. the less users we send to it), the more reliable it
>> is, and the less daily maintenance effort is required. This is
>> especially true until we have recruited very fast and reliable mirrors
>> to put into this pool.
>>
>> Now, indeed it may be more worth our time to go after such new
>> mirrors, than writing code to workaround the lack thereof :)


> :) What would this be?


> A. Do stats on faster mirror as reported by check-mirrors.


Yes, we can do that for our current set of mirrors.

> B. Do stats on mirrors with less incidents in the mirrors Git repo.


Yes.

> or you are thinking about recruiting new mirrors we don't yet have in
> the pool?


Also this, yes. (This is why I've started the discussion about dropping
the requirement for OpenPGP communication with mirror operators.)

> To do this I can dig check-mirrors reports from my trash (1069!) and
> compile some stats over the last two years.


I don't think it's worth the effort to go back in the past: IMO for
(A) we can just check the _current_ state of our mirrors. But if
you're excited by this idea and wants to put extra effort into it,
well, the better :)

> I guess that, as time goes by, we will still be able to silently modify
> the DNS pool for example to add fast and reliable mirrors from the JS
> pool or to remove flaky ones. But we should be able to do this very
> rarely compare to the maintenance work we do nowadays.


That's what I hope too.

Cheers,
--
intrigeri