On Tuesday 25 November 2008 14:10, Zero3 wrote: > Ian Clarke skrev: > > On Tue, Nov 25, 2008 at 3:04 AM, Zero3 <zero3 at zerosplayground.dk> wrote: > > > >> but assuming Linux is the future, and Linux apps ought to be packaged anyway, we only have Windows > >> and Mac left, leaving less reason > > > > An unwarranted assumption.
As a convicted linux/Free Software zealot, I still have to side with Ian here. > > > True. But don't you agree that Linux is gaining market share at the > moment, that these new users prefer the easy GUI-based distros like > Ubuntu, and the de-facto standard of installing software on these > distros are via packaging systems? Getting Freenet packaged (and > prepared to be such properly) and available in the Debian/Ubuntu > repository seems like a great step towards a more user-friendly > installation on Freenet on Linux. Including Freenet in anything other than the debian-volatile repository and its equivalents is grossly unrealistic at this point. And I doubt even debian-volatile would have us. We make network level behaviour changes constantly, and we need those changes to be deployed in days, not years: freezing the code short of security fixes for 3 years, or even for 12 months, is unacceptable and infeasible. Including ourselves in the experimental repositories etc is conceivable but would have to be accompanied by a cast iron promise not to ship Freenet in stable until 1.0, and I doubt that debian et al would be interested on those terms. What we can do is provide a repository of our own, like for example Wine does. However, we must provide packages for at least: - All debian derivatives including Ubuntu variants - SuSE (not necessarily compatible with Fedora) - Fedora (arguably; many geeks use Fedora and IMHO geeks are important to us) - Gentoo (slightly weaker case than Fedora, but at least we have an ebuild already thanks to Tommy[D]) Even then, there is a big question mark over whether the packages will be updated frequently enough. Is this a problem in practice on GUI distros? I know they generally offer a GUI update notification service, so maybe not if we average say one new build a week... ... > > > I completely agree about the importance of Windows users and the appeal > and simplicity of the installation procedure in order to meet the user > demands. The reasons for sticking with the current installation > procedure are, if I remember correctly, easiness (if that's even a word) > to maintain and cross-platform support. While this might work "okay" at > the moment, I personally think splitting the installation process up to > be platform-specific is the way to go - especially because of the huge > differences in installation procedures between the platforms, as you > mentioned. One argument in favour is better support for auto-downloading the JVM. This is easy on NSIS, but very hard with our current arrangement. > > > Next, we must identify anything that can be improved in Freenet that > > would make writing these installers easier. > > ... > To make proper packaging possible on Linux, and to properly support > multi-user environments on Windows, Freenet also needs to separate the > identity, machine settings and eventually the cache, from the program > files. Quick example of where different things probably ought to be > located in Windows and Linux (sorry, don't know anything about Macs): As long as updating is turned off, this is simply a matter of changing the classpath, shortcuts, and wrapper.conf. But even on linux, it's arguable whether we want to only update when the user does a dist-upgrade; and on Windows and Mac, we have to implement updating ourselves. Which means we need to be able to overwrite the jar files, even though they are program files. Note that Freenet is a daemon, not a web browser. For a web browser, you can have per-user settings. For a daemon, even on unix, you have /etc, /usr/bin and /var. > > - Windows: > Program files: "%ProgramFiles%\Freenet" > Machine-specific settings: Same location as program files, or in > "%ALLUSERSPROFILE%\Application Data\Freenet", or if run as a service, in > the service's appdata folder. > User-specific data: "%AppData%\Freenet" ... > Another thing to solve is the disagreements on how Freenet should > operate on Windows. Atm. Freenet creates its own user account and > installs itself as a service, as opposed to running as a normal > background application as the logged in user. I'm unsure. On the one hand, creating a user account and installing a service is counterintuitive for Windows users, causes permissions problems and can cause the service to not be easily killable from Task Manager. On the other hand, on any machine with a login screen, whether or not you need a password, starting on startup can gain us a significant amount of uptime - not only because it will run in the background when other users are logged in, which IMHO is perfectly legitimate and something that the users can negotiate amongst themselves - but also because if the computer is switched on but not logged in, Freenet won't run at all. Uptime matters. Dealing with low uptimes is hard. If we install as the logged in user, we don't need to create an account, we can simply create a user-specific startup item. This would certainly simplify installation. Maybe we should ask the user? But that means more steps in the installation process!! I strongly suspect that Littleshoot deals with uptime issues in the same way that every other p2p app does ... it doesn't, it has centralised or at least massive databases of everyone online, and *hopes* that the data source is online at the same time as you are through sheer force of numbers, resulting in a lot of downloads for less popular files failing. Am I wrong? What do other p2p's do anyway? Rely on high-bandwidth seeds mostly? Surely most of the high bandwidth seeds will have been taken out by now... > > - Linux: > Program files: "/usr/lib/freenet" (and executable in "/usr/bin"?) Most stuff is just in /usr/bin ... but since we have jar files etc we probably need a directory in /usr/bin ... > Machine-specific settings: "/etc/freenet" > User-specific data: "~/.freenet" IMHO there is no user-specific data for Freenet. It's a daemon, like Apache. It may implement its own user mechanism, Right now we install into the user who installs the node. For a standalone graphical installer this is by far the easiest. I agree that a proper package should obey the normal packaging guidelines within reason, put the files in their proper places, and create a user for Freenet to run under, like most other daemons get. > > At the moment, everything is throw into "%ProgramFiles%\Freenet" on > Windows and "~/.Freenet" on Linux. > > - Zero3 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20081125/c05f3cbf/attachment.pgp>
