Matthew Toseland skrev: >> 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. > ... you have to work your way up from the bottom, don't you? :). > 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... > ... > It would seem like a perfectly acceptable solutions to provide "private" packages for all popular distros. Once it runs smoothly, have been testing, fixed, adjusted, etc., it should be *much* easier to get accepted into official repositories. I'm quite sure the official package maintainers would rather move a well-tested private package into their repositories than build a new one up from the ground (which also requires knowledge only the devs will have). You will have to start somewhere...
Regarding package updates: Atm. Freenet probably *does* have way too many short-notice mandantory updates to rely on packaged files alone. See my previous suggestion about a packaged version with "update overlays" though (to sum up very short: Between package updates, Freenet keeps itself up-to-date by "shadowing" the newer files over the packaged ones, and when package gets updated, deletes the "shadow files"). Obviously this is not a problem if Freenet is solely distributed via own repositories, but if the goal is to get accepted into distro reps., this needs to be taken care of. >> 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. > Question is: Is this uptime worth it, compared to the consequences of running as a service? (Wireless connections most likely won't be active at the logon screen anyway, mind you, and no internet connection makes it quite pointless?). Freenet will probably have to learn how to deal with poor uptime with the increase of laptops and mobile internet connections anyway... I don't have any stats at hand, but I'd argue that wired machines on logon screens are responsible for a very little part of the general Freenet uptime available. And it will most likely only get smaller with time anyway... > 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!! > If we (as previously discussed) move the autorun question to the wizard and separate the identity from the program files, we can simply add Freenet to each user's startup group as we are given permission to from the users (assuming every user will get to complete their own copy of the first-time wizard). Maximum userfriendliness... >> 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, > The identity? Friends (darknet)? fproxy theme and similar settings? All seems user-specific to me? - Zero3
