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
-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]
[freenet-support] Re: [freenet-dev] Retiring from the project
>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. 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. 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. 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. 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... Regards, J ___ 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 Wed, May 26, 2004 at 10:34:47PM +0100, 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) Primarily Classpath NIO bugs. -- 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
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 Wed, May 26, 2004 at 03:15:32PM +0100, Ian Clarke wrote: > 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. Avoiding proprietary software is ALWAYS an advantage. At least if you want anyone to run it on *nix. Also, precompilation is normally an advantage on memory usage, even if not on CPU. And in fact it usually is on CPU too. > > Ian. -- 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
On Tue, May 25, 2004 at 08:22:51PM -0400, Paul Derbyshire wrote: > On 26 May 2004 at 9:47, Phillip Hutchings wrote: > > > > > 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? > > In this case, because the result's performance sucks? Anyway, the > code to stick the little bunny in the system tray on Windows is a > system-specific case. And it's probably messier to do system specific > crap like that from Java than using native code. By the way, making > the icon a leaping rabbit doesn't actually make the darn thing run > any faster, you know. :P Freenet's performance sucks primarily because of implementation and architecture issues, NOT because of the language it's implemented in. If you think you can rewrite Freenet in 1000 lines of C++, and have it run 5x faster in 100kB of RAM, go right ahead! The basic problems here are NOT those of optimization, they are fundamental things such as how the network works. -- 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 01:37:04PM -0700, 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. Which are reduced by our not using GUIs etc. But certainly are still a big problem - we'd basically need an active win32 developer. -- 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
I suggest a puppy chasing it's tail. > > Oh, you know that when I get a bit of free time, that's the next change I'm > going to make to the freenet systray app... (of course, maybe a limping > rabbit, rather than a running one) > > d ___ 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
> In this case, because the result's performance sucks? Anyway, the > code to stick the little bunny in the system tray on Windows is a > system-specific case. And it's probably messier to do system specific > crap like that from Java than using native code. By the way, making > the icon a leaping rabbit doesn't actually make the darn thing run > any faster, you know. :P Oh, you know that when I get a bit of free time, that's the next change I'm going to make to the freenet systray app... (of course, maybe a limping rabbit, rather than a running one) d ___ 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 May 2004 at 9:47, Phillip Hutchings wrote: > > 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? In this case, because the result's performance sucks? Anyway, the code to stick the little bunny in the system tray on Windows is a system-specific case. And it's probably messier to do system specific crap like that from Java than using native code. By the way, making the icon a leaping rabbit doesn't actually make the darn thing run any faster, you know. :P ___ 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]
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 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 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 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
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. 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. > [Original Message] > From: Ian Clarke <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; Discussion of development issues <[EMAIL PROTECTED]> > Cc: Freenet technical mailing list <[EMAIL PROTECTED]>; Freenet support mailing list <[EMAIL PROTECTED]> > Date: 5/25/04 12:42:21 AM > Subject: [freenet-support] Re: [freenet-dev] Retiring from the project > > 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 > experimental approach is a necessary consequence of the fact that we are > doing something completely new that nobody has done before, this > necessitates a different approach than if we were, say, implementing an > operating system. Furthermore, many of the changes made to the code > have been to simplify and refactor it, not just to add further complexity. > > Anyway, thanks for your contribution to-date, can someone remove DFI > from the gateway page? > > Ian. > > Conrad Sabatier wrote: > > It saddens me more than a little to have to announce this, but I've decided to > > retire from the freenet project. I will no longer be active as a developer or > > as an index site maintainer, or as the operator of a node. > > > > I'm truly sorry, but with only a 1 gHz machine with 512 MB of RAM, freenet > > simply consumes too much of my system's resources, both in terms of CPU time > > and memory (not to mention bandwidth), especially continuously running a second > > Java app besides (the spider). > > > > 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. > > A native-compiled language would have offered vastly superior speed and, no > > doubt, significantly lower memory consumption as well. > > > > In addition, I'm finding myself increasingly put off by the project's apparent > > lack of organization and focus. Rather than streamlining, simplifying, > > cleaning up and verifying the existing design, we have a never-ending series of > > "let's try this" and "let's try that". Too many code changes are being done on > > pure speculation and hopeful optimism, rather than close scrutiny and careful > > analysis. I fear that at the rate we're going, as more and more new ideas are > > incorporated into an already extremely complex design, this burgeoning > > complexity will eventually result in a system that *no one* truly understands > > the workings of, or how the various parts of the whole interact, rendering it > > virtually impossible to anticipate or even estimate the impact that changing > > this or that part of the code will have on the rest. This does not exactly > > make me feel optimistic about the project's future success. > > > > I still do believe the project's goal is an admirable one, and an important > > one, and I do wish you all the best in your endeavors. > > > > Regards to everyone, > > > > Conrad (aka dolphin) > > > > ___ > 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] ___ 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]
[freenet-support] Re: [freenet-dev] Retiring from the project
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 experimental approach is a necessary consequence of the fact that we are doing something completely new that nobody has done before, this necessitates a different approach than if we were, say, implementing an operating system. Furthermore, many of the changes made to the code have been to simplify and refactor it, not just to add further complexity. Anyway, thanks for your contribution to-date, can someone remove DFI from the gateway page? Ian. Conrad Sabatier wrote: It saddens me more than a little to have to announce this, but I've decided to retire from the freenet project. I will no longer be active as a developer or as an index site maintainer, or as the operator of a node. I'm truly sorry, but with only a 1 gHz machine with 512 MB of RAM, freenet simply consumes too much of my system's resources, both in terms of CPU time and memory (not to mention bandwidth), especially continuously running a second Java app besides (the spider). 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. A native-compiled language would have offered vastly superior speed and, no doubt, significantly lower memory consumption as well. In addition, I'm finding myself increasingly put off by the project's apparent lack of organization and focus. Rather than streamlining, simplifying, cleaning up and verifying the existing design, we have a never-ending series of "let's try this" and "let's try that". Too many code changes are being done on pure speculation and hopeful optimism, rather than close scrutiny and careful analysis. I fear that at the rate we're going, as more and more new ideas are incorporated into an already extremely complex design, this burgeoning complexity will eventually result in a system that *no one* truly understands the workings of, or how the various parts of the whole interact, rendering it virtually impossible to anticipate or even estimate the impact that changing this or that part of the code will have on the rest. This does not exactly make me feel optimistic about the project's future success. I still do believe the project's goal is an admirable one, and an important one, and I do wish you all the best in your endeavors. Regards to everyone, Conrad (aka dolphin) ___ 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]
