gjalt@eutesap13.euteal.uucp (Gjalt de Jong) (04/07/89)
If you change the color table of your node, by modifying the file
/sys/dm/color_map, and reloading it with the 'lcm' command, the color
table of all the partner nodes are also changed.
Wouldn't it be better if this file were a link to the `node_data directory?
Since it is, at least to me, node specific data.
BTW, we're still running SR9.7, so I don't know if it's changed in SR10.x.
--
Gjalt G. de Jong, | Phone: +(31)40-473345
Eindhoven University of Technology, Dept. of Electr. Eng.
P.O. Box 513, 5600 MB Eindhoven, The Netherlands
Email: gjalt@euteal UUCP: {...}!mcvax!hp4nl!euteal!gjaltoj@apollo.COM (Ellis Oliver Jones) (04/19/89)
In article <GJALT.89Apr7091124@eutesap13.euteal.uucp> gjalt@eutesap13.euteal.uucp (Gjalt de Jong) writes: >If you change the color table of your node... >with the 'lcm' command, the color >table of all the partner nodes are also changed. >Wouldn't it be better if this file were a link to the `node_data directory? Right you are. It would be better. >...I don't know if it's changed in SR10.x. It's changed in sr10.1.p for the DN10000 (Real Soon Now) and will be changed in sr10.2 . /oj (speaking for myself, not for Apollo Computer, Inc.)
deborah@CITI.UMICH.EDU (Deborah Swanberg) (04/21/89)
In article <42b70de8.d5b2@apollo.COM> oj@apollo.com (Ollie Jones) writes: >In article <GJALT.89Apr7091124@eutesap13.euteal.uucp> gjalt@eutesap13.euteal.uucp (Gjalt de Jong) writes: >>Wouldn't it be better if this file were a link to the `node_data directory? > >Right you are. It would be better. > >>...I don't know if it's changed in SR10.x. > >It's changed in sr10.1.p for the DN10000 (Real Soon Now) and >will be changed in sr10.2 . > >/oj (speaking for myself, not for Apollo Computer, Inc.) Why don't you just make it a link. I did along time ago. There are several files that would be better of being links that I have made into links without problems. Just use your preferred method of creating a link, either AEGIS or UNIX. Mike Markley Apollo Systems Support UCSD Department of Electrical and Computer Engineering I always speak for myself. No one listens that way. No, I think this is still wrong because it works only in an environment where an Apollo is a personal workstation assigned to one person. In an envoronment where many people share the worstations, each person may want their own color scheme, and the original dictation of the sole color map is revisited. The lcm command allows a color map at any location to be loaded. I have a directory of color maps I've collected from various people, load my favorite from my user_data startup file, and change it according to the amount of light in the room. Deborah Swanberg Center for Information Technology Integration (CITI) University of Michigan 2901 Hubard Ann Arbor, MI 48105 313-763-7479 deborah@citi.umich.edu
FERGUSON@TMASL.EXXON.COM (04/22/89)
Why not just make the link to people's user_data directories, and copy it in to all active accounts then? You can put these files anywhere you like, just remember that Apollo software updates don't assume anything and you'll need to re-create your changes with every update. Scott ferguson@erevax.bitnet
oj@apollo.COM (Ellis Oliver Jones) (04/22/89)
In article <GJALT.89Apr7091124@eutesap13.euteal.uucp> gjalt@eutesap13.euteal.uucp (Gjalt de Jong) writes: >Why don't you just make it a link. I did along time ago. Yes, so did I on my own node. However, read the excerpted release notes included at the end of this article to see a problem that isn't solved by a simple `node_data link. *** In article <8904201526.AA04468@umix.cc.umich.edu> deborah@CITI.UMICH.EDU (Deborah Swanberg) writes: > ...The lcm command allows a color map >at any location to be loaded. I have a directory of color maps I've >collected from various people, load my favorite from my user_data startup file >and change it according to... This is a fine idea. Are you asking us to change something? It doesn't seem like we need to change anything further so you can continue to do this. *** Here's an excerpt from the release notes going out on SR10.1.p and SR10.2 describing how the new scheme works. (caution; don't use stuff you read on news as a reliable source for release notes, but rather read the notes that come with your software, because this stuff could still be changed at the last second). "At SR10.1.p we are moving the location of the system color maps in order to allow diskless nodes to have different color maps than their paging partners. "Prior to SR10.1.p, the system color map was stored in /sys/dm/color_map. At SR10.1.p color_map is stored in two directories: 'node_data/etc/dm_display/color_map and /etc/templates/dm_display/color_map "Note that /sys/dm/color_map remains as a link to the color map in the 'node_data directory." "When a diskless node boots from a paging partner that it has not used before, the system software copies the color map in /etc/templates/dm_display/color_map into 'node_data/etc/dm_display/color_map. "You can then modify the color map for the diskless node by editing 'node_data/etc/dm_display/color_map. "Note that if the diskless node has used the paging partner before the system leaves the color map file alone. /Ollie Jones (speaking for myself, not necessarily for Apollo Computer, Inc.)
freedman@cpsc.ucalgary.ca (Dan Freedman) (04/23/89)
In article <8904211745.AA10904@umix.cc.umich.edu> FERGUSON@TMASL.EXXON.COM writes: > >Why not just make the link to people's user_data directories, and >copy it in to all active accounts then? You can put these files anywhere >you like, just remember that Apollo software updates don't assume >anything and you'll need to re-create your changes with every update. I think you just answered your own question. Having to re-create things when the software changes is quite time-consuming. What makes it worse, is that it is difficult to tell ahead of time which changes will need to be re-done after the installation. The solution is to have the vendor *assume* that people are going to want to customize the o/s on both a system-wide and on a per-user level. The vendor then provides oodles of hooks that both system administrators and users can hook their customizations into. This is done already for some things. For example, both a system administrator and a user can hook extra directories into the shell's search paths. This kind of flexibility should be extended to all system software. True, we can make our modifications and patches, but really, the o/s vendor should make the software flexible enough so that user's own customizations can fit in without changes to the o/s. Dan Freedman University of Calgary Computer Science Department 2500 University Drive N.W. freedman@cpsc.UCalgary.CA Calgary, Alberta, T2N 1N4 ...!alberta!calgary!freedman
dennis@peanuts.nosc.mil (Dennis Cottel) (04/26/89)
Dan Freedman says: > The solution is to have the vendor *assume* that people are going to > want to customize the o/s on both a system-wide and on a per-user > level. The vendor then provides oodles of hooks that both system > administrators and users can hook their customizations into. Exactly. Another example: make the HELP command search a list of directories. A simple change to the program by the vendor, and lots of ugly configuration tricks could be done away with. Yet another example: the DPCC installation requires configuration files to be modified down in /sys/dpcc making them global to the node and not variable for specific users. (Unless you make your own links, but we're discussing a better way.) Ok, now that I'm worked up: *all* the configuration files for various products ought to be segregated into a common specific area. That way, rebuilding the disk becomes simply reinstalling the product (binaries and unchangeable data files), and then reloading a single small backup of this node's specific configuration directory. Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152 (619) 553-1645 dennis@nosc.MIL sdcsvax!noscvax!dennis