On Wednesday 12 March 2008 07:30, Sven-Ola T?cke wrote: > Matthew, > > thanks for pointers & patience. No ifdef? No problem, I can use patches. And > no - I don't need commit access. I prefer to have a personal filter for > commits until I'm really involved.
If there's no local client stuff, you can strip out most of the client layer. Although you probably do want to be able to fetch ARKs and auto-updates, so maybe not... You can strip out stuff like fproxy though. > > Google-SoC? Hmm - just received a query to do mentoring for ours (refer to > http://wiki.freifunk.net/Google_Summer_of_Code ). Not sure if I want to take > that job. How much work is that? Google says an average of 5 hours a week. > > Yep - I mixed up SVN and CVS. The ext-jar file name still have a cvs component > and both systems are too similar. Currently, my favorite is mercurial, since > it fits better to OSS and its less @"!%&/// compared to GIT. We're thinking seriously about that, there's a freenet plugin for mercurial, but nothing will happen before 0.7.0. > > I've splitted my patch in two. May I ask to commit at least this one? Nextgens? > http://download-master.berlin.freifunk.net/sven-ola/freenet/001-freenet-v1122-gcjcompat.patch > You may try to compile using GCJ for yourself, since it outputs a lot of > warning. The sun compiler isn't too chatty, isn't it? There are a lot of > unused variables and imports etc. - maybe that's worth a look. They're > non-critical but at least those warnings clutter my screen <ggg>. > > No - I don't have the hope to deploy on WRT54G. That's past. My target has 128 > Mb of RAM (maybe 64) and they dont need a browser on them because nobody will > climb up to a church rooftop in order to surf or mail (those boxes are meant > to be placed on high public buildings). If you use up too many memory, you > cannot hope to get too many freenet-users until a standard PC has 4 GB of RAM > (maybe 1010). So there's a natural limit for using too much resources anyhow. :) If it's purely a node, with no client activity, then it will work fine in 128M. It might work in 64M. Obviously you'll have other stuff running too... but it should be feasible with 128M total RAM and maybe with a bit less. Flash disk I assume? > > // Sven-Ola > > Am Mittwoch 12 M?rz 2008 00:55:35 schrieb Matthew Toseland: > > You might actually be better off with an embedded/low footprint VM? Some of > > them are very efficient on memory usage, and the hard stuff is mostly done > > via JNI or via system libraries which hopefully have optimised code. > > Although the CPU is likely to be quite a lot slower than we're used to... > > > > You should seriously consider an alternative datastore implementation, but > > I dunno what. And the global queue will be a big problem - right now our > > memory usage increases linearly with the number of queued keys (with a > > bigger factor for inserts than for requests). Obviously this is something > > we'd like to fix at some point (likely using a database), but it's going to > > be a fair amount of work - it could be done in a good SoC project. (I don't > > suppose you're eligible to be a Google Summer of Code student...?) > > > > However, if we're talking about a box with a 200MHz+ CPU and 512M of RAM > > (maybe down to 128M with no queue, lightweight browser etc), and if we have > > optimised FEC libraries, it should be possible. But it'll probably never > > run on e.g. a Linksys WRT54G (16M RAM in recent models iirc). > > > > PS it's SVN not CVS. Any changes for GCJ support that aren't too ugly > > should be merged with trunk - email me if you want SVN commit access, > > include username, password, etc. Major changes should go on a branch until > > 0.7.0 ships. Bundling a README or scripts for building with GCJ is a good > > idea, but iirc there are some biggish bugs to work out still (try running a > > GCJ-built node). > > > > No idea re ifdef's, certainly there's no built in support for this. > > > > On Tuesday 11 March 2008 18:53, Sven-Ola T?cke wrote: > > > Hey, > > > > > > completed my next step - which is a binary-only freenet compiled for > > > i386. Looks like that it's running - whith some complaints of not having > > > the wrapper and cannot autoupgrade etc. Maybe threading has issues. > > > > > > The resulting binaries are a bit large (8 Mb program and 8 Mb shared lib > > > > plus > > > > > the ubiquitous libgjc with ~80 Mb). I've also tried to link static > > > against libgcj.a - but that fails (maybe because I've grabbed an unsigned > > > binary > > > > from > > > > > a french linux called mandriva - ubuntu does not offer libgcj.a). This > > > one looks also promising: http://ulibgcj.sourceforge.net/ but may require > > > a change from JNI to CNI. > > > > > > I order to compile for mips, I have to refresh my mips-GCC/GCJ > > > (recompiling now for 2 days - still running, those embedded boxes are not > > > too fast)... > > > > > > Please mind: > > > > http://download-master.berlin.freifunk.net/sven-ola/freenet/readme-compile. > >txt > > > > > P.S. While I'm not a Java expert - for unbloating software, normally an > > > > #ifdef > > > > > is a good thing [tm]. Any analog contructs with this funny language? > > > > > > // Sven-Ola > > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080312/2ff23126/attachment.pgp>
