-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | I disagree. Your actual bandwidth usage is determined by how many requests the | other nodes send you. This is largely determined by the *average bandwidth | limit* across the whole network. If we increase the average bandwidth limit, | we increase the traffic on your node.
Ah, ok, that's probably true. I was thinking you've been talking about that helping *my* node to better utilize the bandwidth available, hence my reply. |> Great that we agree on this one. I've been unsuccessful in bringing at |> least two of my friends to Freenet because they were running into |> memory-related problems, one of them going as far as calling Freenet |> "that damn bloatware" (well, actual wording also included a couple of |> pretty strong Russian expletives :-((((). | | Hehe. Consensus is good. They are specifically talking about memory/CPU here? | Or bandwidth usage, total transfer in a month, etc etc? Well, memory usage was what finally turned them off, as far as I can see. One of the people I've mentioned (a pretty experienced computer and p2p user) had immediately and repeatedly crashed his node upon discovering Thaw and Frost file sharing tools - he put a couple of hundreds of large files there for both insertion and download, not really understanding how Freenet handles this (on a side note, this is something which is *really* unclear to most casual P2P users I've talked to, especially those with Gnutella/eMule/Kazaa background). Naturally, Freenet quickly ran out of memory, and simply wasn't recovering on its own. We've finally been able to solve this problem by giving Java enough memory to load the queue, then quickly removing files from it (there's probably a better way, but I wasn't aware of it). In the second case, the machine on which we tried to install Freenet was a little bit old (but nothing ancient - P4 2.4 GHz/1 Gb RAM), used as a dedicated P2P machine by my other friend. Shortly after installing Freenet, it became unresponsive - almost constant disk access, high CPU usage, etc. After stopping Freenet, the load went down immediately. We tried actually giving Freenet less than default memory (96 Mb, IIRC), but it didn't really help. |> Well, it seems more or less straightforward from the outside: handle |> additional update URLs and a set of (revocable?) public keys + expose |> the API over FCP. Am I missing something important? | | Yeah but we'd have to unpack, support post-unpack scripts, etc etc ... really | we'd want the apps to provide their own unpacker and just feed them a single | file for them to do what they want with? I think that the latter approach is preferable - they could be using full-blown native installers, etc. No need for Freenet to open that can of worms. Just allow the app to check for updates over FCP and feed it the (verified) update file when one becomes available. What to do with it is up to the application. Regards, Victor Denisov. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKekCS81Mh9/iCDgRAirPAKDMp5pzomB5CCZgDSJmS9iHv0I0RgCg02+v eEJQYj+Qj0VTyGW2I1uXJDE= =6bPm -----END PGP SIGNATURE-----
