|
|
|
| Task: | Applications at Buccleuch Place |
| Group: | roger |
| Stage: | 1 |
User applications specific to Buccleuch Place.
There are very few - if any - user applications specific to
Buccleuch Place, as most are shared or also used elsewhere. To provide
continuity of use within DICE, we need to co-ordinate with other sites
to identify shared applications, and highlight any issues or
applications that are specific to Buccleuch Place - making
sure that these continue to function in the DICE world, or that
functional equivalents are made available.
Applications can be grouped according to the user base of each - which can be defined in three (possibly four) broad categories: Research, Teaching, and Students (and Admin, if we want to separate out any purely administrative applications - DB access/updates, for example?). (Applications can also be grouped according to location: /corpora, /usr/local, /usr/contrib, /opt - and possibly /projects.)
We need to be aware of the differences between Research and Teaching, as the needs of Research Staff tend to be very tightly focused (an application may be used by only one person) and therefore - although important - researchers do not (on an individual basis) have such a widespread impact (application provision and support solutions may need to be on a one-to-one basis). How do we decide how much time to allocate to any such "island" applications?
Teaching Staff & Students are more inter-linked, and support for any particular application is likely to affect more people. With respect to taught courses within Buccleuch Place, we need to make sure that packages such as:
Also of concern is support for local, user-installed applications (officially unsupported, but useful to the user community). Do we make such things generally available on an "as is" basis? How would we do this? Possibilities:
There does appear to be some support for user-contributed software, although it has not yet been decided whether this will be by signed RPMs, or other alternative (see the Software Management Task), which says:
"A mechanism for submission of RPMs to the SRPM master repository is required. It may be prudent to accept only signed RPMs for submission. This mechanism should also allow for user contributed software."
The easiest solution is just to say "for application foo, log in to legacy Suns". It is unlikely that students will be the first group to move to DICE (it would make sense if the order of groups were Research Staff, Teaching Staff, and then Students - as this would allow teaching staff to familiarise themselves with the new environment prior to exposing the students to it!), so the provision of site-specific teaching packages is not likely to be in the front rank of tasks - although this is not to say that such applications specific to Buccleuch Place can be ignored. However, the order of exposure to DICE needs to be checked to make sure that there are no immediate requirements for teaching applications (purely a scheduling issue).
The initial concern over version management using Linux RPMs appears to have lessened, as version information can be incorporated into the RPM name, thus allowing different versions to co-exist and be selected for particular machine configurations. Do we wish to take this opportunity to standardise on versions within the Division?
We should check that applications under /opt are also available in the DICE world, as these tend to be Sun packages and standalone applications - for example:
maple, xwaves, spss, bmdp, wordperfect, Quintus Prolog
We also need to establish what happens to local data (including corpora). This may (ultimately) be mounted centrally (there is currently no planned central provision - Stage II perhaps?), but corpora and other non-application data will initially be duplicated locally via RPM installs - with a possible interim workaround of using the legacy machine NFS (read-only) export route. As some corpora are LARGE, we need to establish that the RPM route would not create disk-space problems on desk-top machines (incorporate check into install procedure? Use RPM if sufficient space, otherwise NFS mount?). The current "top ten" corpora are:
| Corpora Name | Space Req'd (Mb) | User Group |
|---|---|---|
| diphone | 2996 | CSTR |
| KAIST | 3711 | CogSci/CSTR |
| bnc-corpus | 3882 | CogSci |
| wsj | 4546 | CSTR |
| multimap | 4852 | CSTR |
| maptask | 5092 | CogSci/CSTR |
| umls | 7009 | CogSci |
| dciem | 7448 | CogSci/CSTR |
| wsj-disk42 | 9025 | CSTR |
| maptask | 13665 | CogSci/CSTR |
It should be noted that (some) corpora and other non-application data are shared via NFS with CSTR - this provision would need to remain.
If DICE intends to provide the majority of current applications under Linux, the issue of licences needs to be addressed. We may need to transfer licences from the Solaris to Linux, or acquire more licences for Linux. We may need to look at expanding our site licence arrangements (how would current licences be affected by the new Division vs old Departments? If a departmental licence was granted to, say, CS, does this now cover all of Informatics?). Some inter-site co-operation is required to identify licences needed to support BP applications that could - or should - now be division-wide.
Any packages or applications that are not being migrated to Linux (for whatever reason) need to be identified and suitable replacements found (including any necessary conversion work, etc). Are there obvious alternatives to Star Office & WordPerfect? It would be useful to survey current BP users to see what the reported "required applications" are...
We need to define distribution methods for such applications (via RPMs, or NFS mounts) so that local configuration of a DICE machine is possible, reflecting - as closely as possible - the user's pre-DICE application environment.
The status of user-contributed applications needs to be established, and support for such applications provided (if appropriate).
Decisions need to be taken about "contributed software" - if this is to be included, then the method needs to be established (and RPMs created, as required). This may require 2-3 weeks, but can be done in parallel with inter-site consultation about standard applications (and is not a "core" commitment anyway).
Once standard applications, and versions thereof, have been decided upon, the appropriate RPMs need to be constructed (if they don't already exist). Allow 2-3 weeks for this (once responsibility is decided & allocated).
Investigation of alternative provision for packages that are not to be migrated to Linux (such as cm) may be more problematic, but (once identified) should be do-able in 2-3 weeks.
The ordering of who gets DICE machines, and when, needs to be sorted out, to make sure that there is no problem with providing the required applications to run under Linux (building the RPMs) at the time they're needed (this is predominantly a teaching issue).
The Software Management Task needs to decide on a mechanism for user-contributed software submission (assuming this is to be permitted).
There may already be some Linux applications in the list below, but the intention is to focus on Solaris applications, since those are the ones at risk of disappearing...
| Software Category | Application(s) |
|---|---|
| Audio Tools | xmcd, RealPlayer, Xwaves/esps, xmms, netaudio(ausun), gaintool, audiocontrol |
| Corpus Tools | gsearch, xkwic, tgrep |
| Databases | postgres, mysql |
| Calendar Application(s) | cm, evolution |
| Graphics Packages | fig/xfig, gimp, convert, xview, xmgrace, Portable Bitmap Tools (pbm*), daVinci |
| Image Viewers/Players | xv, ImageMagick |
| Mail Readers | mailx (UCB mail), emacs/rmail, xemacs/vm, mh, mutt, pine, ream, exmh |
| News Readers | gnus, trn |
| Presentation Packages | [none under Solaris?] |
| Programming | Java, C, perl, poplog, ML, prolog/sicstus, ACL+CLIM, mozart, python, gcc, g++, Matlab, gdb, cvs, xmlperl, swi-pl (Prolog), GNU Common Lisp, scheme (scm), Quintus Prolog, Fortran, Perforce |
| Spreadsheets | StarOffice, gnumeric |
| Stats Packages | SPSS, |stat |
| Teaching | ps2pdf |
| Text Editing/Processing | emacs/latex, [g]vim |
| Text Formatting/Previewing | emacs/xdvi, gv/ghostview, distill/xpdf, a2ps |
| Web Browsers/Tools | netscape, opera, Internet Explorer, lynx, wget, mozilla |
| Window Managers | CDE, fvwm[2], blackbox, xfce, gnome, kde, tvtwm |
| Miscellaneous | LKB, Festival, HTK, PRAAT, licq, Mate, LT XML tools, xt/xerces/xalan, lyx, Stuttgart Neural Network Simulation package, m[un]pack, NUANCE speech recognition software, cdplayer, diskman |
The categorisation may not be exact, but it is of more concern to establish the required Solaris applications, than to make sure they're correctly classified.
|
Please contact us with any
comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh |
|
