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? Matter more than having a true one-click installation? >>>> - 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? Will there be one available within reasonable time perhaps, or will we have to depend on the non-free one later on? >>> >>> >>>> - 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. >>> 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? 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. >> 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. > >>> 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)? >>>> 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?). 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. >> 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. - Zero3
