On 2011/08/30 (Aug), at 3:17 AM, Thomas Bruderer wrote: > Thank you Ian! Good message! I am 100% behind your whole post! The > routing must go back to a simple system!
Even tearing up the current systems for a fifo queue is destructive without organization and a means of comparison. In the science of software, there are generally two kinds of commits: * Features - divergent, potentially disruptive, tend to contain bugs * Bugfixes - convergent, generally repairing feature disruption, rarely unmask other bugs On 2011/08/29 (Aug), at 12:58 PM, Ian Clarke wrote: > The problem is that we come up with solutions that are too > complicated to analyze or fix when they don't work.... > The cause is complexity, which just grows and grows as we try to fix > problems we don't understand by layering on more complexity. And what is the cause of that? Is the problem really one of behavior? emotions? workflow? organization? Matthew has presented some very real problems which he is trying to work around (with much frustration, I'm sure). I think he needs more leverage If you read my suggestion below, we can discuss how it would allow: * a full-network-sized network to try out new features & bugfixes * nearly-identical traffic on both networks * zero traffic redundancy (network waste) * easy 1:1 comparison of various performances of two implementations (for measuring network effectiveness) * full network uptime (at worst a totally-broken / 0% unstable-side would yield a 50% reduction in effectiveness) It is simply a matter of *organization* and *multi-versioning* (which IMO, are both solved problems). This is also tied into the subject of 'mandatory' node update deadline, as the utility of a split network would diminish if it's stable-side succumbs to the same 'chase' issues. -- Robert Hailey On 2011/08/26 (Aug), at 10:18 AM, Robert Hailey wrote: > > On 2011/08/25 (Aug), at 2:15 PM, Matthew Toseland wrote: > >> And we never, ever, ever, have enough data to evaluate a single >> build, even on the simplest metrics (see the push-pull tests). I >> could write a plugin to get more data, but digger3 promises to do >> it eventually and anyway I don't have time given the remaining >> funding and unlikeliness of getting more. And it's always been this >> way! >> >> Our whole business model forces me to just do things and not >> evaluate them! > > I think we had an idea for empirical stepwise advancement earlier. > > With an investment of developer time, we could separate the current > freenet code into three interfaced sections (link-layer, routing- > layer, user/client-interface-layer). > > If we then were to modify the outer layers to accept two routing- > layers (e.g. client requests round-robin between the two but > thereafter stay in that network) we could have "two networks in one" > a stable-net (for the nay-sayers, a disaster/fallback, and as a > control for measurement), and a development-net where > experimentation could take place. > > Drawing the interface lines on theory (rather than present code- > state) would be critical [e.g. load-balancing should be in the > middle layer, imo]. The goal being, reliable communication with near- > guaranteed/methodical improvement. > > -- > Robert Hailey > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://freenetproject.org/cgi-bin/mailman/listinfo/devl -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20110830/b3f0eedb/attachment.html>
