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? >>>>> 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? > >> 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). 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? >>>>>> 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? ;) >> 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) > > Actually, the greatest barrier seems to be the people, IMHO. Documentation and easier methods of messing around with the code is on the list too, yea. If none is available, people probably won't even ask for it (I wouldn't!). But if it's all served right to you, chances are you feel like messing around with it, and eventually end up developing... - Zero3
