> > Well, I thought you were worried about something running in Fred's JVM > > by default. > When you next talk to the press and mention Freenet as a replacement for > internet radio (which it is not), everyone will turn it on and try to run it > for a while until the network collapses.
More groundless pessimism. You have no evidence that Freenet could not deliver an FM quality stream - in fact, we have seen indications that it can, and things are only likely to get better as the network improves. > You don't want fred to have to compete with code that is running continuous > FEC decoding in the same JVM. Perhaps your machine is so powerful that you > haven't noticed, but we can't get fred to run with reasonable CPU usage *all > by itself*. So it is more efficient to have two JVMs running than one? I would love to hear that argument. > 0) If the code runs in it's own JVM then when it crashes it doesn't take down > fred. Ever heard of proper exception handling? Why didn't you think of this argument for FProxy, FEC, and all the other client-side stuff? When is the last time FEC decoding took down your node? > 1)Fred has the help of the OS scheduler in competing with it for resources. Huh? Please explain - if these things are running in different threads then they have the "help" of the OS scheduler anyway. They don't need to be running in two separate JVMs. > 2)If all requests go over FCP fred can better defend itself from clients that > make unreasonable requests. Again, this is a meaningless statement. We can't actively prevent people from running one client or another with their own node (hey, maybe with Palladium we could...?!). Ian. -- Ian Clarke ian@[freenetproject.org|locut.us|cematics.com] Latest Project http://locut.us/ Personal Homepage http://locut.us/ian/
msg06405/pgp00000.pgp
Description: PGP signature
