On Monday 11 October 2010 23:16:48 Ximin Luo wrote: > On 06/10/10 13:08, Todd Walton wrote: > > On Sat, Oct 2, 2010 at 11:55 PM, Volodya <[email protected]> > > wrote: > >> Freenet is in active development. > > > > The good old standby argument. > > > >> Stability is good, but would you rather have a buggy insecure node? > > > > So, Freenet is buggy and insecure? I understood that it was caveat > > emptor, but being so buggy and insecure that a fix can't wait a mere > > two weeks or so is something else entirely. > > > > (I meant to reply to this much earlier, forgot, sorry.) > > I agree, the "in-development" argument shouldn't be used as an excuse, and > it's > wrong to use it as an excuse. Frequently *forced* updates are a *bad* thing > and > we should aim to reduce them. > > The reason for the "forced" updates is *protocol changes*, due to freenet > being > a distributed network. This means that newer nodes won't talk to, or will have > trouble talking to, older nodes. This is what's unavoidable and "forces" an > update - we don't directly force people to update; you can turn auto-update > off. > > I don't know exactly how Matthew chooses when to make a particular build > mandatory, but I'd guess it would be based on a subjective judgement of when > to > force all nodes to switch to the new protocol, rather than have parts of the > network talking different languages. > > I'm pretty sure that fixes to buggy/insecure code don't *force* updates (at > least, we shouldn't do this - no other project forces updates, even for > security reasons).
Why is it bad to make e.g. a content filter vulnerability mandatory? It looks legitimate to me... > > The changelogs don't actually explain this. I guess it would be best to > explain > exactly why a build is being made mandatory, such as highlighting the > particular protocol change that's triggering it. Fair enough, I just assume it is obvious when I am making a bunch of core changes, but maybe I need to explain more.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://freenetproject.org/cgi-bin/mailman/listinfo/devl
