7 votesAdmintoad (Admin, Freenet Project Inc.) responded
Please contact the support list at support at freenetproject.org, or see http://freenetproject.org/lists.html . Sustained high CPU usage should not happen with Freenet. It may use 100% cpu for brief periods, but will do so at a low priority and should not cause a significant slowdown. This may be related to having lots of downloads, we will do significant further optimisations on that soon.
What are you running it on? Freenet uses about 20% of one modern core in my experience, and you are likely to have more than one (it might struggle on an ATOM system or similar though). However, it may be configured to use less memory than is optimal, especially if when it was installed the computer didn't have much RAM. This is the most common cause of constant 100% CPU usage (it's constantly trying to find free bytes, eventually it will crash). Also, if you are using plugins such as Web of Trust and Sone that can make it use more RAM and therefore more CPU. IMHO mostly nowadays the problem is disk access, not CPU... we're working on that too.
This is mostly out of scope for Freenet, though it's a good idea. Freenet can run over a local meshnet, although you need to make sure that darknet (friend) connections aren't *all* very nearby: you want a small world network, not a pure mesh network, from the freenet point of view. So some of your connections/friends would need to be more than one hop, i.e. be routed by the underlying mesh network. This is very inefficient as it wastes radio spectrum by repeating packets. Conceivably Freenet could have some support for local multicast over such networks.
Anything that's more than one hop will be fairly inefficient because of having to relay the data. More generally, mesh networks are a good idea, but it is technically difficult, and expensive, with current technology to get good performance unless there are only a few nodes; proper wifi networks use infrastructure, and somebody owns infrastructure. A fully decentralised, reasonably scalable system would require that users have boxes on their rooftops, with both sectors and multiple directional aerials, preferably software aimable so that they can change when e.g. people leave, new nodes are added. IMHO the expense and hassle is probably unrealistic with current technology, though with beamforming it might be possible.
I'm not an expert in this, but I have had some involvement; let me know (toad) if you make any progress! :)
We don't have the resources, but if people want to work on this please let us know. It may make more sense to work with an existing privacy-oriented distribution. IMHO there is a lot that could be usefully done re local privacy, encryption of temporary files etc.
We are planning to get rid of db4o and implement a more robust system for download persistence. Probably start on this in late June.
You can report bugs on the bug tracker but you have to create an account first. The reason for this is we need to be able to contact people who report bugs to check whether the solution works.
Right, that's what bin/remove_crontab.sh does.
You can either uninstall it, or use the provided script bin/remove_crontab.sh.
We currently use 256-bit block size Rijndael, which isn’t strictly AES. We are slowly moving to using AES, for example, CHKs already use AES via JCA. In theory JCA should allow us to access hardware acceleration. Unfortunately in practice it is not often faster in practice because of the considerable setup costs. However this is based on comparisons of native code, without AESNI, versus pure java code. Also, using JCA may actually be slower than our built-in Rijndael (AES) class; I am looking into this with Eleriseth. Watch this space.
First off, the best place to have this discussion is the tech mailing list. You can sign up from the web page under Mailing Lists.
I don't believe PC/Mac/Linux is a shrinking hardware base. It's just not expanding as rapidly as it once did. "Today's platforms" remain Windows, Mac and Linux, in that order.
People in the third world who only have a basic cellphone are unlikely ever to be able to run Freenet (as an open p2p network), even though in theory it could be made to run on Android. The reason is simply that most mobile providers, even in the developed world, have severe monthly bandwidth usage limits. In fact the bandwidth will cost far more than a PC would.
"Low power always on hardware" is the ideal in the long run, I agree. However today it doesn't really exist in the mass market. Home server boxes are more common than they once were, but they are a minority, a toy for geeks. And people who can't afford a PC certainly won't have a home-server-box.
Anyway, I don't see what your practical point is. We should probably make it possible for Freenet to use hardware acceleration where it is available. However on many systems the overhead of JNI outweighs the benefits, especially for packet crypto, so don't expect big gains.
The bigger issues on low end systems IMHO are disk I/O, the fact that it's always on, and the fact that it needs a lot of memory to run well. Few home server boxes have enough to run Freenet yet, especially if you are doing other stuff too.
Currently the overwhelming majority of Freenet nodes run on x86, 80% or so Windows, more Linux than Mac. Freenet generally works best with fairly high uptime, especially on darknet, a long term focus, so I entirely agree that in the long run we should be targeting some sort of home server box. Right now most such devices on the market don't have enough RAM to run Freenet, but it looks like that's changing fast. Realistically we need 512MB to run a node with plugins, 256 at an absolute minimum, more if there are other things on the box. (E.g. freenet + bittorrent + mythtv would be awesome!). We also need a reasonable amount of storage - there are security reasons to think about imposing a minimum datastore size of say 10GB.
As I understand it there are usually JCA libraries for using the native crypto acceleration on such systems. I haven't checked this in detail. If you have researched specific systems I'd be very happy to hear it; I'm pretty busy! The main problem with this is anything using JNI has a fairly substantial overhead, and the API usually doesn't allow you to efficiently reuse a cipher with the same key and a new IV either. So on x86 it looks like it may actually be faster to use pure java - at least if encrypting small amounts of data e.g. packets.
Currently, encryption of CHKs uses JCA if available (key length issues), otherwise uses the built-in pure java code. We may change that to benchmark it, but it's likely JCA is always comparable as CHKs are 32KB. Connection setup uses ECDH and DSA, the former is used via JCA (hopefully we will be able to use the NSS native code JCA provider in the near future since there is a ~ 5x speedup when it's supported). We will soon use ECDSA via JCA as well.
The real question is packet encryption. There is an argument to not bother changing this to JCA because it's not any faster on x86, although long term clearly we should switch from the 256-bit block size to a standard AES (128-bit block size) for (marginal) security reasons. However, as you point out, on embedded hardware it is likely that switching to JCA will give a big performance gain.
Probably we will end up supporting both and using whichever works faster according to boot-time benchmarks.
Finally, many embedded hobbyist systems don't have a licensed commercial JVM, and the free ones aren't all that fast...
Please contact us if you have any interest in this stuff!
There are ongoing discussions on using some form of continuous integration. We have had unit tests for some years but there is limited coverage. Testing on Linux and Windows on a normal release is feasible, as those who do releases can likely have access to both platforms. However testing on Mac is not generally possible, except possibly via third party support. The unit tests do not operate at anywhere near this level though. And mostly Mac issues are related to the installer and changes in the operating system, which again we have difficulty dealing with. Let me know if you can help, we do have a recent volunteer for this…
Re embedded java, Freenet doesn't use Swing or other APIs (okay it uses a little bit of AWT to generate graphics when web-pushing is enabled, but that's trivial). 99% of it just uses the core java APIs. So it could almost be built for Android out of the box, let alone (higher level versions of) embedded java.
Freenet works fine on Windows. Building it and running it without using the installer can be a bit convoluted, there should be a wiki page about this. We require various libraries, we strongly recommend using the Java Service Wrapper, and for opennet you need the seednodes file.
I agree currently unit test coverage is inadequate. In particular we need more high level tests.
I'm not sure what you mean by integration tests, we do have a few high level tests which use multiple nodes in one JVM, these are in freenet/node/simulator/ . Clearly we need more. These are too slow to be used routinely in unit testing but could be adapted for continuous integration.
However there are serious architectural security issues that need solving too. And we have limited resources; since most users assume Freenet has near-perfect security, there has often been an emphasis on solving non-security problems, such as performance or ease of use. However recently there has been a push to solve some of the fundamental problems.
In any case, help would be appreciated. I can't do everything, the more volunteers we have the better.
Basic problems with this sort of utopian wireless vision are 1) current wireless routing algorithms don't scale beyond a few thousand nodes (please update me if you have better info); 2) if you're just layering freenet on top, and using that, then you have to consider that this is radio, a broadcast mechanism; maybe it could be optimised for that, but preserving privacy? not sure... 3) at a hardware level, this sort of thing won't work well and / or scale (due to e.g. noise) unless everyone has multiple rooftop-level directional antennas, which is a big hassle and rather expensive, especially as they'll have to be re-pointed when people enter and leave the network. IMHO for this to take off we need both better routing algorithms (for IP traffic) and better hardware, in particular some sort of cheap box including multiple software-aimable directional aerials, maybe via beamforming.
245 votesAdmintoad (Admin, Freenet Project Inc.) responded
Most applications need admin rights to install on Windows. On unix, Freenet is self-contained within the installing user. More broadly, we don’t really want to encourage people to run Freenet for a few hours a day here and there behind other people’s NATs as low uptime is very problematic for the network; if you do need to run Freenet from a webcafe, use a laptop.
One final point: Freenet could benefit from being "portable" i.e. not leaving any traces, even if you don't run it on third party machines (which is generally a very bad idea since they're probably infested with keyloggers etc). If you can help us build a more portable package, let us know. (A bundled browser has a lot of advantages too).
More than several probably: You would have a small core of nodes with good uptimes and a huge number of nodes with low uptimes. This might be a feasible model but would likely need major work on routing and other stuff. IMHO it is distant future, and would need a lot of simulation work first. Using your laptop is much more secure, that's the main difference: The cafe owner, the police, or anyone else who left some malware around, can steal your node identity, impersonate you, read your download queue, etc; it's not a good idea generally to run a node on a computer belonging to somebody else whom you have no good reason to trust. If your node is actually portable with its full node identity, as opposed to bootstrapping a new node on the cafe PC, then it's pretty equivalent otherwise. The other issue here is packaging - we don't have the expertise, although in principle I can see some benefits to having a self-contained folder with a browser and a node and so on, it would need some platform specific work and ongoing maintenance (which isn't a reason not to do it, it's a reason why we'd need help from new volunteers).
Can you give any more information about your rebooting? I really don't see how Freenet could cause this. Most likely your computer is overheating or something?
What exactly is the problem? You could answer here or post to the support mailing list (you need to join it first, go to the mailing lists page on the website).
This is planned. We have code that implements this for Ogg Theora, but it’s not merged yet.
There are however some technical difficulties especially with starting to playback before we have the whole file and with losing parts of it. But this will happen in some form.
Please show us what the error message actually said.
Run the remove_cronjob.sh script in bin/
Mostly these are separate - it should be able to do both at once, although Freetalk can take some time before it starts downloading actual messages.
Large freesites are not handled very efficiently at the moment. We have half-finished code to greatly improve this, but don’t have time to integrate it in the near future. Apart from that, it would be good to have a mirroring wizard.
Try adding ?forcedownload=true to the url.
Freenet publishing as a filesystem and/or as WebDAV isn't a bad idea, but you will still need to have some "commit" operation.
In fact it looks like we only have the user visible stuff (send a text message, recommend a bookmark etc) ... I don't think we have app-to-app comms yet ...
Freenet provides distributed, anonymous data storage - the basic operations being insert and retrieve. On top of that lots of apps can be and have been built. However, it also provides the ability to connect directly to non-anonymous friends ("darknet"), and there are (currently relatively limited) APIs for sending short messages to them. Anything you can do to encourage use of darknet would be helpful, let us know what sort of APIs you need and we'll consider it. However, I believe we already have FCP APIs for sending small messages between nodes?
Is it so difficult to ssh -X ?
I'm not sure I follow. You want to have different bits of HTML be different keys? One reason we include everything in a container is that it is more reliable: very small single files tend to fall out too easily.
Re databases, there are some ideas for that, see the wiki.
Very unlikely in the short to medium term. Long term, we will need a filter for office file types, and sharing could be implemented by a plugin. It would be slow though - likely better to publish the final results on Freenet rather than trying to keep it up to date in real time.
Long term, Freenet may or may not support non-real-time transports suitable for hostile environments: Sneakernet (exchanging a USB key with each of several friends regularly), wireless rendezvous (when your phone gets near your friend's phone they exchange lots of data), and so on. Haggle does something similar in "opennet" fashion (= sitting on a bus, shout "DOES ANYONE HAVE A COPY OF THE PENTAGON PAPERS???", and hope there isn't a secret service agent nearby); Freenet would do it in "darknet" fashion (= talks to friends when nearby). There are two views within the Freenet project as to whether this is within Freenet's remit, although such a system might use some Freenet-derived technology.
Freenet in the long term is intended to work over a variety of transports, possibly including non-realtime means such as phone rendezvous, sneakernet, etc. IMHO community wireless that isn't owned by anyone is unlikely to provide good performance cheaply with current technology (because of routing overhead, the expense of the rooftop directionals you need for infrastructure, and so on), but good luck. Freenet itself will work fine with darknet peers added via wifi links, provided the packet loss isn't too high, but it does need (a few) "long" links (e.g. over the internet, or maybe directionals) as well as "short" links. In general freenet routing on darknet will work well if it is a small world network; the best way to ensure this is to connect to people you know, and if they are close enough that you can do that via wifi, ronjas or similar, that's awesome.
AFAIK ICANN didn't shut down wikileaks, their domain hosters did; look at all the other domains that wikileaks is still accessible on. The big story with Wikileaks is that the internet is vulnerable: hosting controversial content is extremely difficult, as only the big providers can deal with big DoS's and many of the big providers are vulnerable to political interference.