Zero3- I appreciate the suggestions you've made, and I'm sorry that you seem to be butting heads a bit.
I tend to agree with you that the installer should default to having as much as a user might reasonably need- To my eyes, this includes at the very least the Librarian plugin, since I think that searching should be made prominent in the UI. It should also probably include the Spider plugin, so that users can easily create their own indexes to search, as well as publishing them to their flog. The other plugins don't really belong in most people's installs. SNMP, and tests won't be used my many people, and MDNS shouldn't be on without the user explicitly asking for it, since it's potentially unsafe. Freenet should also bundle a jSite-like tool, as part of the web- interface, and the FMS and FMS-email tools. This allows users full control over the Freenet experience. What would be nice is if there were an official way to download additional plugins over freenet, once the node were up and running; That way these, and others as the project grows, could be easily added, akin to firefox Extensions. Part of the problem, Zero3, is that there is STILL a lot of debate about where to draw the line between application and platform with freenet. If Freenet is an application, of COURSE it should have most of the plugins included by default- It needs to be something that people want to use. If Freenet is a platform, the installer should be as minimal as possible, so that it's easy to bundle and doesn't impose it's own UI, instead relying on the applications that use it. This has, to my eyes, long been a contentious issue, so don't take it personally. On your second issue- Ian has made it pretty clear that he wants to simplify the install process. The most user-centric way to do this is to do separate native installers for every platform. A DMG for OSX that then gives a "Drag this to install" app, a GUI installer like yours or the old NSIS installer for Windows, and native packages (rpm/ deb) for Linux. The problem is, these take a LOT of work to make, and that work has to be maintained. The project has seen people make installers before, and then vanish... This is worse than not having one in the first place, since it then means that there is an unmaintainable system in place, and the project gets stuck when they need to update them. Thanks, Colin On Dec 11, 2008, at 8:37 PM, Zero3 wrote: > Florent Daigni?re skrev: >>> How do you suggest it would? >>> >> >> Start the node as a user, shut it down, login as admin, start the >> node >> up... it creates new files, shut it down... then the user doesn't >> have >> access to the newly created files. >> > > Files created by Freenet are created within the main Freenet folder > which all administrators (e.g. almost all users) have full access to > by > default. As mentioned earlier, we can simply give normal users the > same > access privileges if we want unprivileged users to be able to use > Freenet as well. These privileges are inherited to new files and > subfolders within the main Freenet folder, so there is no problem. > > If you don't believe me, read for yourself at Microsoft's support > site: > http://support.microsoft.com/kb/313398 > >> >>> By default, all administrators (which initial user is created as, >>> and is default for all new users) have read-write access to the >>> program >>> files folder. Limited users do not by default, but that can be fixed >>> with a single command as well. >>> >>> >> >> By default limited-users can access other limited users's files or >> administrator's files. The node does create new files and needs to be >> able to access them; regardless of "who" started it! >> >> > > Read above. > > - Zero3 > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
