Re: [freenet-dev] Combating bloat (was: Re: Post 0.7?idea:?off-grid darknet!
* Matthew Toseland <[EMAIL PROTECTED]> [2008-05-19 12:58:24]: > > > > > software on people's machines which we didn't write, and which for all > > > > > we know could contain well hidden code to delete their hard disks on > > > > > July 4th just for a laugh. If we install this software, WE ARE > > > > > RESPONSIBLE FOR WHAT IS DOES. We don't have the resources to audit > > > > > this code, and we can't install anonymously written code on people's > > > > > computers without an audit. > > > > > > > > Agreed, that's a big concern... and reviewing all the 3rd party code we > > > > bundle is unrealistic. > > > > > > > You mean the database engine (BDBJE currently), the native big integer > code, > > > the java service wrapper, etc? > > > > We can make the assumption that they are widely used and that they were > > reviewed by competent people outside of freenet's scope. > > > > I don't think that making such an assumption for freenet-related code is > > wise; Who would use Thaw/jSite/Frost/... without freenet ? > > > > > Or you agree with Ian that we shouldn't bundle any freenet-related code? > > > > I agree with Ian that bundling freenet-related code might lead to > > problems... Both from the PR PoV and from the legal one. > > In which case, we should simply link to the freesites for popular > applications? That would be much better imho signature.asc Description: Digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea:?off-grid darknet!
* Matthew Toseland <[EMAIL PROTECTED]> [2008-05-19 11:47:16]: > On Sunday 18 May 2008 05:17, Florent Daignière wrote: > > * Ian Clarke <[EMAIL PROTECTED]> [2008-05-17 13:35:40]: > > > > > On Sat, May 17, 2008 at 6:10 AM, Matthew Toseland > > > <[EMAIL PROTECTED]> wrote: > > > >> Exactly, which is why Thaw, Freemail, etc are the apps that will > > > >> motivate users to use Freenet. Only developers download the JRE, most > > > >> users get it bundled with Java apps. The same will be true of > > > >> Freenet, its a platform, most end-users don't want platforms on their > > > >> own. The solution is *not* to bundle, that is just pretending that > > > >> Freenet is more than it is. > > > > > > > > We have a lot of traffic from wikipedia. We have a lot of traffic from > > > > slashdot. For a user to even understand what Thaw is he must first > understand > > > > what Freenet is. Thaw, Freemail, FMS and jSite, don't have any sort of > web > > > > presence right now. > > > > > > So they should get a web presence, we can't reinvent sourceforge, and > > > we can't reinvent apt-get, we don't have the resources. > > > > > > > Agreed > > > > > > Freenet is not the same as Java. It's a bad metaphor. Maybe it would be > a > > > > better metaphor if any major freenet client had a web presence and > > > > significant hits of its own, but none of them do. AND WE CAN'T WAIT FOR > THEM > > > > TO GET ONE > > > > > > Why not? It would be a 30 minute job for those apps to set up with > > > Google > Code. > > > > > > >, for much the same reason that we couldn't wait for FMS to release > > > > 0.7.0. That means we have to do what we can for *our users*, which means > > > > making it as easy as possible to get these client applications. > > > > > > You must think our users are morons if the only way they can use an > > > app is if we bundle it. FMS isn't bundled, and it seems to have no > > > shortage of users. > > > > > > This "we've got to bundle everything" is a classic feature creep > > > attitude. If you think being user friendly means installing a bunch > > > of software on someone's computer without them asking for it then you > > > have a bizarre notion of user friendliness. > > > > > > We aren't Google Code, we aren't apt-get, and we aren't Sourceforge. > > > Trying to be those things will be a massive waste of resources. > > > > > > > On the other hand, hosting freenet-related projects doesn't involve too > > much overhead as far as emu's administration is concerned... And it > > allows us to cross-reference bugs in between applications and the node, > > which is very handy. > > > > > And of course there is also the issue that we would be installing > > > software on people's machines which we didn't write, and which for all > > > we know could contain well hidden code to delete their hard disks on > > > July 4th just for a laugh. If we install this software, WE ARE > > > RESPONSIBLE FOR WHAT IS DOES. We don't have the resources to audit > > > this code, and we can't install anonymously written code on people's > > > computers without an audit. > > > > Agreed, that's a big concern... and reviewing all the 3rd party code we > > bundle is unrealistic. > > > You mean the database engine (BDBJE currently), the native big integer code, > the java service wrapper, etc? We can make the assumption that they are widely used and that they were reviewed by competent people outside of freenet's scope. I don't think that making such an assumption for freenet-related code is wise; Who would use Thaw/jSite/Frost/... without freenet ? > Or you agree with Ian that we shouldn't bundle any freenet-related code? I agree with Ian that bundling freenet-related code might lead to problems... Both from the PR PoV and from the legal one. signature.asc Description: Digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
* Ian Clarke <[EMAIL PROTECTED]> [2008-05-17 13:35:40]: > On Sat, May 17, 2008 at 6:10 AM, Matthew Toseland > <[EMAIL PROTECTED]> wrote: > >> Exactly, which is why Thaw, Freemail, etc are the apps that will > >> motivate users to use Freenet. Only developers download the JRE, most > >> users get it bundled with Java apps. The same will be true of > >> Freenet, its a platform, most end-users don't want platforms on their > >> own. The solution is *not* to bundle, that is just pretending that > >> Freenet is more than it is. > > > > We have a lot of traffic from wikipedia. We have a lot of traffic from > > slashdot. For a user to even understand what Thaw is he must first > > understand > > what Freenet is. Thaw, Freemail, FMS and jSite, don't have any sort of web > > presence right now. > > So they should get a web presence, we can't reinvent sourceforge, and > we can't reinvent apt-get, we don't have the resources. > Agreed > > Freenet is not the same as Java. It's a bad metaphor. Maybe it would be a > > better metaphor if any major freenet client had a web presence and > > significant hits of its own, but none of them do. AND WE CAN'T WAIT FOR THEM > > TO GET ONE > > Why not? It would be a 30 minute job for those apps to set up with Google > Code. > > >, for much the same reason that we couldn't wait for FMS to release > > 0.7.0. That means we have to do what we can for *our users*, which means > > making it as easy as possible to get these client applications. > > You must think our users are morons if the only way they can use an > app is if we bundle it. FMS isn't bundled, and it seems to have no > shortage of users. > > This "we've got to bundle everything" is a classic feature creep > attitude. If you think being user friendly means installing a bunch > of software on someone's computer without them asking for it then you > have a bizarre notion of user friendliness. > > We aren't Google Code, we aren't apt-get, and we aren't Sourceforge. > Trying to be those things will be a massive waste of resources. > On the other hand, hosting freenet-related projects doesn't involve too much overhead as far as emu's administration is concerned... And it allows us to cross-reference bugs in between applications and the node, which is very handy. > And of course there is also the issue that we would be installing > software on people's machines which we didn't write, and which for all > we know could contain well hidden code to delete their hard disks on > July 4th just for a laugh. If we install this software, WE ARE > RESPONSIBLE FOR WHAT IS DOES. We don't have the resources to audit > this code, and we can't install anonymously written code on people's > computers without an audit. > Agreed, that's a big concern... and reviewing all the 3rd party code we bundle is unrealistic. signature.asc Description: Digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
On Sat, May 17, 2008 at 6:10 AM, Matthew Toseland <[EMAIL PROTECTED]> wrote: >> Exactly, which is why Thaw, Freemail, etc are the apps that will >> motivate users to use Freenet. Only developers download the JRE, most >> users get it bundled with Java apps. The same will be true of >> Freenet, its a platform, most end-users don't want platforms on their >> own. The solution is *not* to bundle, that is just pretending that >> Freenet is more than it is. > > We have a lot of traffic from wikipedia. We have a lot of traffic from > slashdot. For a user to even understand what Thaw is he must first understand > what Freenet is. Thaw, Freemail, FMS and jSite, don't have any sort of web > presence right now. So they should get a web presence, we can't reinvent sourceforge, and we can't reinvent apt-get, we don't have the resources. > Freenet is not the same as Java. It's a bad metaphor. Maybe it would be a > better metaphor if any major freenet client had a web presence and > significant hits of its own, but none of them do. AND WE CAN'T WAIT FOR THEM > TO GET ONE Why not? It would be a 30 minute job for those apps to set up with Google Code. >, for much the same reason that we couldn't wait for FMS to release > 0.7.0. That means we have to do what we can for *our users*, which means > making it as easy as possible to get these client applications. You must think our users are morons if the only way they can use an app is if we bundle it. FMS isn't bundled, and it seems to have no shortage of users. This "we've got to bundle everything" is a classic feature creep attitude. If you think being user friendly means installing a bunch of software on someone's computer without them asking for it then you have a bizarre notion of user friendliness. We aren't Google Code, we aren't apt-get, and we aren't Sourceforge. Trying to be those things will be a massive waste of resources. And of course there is also the issue that we would be installing software on people's machines which we didn't write, and which for all we know could contain well hidden code to delete their hard disks on July 4th just for a laugh. If we install this software, WE ARE RESPONSIBLE FOR WHAT IS DOES. We don't have the resources to audit this code, and we can't install anonymously written code on people's computers without an audit. Ian. -- Email: [EMAIL PROTECTED] Cell: +1 512 422 3588 Skype: sanity ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
On Friday 16 May 2008 22:09, Ian Clarke wrote: > On Fri, May 16, 2008 at 11:12 AM, Colin Davis <[EMAIL PROTECTED]> wrote: > >> Why are you so obsessed with turning us into Sourceforge for Freenet > >> apps? If we are successful there could be hundreds of apps, there is > >> no reason for us to host all of them - that is rediculous. Let them > >> use sourceforge, or google code, or set up their own website. > > > For the same reason, I suspect, that Apple is hosting a page of Mac > > Applications, and heavily-pushes third-party applications in it's retail > > stores, and the same reason that developers around the world are excited > > that the iPhone will have a built-in appstore. > > You may not have noticed, but we have slightly fewer resources than Apple. > > > Distribution matters. Users don't buy/install a product because of it's > > inherent properties, they install it because it solves a need. > > Freenet/Fproxy alone don't solve very many people's need, but Thaw, > > Freemail, etc are services that people find useful. > > Exactly, which is why Thaw, Freemail, etc are the apps that will > motivate users to use Freenet. Only developers download the JRE, most > users get it bundled with Java apps. The same will be true of > Freenet, its a platform, most end-users don't want platforms on their > own. The solution is *not* to bundle, that is just pretending that > Freenet is more than it is. We have a lot of traffic from wikipedia. We have a lot of traffic from slashdot. For a user to even understand what Thaw is he must first understand what Freenet is. Thaw, Freemail, FMS and jSite, don't have any sort of web presence right now. Freenet is not the same as Java. It's a bad metaphor. Maybe it would be a better metaphor if any major freenet client had a web presence and significant hits of its own, but none of them do. AND WE CAN'T WAIT FOR THEM TO GET ONE, for much the same reason that we couldn't wait for FMS to release 0.7.0. That means we have to do what we can for *our users*, which means making it as easy as possible to get these client applications. > > Ian. pgp8vXYYCTqU1.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
On Fri, May 16, 2008 at 11:12 AM, Colin Davis <[EMAIL PROTECTED]> wrote: >> Why are you so obsessed with turning us into Sourceforge for Freenet >> apps? If we are successful there could be hundreds of apps, there is >> no reason for us to host all of them - that is rediculous. Let them >> use sourceforge, or google code, or set up their own website. > For the same reason, I suspect, that Apple is hosting a page of Mac > Applications, and heavily-pushes third-party applications in it's retail > stores, and the same reason that developers around the world are excited > that the iPhone will have a built-in appstore. You may not have noticed, but we have slightly fewer resources than Apple. > Distribution matters. Users don't buy/install a product because of it's > inherent properties, they install it because it solves a need. > Freenet/Fproxy alone don't solve very many people's need, but Thaw, > Freemail, etc are services that people find useful. Exactly, which is why Thaw, Freemail, etc are the apps that will motivate users to use Freenet. Only developers download the JRE, most users get it bundled with Java apps. The same will be true of Freenet, its a platform, most end-users don't want platforms on their own. The solution is *not* to bundle, that is just pretending that Freenet is more than it is. Ian. -- Email: [EMAIL PROTECTED] Cell: +1 512 422 3588 Skype: sanity ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
Ian Clarke wrote: > On Fri, May 16, 2008 at 9:27 AM, Florent Daignière > <[EMAIL PROTECTED]> wrote: > >>> But the same argument could be used in my Java analogy. Java has a >>> far higher profile than many apps written in Java, but it doesn't >>> follow that Java should bundle all of these apps. >>> >> Heh, java has a frozen API... last time I checked ours is neither frozen nor >> even versioned! >> > > How is that relevant to this discussion? > It would seem to be difficult for a client application to ship given the current rate of development.. Let's say I was writing a game, such as WoW, and wanted my players to do all their updating over Freenet.. I'm going to be pressing this game to millions of CDs, and don't expect to revise it for another 6-12 months, at the earliest. What version do I put on the CD? 9 months from now, when someone installs my game, and it auto-fires up Freenet, Freenet will be many, many revisions out of date. I would have to take it on faith that update-over-mandatory through opennet would get the users up to the newest level, and then hope that FCP hasn't changed in the intervening months. With Java, I can say "This requires version 5.0 of the JVM" , and know that the APIs that I want will be there, and that users will be at the revision I expect. As a further aside- What is the expected/desired behavior if two applications are both installed which want to bundle freenet? Should they check to see if something exists? What if it's the old .5 or .3 versions? What if the Freenet project goes through another network reset? These aren't unsolvable problems, but they're the sorts of things which I would suspect give client apps concerns. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
> Why are you so obsessed with turning us into Sourceforge for Freenet > apps? If we are successful there could be hundreds of apps, there is > no reason for us to host all of them - that is rediculous. Let them > use sourceforge, or google code, or set up their own website. > > For the same reason, I suspect, that Apple is hosting a page of Mac Applications, and heavily-pushes third-party applications in it's retail stores, and the same reason that developers around the world are excited that the iPhone will have a built-in appstore. Distribution matters. Users don't buy/install a product because of it's inherent properties, they install it because it solves a need. Freenet/Fproxy alone don't solve very many people's need, but Thaw, Freemail, etc are services that people find useful. > Ian. > > ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
On Friday 16 May 2008 15:35, Ian Clarke wrote: > On Fri, May 16, 2008 at 9:27 AM, Florent Daignière > <[EMAIL PROTECTED]> wrote: > > > > What about fproxy; shall it be separated from fred too ? I think it > > should be a plugin to the node. > > Fproxy is the means through which the node is configured, so it > doesn't make sense to separate it. Technically the freenet->http > aspect of fproxy is a client app, but since its already tightly > integrated, and since it is serves as a "gateway" to Freenet, it makes > sense to keep it part of Freenet. It is not tightly integrated. The freenet to HTTP layer is a relatively thin veneer over the client layer. And eventually all of fproxy should be a plugin, connected to the rest of the node via a well defined API that can be implemented either internally (for speed) or through FCP. At least, it should be if elegance is important. Since it isn't, it won't be. The Freenet to HTTP layer would be vastly more useful *to a typical end user* with a few tightly integrated plugins. These could be maintained independantly, and integrate through well defined APIs. This would allow: - Searching of freesites ("google"). - Embedded forums ("google groups"). - Webmail ("gmail"). Getting rid of plugins, at least in terms of getting rid of the plugin API, will really *not* help matters. Right now, there aren't hundreds of Freenet client apps, there aren't even dozens of Freenet client apps. There are a few. There will be more if Freenet is popular, but if it is not easy to use, and useful, it will never be popular. And if we stop bundling apps which are critical to Freenet being easy to use and useful, this will *reduce* Freenet's popularity. > > Ian. pgp6rBk0351Ts.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
* Ian Clarke <[EMAIL PROTECTED]> [2008-05-16 09:35:34]: > On Fri, May 16, 2008 at 9:27 AM, Florent Daignière > <[EMAIL PROTECTED]> wrote: > >> But the same argument could be used in my Java analogy. Java has a > >> far higher profile than many apps written in Java, but it doesn't > >> follow that Java should bundle all of these apps. > > > > Heh, java has a frozen API... last time I checked ours is neither frozen nor > > even versioned! > > How is that relevant to this discussion? > If you want freenet to be a framework people actually use to write applications for, then it has to be versioned and to provide some level of backward-compatibility in between minor versions. > > [snip.] > >> > If you did want to push Freenet-the-service, rather than > >> > Freenet-the-program, I'd suggest that for the late .7 and early .8 you > >> > continue the focus on making the install simpler.. For example, the > >> > project could create a Freenet-for-embedded.zip, which defaults to > >> > opennet only, auto-detects it's IP, and joins the network when the .jar > >> > is run, rather than asking the user any questions. > >> > >> Well, I've been describing Freenet as a platform since around 1999 - > >> there is nothing new about this. I think we do need to do some work > >> to make Freenet more easily embedded, possibly as you suggest. > >> > > > > What about fproxy; shall it be separated from fred too ? I think it > > should be a plugin to the node. > > Fproxy is the means through which the node is configured, so it > doesn't make sense to separate it. The configuration framework is accessible from FCP... Some applications like Thaw are already using it. > Technically the freenet->http > aspect of fproxy is a client app, but since its already tightly > integrated, and since it is serves as a "gateway" to Freenet, it makes > sense to keep it part of Freenet. > Well, if you want freenet to run on embedded systems you will have some tradeoffs to make at some point... I do think that fproxy and its dependencies (the content-filter could be pluggable too) are nothing but overhead. signature.asc Description: Digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
On Fri, May 16, 2008 at 9:27 AM, Florent Daignière <[EMAIL PROTECTED]> wrote: >> But the same argument could be used in my Java analogy. Java has a >> far higher profile than many apps written in Java, but it doesn't >> follow that Java should bundle all of these apps. > > Heh, java has a frozen API... last time I checked ours is neither frozen nor > even versioned! How is that relevant to this discussion? > [snip.] >> > If you did want to push Freenet-the-service, rather than >> > Freenet-the-program, I'd suggest that for the late .7 and early .8 you >> > continue the focus on making the install simpler.. For example, the >> > project could create a Freenet-for-embedded.zip, which defaults to >> > opennet only, auto-detects it's IP, and joins the network when the .jar >> > is run, rather than asking the user any questions. >> >> Well, I've been describing Freenet as a platform since around 1999 - >> there is nothing new about this. I think we do need to do some work >> to make Freenet more easily embedded, possibly as you suggest. >> > > What about fproxy; shall it be separated from fred too ? I think it > should be a plugin to the node. Fproxy is the means through which the node is configured, so it doesn't make sense to separate it. Technically the freenet->http aspect of fproxy is a client app, but since its already tightly integrated, and since it is serves as a "gateway" to Freenet, it makes sense to keep it part of Freenet. Ian. -- Email: [EMAIL PROTECTED] Cell: +1 512 422 3588 Skype: sanity ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
On Fri, May 16, 2008 at 6:35 AM, Matthew Toseland <[EMAIL PROTECTED]> wrote: > Strongly agreed. From the point of view of a new user, or a journalist, FMS is > part of Freenet. It is highly unlikely to get any independant publicity, even > if we don't bundle it. All that happens if we don't bundle it is it doesn't > get used and there's one less reason for people to stay on Freenet. Bundling it doesn't help FMS get publicity - having an independent distribution point for FMS will - but bundling FMS will mean it is forever dependent on us for it to get attention. Anyway, we don't bundle FMS now, and yet it has users, a surprising number of users actually. > The base > system really isn't that interesting. Fproxy plus an embeddable FMS web > interface (i.e. forums-within-freesites) plus an embeddable search engine > plus a webmail implementation, plus an external blog publishing tool for > those who want to create content themselves, *that* is more or less a > complete underground network. "Java really isn't that interesting. Java plus a P2P client plus a game, plus a Java email client, *that* is more or less a complete system". See, you could use these arguments to justify something that would clearly be inappropriate were it applied to Java. > And as the other poster pointed out, the > download size really isn't the problem. The problem is that the user often > doesn't know about the apps we bundle. There are ways to deal with that. We shouldn't be bundling apps in the first place. > Apart from all these excellent points ... why should the user have to download > the client apps from the website and thereby blow their anonymity? Now a bad > guy tracing a freesite author only has to look in the set of people who > downloaded jSite! jSite can be downloaded from within Freenet for users that already have Freenet running. > IMHO if we don't bundle the apps, we should either: > 1) Ask the user about them at the end of the post-install wizard, explaining > clearly and concisely what each one is, and then download them over Freenet. > OR > 2) Offer them for download on an Official Project Freesite, with the stuff > that is hosted on our servers being officially endorsed by us for security > reasons. Why are you so obsessed with turning us into Sourceforge for Freenet apps? If we are successful there could be hundreds of apps, there is no reason for us to host all of them - that is rediculous. Let them use sourceforge, or google code, or set up their own website. Ian. -- Email: [EMAIL PROTECTED] Cell: +1 512 422 3588 Skype: sanity ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
* Ian Clarke <[EMAIL PROTECTED]> [2008-05-16 09:21:10]: > On Thu, May 15, 2008 at 5:09 PM, Colin Davis <[EMAIL PROTECTED]> wrote: > > I can certainly understand where you're coming from, and agree that it > > would be ideal, but I don't think that Freenet is ready to be promoted > > by application development.. Currently, when Freenet makes a new > > revision, that hits Slashdot, Reddit, etc, and encourages people to > > download.. A new revision of Frost/etc doesn't make a blip, and > > certainly doesn't spur much action. > > But the same argument could be used in my Java analogy. Java has a > far higher profile than many apps written in Java, but it doesn't > follow that Java should bundle all of these apps. > Heh, java has a frozen API... last time I checked ours is neither frozen nor even versioned! [snip.] > > If you did want to push Freenet-the-service, rather than > > Freenet-the-program, I'd suggest that for the late .7 and early .8 you > > continue the focus on making the install simpler.. For example, the > > project could create a Freenet-for-embedded.zip, which defaults to > > opennet only, auto-detects it's IP, and joins the network when the .jar > > is run, rather than asking the user any questions. > > Well, I've been describing Freenet as a platform since around 1999 - > there is nothing new about this. I think we do need to do some work > to make Freenet more easily embedded, possibly as you suggest. > What about fproxy; shall it be separated from fred too ? I think it should be a plugin to the node. signature.asc Description: Digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
On Friday 16 May 2008 15:21, Ian Clarke wrote: > On Thu, May 15, 2008 at 5:09 PM, Colin Davis <[EMAIL PROTECTED]> wrote: > > I can certainly understand where you're coming from, and agree that it > > would be ideal, but I don't think that Freenet is ready to be promoted > > by application development.. Currently, when Freenet makes a new > > revision, that hits Slashdot, Reddit, etc, and encourages people to > > download.. A new revision of Frost/etc doesn't make a blip, and > > certainly doesn't spur much action. > > But the same argument could be used in my Java analogy. Java has a > far higher profile than many apps written in Java, but it doesn't > follow that Java should bundle all of these apps. It's still a bad analogy. There are thousands of java apps. > > > The second problem is that Freenet, unlike the JVM, requires direct > > interaction.. After downloading Freenet, users should (ideally) add > > Darknet links, configure cache sizes, etc. > > I believe all of this functionality is exposed via FCP, so the client > app could expose it to the user in a manner which makes sense for that > client app. > > > Further, the JVM doesn't load > > and consume resources when it's not being used directly by a program.. > > Freenet nodes work better when they're running 24/7, so we want people > > to leave Freenet running, even if their client-app isn't. > > That is fine, it can be installed as a service while the client app is > installed as a client app. > > > If you did want to push Freenet-the-service, rather than > > Freenet-the-program, I'd suggest that for the late .7 and early .8 you > > continue the focus on making the install simpler.. For example, the > > project could create a Freenet-for-embedded.zip, which defaults to > > opennet only, auto-detects it's IP, and joins the network when the .jar > > is run, rather than asking the user any questions. > > Well, I've been describing Freenet as a platform since around 1999 - > there is nothing new about this. I think we do need to do some work > to make Freenet more easily embedded, possibly as you suggest. > > > Also of interest is the http://java.com/en/ page.. It uses a big > > download button, similar to Firefox, but also spends a significant > > amount of realestate on the page showing people what they can do using > > Java. Freenet could create a similar page with links to prominent > > Freenet applications for quick download directly from the website.. > > Doing this would lend some of the media coverage and promotion that the > > project is generating now, onto the applications. > > I agree that we should certainly direct user's attention to the > various client apps, as Java does. Many of them don't even have webpages. > > Ian. pgpPLGxRsjVJt.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
On Thu, May 15, 2008 at 5:09 PM, Colin Davis <[EMAIL PROTECTED]> wrote: > I can certainly understand where you're coming from, and agree that it > would be ideal, but I don't think that Freenet is ready to be promoted > by application development.. Currently, when Freenet makes a new > revision, that hits Slashdot, Reddit, etc, and encourages people to > download.. A new revision of Frost/etc doesn't make a blip, and > certainly doesn't spur much action. But the same argument could be used in my Java analogy. Java has a far higher profile than many apps written in Java, but it doesn't follow that Java should bundle all of these apps. > The second problem is that Freenet, unlike the JVM, requires direct > interaction.. After downloading Freenet, users should (ideally) add > Darknet links, configure cache sizes, etc. I believe all of this functionality is exposed via FCP, so the client app could expose it to the user in a manner which makes sense for that client app. > Further, the JVM doesn't load > and consume resources when it's not being used directly by a program.. > Freenet nodes work better when they're running 24/7, so we want people > to leave Freenet running, even if their client-app isn't. That is fine, it can be installed as a service while the client app is installed as a client app. > If you did want to push Freenet-the-service, rather than > Freenet-the-program, I'd suggest that for the late .7 and early .8 you > continue the focus on making the install simpler.. For example, the > project could create a Freenet-for-embedded.zip, which defaults to > opennet only, auto-detects it's IP, and joins the network when the .jar > is run, rather than asking the user any questions. Well, I've been describing Freenet as a platform since around 1999 - there is nothing new about this. I think we do need to do some work to make Freenet more easily embedded, possibly as you suggest. > Also of interest is the http://java.com/en/ page.. It uses a big > download button, similar to Firefox, but also spends a significant > amount of realestate on the page showing people what they can do using > Java. Freenet could create a similar page with links to prominent > Freenet applications for quick download directly from the website.. > Doing this would lend some of the media coverage and promotion that the > project is generating now, onto the applications. I agree that we should certainly direct user's attention to the various client apps, as Java does. Ian. -- Email: [EMAIL PROTECTED] Cell: +1 512 422 3588 Skype: sanity ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
Okay, I'm modifying my compromise solution slightly here: The installer itself should be lean and mean, and not bundle anything apart from the smaller plugins. At the end of the post-install wizard, we show the user a brief explanation of each application, and ask them whether they want it. Those apps the user selects, we download in the background from Freenet. When they are done, instead of actually installing them, we post a notice on the home page, with a link to the installer (which has already been downloaded so will open instantly). Thus we are not re-inventing apt-get, we get a nice fast installer, and the user knows what each app does. Comments? On Friday 16 May 2008 12:35, Matthew Toseland wrote: > On Thursday 15 May 2008 23:09, Colin Davis wrote: > > Ian Clarke wrote: > > > I do agree that bundling can make user's lives easier, but it should > > > be >>client apps bundling Freenet<<, not the other way around. > > > > > > Ian. > > > > > > > > > > I can certainly understand where you're coming from, and agree that it > > would be ideal, but I don't think that Freenet is ready to be promoted > > by application development.. Currently, when Freenet makes a new > > revision, that hits Slashdot, Reddit, etc, and encourages people to > > download.. A new revision of Frost/etc doesn't make a blip, and > > certainly doesn't spur much action. > > Strongly agreed. From the point of view of a new user, or a journalist, FMS is > part of Freenet. It is highly unlikely to get any independant publicity, even > if we don't bundle it. All that happens if we don't bundle it is it doesn't > get used and there's one less reason for people to stay on Freenet. The base > system really isn't that interesting. Fproxy plus an embeddable FMS web > interface (i.e. forums-within-freesites) plus an embeddable search engine > plus a webmail implementation, plus an external blog publishing tool for > those who want to create content themselves, *that* is more or less a > complete underground network. And as the other poster pointed out, the > download size really isn't the problem. The problem is that the user often > doesn't know about the apps we bundle. There are ways to deal with that. > > > > The second problem is that Freenet, unlike the JVM, requires direct > > interaction.. After downloading Freenet, users should (ideally) add > > Darknet links, configure cache sizes, etc. Further, the JVM doesn't load > > and consume resources when it's not being used directly by a program.. > > Freenet nodes work better when they're running 24/7, so we want people > > to leave Freenet running, even if their client-app isn't. > > Right. > > > > If you did want to push Freenet-the-service, rather than > > Freenet-the-program, I'd suggest that for the late .7 and early .8 you > > continue the focus on making the install simpler.. For example, the > > project could create a Freenet-for-embedded.zip, which defaults to > > opennet only, auto-detects it's IP, and joins the network when the .jar > > is run, rather than asking the user any questions. > > > > Also of interest is the http://java.com/en/ page.. It uses a big > > download button, similar to Firefox, but also spends a significant > > amount of realestate on the page showing people what they can do using > > Java. Freenet could create a similar page with links to prominent > > Freenet applications for quick download directly from the website.. > > Doing this would lend some of the media coverage and promotion that the > > project is generating now, onto the applications. > > Apart from all these excellent points ... why should the user have to download > the client apps from the website and thereby blow their anonymity? Now a bad > guy tracing a freesite author only has to look in the set of people who > downloaded jSite! > > IMHO if we don't bundle the apps, we should either: > 1) Ask the user about them at the end of the post-install wizard, explaining > clearly and concisely what each one is, and then download them over Freenet. > OR > 2) Offer them for download on an Official Project Freesite, with the stuff > that is hosted on our servers being officially endorsed by us for security > reasons. > > > > -Colin > pgpl5XGlIH0Ev.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
On Friday 16 May 2008 09:53, Jano wrote: > Ian Clarke wrote: > > > On Thu, May 15, 2008 at 3:28 PM, Michael Rogers > > <[EMAIL PROTECTED]> wrote: > That would be a very valuable system, I just don't see what it's got to > do with Freenet. > >>> > >>> Ummm, the fact that it would be a routable small world darknet? > >> > >> That's an assumption, not a fact. As far as I know there's little reason > >> to assume that the contact graphs of clandestine political organisations > >> are routable small worlds, let alone to assume that the combined contact > >> graph of several diverse organisations is a routable small world. > > > > Well, I think they might be a routable small world, but even if they > > are it doesn't follow that this "sneakernet" functionality should be > > part of freenet. > > > > I've heard a few people refer to Freenet as "bloatware", and frankly, > > given that 10MB of the install consists of client apps that really > > don't need to be bundled with Freenet, I can see why. > > I disagree here. Freenet feels like bloatware because it has had[*] problems > with high CPU usage, disk trashing and munching memory like crazy. > > A big download and a couple of satellite apps don't cause a judgment of bloat > ware (at least not in the people I known). It is that your computer really > loses responsiveness when such a resource hungry java app is running in the > background. > > YMMV. > > [*] I ceased running freenet in my desktop over half a year a go, so this may > be inaccurate now. It has improved somewhat, but the basic problem remains that the bigger the queue of uploads and downloads, the more memory Freenet wants to use ... and if it doesn't get what it wants, it tends to use 100% CPU and then crash. Also our bandwidth limiting isn't very accurate, and therefore can interfere with e.g. online gaming, and there's no obvious two-click way to throttle/disable it such as a systray icon. Here's what Victor Denisov's Russian friends said about Freenet (in the priorities thread). These are actual would-be-users who were put off by Freenet being bloatware: >|> 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. As you can see, what makes an application bloatware is: - Memory usage that depends on the number of files you queue, especially if there's a low default limit. - High CPU usage (especially if it's at high priority). Mostly nowadays this is caused by memory issues, although on AMD64 systems FEC may be a problem. - Constant heavy disk I/O. All of these are things we should address in 0.7.1. pgpDSEvlgmMSj.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
On Thursday 15 May 2008 23:09, Colin Davis wrote: > Ian Clarke wrote: > > I do agree that bundling can make user's lives easier, but it should > > be >>client apps bundling Freenet<<, not the other way around. > > > > Ian. > > > > > > I can certainly understand where you're coming from, and agree that it > would be ideal, but I don't think that Freenet is ready to be promoted > by application development.. Currently, when Freenet makes a new > revision, that hits Slashdot, Reddit, etc, and encourages people to > download.. A new revision of Frost/etc doesn't make a blip, and > certainly doesn't spur much action. Strongly agreed. From the point of view of a new user, or a journalist, FMS is part of Freenet. It is highly unlikely to get any independant publicity, even if we don't bundle it. All that happens if we don't bundle it is it doesn't get used and there's one less reason for people to stay on Freenet. The base system really isn't that interesting. Fproxy plus an embeddable FMS web interface (i.e. forums-within-freesites) plus an embeddable search engine plus a webmail implementation, plus an external blog publishing tool for those who want to create content themselves, *that* is more or less a complete underground network. And as the other poster pointed out, the download size really isn't the problem. The problem is that the user often doesn't know about the apps we bundle. There are ways to deal with that. > > The second problem is that Freenet, unlike the JVM, requires direct > interaction.. After downloading Freenet, users should (ideally) add > Darknet links, configure cache sizes, etc. Further, the JVM doesn't load > and consume resources when it's not being used directly by a program.. > Freenet nodes work better when they're running 24/7, so we want people > to leave Freenet running, even if their client-app isn't. Right. > > If you did want to push Freenet-the-service, rather than > Freenet-the-program, I'd suggest that for the late .7 and early .8 you > continue the focus on making the install simpler.. For example, the > project could create a Freenet-for-embedded.zip, which defaults to > opennet only, auto-detects it's IP, and joins the network when the .jar > is run, rather than asking the user any questions. > > Also of interest is the http://java.com/en/ page.. It uses a big > download button, similar to Firefox, but also spends a significant > amount of realestate on the page showing people what they can do using > Java. Freenet could create a similar page with links to prominent > Freenet applications for quick download directly from the website.. > Doing this would lend some of the media coverage and promotion that the > project is generating now, onto the applications. Apart from all these excellent points ... why should the user have to download the client apps from the website and thereby blow their anonymity? Now a bad guy tracing a freesite author only has to look in the set of people who downloaded jSite! IMHO if we don't bundle the apps, we should either: 1) Ask the user about them at the end of the post-install wizard, explaining clearly and concisely what each one is, and then download them over Freenet. OR 2) Offer them for download on an Official Project Freesite, with the stuff that is hosted on our servers being officially endorsed by us for security reasons. > > -Colin pgpP8taP5TGpC.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
Ian Clarke wrote: > On Thu, May 15, 2008 at 3:28 PM, Michael Rogers > <[EMAIL PROTECTED]> wrote: That would be a very valuable system, I just don't see what it's got to do with Freenet. >>> >>> Ummm, the fact that it would be a routable small world darknet? >> >> That's an assumption, not a fact. As far as I know there's little reason >> to assume that the contact graphs of clandestine political organisations >> are routable small worlds, let alone to assume that the combined contact >> graph of several diverse organisations is a routable small world. > > Well, I think they might be a routable small world, but even if they > are it doesn't follow that this "sneakernet" functionality should be > part of freenet. > > I've heard a few people refer to Freenet as "bloatware", and frankly, > given that 10MB of the install consists of client apps that really > don't need to be bundled with Freenet, I can see why. I disagree here. Freenet feels like bloatware because it has had[*] problems with high CPU usage, disk trashing and munching memory like crazy. A big download and a couple of satellite apps don't cause a judgment of bloat ware (at least not in the people I known). It is that your computer really loses responsiveness when such a resource hungry java app is running in the background. YMMV. [*] I ceased running freenet in my desktop over half a year a go, so this may be inaccurate now. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!
Ian Clarke wrote: > I do agree that bundling can make user's lives easier, but it should > be >>client apps bundling Freenet<<, not the other way around. > > Ian. > > I can certainly understand where you're coming from, and agree that it would be ideal, but I don't think that Freenet is ready to be promoted by application development.. Currently, when Freenet makes a new revision, that hits Slashdot, Reddit, etc, and encourages people to download.. A new revision of Frost/etc doesn't make a blip, and certainly doesn't spur much action. The second problem is that Freenet, unlike the JVM, requires direct interaction.. After downloading Freenet, users should (ideally) add Darknet links, configure cache sizes, etc. Further, the JVM doesn't load and consume resources when it's not being used directly by a program.. Freenet nodes work better when they're running 24/7, so we want people to leave Freenet running, even if their client-app isn't. If you did want to push Freenet-the-service, rather than Freenet-the-program, I'd suggest that for the late .7 and early .8 you continue the focus on making the install simpler.. For example, the project could create a Freenet-for-embedded.zip, which defaults to opennet only, auto-detects it's IP, and joins the network when the .jar is run, rather than asking the user any questions. Also of interest is the http://java.com/en/ page.. It uses a big download button, similar to Firefox, but also spends a significant amount of realestate on the page showing people what they can do using Java. Freenet could create a similar page with links to prominent Freenet applications for quick download directly from the website.. Doing this would lend some of the media coverage and promotion that the project is generating now, onto the applications. -Colin ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl