I've been holding off on sending this email for ages but I'm sitting here for the zillionth time looking an insert that is going nowhere preventing me from inserting the kind of legal and legitimate content that freenet needs to survive and my frustration level is getting the better of me. I've been watching the freenet project since it's inception four years ago when I read the original white papers and running a node for two (this month marks my second year actually) and it really gets to me that freenet worked better a year ago.
Why do we think we can judge the performance of the latest unstable builds when we throw it onto a public network full of ancient broken builds? That isn't exactly controlling many variables or using scientific principles. Why do we have a build called "stable"? That implies it is useable when it is not. No build should be called "stable" until freenet reaches version 1.0. I know in this context stable means "relatively stable compared to unstable" but that's just silly especially when unstable is sometimes more stable than stable. Something extreme has to be done to get us out of the endless cycle of broken builds we have found ourselves in. I propose the following: Get rid of stable. There is no point in maintaining two codebases. It is killing us. Merge with unstable now and be done with it. It can't get much worse and ngr is clearly the future. Don't call the result stable or unstable, just give it a build number. Make a new release twice a week and twice a week only on a schedule. Tuesdays and Fridays for example. Why? Because... Last good build should ALWAYS be CURRENT_BUILD - 1. This way brand new nodes will have someone to talk to but we will only be talking to the most recent or second most recent build. Freenet SHOULD have to be upgraded once a week. Freenet is still in the development phase and changing quickly. Anyone running freenet should be willing to maintain their node and upgrade at least once a week. Those people running ancient 5xxx series builds should be booted in the head for fscking up the network. Letting people run builds months old is accomplishing nothing since the network as it is is completely broken and makes it impossible to gauge performance of the new build when we have old builds DoS'ing us with tons of connections, bad routing, and other bugs. Yes, some people might not upgrade and the network might shrink. GREAT. We'll get better performance for it I'm willing to wager. A smaller network that works is better than a big network which doesn't. But I bet that as long as people know what to expect and expect regular upgrades once a week they will do the upgrades or even cron their system to shutdown freenet on Tuesdays and Fridays, run the update script, and start it up again. I have set up a test network of 10 nodes on one box, removed all refs to external nodes, and seeded them all with each others references. I then inserted data, retrieved data, etc. Inserts worked well and so did retrieving although inserts were not quite as fast as I would have expected them to be talking to all local machines at around 1M/minute. Shouldn't something like this be part of the standard smoke test before release of a new version? Set up a bunch of nodes on a machine where the developer has access to the guts of all of the fred's involved, copy the new jar into them, start them up, and run a series of tests for inserts and retrieves and basically exercise all of the functionality and benchmark it against other builds looking for regressions? This is an *ideal* setup suitable for basic testing. My setup seemed to work ok aside from the fact that none of the nodes specialized which is actually a fatal flaw but perhaps I just wasn't pushing enough data through it. I will have to try again with some automation to insert and retrieve a whole mess of data and generate some useful statistics. Perhaps I'll work on this tomorrow. Can someone give me a command line example of how to insert and retrieve? I am having trouble deciphering the docs. Maybe I'll just go to fishtools. -- Tracy Reed http://copilotconsulting.com
pgp00000.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
