OK, I'll bite. Let's run with this discussion a bit... Greg Hellings wrote:
> Most Linux or FreeBSD users are familiar with a source tree compile > with autotools. Really? In 2009? Do you have a source or at least some anecdotes to back up that idea? If you are correct, why was it valuable to get this software packaged? If that is really the standard conventional way today's Linux users expect to receive and install software, then packaging it for them in distro-specific ways is clearly a waste of my time! About 15 years ago, I would have agreed that most Linux users knew how to use autotools and gcc and friends. Maybe 10 years ago that was still true, although it was definitely a declining fraction of the userbase, even then. I'm not at all sure the same is true today. How much time have you spent on the Freenode IRC support channels such as #ubuntu or ##linux or even #debian recently? I assure you, the vast majority of questions being asked are not coming from users comfortable with the command line and with compiling their application software from source code! > When a Linux or BSD user searches for software on the Internet, finds > a home page, and sees a "Download" link they're very likely to be > looking for an option that ends in a .tar.gz or .tar.bz2 so they can > pull the source, compile, install and be on their way. This is > native and natural ... I submit that it is no longer natural at all. In today's Linux world, for end users, application software is packaged and signed and tested before being allowed into a repository, and there are very few of these for a given Linux distribution. The natural way to search for software is therefore with your package manager, which is often a GUI tool (Synaptic for example). Newcomers quickly find that you *don't* go around searching the Internet for Linux software in random places, because (unlike Windows) installing it when you find it there is often "too hard". Instead, Linux users will often only use what is already packaged for their specific Linux variant, and which is easily available for installation in a pretty GUI tool. Some will even wipe their hard drive and reinstall from scratch to use a different Linux distribution *just* to get some particular piece of software that one distro packages and another does not! In Ubuntu, the default way to search for and then install software is to click on a menu item labelled "Add/Remove...". It brings up a (deliberately simplified!) graphical package manager. I suggest that this is a clear sign that today's Linux distros do not expect their users to be experienced in downloading and compiling tarballs at a command line in order to install software :) I really do not think one should expect any autotools and compiler knowledge at all in the average Linux user. Not any more. Those days are over. > It is native and natural for a Windows user to look for a package > that ends in .msi or .exe and download and install that. This is how > software is expected in Windows. Indeed. They lack a common package manager, so they have to search the entire Internet for individual (binary) packages. The direct equivalent in Linux is a binary .deb or a .rpm for ones own distribution (most commonly found in the repos for ones own distribution rather than elsewhere, to avoid dependency issues or trojans). This is how software is expected in Linux, in 2009. Indeed, so prevalent is this approach that even providing .debs for download in PPAs is considered by some to be for the "expert" few only, and we find we need to provide a way to enable our team PPA that completely avoids the command line, so that the PPA contents will be useful to many users! And, as I said earlier, Crosswire currently directly provides the former (compiled binaries for Windows) but not the latter (compiled binaries for Linux). So which is the "poor cousin"? :) > On another hand, one could also point out that autotools is native to > the SWORD library, is regularly updated when file names, directory > structures and the like change. Thus, at any given point, a user > could just pull the SVN tree and have a very high probability of > things "just working." Autotools is not Linux-specific. > The Windows build files are maintained manually -- nearly every time > I try to build from SVN on Windows (which is every 4-5 months, so not > very regularly) thus far, I have had to edit the file list, or find > compiler directives and defines, etc that need to be tweaked because > of the manual system which does take a "poor cousin" seat all too > often. Really? For SWORD itself? Not strange proprietary "project files", not tweaks needed to suit one version of one specific commercial compiler, or a specific IDE -- just the usual standard autotools/Makefile/GCC approach, that is the same on all the other operating systems supported? It is 4-5 months since SWORD 1.6.0 was released, so can you provide an example of what in the SWORD 1.6.0 tarball had to be changed to permit Windows compilation of SWORD with autotools/GCC? > There are also file system paths on Windows which had not been > tested, then were found to mishandle unicode. Sure, but (to the limited extent that I understand that issue) that's not the SWORD developers making poor cousins our of Windows users -- that's Windows containing bugs :) I strongly suspect that the equivalent code paths were not really all that well tested by the SWORD developers on Linux either -- it is just that in Linux they worked even when using non-USASCII characters in file and directory names, whereas in Windows they did not. > Looking for those perspectives, it certainly does appear to some > viewers that Windows is a "poor cousin" in the scheme of things. Given what is available right now on the CrossWire site, and nowhere else, I see no basis for that. The Crosswire site has source code for all, has SWORD modules for all, and has Windows-specific binaries and at least one significant Windows-specific project. In contrast, it has no Linux-specific binaries and no Linux-specific projects. It's sad that independent Windows developers can't fix their core OS libraries unicode issues, as independent Linux developers could if such bugs existed in Linux... but that dependence on Microsoft for the core OS is a choice that gets made when you choose that OS. For some people the benefits must outweigh the disadvantages. At this point it might be fun to suggest that Microsoft makes its own users (or its own independent developers, and so indirectly its users) into "poor cousins" by restricting access to source code ... :) :) > For better or worse, Windows DOES garner less attention than the > library itself, and probably less attention than Linux -- because > there are dedicated teams working on Xiphos, BibleTime and the rest, > while the BibleCS work is done almost exclusively by people who are > also concentrating on the whole library. So perhaps, just as some months back there was a call on a relevant mailing list for help packaging SWORD for Ubuntu, to which I responded, there is now a perceived need for a similar request for help packaging SWORD for Windows, so relieving any pressure on the Crosswire devs to do that kind of work themselves? I don't know what mailing lists would be appropriate for such a request, but if it worked for Ubuntu, perhaps it will work for Windows too? > It's more the fact that CrossWire clearly goes all the way for its > Linux users, but the efforts on Windows do seem to lag behind, But it *doesn't* go all the way for Linux... mentioning packaging SWORD modules as .debs so we can truly integrate with the existing packaging mechanism gets me... a lot of feedback, shall we say! Suggesting .debs and .rpms could be provided from crosswire.org itself does not seem to be well received overall. Crosswire could be creating nightly builds of SWORD SVN and distributing the resulting .debs and .rpms for a few major Linux distros. That would be nice to see, a convenience roughly equivalent to providing binary builds for Windows users. But it isn't happening... and so on and so forth. [Aside: One obvious use of my .bat file based Windows development setup, if it ever gets to the point where it reliably compiles and links SWORD, would be to automate the creation of a binary Windows SWORD library installer, and then run in nightly from svn, so the "latest" code would be available as a nicely packaged .msi file to all who need it in the world of Windows, but who lack the means or desire to compile it for themselves.] SWORD is at its heart a code library. As such, it seems clear to me that its primary expected users are programmers -- people who will write programs that use that SWORD library code. Whether those programmers are Windows or Mac OS X or Linux programmers is not the point; the point is that the expected primary software output of Crosswire is a product suitable for use by programmers. Taking SWORD beyond that, packaging it to be more suitable for use by end users i.e. by non-programmers, is a different project entirely, and one that others will need to choose to run with. Xiphos programmers have worked to package SWORD with their Windows application, so that Windows users do not need to be concerned with downloading and installing a separate library. Great idea (I wish there were a way to package SWORD for Windows that is more independent of which application will be used "on top of" SWORD, though)! If we want to see more of that kind of work, adding polish and ease of SWORD installation for Windows end users, cool... but to expect the SWORD developers to be the ones to do it seems to me to be expecting a lot. If, as you suggest, SWORD devs are mostly Linux programmers, it would probably be more natural for them to package their library for Fedora/Debian/Ubuntu/Mandriva/etc. than for them to package it for Windows. They do not even attempt the first; why would anyone expect that they do the second? Both are tasks left for others to do, building on the work of the SWORD team. Which, given the size of the team, is a very valid way to divide up the total necessary work :) > This could just be my experience, but I can count on a single hand the > number of PC power users I know who are comfortable with virtualization > without being programmers. All I can say is, I know people for whom typing is slow and hard, who much prefer GUIs and mice and clicking their way around... who use virtualization. It is very possible to download and install VirtualBox OSE and get some friendly Linux distro of your choice up and running inside it without seeing a command line at all, never mind being a programmer :) > If we're going to offer applications and utilities for an operating > system, it makes sense to offer them in the format most comfortable and > native to its users. Sure. I wasn't intending to propose virtualization as a permanent replacement for a lack of up to date packaged Windows binaries! But if right now there is some issue with that, such as a lack of a team packaging the latest output of Crosswire for the Windows environment, then, as a stopgap measure, running SWORD-based apps inside a window on Windows (that happens to be a Linux VM) is one way to make forward progress. Without forcing Windows users to learn the Linux command line, or even the Windows command line for that matter. > Saying to them, "Oh, just get virtualization software and run Linux" > or "Go learn how to use a compiler and figure out how autotools will > work on Windows, then build it yourself" does not increase our > likelihood of acceptance with a market of people for whom that is > neither the norm, nor a comfortable stretch. We don't expect Linux end users to use autotools or a compiler. We don't expect Windows end users to do that either. The platforms are 100% identical in that regard. Windows is neither a poor cousin nor a rich uncle in that regard. We do tend to expect developers on either platform to be developers who are unafraid of the command line. That's not unreasonable on any cross-platform project, really... and if someone wants to create a GUI wrapper for the utilities, or some Eclipse project stuff so that building SWORD inside a huge GUI IDE like that (on Windows or on Linux -- Eclipse runs on both) would become relatively simple ... OK, both of those are nice (OS-independent, cross-platform!) projects which someone who likes GUIs or who likes IDEs can take on if they choose. Crosswire in essence outputs a code library (and a few command line utilities). It hosts a repository of SWORD modules that the code library can use. Others then take that output, and use it to build software for end users (or any OS) who do not think of a library as being a set of files that contains code, but as a building that contains books! At most, we can say that current packaging efforts for SWORD on Windows lag the recent efforts and progress being made in the Debian/Ubuntu arena; just a year ago that was far from the case, though -- and even now, the current release of Ubuntu comes with an incredibly ancient version of SWORD (this will change in a few short weeks when Karmic is released)! Those packaging efforts for Debian/Ubuntu are outside of Crosswire. Comparable efforts in the Windows world could and perhaps should be undertaken in a similar manner -- outside of Crosswire itself. > I know that this is largely just a perception issue. Looking at the output of Crosswire, and not the output of other related projects, I don't really see where that perception comes from (unless you make assumptions that all Linux users are developers). The primary software output of Crosswire is a set of source code files, which are compilable on Linux, OS X, *BSD and Windows, by developers -- asking end users to do that is of course expecting too much, no matter the OS platform. > But to the casual user strolling through the website who sees version > 1.6.0 available for Linux but only 1.5.11 available for Windows, it's > easy to see how they might be confused. Well... maybe so, but surely SWORD, as released by Crosswire, is clearly not intended for a casual user strolling by, on any platform. It's a software code library. How many C++ code libraries do you know of that are intended for "the casual user strolling through the website"? A "casual user" of any OS is not going to be able to do anything useful with SWORD 1.6.0 as released (a pile of C++ source code) anyway. Oh, hmm, the Windows part of the site doesn't point to the source code? That's probably a web site bug, since the SWORD source code is definitely available for all OSes. Another probable bug is having http://www.crosswire.org/sword/software/ still refer to GnomeSword under "Linux Software", and not mention that Xiphos is now a viable option for Windows too, I suspect. Likewise BibleTime should probably say (Qt) rather than (KDE) these days. Again though, none of those things appear to me to be loaded pro-Linux or contra-Windows, they are just small web site issues that will no doubt be corrected/updated, in time. Jonathan _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
