* 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. > > > >> - 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. > > > >> - 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. > >> - 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.] > > > > Other projects provide source-code-only releases and outsource > > completely the installation process. Is that what you are suggesting? > > > > > Not at all! I was thinking something like replacing the current > installation procedure with platform specific ones, like: > > Linux: Package (from official repositories, or from own if no official > available) > Windows: Installation wizard of *minimal* size (from homepage) > Mac: <whatever works best on macs> That's time consuming and requiring man-power we don't have. Again: patches are welcome. If we went down the route of a single, multi-platform installer it's because there is less overhead needed to maintain it. [snip.] > > 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. > If it > really matters that much, install none and let the wizard do it instead. Again, that's against the packaging philosophy [snip.] > > 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. > >> 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. > 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 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? -------------- 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/5627138b/attachment.pgp>
