This mail shall contain only my ideas about your proposals. I've posted my proposals in a reply of its own. It's easy to discuss the both of them in separate threads.
On Friday, May 06, 2016 12:02:08 AM Ian Clarke wrote: > * Speed - > Make Freenet requests and responses faster Working on the core network algorithms is one of the most complex tasks we have. Only the "src/freenet/node" directory alone is 74 000 lines of code (with only 2000 lines of unit tests for that :|). Given that Matthew said he's not available with the current level of funding, we would have to spend very significant education costs on anyone else doing this. Only the education might easily exceed the 6 months of planning you suggested. And before any attempts at changing things are released, the whole 12 months of funding could expire: A new developer would first have to understand the codebase. Then write simulations / measurements. And only then he could start modifying the actual network. And then he might still have to wait for the half a year release cycle of Freenet to allow his first experiments to hit the network. And then as there's usually more than one cycle of doing changes and measuring the results, he'd have to wait for another release afterwards... But there are very good news about the network performance: - AFAIK, Matthew is doing Freenet simulations as his bachelor's thesis. He talked about the simulations on IRC, they also seem to include load management stuff. He did send quite a few pull requests from that as well. So given that he is *the* core network expert, I would say we should wait for the results of his work to be finished before we spend any time on educating someone else. Maybe his improvements will be enough already! :) - The other volunteers have also done very much work on the core network recently. - During his 10 years of employment, AFAIK Matthew's focus was mostly the core network performance and security. And he did very good performance improvements recently. I've done tests of downloading well-seeded files, and I do feel like this can exceed 500 kb/s easily even on my 8 year old laptop. So do we even want to invest any further money on core performance currently? It could just be enough. And we have certainly neglected stuff beyond the core for many years. So IMHO we should focus on the performance of the many potential client applications. See my other mail. (Client performance is not only WoT which is mentioned there, Sone/Freetalk will also need performance work. But WoT is a prerequisite for both.) > * User friendliness - Work on FProxy and installer to make them easier to > use About installers: The Mac installer was recently rewritten by Stephen Oliver (mrsteveman1), so no work is required there most likely. The Windows installer was also rewritten recently I think. What we do definitely lack is Debian packages. This has recently been investigated on the mailing list, and received some volunteer work. AFAIK it would be very difficult due to issues with the bouncycastle crypto library. IIRC, we use a newer version than current Debian, so we cannot use the one from package management. Adding a package of our own is probably not allowed since crypto libs are very security critical, and Debian is conservative about security. Nextgens seems to be doing a lot of crypto work recently, and once he's finished, the bouncycastle version we use might stay constant for a while. So perhaps this might unfortunately be something where we just have to wait for our bouncycastle requirements to settle, and a new Debian version to ship what we need? With regards to FProxy: You're right that it needs some work! For specific proposals from my side, see the "USE FRIENDLINESS" (should have been "USER") section of my other mail. > * Security - Make Freenet more secure against attack > * Technical debt - Stuff that will make future development faster > * Outreach - Stuff that will help attract users, developers, and donors to > Freenet (eg. the website) (see my other mail for specific proposals from my side) -- hopstolive (keyword for Ians spam filter)
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
