* 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. >>>>> - 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? ... no comment. > 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. >>>> >>>>> - 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. >>>> 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. > 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. >>> If it really matters that much, install none and let the wizard do it >>> instead. >>> >> >> Again, that's against the packaging philosophy >> >> >> > > Surely applications are allowed to ask questions on the first run? As > does FireFox and Thunderbird, just to mention 2 large pieces of packaged > open-source software. If they are included in the package, the node > won't have to download them from the web. > Neither firefox nor thunderbird do ask questions on their first run on my debian. That's a windowsish behaviour. >> >>>> I don't get what you mean here. Are you seriously suggesting that >>>> multi-user computers should run multiple, concurrent nodes? It's >>>> not like running a freenet node was overhead less... nor like we >>>> wanted to maximize churn. >>>> >>>> >>> Not at all! I'm suggesting that users share the program files and >>> machine settings (which should be equal for all users) but *do not* >>> share identities and user-specific settings (privacy and >>> customization concerns). Atm., everything is shared on Windows and >>> nothing is shared on Linux. >>> >> >> That's because there is no easy way of "sharing" stuffs on Linux. There >> is a bug ticket for it and it's a long-overdue. I just didn't get around to >> implement it yet. >> >> > > I'm not sure I understand you. Doesn't most applications do this? Keep > the program files in the "public space", and the settings inside the > users' home folders (in hidden subfolders)? > You are not comparing similar applications... Freenet is different from emule/bittorent... you should compare it to servers: Apache/Mysql... or even MLDonkey if you want to stay in the field of what is called "p2p software" by users... Like for them, we do require a high uptime... and like for them there is no per-user settings. >>>>> 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. >>>>> >>>>> >>>> There is no disagreement here. As far as I know, everyone in the >>>> dev. team agree that we do it the RightWay. What would be the point >>>> of changing that behaviour back ... again (it was like that until >>>> people complained)? >>>> >>> If you only care about the dev team's opinions, then you might be >>> right. >> >> I do. Users have proved that they don't have any understanding of how >> the node works not to mention that they don't know how the network >> is supposed to work; While I can conceive that it might prove useful >> to take some of their advices into consideration, I think that the >> technical implementation decisions should (and have to) be left to >> the developer's judgment. >> >> > > Isn't that also kind of closed-minded to not listen to anyone just > because they aren't on the dev list? No? I'm not saying you shouldn't be > critical to outside views, but afterall, Freenet depends on its users, > so I assume the devs are interested in the users' opinions too? Nothing > prevents you from kindly informing the users that the issue has been > discussed in the past, and provide a link for them to read it up > themselves (is there any?). > Ah, right... that's it: you are missing the classical "RTFM! RTFW! RTFMLA!" :) > I totally agree with you - that the devs should make all the decisions. > All I ask for is that the users aren't flamed to death because they > kindly spend their freetime trying to improve the project by writing > down their thoughts and opinions. > >>> Some people (myself included, indeed) have different opinions. (It >>> was discussed on this mailing list a while ago I think - and on IRC >>> on multiple occasions). Both sides have supporters. I'm not aware of >>> when Freenet was a service and when not. Atm. I can just comment on >>> how Freenet works today. >>> >> >> I don't intend to be rude here but that's what you are missing here: >> history and experience. Most of what you have been suggesting has >> already been tried or is on the TODO list. >> >> We had packages, we had a MSIS installer, ... and the list goes on. >> >> If you really think it's important and you're willing to make things go >> forward, gets your hand dirty and get on coding :) >> >> > > I'm trying to, actually. The barriers for actually getting a chance to > do something are kind of... tough... for Freenet though. Have been for > me, at least. > We can work towards easing that... writing documentation. But as far as I know no one asked for it so far (except Ian in a former email on this thread) > >>> I'm not saying it's a big problem or anything, but it could prove >>> useful to analyze the possibilities and figuring out which one that >>> actually works the best for Freenet. >>> >> >> FYI we did analyze that already... and reached a conclusion... and >> implemented the technical solution we found appropriate at the time. I >> don't see any reason why we should reconsider our position here: do you >> have any new point to bring to the debate? >> > > Please, feel free to link me to previous discussions about > advantages/disadvantages about the various form of installers... I'll > gladly read them and save you the time of telling it all again. It's > hard for me to know exactly what have and have not been discussed > previously. > I wrote the freenet-izPack installer back in 2006 for the google summer of code. You can start by digging up my proposal from the mailing list archives... -------------- 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/20081126/a64cce6a/attachment.pgp>
