Re: [freenet-support] Re: [freenet-dev] Retiring from the project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 27 May 2004 00:34, Dave wrote: Just for an update on this, bouncing the thread appropriately for devl: What are the current outstanding issues with GCJ compatibility (or, for that matter, Kaffe/Blackdown/IBM java compatibility) IBM's java is essentially a fork of Sun's java. I'm running freenet in IBM java 1.4.1 and it works most of the time. IBM's java is allergic to Linux 2.6 (the new threading model) and must be run in compatibility mode with LD_ASSUME_KERNEL=2.2.5 or else it will randomly freeze when fred is heavily loaded. - -- Roger Oksanen [EMAIL PROTECTED] +358 50 355 1990 CS Student at Helsinki UniversityPGP id 1B125A3E Homepage http://www.cs.helsinki.fi/u/raoksane/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAtbSA78OZUBsSWj4RApt9AKDDkz4UY0y8gD06IhI0WqhaFvjYUwCghSwa uyW+FBg7TnVrUXN+dQ+hT0A= =ALvo -END PGP SIGNATURE- ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] Re: [freenet-dev] Retiring from the project
On Thu, May 27, 2004 at 09:15:25AM +0200, Garb wrote: Conrad Sabatier wrote: I find Java's memory requirements to be totally unreasonable, its performance lackluster, and I've finally come to the conclusion that it was indeed a poor choice of language in which to implement a project of this size and complexity. As far as I see it, freenet is very much a project under development at the time, so therefore overall functionality and ease of coding should naturally take precedence over tweaking and local optimization on specific platforms. Conrad Sabatiers point is certainly valid enough. A little while back I took my linux box down for a 256MB memory update. When I started it back up, I was genuinely surprised over the substantial gain in speed and responsiveness I got from a measely 256MB upgrade - until I realized that I hadnt started freenet yet. When I did, performance went down the drain right away. Freenet's memory usage has already been improved substantially over where it was 6 or 12 months ago. However, as I have said over and over, and especially in the light of Moore's Law (which will likely continue for at least the next five years): RAM is cheap. Working software is expensive (the currency is man years). Freedom is *REALLY* expensive (the currency is human blood). I would imagine that freenet will eventually reach a point in its development cycle where both the networking protocol and the API are pretty fixed and no longer likely to undergo major changes. And at this time, the focus of the project should be switched to reduction of the system footprint and increasing the efficiency of execution on different platforms. Perhaps, perhaps not. I expect Freenet to continue to innovate the core platform for many years to come. I also imagine that freenet, once mature, will be a natural part of most major linux distros as one of the essentail networks that is supported out of the box - but that will not be in the form of a java app. Perhaps. And I don't see what Java has to do with it. Currently Freenet only works on the Sun JVM. In the future it will work with Kaffe, GCJ and all the Classpath-based free JVMs. GCJ will mean that it can be shipped as a standalone binary. Java is a great prototyping tool for the developers and programmers, but it is also the cause of many problems for the users. In fact I would estimate that 90% of the times that I have been called upon to assist someone in getting freenet to run, the difficulties have been caused by java rather than freenet itself. That has NOT been my experience. And it IS bloated and it DOES take up a lot of ressources - a fact that I see mentioned often in the mailing lists. I can imagine that this is also frustrating for the developers to read, since they cant do much about it - this is mainly in the hands of Sun Micro Systems... Java is a source of memory bloat. So is Freenet's architecture and bugs. We try to fix actual leaks. Sometimes we try to improve overall memory/CPU usage for its own sake. But see above. We are not writing a word processor here. We are writing something new. In all likelihood it will be several years before Freenet works as well as we'd like it to. There is no point rewriting it in assembly language; we need to get it WORKING, and that means the network protocol, and so on. Regards, J -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. signature.asc Description: Digital signature ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] Re: [freenet-dev] Retiring from the project
On Tue, May 25, 2004 at 05:39:34PM +0200, Troed S?ngberg wrote: On Tue, 25 May 2004 10:51:20 -0400, Jay Oliveri [EMAIL PROTECTED] wrote: 1) Fred takes too much CPU and RAM because it's written in Java. I hate this depate. It's true that object orienting uses up (a few) more bytes than non-OO programming, but that's trivial compared to the structuring you (can) get with OO vs non-OO. Absolutely, virtual pointers are well worth the cost. JIT Java (which we're all running) is also very speedy, there's only a few rare instances where it's worth the trouble to replace code with something natively instead. Debatable. But most of the problems with Java come from the fact that it is non-free IMHO. If and when freenet works on GCJ, we benefit from: 1. Reduced CPU usage due to better optimization and no compilation at run time. 2. Reduced memory usage for the same reason. 3. Increased performance for BigInteger operations such as crypto; 5-10x faster using the free GMP library than Sun's proprietary implementation. On the other hand, it's quite easy to lose control with object creation, and to forget how to help the GC do the work most efficiently. That has nothing to do with Java in itself though. Well, Java does tend to produce a lot of object churn. But even if I was doing a project the size of Freenet in C++ I would find a GC very useful. Explicit deallocation support would *occasionally* be useful. /me - professional Software Engineer, well trained in C, C++ and Java (although mostly J2ME) -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. signature.asc Description: Digital signature ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] Re: [freenet-dev] Retiring from the project
Toad wrote: JIT Java (which we're all running) is also very speedy, there's only a few rare instances where it's worth the trouble to replace code with something natively instead. Debatable. But most of the problems with Java come from the fact that it is non-free IMHO. If and when freenet works on GCJ, we benefit from: 1. Reduced CPU usage due to better optimization and no compilation at run time. There are optimisations that can be performed at runtime by a JIT which cannot be performed by a native compiler, so it can't be taken for granted that avoiding runtime compilation is an advantage. Ian. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] Re: [freenet-dev] Retiring from the project
Just for an update on this, bouncing the thread appropriately for devl: What are the current outstanding issues with GCJ compatibility (or, for that matter, Kaffe/Blackdown/IBM java compatibility) ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] Re: [freenet-dev] Retiring from the project
On Tuesday 25 May 2004 06:36 am, Robert Greenage wrote: This appears to be a major blow to the development of freenet.Conrad is a major force behind the whole project.Without him I don't see any other developer capable of stepping up and filling the void. He has a good point with the constant code changes that do seem to be a shot in the dark There is a fuzziness of focus that has impeded the development of the project. I'm not sure how long you've been around the project but to say you don't see any other developer capable of stepping up and filling the void is an overstatement. I thought Conrad's main points were: 1) Fred takes too much CPU and RAM because it's written in Java. 2) The project has no focus. I don't agree with either point in absolute terms, but there's always room for improvement. It saddens me to see a new significant idea come to fruition and then, for whatever reason(s) become bogged down in what appears to be an aimless series of attempts at correction. Conrad you will be missed. Well some of these ideas worked on paper, and then didn't work when they were released into the wild. Most of these ideas are untested, and do not have a prior-case to study and learn from. -- Jay Oliveri GnuPG ID: 0x5AA5DD54 FCPTools Maintainer www.sf.net/users/joliveri ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] Re: [freenet-dev] Retiring from the project
On Tue, 25 May 2004 10:51:20 -0400, Jay Oliveri [EMAIL PROTECTED] wrote: 1) Fred takes too much CPU and RAM because it's written in Java. I hate this depate. It's true that object orienting uses up (a few) more bytes than non-OO programming, but that's trivial compared to the structuring you (can) get with OO vs non-OO. JIT Java (which we're all running) is also very speedy, there's only a few rare instances where it's worth the trouble to replace code with something natively instead. On the other hand, it's quite easy to lose control with object creation, and to forget how to help the GC do the work most efficiently. That has nothing to do with Java in itself though. /me - professional Software Engineer, well trained in C, C++ and Java (although mostly J2ME) -- http://troed.se - controversial views or common sense? ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] Re: [freenet-dev] Retiring from the project
On Tue, 25 May 2004, Ian Clarke wrote: That is a shame. Clearly I don't agree with your reasoning, there is no evidence that any other language would not have similar or worse issues (consider the amount of time we would spend dealing with memory leaks and array overflows had we implemented in C++). As for focus, our Not to mention the issues with portability on a C/C++ implementation. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] Re: [freenet-dev] Retiring from the project
On 25 May 2004 at 13:37, Christopher Brian Jack wrote: On Tue, 25 May 2004, Ian Clarke wrote: That is a shame. Clearly I don't agree with your reasoning, there is no evidence that any other language would not have similar or worse issues (consider the amount of time we would spend dealing with memory leaks and array overflows had we implemented in C++). As for focus, our Not to mention the issues with portability on a C/C++ implementation. Issues with portability? If we were talking a GUI app I'd agree with you, but the core of freenet is basically a pure backend is it not? The only visible UI most of the time on Windows is a systray icon or the Web interface; the latter's retrieved via HTTP and will work with any browser on any OS, and the former is not something Java supports directly anyway, so displaying a suitable icon in a suitable background-tasks part of the UI is system dependent any way you slice it, causing exactly as many portability headaches in Java as it would in C or C++ -- maybe more since you probably have to wrestle with the hairy JNI to pull it off, rather than just having one, platform dependent #idfef-filled source file with the appropriate functions duplicated for all the different supported platforms. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] Re: [freenet-dev] Retiring from the project
On 26/05/2004, at 9:36 AM, Paul Derbyshire wrote: ... rather than just having one, platform dependent #idfef-filled source file with the appropriate functions duplicated for all the different supported platforms. That's the perfect reason to use Java! It may not be the nicest code, but you only have one version! It makes maintainability far easier than #ifdef'd code, which is problematic at best. If one code base runs on all platforms, and even better if the same executable does, then why not use it? -- Phillip Hutchings [EMAIL PROTECTED] http://www.sitharus.com/ smime.p7s Description: S/MIME cryptographic signature ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
