response 1 of 32:

Jul 30 19:45 UTC 1996

Whoops, looks like staff is planning to reboot Grex to free up some ptys, so
I don't have time to enter a long response right now.  I'll post more later.

response 3 of 32:

Jul 30 21:33 UTC 1996

Thank you for entering this item! Definitely grexian. So, color next?

response 5 of 32:

Jul 31 03:01 UTC 1996

Grex's staff is planning to change the structure of the /home directory
and possibly (but maybe not at the same time) the /var/spool/mail directpry
as well.

/home will become hierarchical instead of flat. If your personal home
directory is /home/srw (which it isn't, because mine is), then it will change
to become /home/s/r/srw

The reason for this change is performance. We expect it to speed Grex up for
several reasons. The main effect will be that searching to find a directory
will require a much shorter search.

If you have a single letter user id, or the second character of your user id
is a digit, a "z" will be used for the second letter. (Or else we'll use some
similar trick, so don't worry about it.)

Most people will not notice this, but if you have written a script that refers
to anyone's home directory (or mail directory, perhaps) be full path, it will
no longer work after this change, You will have to edit your script.
I am not sure if the /u symlink will continue to exist as a symlink for /home.

URLs will not be affected, nor will references to files that begin with ~,
as these both will get clued in by the entry in the password file/database.

The password file will increase slightly in size, as we change the pathname
to your home directory, both by adding the letters, and by changing the /u
(A symlink) to /home. Staff members still fight over this one, but the
consensus is that the time saved by not looking up a symlink outweighs the
advantage of a slightly smaller password file.

(Important functions don't use the password file, anyway, but an indexed
database, anyway.)

response 7 of 32:

Jul 31 05:53 UTC 1996

(Yes, it is very garagey.  I'll link it.)

Cool, being chased off Grex at just the right time saved me the trouble of
entering descriptions of these three items, which were exactly the ones I had
in mind.

Couple notes:

  Terminal server:  The main advantage of this is that it will allow us to
    switch more of the modems up to higher speeds.  There is some difference
    of opinion on whether it will improve system performance.  Likely not.
    This isn't going to be doable until there are further modifications
    to the telnetd Marcus has been working on.  With the current telnetd.
    dialup users would find themselves put on the waiting list, and with
    the old one, they'd often get an "all ports busy" message.  Obviously
    not a good thing.  We need a version of telnetd that reserves connections
    for dialin users.  When this change is made, dialin users won't be
    showing up on the ttyh* lines anymore.  They will be on pseudo-tty's
    just like telnet users, only they will be telnetting in from the
    terminal server instead of some other computer.

  Hierarchical Home:  Right now the /home directory is a big problem because
    it has about 12,000 subdirectories.  That means everytime Grex tries to
    access /home/whomever, it has to search an unsorted list of 12,000 names
    find whomever's name in the /home directory.  Since Grex does this *alot*,
    this huge directory significantly slows down the system.  If we change
    the directory to /home/w/h/whomever, then it has to search a size 26
    directory to find /home/w, another size 26 directory to find /home/w/h
    and an average of maybe 17 users to find /home/w/h/whomever.  So you
    have to search about 26+26+17 = 69 things instead of 12,000.  Clearly
    this is a big performance gain on an operation Grex does very often.

    The issue with the mail spool is similar.  /usr/spool/mail is almost as
    big as /home, because many users have some unread mail sitting there.
    Everytime grex delivers mail or a user reads mail, Grex has to search
    that directory.  We could speed things up a lot by reoganizing that in
    a hierarchical form.  I wouldn't be surprise if this change alone were
    enough to solve our current mail queue problems.

    We had originally planned to do the home reorganization before we moved
    from the Sun3 to the Sun4.  But the easiest way to rebuild /home would
    be if we had a spare disk.  We had borrowed one from Marcus, but it died
    and is now under repair.  We probably won't do the rebuild until either
    it gets fixed or a new disk is purchased.

  Mail Machine:  There are a lot of different ideas on how to shift mail
    processing off of Grex's main machine and onto a subsidiary machine.
    Different ones have different problems.  Most alternatives seem to either
    (1) screw up the ability of users to set .forward files, or (2) leave lots
    of processing still on Grex, or (3) introduce potential security problems.
    We are still looking for a solution with none of these defects.

response 9 of 32:

Aug 1 06:12 UTC 1996

Staff is thinking about giving the current website a cleanup.
We are actually more than thinking about it, we have a volunteer who has been
making progress. We will probably install a new version soon.

Note that you do not need to be a staff member to help out the webmasters with
the web site. You need to have skill with HTML and a willingness to spend
time to improve what is out there.

response 11 of 32:

Aug 5 18:58 UTC 1996

   Heh.  Are you volunteering to help write it down, Arnold?  We could
have a campfire whee the GrexOldFarts got together and expounded on
things.  I think we could collectively make a lot of hot air.   ...But
putting it down on paper is the hard part.
   More seriously, I think that your suggestion is a good one.

response 13 of 32:

Aug 6 15:39 UTC 1996

We are thinking of making some changes in the default configuration of the
"mail" program for newusers.  This would not effect oldusers at all.  Possible
changes would include:
  - you get the menumore pager automatically when reading long messages.
  - when you use ~m to read in a message, it will be indented with >'s
    instead of tabs.
  - messages would be left in the incoming mail file instead of being stuck
    into "mbox".
This is being talked about a bit in the garage conference.

There are plans to install a program that would monitor the net connecton and
reinitialize Grpys if the connection seems to fail.  This might give a more
reliable net connection.

response 19 of 32:

Aug 8 05:07 UTC 1996

I don't have a pager set, but i do have crt set, and what looks like
"more" is invoked on long messages...mail's man page says crt without
a pager defaults to more.

response 21 of 32:

Aug 8 14:11 UTC 1996

I agree, Valerie.  It sounds like a great idea, and most conferencing systems
employ it for just that purpose.

response 23 of 32:

Aug 8 15:36 UTC 1996

Gods, alternate e-mail address was in newuser when *I* ran it,
tsty.  And that was in 1992!