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
> 

Attachment: pgpl5XGlIH0Ev.pgp
Description: PGP signature

_______________________________________________
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to