[developers] LKB on Windows

[R. Bergmair]

I have a webserver with root-access, which I rent privately
from a provider in Germany, and I'd be happy to use it to host
the `http://lingo.stanford.edu/ftp/' repository.

I should warn you, that I don't have any automatic backup
strategies in place or anything.  Furthermore, I don't have
the time or expertise necessary to take on the role Stephan
is suggesting.  I was more thinking along the lines of giving
FTP and SSH access (if necessary also root access) to the
person -- god have mercy on his soul -- who does want to take
the job, if this is at all useful to them.

On that note, can I throw in a related 'policy' question?

Am I the only one here who thinks that Franz is completely, and
entirely, evil?  Or have I just been hanging out with open source
idealists too much?  If I were you, I wouldn't pay these guys
another penny beyond what is absolutely necessary.

You have to forgive me that, at this point, as I'm physically
and psychologically incapable of resisting my natural inclination
to blurt out half-baked ideas, and speak, completely out of turn,
my mind on issues that are probably sensitive enough, as it is.

But let me try to explain.

A great deal of complexity in this software and the related
deployment process is due to the technical heterogeneity both
of the DELPH-IN components themselves, and of the platforms
out there running them.  And I really don't envy the job of
"build manager", who has to single-handedly bridge the gap
between users to whom this should all appear as a
well-integrated monolithic whole, and the "ownership of code"
sort of division of labour in the development process.

On the other hand: A vast majority of the users (especially
first-time users) out there have quite homogeneous user needs
that are probably easy to anticipate.  "I'm trying to write
a toy grammar for Swahili using the LKB.  I'd like to measure
how long the PET really takes to process sentences under
certain conditions, compared to my own parser.  I'd like
to do my good deed for the day and do some treebanking with
TSDB.  I'm really intrigued by this whole RMRS thing; show
me what the HoG produces for a given sentence with TNT /
chunkie / RASP / ERG."  These sorts of things just shouldn't
be too much to ask, regardless of whether the user has a Mac,
a Windows PC, or a Linux system.

So, it would seem like a natural match to go for more of an
ASP (application service providing) sort of model for getting
the software out there.

I'll happily volunteer my 32-bit linux server as an initial
guinea pig.  Developers would simply install and test their
stuff on that server, and users could connect using X11.

>From the users' perspective:

   The vast majority of users would probably, in a first step,
   only want to play around with some stuff to see how the
   software can help them with their research problems.
   At that stage, we can help them by sparing them all the
   hoops they would otherwise have to jump through to set
   up the software in their own computing environments.

   In a second step, when they decide they need to spend
   lots of CPU time, they could contribute some PVM nodes
   to a central cluster, or use the central installation
   as a useful point of reference to do their own installation.
   In any case: They would be motivated, at that point to
   get stuff going, where they might otherwise have given
   up long ago.

>From the developers' perspective:

   It must surely be easier for developers to install their
   stuff once and for all, than it is to develop and document
   a deployment process.  Plus, they can actually test and
   debug that installation on behalf of users who are technically
   clueless (and who have every right to want to stay that way),
   rather than sending error-messages back and forth on the
   mailing list.

   And, more importantly, we could leave it up the the developer
   of a specific software component, or of a specific interface
   between two components, to maintain its central installation.
   Surely, this would make life a lot easier for the build manager,
   or even make that role unnecessary altogether.

   When users have specific needs, not met by the central
   installation, one way or another, there is no way around
   the user actually interacting with the developers of the
   specific components involved, to get things going on their
   own machines.


Am I making any sense at all, or is this just the worst
idea of the century?


Richard



On Sun, 19 Apr 2009, Stephan Oepen wrote:

> hi again, my apologies for a tardy follow-up to this thread!
>
>> Currently (2009-04-14) there is no working Windows version available
>> for download as the lisp license has expired.  [...] Ann and Stephen
>> know about it, and hope to fix it at some stage (I think).
>
> well, to be precise: i can do the knowing.  ann (or someone else) will
> have to do the fixing.  DELPH-IN work at oslo makes no use of Windows,
> so we do not have the infrastructure.
>
> but maybe this is a good opportunity to start a broader discussion: on
> how to distribute responsibilities among ourselves.  anyone who could
> see themselves get involved in packaging of DELPH-IN resources, please
> read on!
>
> for the past several years, we have provided LKB and [incr tsdb()] run-
> time binaries for 32-bit Windows and 32- and 64-bit Linux.  being able
> to build and distribute these binaries requires an Allegro Common Lisp
> license in `good standing' (with active maintenance), i.e. there is an
> annual cost involved.  in recent years, LinGO was responsible for 32-
> bit Linux, UiO for 64-bit Linux, and cambridge for Windows; i took the
> role of a `build master': coordinating (to a certain degree), creating
> Linux binaries, maintaining the `install' script and download site.  i
> would now like to pass on this responsibility to someone else.
>
> the cambridge license expired sometime last fall, which to our surprise
> rendered existing builds for Windows dysfunctional (owed to the type of
> license, which was only `leased').  ann is aiming to renew her license,
> but she is currently unsure as to when this can happen and for how long
> she will be able to provide Windows run-time binaries in the future.
>
> all of the above relates to the so-called LinGO builds, i.e. the bundle
> of LKB, [incr tsdb()], and the ERG available for download from stanford
> (e.g. via the `install' script described under `LkbInstallation' on the
> wiki).
>
> in more recent developments, i have started to make available the exact
> development environment originally used for the LOGON MT project, i.e.
> a much larger bundle of tools, the so-called LOGON tree (see `LogonTop'
> on the wiki).  this is effectively an alternate way of doing a DELPH-IN
> install, but there are important differences: (a) LOGON is primarily my
> way of organizing (DELPH-IN) projects at UiO and close partners, hence
> it may at times use older versions of individual components or include
> experimental new features; (b) LOGON makes more restrictive assumptions
> about the use environment: only Linux (both 32- and 64-bit) and Allegro
> CL are supported, accessible via SVN only; and (c) the LOGON tree uses
> a lot of disk space (a minimum of four gigabytes) and is `intrusive' in
> how it expects to be installed.
>
> in the future, i would like to focus my (nowadays more limited) time on
> the LOGON tree.  but i believe it cannot replace the older distribution
> methods, e.g. we need the more lightweight, more general-purpose LinGO
> builds (or something similar) for new users, use in teaching, folks who
> only want part of the bundle (typically the LKB) or different platforms
> (typically Windows).  so, in practical terms, there are different types
> of user groups, and the LOGON distribution only accomdates a small sub-
> set of these.
>
> --- in conclusion, we are looking for volunteers to take over the LinGO
> build infrastructure.  ideally, this would be a site with ACL licenses,
> preferably not as leases, for all current platforms; or a federation of
> sites who complement each other in terms of platform-specific licenses.
> furthermore, one site would have to provide a web server with download
> space, similar to the current `http://lingo.stanford.edu/ftp/'.  we can
> wrap a virtual DELPH-IN address around that web server, which will make
> it easier to `move around' the actual server in the future.  finally, i
> think there should be one individual who takes the `build master' role,
> i.e. someone who understands how things `hang together', and who would
> maintain (and revise) the build setup over time (essentially, a complex
> Makefile).  as i am trying to demonstrate just now, this need not be a
> lifetime job, but in my view there should be a commitment for at least
> a few years :-).
>
> please either reply to the list or to `lkb-bugs at csli.stanford.edu', to
> include all parties involved.
>
>                                                  best wishes  -  oe
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; (+47) 2284 0125
> +++     CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515
> +++       --- oe at ifi.uio.no; oe at csli.stanford.edu; stephan at oepen.net ---
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>