|
|
| Author |
Message |
| 25 new of 175 responses total. |
gregb
|
|
response 39 of 175:
| 
Nov 19 15:17 UTC 1998 |
Re. 37: Any idea on what happened Tuesday morning? Everytime I tried to
telnet in I kept getting refused connections.
|
valerie
|
|
response 40 of 175:
|
Nov 22 01:40 UTC 1998 |
This response has been erased.
|
tpryan
|
|
response 41 of 175:
|
Nov 22 15:54 UTC 1998 |
Now that you know the system has stability, consider a more
regular routine for re-boot the system, say weekly.
|
shf
|
|
response 42 of 175:
|
Nov 22 19:44 UTC 1998 |
Grex is a very friendly system. It even remembered my daughter's 16th birthday
is today. Astounding!
|
gregb
|
|
response 43 of 175:
|
Nov 23 14:21 UTC 1998 |
Re. 41: I thought with Linux/Unix, you didn't have to do such things.
|
dpc
|
|
response 44 of 175:
|
Nov 23 14:51 UTC 1998 |
That's what I thought, too.
|
mcnally
|
|
response 45 of 175:
|
Nov 23 20:07 UTC 1998 |
re #43, 44: It's less necessary under Unix than with some other operating
systems but running for weeks with hundreds or thousands of users logging
in and running tens of thousands of programs takes its toll on even the most
robust system. I'm telnetted in from another Unix system which has been
up for forty-five days with about 30-40 users logged in at any given time
and it wouldn't surprise me if it ran for another 45 days without problems
but Grex is basically pushing itself pretty hard to operate under typical
conditions day in and day out..
|
mdw
|
|
response 46 of 175:
|
Nov 24 03:32 UTC 1998 |
Actually, it depends a lot on the system as to whether it's necessary.
There is definitely a religion that says "reboot weekly" no matter what.
There are also plenty of Unix systems that stay up weeks, or even years,
under hard usage. The basic issue is the possibility that, somewhere in
the complex of the system, there is a bug that causes the system to get
sick. This bug could have one of 3 major behaviors: it could be a simple
matter of probability; it will happen sooner or later, how often the system
is rebooted doesn't affect it, and once the bug happens, the system needs
to be rebooted. Or, it could be a resource fragmentation problem; if there
is something that needs physically contiguous memory, and something else
that randomly pins pages in memory, then it's possible that with
continued heavy use, the system will tend to evolve in a direction where
the randomly pinned pages are scattered in memory making it impossible
to allocate a large physically contigous chunk. Or, there could be a
resource "leak" problem - the classical one is a system that forgets to
free memory - as it continues to run and allocate memory, it will grow and
grow and grow...
With grex, we don't *know* that the current systems has any of these problems.
We *do* know that previous versions of the system did have stability problems,
and that it was helpful to have weekly preventative reboots. *That* problem
doesn't seem to exist in the current system.
|
valerie
|
|
response 47 of 175:
|
Nov 25 15:29 UTC 1998 |
This response has been erased.
|
atticus
|
|
response 48 of 175:
|
Nov 25 16:13 UTC 1998 |
re #46: I remember reading somewhere that 5ESS telephone switches from
AT&T have an automatic periodic rebooting feature. A switch is an ideal
candidate for problems of category 3 (resource leak) as listed by
Marcus. The number of specific programs are limited, but they are
executed for every phone call that is made. AT&T's technical name for
the periodic reboot is "stochastic rejuvenation", I believe.
|
danr
|
|
response 49 of 175:
|
Nov 25 19:27 UTC 1998 |
Stochastic rejuvenation....I like it!
|
srw
|
|
response 50 of 175:
|
Nov 28 08:23 UTC 1998 |
I have just added support on Grex for a new time zone. Many of our users
come from India, but our version of SunOS had no zoneinfo file for it. I
added one, so you can now get Grex to tell time in IST. Just set your TZ
environment variable to India. If your shell is BBS or a bourne-based
shell you probably want to put the command in your .profile file. use
export TZ=India
If your shell is lynx, menu, C-shell or a derivative, you need to put
setenv TZ India
in your .login file. of course you can just type the appropriate command
to see its effect on the date command and ls -l command, without putting
it in your dotfile, if you are merely curious.
there are many other supported zones. Look in /usr/share/lib/zoneinfo
By default, if you don't set TZ, you get Grex's time, by the way.
|
remmers
|
|
response 51 of 175:
|
Nov 28 12:12 UTC 1998 |
Thanks for the info about TZ, Steve. In looking over the directory, it
seems appropriate for me to do
setenv TZ US/Michigan
(There don't exist corresponding symbols for all the states, though.)
|
srw
|
|
response 52 of 175:
|
Nov 30 02:04 UTC 1998 |
Michigan has a separate data file from the rest of the time zone because
Michigan did not observe daylight savings from 1968 to 1973. With
TZ set to US/Michigan, historical dates will be interpreted according to
the rules in place for Michigan at the time.
The source code for US/Michigan can be found in the text file
/usr/share/lib/zoneinfo/northamerica
Grex uses TZ=EST5EDT which is the same as TZ=US/Eastern, so incorrectly
interprets times as EDT during the Spring and Summer months of
1968-1973, when the Eastern time zone honored daylight time, but
Michigan was still on EST.
Arizona, Eastern Indiana, and Alaska have their own time zones, because
they have their own time rules, to this day.
If someone is in a country which we do not support, or do not support
correctly, I will be happy to make the additions or corrections. Most of
the data in there is from the SunOS release many years ago, so recent
time rule changes are not likely to be there unless we put them in.
|
mcnally
|
|
response 53 of 175:
|
Nov 30 05:10 UTC 1998 |
nifty.. I always wondered why Michigan commonly got its own zoneinfo
file.. Now that I think about it I even remember my first year of
kindergarten, which was the last year Michigan didn't observe DST.
|
davel
|
|
response 54 of 175:
|
Nov 30 13:00 UTC 1998 |
Hmph. We moved here in June, 1973, & I don't remember Michigan's not changing
to DST.
|
keesan
|
|
response 55 of 175:
|
Nov 30 17:34 UTC 1998 |
A friend in NW Indiana tried to explain their time zones to us, in fact he
had written a paper for school once on the subject. I recall that a small
portion of the state near Chicago (whose inhabitants presumably commute to
Chicago) was in the Chicago time zone.
|
rcurl
|
|
response 56 of 175:
|
Nov 30 17:49 UTC 1998 |
And I moved here in 1964, and also do not recall ever not being on DST.
|
bruin
|
|
response 57 of 175:
|
Nov 30 21:25 UTC 1998 |
RE #56 I do believe that Michigan and Northwest Ohio (Toledo area) were on
Eastern Standard Time year round until it was decided that the entire United
States would be on Daylight Time in 1966-67. Michigan went on EDT in June
of 1967 or thereabouts, and was on Daylight Time during the summer of 1968.
In November of that year, voters rejected Daylight Time, but it was voted in
for the 1972 ballot, never to be voted down again (so far).
Other major headaches that Michigan had faced on year round EST was the fact
that the Toledo (Ohio) area and Windsor, Ontario, each went on EDT during the
summers of 1969-72, resulting in time checks on CKLW giving both Detroit and
Windsor times (or the elusive "40 minutes past the hour").
As a final note, during the Energy Crisis of the mid-late 1970's, the United
States was on Daylight Savings Time year round. This was quickly repealed
after complaints about 9:00 am sunrises and such.
|
scott
|
|
response 58 of 175:
|
Nov 30 21:42 UTC 1998 |
A lot of Indiana is still *not* on daylight time. I have a customer which
changes relative time zones twice a year.
|
keesan
|
|
response 59 of 175:
|
Nov 30 22:42 UTC 1998 |
I prefer a 9 am sunrise to a 3:30 pm sunset, as found in Boston winters.
|
rcurl
|
|
response 60 of 175:
|
Nov 30 22:54 UTC 1998 |
Thanks, bruin - shows how unimportant it has been to me over the years
that DST came/went for a while in '64-'72.
|
i
|
|
response 61 of 175:
|
Dec 1 01:07 UTC 1998 |
I've got a supplier who's order-must-print-by-5PM-to-ship-today warehouse
is in that murky part of Indiana....
|
remmers
|
|
response 62 of 175:
|
Dec 1 09:42 UTC 1998 |
The polls are open through December 15 in the Grex Board of Directors
election. To cast a ballot or just to get more info on the election
and candidates, type "vote" at a Unix prompt or "!vote" at a bbs or menu
prompt. On the web, go to http://cyberspace.org/cgi-bin/pw/voting-booth
to do the same.
Any user can cast a ballot, but only the votes of Grex members in
good standing will be counted in determining the outcome.
|
remmers
|
|
response 63 of 175:
|
Dec 1 09:46 UTC 1998 |
Also - you can vote more than once. If you've cast a ballot and later
change your mind about who you want to vote for, just vote again.
Your new ballot replaces the previous one.
|
