On Tuesday 25 November 2008 23:31, Zero3 wrote: > 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.
Yes, we should have our own repository for each major linux distro family. > 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... No point until 1.0, as explained already. > > 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. Not going to be acceptable for distro repositories. And complicated/messy. > > >> 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? Yes. > (Wireless connections most likely won't be active > at the logon screen anyway, mind you, and no internet connection makes > it quite pointless?). Even fixed wireless connections, with login saved already or no login? Wireless connections provided by cafes etc are not suitable for Freenet - they are likely severely throttled and severely NATed, and may bill per gig. Mobile computers suck for Freenet. > Freenet will probably have to learn how to deal > with poor uptime with the increase of laptops and mobile internet > connections anyway... We do, but it's a *hard* problem that we can't deal with right now. > 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... It doesn't matter whether it's wired or not, it matters whether it's *fixed*. Wireless can still be fixed. > > 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... No, we can't. It's a web interface, the user cannot grant us anything, short of typing in his password to a form, which IMHO is baaaaaaad. Also, if the user does not immediately complete the wizard on install, and we don't auto-start, will it be running when he wants to use it? I guess the answer there is for Browse Freenet to include Start Freenet. > > >> 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? None of it is per user. It's a web interface, remember? We have no idea which user is logged in; if we implement a login mechanism in future, we will have to maintain our own username:password database. > > - 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/20081126/1117cbac/attachment.pgp>
