[freenet-dev] Combating bloat (was: Re: Post 0.7?idea:?off-grid darknet!

[Florent Daignière]

* Matthew Toseland  [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
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea:?off-grid darknet!

[Florent Daignière]

* Matthew Toseland  [2008-05-19 11:47:16]:

> On Sunday 18 May 2008 05:17, Florent Daigni?re wrote:
> > * Ian Clarke  [2008-05-17 13:35:40]:
> > 
> > > On Sat, May 17, 2008 at 6:10 AM, Matthew Toseland
> > >  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.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea:?off-grid darknet!

[Matthew Toseland]

On Monday 19 May 2008 12:33, Florent Daigni?re wrote:
> * Matthew Toseland  [2008-05-19 11:47:16]:
> 
> > On Sunday 18 May 2008 05:17, Florent Daigni?re wrote:
> > > * Ian Clarke  [2008-05-17 13:35:40]:
> > > 
> > > > On Sat, May 17, 2008 at 6:10 AM, Matthew Toseland
> > > >  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.

In which case, we should simply link to the freesites for popular 
applications?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Matthew Toseland]

On Sunday 18 May 2008 05:17, Florent Daigni?re wrote:
> * Ian Clarke  [2008-05-17 13:35:40]:
> 
> > On Sat, May 17, 2008 at 6:10 AM, Matthew Toseland
> >  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? Or you agree with Ian that we shouldn't bundle 
any freenet-related code?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

Re: [freenet-dev] Combating bloat (was: Re: Post 0.7?idea:?off-grid darknet!

[Florent Daignière]

* 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!

[Florent Daignière]

* 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

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Florent Daignière]

* Ian Clarke  [2008-05-17 13:35:40]:

> On Sat, May 17, 2008 at 6:10 AM, Matthew Toseland
>  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.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Florent Daignière]

* 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

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Ian Clarke]

On Sat, May 17, 2008 at 6:10 AM, Matthew Toseland
 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: ian at uprizer.com
Cell: +1 512 422 3588
Skype: sanity

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Matthew Toseland]

On Friday 16 May 2008 22:09, Ian Clarke wrote:
> On Fri, May 16, 2008 at 11:12 AM, Colin Davis  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.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Ian Clarke]

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!

[Matthew Toseland]

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

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Florent Daignière]

* Ian Clarke  [2008-05-16 09:35:34]:

> On Fri, May 16, 2008 at 9:27 AM, Florent Daigni?re
>  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.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Matthew Toseland]

On Friday 16 May 2008 15:35, Ian Clarke wrote:
> On Fri, May 16, 2008 at 9:27 AM, Florent Daigni?re
>  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.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Florent Daignière]

* Ian Clarke  [2008-05-16 09:21:10]:

> On Thu, May 15, 2008 at 5:09 PM, Colin Davis  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.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Ian Clarke]

On Fri, May 16, 2008 at 11:12 AM, Colin Davis  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: ian at uprizer.com
Cell: +1 512 422 3588
Skype: sanity

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Matthew Toseland]

On Friday 16 May 2008 15:21, Ian Clarke wrote:
> On Thu, May 15, 2008 at 5:09 PM, Colin Davis  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.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Ian Clarke]

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

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Matthew Toseland]

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
> 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Matthew Toseland]

On Friday 16 May 2008 09:53, Jano wrote:
> Ian Clarke wrote:
> 
> > On Thu, May 15, 2008 at 3:28 PM, Michael Rogers
> >  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.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Matthew Toseland]

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
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Colin Davis]

Ian Clarke wrote:
> On Fri, May 16, 2008 at 9:27 AM, Florent Daigni?re
>  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.

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Colin Davis]

> 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.
>
>   

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Jano]

Ian Clarke wrote:

> On Thu, May 15, 2008 at 3:28 PM, Michael Rogers
>  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.

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Ian Clarke]

On Fri, May 16, 2008 at 9:27 AM, Florent Daigni?re
 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: ian at uprizer.com
Cell: +1 512 422 3588
Skype: sanity

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Ian Clarke]

On Fri, May 16, 2008 at 6:35 AM, Matthew Toseland
 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: ian at uprizer.com
Cell: +1 512 422 3588
Skype: sanity

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Ian Clarke]

On Thu, May 15, 2008 at 5:09 PM, Colin Davis  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: ian at uprizer.com
Cell: +1 512 422 3588
Skype: sanity

Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Colin Davis]

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!

[Colin Davis]

> 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!

[Matthew Toseland]

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!

[Florent Daignière]

* 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!

[Ian Clarke]

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!

[Ian Clarke]

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!

[Florent Daignière]

* 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!

[Matthew Toseland]

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!

[Ian Clarke]

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!

[Matthew Toseland]

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!

[Matthew Toseland]

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!

[Matthew Toseland]

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!

[Jano]

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

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Colin Davis]

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

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Ian Clarke]

On Thu, May 15, 2008 at 3:28 PM, Michael Rogers  
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.

People would think it was dumb if the JRE bundled LimeWire, although
most would agree that its reasonable for LimeWire to bundle the JRE
(at least as an option).  Of course people could say "oh, but the JRE
bundling LimeWire makes it easier for users because they don't need to
install LimeWire separately now!".  Or maybe they say "but we want
people to use LimeWire, so its good that the JRE bundles it!".

Of course no reasonable person would buy either of those arguments as
it relates to the JRE and LimeWire, yet I've heard similar arguments
used to justify bundling apps like Thaw and jSite with Freenet.

We need to get away from this idea that we are somehow helping users
by bundling all of these client apps with Freenet.  We aren't Ubuntu!
I propose removing jSite, Thaw, and any other bundled apps from the
Freenet distro, which should significantly reduce the amount of
downloading required.

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.

-- 
Email: ian at uprizer.com
Cell: +1 512 422 3588
Skype: sanity

Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Colin Davis]

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

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Ian Clarke]

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.

People would think it was dumb if the JRE bundled LimeWire, although
most would agree that its reasonable for LimeWire to bundle the JRE
(at least as an option).  Of course people could say "oh, but the JRE
bundling LimeWire makes it easier for users because they don't need to
install LimeWire separately now!".  Or maybe they say "but we want
people to use LimeWire, so its good that the JRE bundles it!".

Of course no reasonable person would buy either of those arguments as
it relates to the JRE and LimeWire, yet I've heard similar arguments
used to justify bundling apps like Thaw and jSite with Freenet.

We need to get away from this idea that we are somehow helping users
by bundling all of these client apps with Freenet.  We aren't Ubuntu!
I propose removing jSite, Thaw, and any other bundled apps from the
Freenet distro, which should significantly reduce the amount of
downloading required.

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.

-- 
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