On Wednesday 26 November 2008 21:40, Zero3 wrote: > Florent Daigni?re skrev: > > * 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. > > > > > > Pack 'em in then? > > >> Matter more than having a true one-click installation? > >> > > > > Yes. > > > > Oh well. > > >> 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. > > > > > > We all know? That didn't quite answer though: > > >> Will there be one available within reasonable time perhaps, > > and > > >> will we have to depend on the non-free one later on?
EVENTUALLY there will be a stable and usable version of OpenJDK/IcedTea (the one in ubuntu 8.04 isn't that for our purposes). Later on there may be a stable/usable version of GCJ. > > >>>>> 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. > > > > Oh. What's http://sourceforge.net/projects/freenet/ all about then? Legacy marketing. That's all. new_installer pulls jars from our mirror network. > > >> 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. > > > > > > What are the requirements, besides standard HTTP access to the actual > files? > > >>>> 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. > > > > > > Guess it is for FF. Thunderbird asks about account information, surely? > OpenOffice doesn't either? (On Windows it asks about license agreement, > user account and initials). On debian if you have to accept a license agreement, you usually click through it in install. For some non-free packages you need to see it on the first use (e.g. acrobat reader). > > Anyway, it doesn't really change things regarding the topic... > > >>> > >>>>> 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. > > > > Freenet has user settings, yes? Darknet friends, fproxy bookmarks, > fproxy theme and misc settings, ... Or am I misunderstanding you? Freenet uses a web interface. We have NO idea which system uid is using Freenet. We may eventually implement a login system, but we will have to maintain our own user:password database if we do. Having said that, we do actually have some per-user stuff: the firefox profile. Most likely in a proper package we'd have a browsefreenet script or similar, which creates a firefox profile and invokes firefox with that profile. > > >>>>>> 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!" :) > > Or just a link or two? ;) http://archives.freenetproject.org/ -------------- 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/363b056e/attachment.pgp>
