- a "/sciops" area for storage of and work on SciOp data, i.e.
service observing, technical data, etc. It must hold at least one
period of Service Mode (NTT/3P6: 70Gb) and leave ~70Gb of space for
data processing, i.e. >~140Gb for NTT/3P6. For 2P2, the Service data
are not stored locally, but the data processing requires more space, so
similar (>~140Gb) disk should be provided.
- EXTERNAL DISKS: the machine should have USB2/Firewire slots to hot-plug some external disks, such as
- Instrument disks: each instrument shall have a ~100Gb
disk for storrage of calibration plan data, work in progress, etc...
under the responsibility of the Instrument Scientist.
- Visitors' disk, in case they have a compatible disk.
The operating system should be
configured in such way that it recognises and mount automatically these
disks, and permits the users to umount/remove them without root
privileges in a documented way.
We should have at
least 2 USB2/Fireware slots per machine to avoid
conflicts between users/visitors.
Reply: made more clear:
...the machine should have at least 2 USB2/Firewire slots
COMMENT (JPR): I would strongly support dual head systems. I note that the
Dell Precision 650 with nVidia, Quadro4 900XGL, 128MB,
VGA/DVI comes dual monitor
dual display would be a nice feature, but is not
critical. However it would be wise to choose
dual monitor capabale platforms like the ones
John is suggesting or MacIntosh (with linux
(JPR): As there are several standards for DVDs (DVD-R, DVD-RW,
DVD+RW...) it is important to check which standard the drive will
support. These days it is possible to get drives compatible with more
than one standard (though not necessarily from Dell), e.g. the Sony
DRU-500A Dual RW DVDRW, see for example
REPLY: agreed. Text added:
- DISPLAY: large, high-res, flat screen. Dual display would be an advantage but is not critical.
COMMENT (RME): DLT writer for w2p2off is required.
will this requirement stand also after we will have
a central backup office in La Silla ?
(GHA): There should be a read-only CD/DVD reader and an CD/DVD burner (I
would opt for the DVD burner since there will be no need for any
upgrade, and astronomers can burn their data in one go if they have
multiple nights. Same for the TiOs so means less work). The
reason why there should be a separate read-only CD/DVD reader is to
avoid having to dismount the CD when using xcdroast. If we have only
one CD/DVD writer It is easy to have conflicts if the kernal tries to
mount the CD, whereas xcdroast want to write to the CD.
I beleieve we could find a better solution than buy read-only CD/DVD to
avoid conflicts in the system when using xcdroaast. A possibility
would be to start xcdroast from a script which checks that all mounting
is done correctly.
Pls note that the TIOs will have nothing to do
on this machine: this will be for the visitors and SciOp astronomers to
play with their data, not for data archiving and CD production (which
is done eleswhere)Text added:
There should be a scratch area for
the CD images, or that xcdroast is configured to use /tmp or /data
(this requires root permission).
Added in the configuration of XCdRoast
COMMENT (GHA): About the CD/DVD
burner/players -- if the computer will be physically in the computer
room, we should consider using external (fireware or USB) CD/DVD
burner/players which are accessable from the desk, and does not involve
the user going to the computer area. This also may be configured as
part of the auto-detection of external hard disk setup.
REPLY: desk accessibility to CD/DVD burner is desirable but not critical. We should investigate possible solutions.
a read-only unit, and a read-write unit. External unit (USB2/Firewire)
living on the desk as opposed to the computer room would be a nice
luxury provided that this does not degrade transfer rates.
COMMENT (GHA): I would advice against using the "ergonic keyboards". Also, the keyboards must be US standard.
- Keyboard: Standard (i.e. not "Ergonomic") US layout.
- Standard operating system (recommended by VLT, currently RH-7.3),
- Standard applications. This must include the following, properly configured:
COMMENTS and REPLIES
- EMACS, VI
- LaTeX, dvips, a2ps
- xdvi, ghostview, acroread
- xCDroast (with the proper staging space configured)
- Xemacs, jed (JPR, EPO): OK if part of standard LINUX distribution
- cdrecord suite (JPR): is a requirement for XCDRoast
- Spreadsheet (Staroffice ? Openoffice ?) (EPO, GHA): Do we really want these huge packages? Gnumeric OK?
- cdlabelgen (GHA) OK
- xv, xfig, (EPO) OK
- IDL (GHA, GLO) Part of SciSoft
- P2PP -noccs (GHA) OK, but why?
- CMM (JPR) OK
- lyx (see www.lyx.or g) (ISA) wonderful, but is it standards?
- SciSoft updated to the latest available version, with local
configuration (printers visible from the application softwares, IDL
licenses, IRAF pipes, etc...) and patches (infamous
/scisoft/saord/bin/access conflicting with LateX).
- dhsSubscribe installed and configured to transfer all raw data
from the w*dhs machine. In a next step, we may add a secondary
dhsSubscribe for pipeline processed data. dhsSubscrive can be
left with its "default" options (ie store the data in
/data/raw/<date>, DHS filenames, no post-arrival script)
In addition to the various system related accounts:
(GHA): >> The paths should include a /home/user/bin as default so
that additonal programs can be installed by us. There should be a
scratch area for the CD images, or that xcdroast is configured to use
/tmp or /data (this requires root permission). It should also be
decided whether KDE or GNOME should be run. At the moment the different
drl machines are configured differently.
agree, but users should avoid to install unsupported software or they
should ask the requested softwarto be entered in the supported software
- sciops: used for
installation and owner of sciops-related programs (eg MIDAS scripts).
This is the equivallent of the nttops or e3p6ops accounts on the
- astro: used by Sciop astronomers for daily work
- visitor1, 2, 3: used by
the visiting astronomers during their runs. These accounts will be
zapped and re-initialized for each new visitor. These accounts could
(should ideally be) the current lsusr* accounts delivered to the
visitors on the off-line DRL system, PROVIDED that the access time to
their home directory is much faster than currently.
Additionally, the accounts should be configured to use GNOME, and the
path should include a ~sciops/bin directory so that we can install
programs under configuration control but without inserting them in the