Florent Daigni?re skrev: > * Zero3 <zero3 at zerosplayground.dk> [2008-12-12 02:06:54]: > > >> Florent Daigni?re skrev: >> >>> * Matthew Toseland <toad at amphibian.dyndns.org> [2008-12-12 00:06:31]: >>> >>> >>> >>>> On Thursday 11 December 2008 23:46, Florent Daigni?re wrote: >>>> >>>> >>>>> * Zero3 <zero3 at zerosplayground.dk> [2008-12-11 19:18:30]: >>>>> >>>>> >>>>> >>>>>>> Disadvantages: >>>>>>> - Have to do some work on emu. >>>>>>> >>>>>>> >>>>> That alone is a good reason why *not* to do it. I don't see why >>>>> installers should be auto-built nor built from emu for that matter. >>>>> >>>>> >>>> I believe I and Zero3 have given several reasons: >>>> >>>> >>>> >>> Right, but none of them is valid or worth considering whereas the >>> caveats are real. Not to mention that here we are talking about doing >>> additional work changing the *current behaviour* which has proven to be >>> working. >>> >>> >> I strongly disagree. I think the advantages are much greater than the >> disadvantages. >> >> While the current behviour "works", it's certainly not optimal. >> > > No one is arguing it is. > > >> I thought this whole discussion started with Ian pointing out that our >> installer could be improved? >> >> > > Indeed it did. > > I don't know any piece of freenet that can't be improved. >
It seems like we agree then. Great! >>>>>> ADVANTAGES: >>>>>> - Security: Once you have obtained the installer, somehow (over Tor, >>>>>> from >>>>>> >>>>>> >>>> a >>>> >>>> >>>>>> friend, etc etc), you can run it without needing to fetch it from the >>>>>> website. People in hostile environments won't accidentally fetch the >>>>>> wrong >>>>>> version of the installer over Tor and then run it and reveal themselves. >>>>>> >>>>>> >>>> And >>>> >>>> >>>>>> us having less idea how many people are running it is arguably an >>>>>> >>>>>> >>>> advantage. >>>> >>>> >>> We do have a solution for those users: we already have an offline >>> installer. Here you and he are suggesting to make what is currently a >>> special-case the default installer on the basis that some users might >>> gain some security out of it. It's insane. >>> >>> >>> >> The point is that most people will download/be sent the default >> installer (the online one), and won't even be notified before it calls >> home during the installation. >> >> I can't see the insane part of making sure that doesn't happen. >> >> > > We tell them about it on the website iirc. Users don't read ... but there > isn't much we can do about that. > > Bundling is one possibility. It eliminates the problem... >>>>>> - Performance: The actual installation should take less time to complete. >>>>>> >>>>>> >>> Why? You can get a slow mirror and download slowly your bigBundle from >>> it... or get all the packs you need from different (possibly using >>> parallel sessions - we don't do that atm) equally slow mirrors. >>> >>> >>> >> Bundling and compressing everything into a single file saves a lot of >> overhead and connection delays compared to downloading files >> individually. Surely you are aware of that already? >> >> > > So far I am the one in charge of maintaining the mirror network and I > can tell you that delays aren't an issue. Our mirrors are responding > fast otherwise they get kicked out of the rotation list. > I'm talking about the delays by downloading the files during the installation. If you bundle, you get the whole thing in a single connection. If I count correctly, we connect 12 times to download files in the current installer. > Slow mirrors are an issue and to that regard, your solution only makes > things worst. > > At the moment we download different packs from different mirrors > (serially: that should be improved) but some of them are optional. > If we have mirrors slow enough to significantly delay a download of ~8 MB, I suggest getting rid of them. With an install size that small, trying to benefit from parallel downloads seems quite unnecessary. > You are suggesting to download a big bundle from one single mirror: that > will increase the overall bandwidth usage and is likely to be slower > than the "parallel fetching" we should implement. > We already had this discussion once. My final argument was that the extra HTTP and compression overhead from downlading Freenet in parts in all normal installs exceeds the bandwidth saved by people deselecting parts of Freenet in the installer (e.g. plugins, which we wont even let them do now, according to toad). To not even mention the bandwidth we save when people re-use the same installation file. > >>>>> + removal of the website as a Single Point of Failure. >>>>> >>>>> >>> Again, we already have an offline installer. >>> >>> I'm not against improvements: I'm against unnecessary, unjustified >>> and probably dodgy changes. >>> >>> >> An offline installer which is located on the SPoF... >> >> > > No one prevents you from mirroring it. Btw we already do that. > The problem is that most people will use (and distribute) the installer provided to them by default. And all those rely on the website. > >> It appears to me that you are against improvements, at least if they >> come from me. I think both I and toad has listed several good reasons >> for changing some of these things. >> >> > > So far I haven't seen any *good* reason. > I guess we disagree then. That covers mine, toads and nextgens opinions. What do everyone else think? - Zero3
