* 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. > >>>> 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. > >>>> - 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. 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. 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. > >>> + 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. > 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20081212/48a8ea35/attachment.pgp>
