On Wednesday 26 November 2008 20:59, Florent Daigni?re wrote: > * Zero3 <zero3 at zerosplayground.dk> [2008-11-26 21:41:02]: > > > Florent Daigni?re skrev: > >> * Zero3 <zero3 at zerosplayground.dk> [2008-11-25 23:49:24]: > >> > >> > >>>> Then it would require the node to have web-access and to make > >>>> web-requests after it has been set up. The current node doesn't do > >>>> that unless told to. > >>>> > >>> Web access for what? > >> > >> Downloading plugins. > >> > > > > Assuming we are not packaging them with Freenet... Even if we don't, > > does it matter that much if it is the installer or the node that makes > > the request? > > The node doesn't know anything about http-proxies... the installer > might at some point. > > > Matter more than having a true one-click installation? > > Yes.
No. There is no conflict. Simply download them all in new_installer, and decide whether or not to activate them in the post-install wizard. If the user decides not to activate them, delete the files. No problem. > > >>>>> - Integration directly into the OS via "Add/Remove programs" (in > >>>>> Ubuntu, for example) and the package manager (which also means > >>>>> free publicity and more users) > >>>>> > >>>> Can't be done if we aren't in the main repositories. > >>>> > >>> ... isn't the point to get into the main repositories at some point? > >>> I'm not sure if you can get programs in that list form 3rd party > >>> repositories (for any distros without official packages). It might be > >>> possible. > >> > >> We can't because of the frequency of required updates... and because > >> our code depends on a non-free jvm. > > > > See suggestion about "overlaying" updates. I didn't know that the jvm > > wasn't free? W.r.t. overlaying updates, any scheme like that would exclude us from being formally packaged by the major distros. They only ship stable code, which can be frozen and released for a year plus (3 years plus on debian). We are NOT stable code. > > > Will there be one available within reasonable time perhaps, > > or will we have to depend on the non-free one later on? > > Ensuring that the code works reliably on other jvms takes dev's time > we'd rather spare somewhere else. It's all a matter of priorities, like > usual. In particular, some versions of some free JVMs which are currently shipped by default with some popular distros, have severe bugs which prevent Freenet or its installer from working. > > >>>>> - Automatic, fail-safe downloading and updating with checksum and > >>>>> signature checking (no need for the manual update scripts and > >>>>> maintaining them) > >>>>> > >>>> I'm not sure I understand what you mean here. > >>>> > >>> I was merely trying to point out some of the technical advantages of > >>> packaging systems - here referring to the actual package download and > >>> updating part. The update scripts deal with the downloading and > >>> checksumming/verification "manually" atm. With a package, there > >>> shouldn't be a need for any update scripts or worrying about genuine > >>> downloads in the first place (which means less clutter, less manual > >>> work and fewer places things can go wrong). > >> > >> Ok, whatever: you're preaching a converted here. > >> > >> > > > > Okay :) > > > >>>>> - Less maintenance for the installation maintainer > >>>>> > >>>> Neither here... the idea is to outsource the maintenance of the > >>>> installer, isn't it? > >>>> > >>> Meant as: "Less work for *whoever* does the installer/package stuff". > >> > >> Right now we have no one but me and Tommy addressing the installation-related > >> problems. I'd love that to change... hence I would be welcoming your > >> patches. > >> > >> [snip.] > >> > >> > > > > My time is quite limited (yea right, like anyone has enough...), but I'm > > willing to take a look at a simpler Windows installer. Making Linux > > packages would take me much longer as I haven't really messed around > > with that very much in the past. > > > > Good. You might want to have a look to what had been done a while ago > about it... But really, the first step would be to write a decent, > race-free update.cmd ... Or the "bunny" tray icon. Or an NSIS-based launcher which auto-downloads the JVM and then runs new_installer.jar, rather than our current launcher which just tells the user to go get one. > > >>>> The idea is to minimize the amount of data to download in order to > >>>> both spare bandwidth and reduce the overall installation time. > >>>> > >>> Not worth the trouble/annoyances/extra download time/... IMHO. > >> > >> That's your view, not mine. Come back with figures and real arguments if > >> you plan to be convincing. Last time I checked I am the one who wrote > >> that part of the code... So I am the one who decides how it's done. > >> > > That seems like an awfully closed-minded attitude for a collaborative > > open-source project like Freenet. > > > > Being hosted at SourceForge, I can't see bandwidth being a problem? > > We left SourceForge years ago because of their chronical unreliability. Nonetheless, the bandwidth cost for downloading all the plugins on every install is marginal. > > > But since you want some figures: I just did a test install. Downloading > > and setting up the plugins took the installer ~10 seconds on a 2 year > > old mainstream laptop with Windows XP. The plugins take up 383 KB. I > > don't know how many people that uncheck any or all of the plugins before > > installing, but I doubt it's a large part. Even if *everybody* unchecked > > all plugins in the installer and we assume nobody will ever install them > > later on, the overhead would be less than 4% of the ~10 MB that was > > downloaded during the install. In reality, that number will be *much* > > smaller as many people *will* install the plugins. If SourceForge can't > > keep up with that little extra bandwidth, I'll be glad to donate. > > We did call for mirrors a while back, and we usually do before we > announce any new release. > > Right now we have 6 working ones and 13 configured. Why are you squabbling over 400K out of 10MB? -------------- 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/e45b4968/attachment.pgp>
