Hi I really do not like this idea. Freenet is written in java. It does NOT require an installer to get it working (and it will work on any platform with the requisite java). Making this sort of change would require one to use an installer. Why should we require someone to use a piece of software to install another one - consider do we want to have to treat installer bugs as critical? We will have to if that is the only way to install freenet...
Thanks Ed Tomlinson On Tuesday 14 February 2006 12:58, NextGen$ wrote: > * Dennis Olsson <cyberdo at acc.umu.se> [2006-02-09 18:31:54]: > > > On Thu, 9 Feb 2006, NextGen$ wrote: > > > > >Hi, > > > > > > Worried by the growing size of freenet-ext, I had an idea : What > > >about moving the CPUID code to the installer? We would provide several > > >"extended libraries" for each supported OSes and CPU type. > > > > > > Assets would be : > > > - less code in the node > > > - "very small" startup time improvement => It won't > > > auto-detect the cpu type using JNI at statup > > > > Is this what's so time consuming? (real question, I don't know) > > > > No but it's an additional JNI call. > > > > - Smaller files to download => bandwidth usage friendly and > > > less time consuming > > > - We might compile dynamicly linked libraries insteed of > > > statical ones. > > > > Lovely for upgrading parts, a pain in the... if it means a lot of > > dependencies. > > > > > > > > Caveats : > > > - why changing working things ? > > > - would mean that people won't be able to "move" their > > > freenet directory from one box to an other and expect it > > > to work on the first try. > > > > This could be solved using a wrapper for freenet that, upon a change in > > architecture or OS will re-run that bit of the installer... > > > > Agreed : To be written ;) > > > > - setting up a node without the help of the installer will be > > > harder as you'll have to choose/download/rename the right > > > file. > > > > By placing the needed files in different dirs, they's still have the right > > name when downloaded, so only some descent sub-division of the files is > > needed. > > > > This could even be solved with a file-picker-page, very much like: > > http://www.delorie.com/djgpp/zip-picker.html > > > > We don't need it as antinstaller uses ant and ant allows to rename files > > > People who still want to walk the extra mile simply have to accept the > > increased amount of work. The node should be easy for the users, and > > contollable for the 'power users'. > > > > agreed > > > > > > Some facts now : > > > current freenet-ext is 2.3M big : each library is 200K > > > uncompressed and we have 22 libraries for now. > > > > > > current alpha-node is smaller than 800K. > > > > > > Most of x86_32 optimizations are supported on both windows and linux. > > > We have a PowerPC lib for MacOS and a x86_64 lib. for linux. > > > > > > Any feedback will be highly appreciated. > > > > > >NextGen$ > > So, is everyone ok with it ? > I've created a ticket on mantis > https://bugs.freenetproject.org/view.php?id=75 > > NextGen$ > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > >
