Florent Daigniere skrev: > Zero3 wrote: > >> Ian Clarke skrev: >> >>> On Tue, Nov 25, 2008 at 3:04 AM, Zero3 <zero3 at zerosplayground.dk> wrote: >>> >>> >>>> but assuming Linux is the future, and Linux apps ought to be packaged >>>> anyway, we only have Windows >>>> and Mac left, leaving less reason >>>> >>>> >>> An unwarranted assumption. >>> >>> >> True. But don't you agree that Linux is gaining market share at the >> moment, that these new users prefer the easy GUI-based distros like >> Ubuntu, and the de-facto standard of installing software on these >> distros are via packaging systems? Getting Freenet packaged (and >> prepared to be such properly) and available in the Debian/Ubuntu >> repository seems like a great step towards a more user-friendly >> installation on Freenet on Linux. A quick roundup on advantages/features >> for Freenet (just to sum up): >> >> - One-click installation (any real settings should be handled by the >> first-time wizard) >> > > 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?
> >> - 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. > >> - 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). > >> - 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". > >> - Depency handling (e.g. require a specific version of the Java runtime >> and other required libraries) >> - ... probably more if you think about it. >> >>> As open source fans we all want to see Linux do well on the desktop, >>> but we can't allow our hopes for Linux to lead to sub-optimal decision >>> making when it comes to maximizing Freenet's adoption. Windows *is* >>> the most important OS for Freenet adoption. Whether Macs or Linux >>> come next is up for debate, but at the very least, a simple and >>> elegant installation is important on all three platforms. >>> Really what we need are dedicated maintainers for the installers on >>> Windows, Mac, and perhaps a few of the major Linux distros. An >>> installer that works on all three platforms has many advantages, but >>> will never be as smooth or intuitive as platform-specific installers >>> because people have differing expectations of each platform. For >>> example, Windows users tend to expect a Wizard-style installer. Mac >>> users expect a DMG containing an executable App that they can drag to >>> their Applications folder. Linux users expect to be able to use >>> apt-get, yum, or something else depending on their specific distro. >>> >>> >> I completely agree about the importance of Windows users and the appeal >> and simplicity of the installation procedure in order to meet the user >> demands. The reasons for sticking with the current installation >> procedure are, if I remember correctly, easiness (if that's even a word) >> to maintain and cross-platform support. While this might work "okay" at >> the moment, I personally think splitting the installation process up to >> be platform-specific is the way to go - especially because of the huge >> differences in installation procedures between the platforms, as you >> mentioned. >> >> > > 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> >>> Next, we must identify anything that can be improved in Freenet that >>> would make writing these installers easier. >>> >>> >> Random example on top of my head is the downloading of the plugins >> *during* the actual installation process, from the Freenet website. >> Surely they ought to be packed into the installer next to the other >> files? (The question on whether to *use* the various plugins ought to be >> asked during the first-time wizard IMHO. Atm. it seems like all >> installed plugins are automatically loaded?) >> >> > > 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. If it really matters that much, install none and let the wizard do it instead. > >> To make proper packaging possible on Linux, and to properly support >> multi-user environments on Windows, Freenet also needs to separate the >> identity, machine settings and eventually the cache, from the program >> files. Quick example of where different things probably ought to be >> located in Windows and Linux (sorry, don't know anything about Macs): >> >> - Windows: >> Program files: "%ProgramFiles%\Freenet" >> Machine-specific settings: Same location as program files, or in >> "%ALLUSERSPROFILE%\Application Data\Freenet", or if run as a service, in >> the service's appdata folder. >> User-specific data: "%AppData%\Freenet" >> >> - Linux: >> Program files: "/usr/lib/freenet" (and executable in "/usr/bin"?) >> Machine-specific settings: "/etc/freenet" >> User-specific data: "~/.freenet" >> >> At the moment, everything is throw into "%ProgramFiles%\Freenet" on >> Windows and "~/.Freenet" on Linux. >> >> > > 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. >> 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. 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'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. - Zero3
