stevesu@copper.UUCP (03/31/87)
I have come up with a last-minute addition to the set of ways of
dealing with the daylight-savings time change this weekend.
It is based on the following three assumptions:
Compiling DST information into ctime.o and hence linking
it into the a.out file of every program that deals with
time is a total loss. Some sort of dynamic reading from
a file is the only way to go.
Artificially setting the time off by an hour for three
weeks is for the birds. (This is what several vendors
are recommending.) If I wanted to set my system clock
periodically to account for DST, I'd run VMS.
I don't have source for all of my systems, and even if I
did, I wouldn't feel like relinking everything, because
it's a lot of work, and I might not have .o files lying
around so I might have to recompile things too, and then
I might break utilities whose sources were out-of-date.
I have worked out the following two-step solution:
1. Some simple mods to the existing ctime (actually
localtime) to allow it to read the DST information
from a file, but in a simple-minded enough way that
the size of ctime.o doesn't increase much.
2. A patching link editor which, believe it or not, lets
you wedge the new copy of ctime into existing a.out
files, even if they don't have symbol table or
relocation information.
This scheme unfortunately does not use any of Arthur Olson's
remarkable solution, which is clearly the way to go if you're
going to relink everything.
It has been said that "using adb on the running kernel is not for
the faint-of-heart." The same is true for patching a.out files.
If you're not up for a nerve-wracking trek through the bowels of
Unix, involving adb, assembly language, relocation, and hidden
library routines, just relink your executables if you're able to
and set your clock fast for three weeks if you aren't.
I don't think I'm going to post the patching link editor yet, but
I'll send you a copy if you're really interested.
(If it sounds like I've changed my tone since the beginning of
this article, it's because these last three paragraphs are being
written after I started doing wholesale patching of lots of files
in /bin and friends, and discovering that writing the patcher,
which is as far as I'd gotten when I wrote the first part of the
article, did not leave me home and dry. I wasn't even home and
vigorously toweling myself off.)
Steve Summit
stevesu@copper.tek.comrbj@icst-cmr.arpa (04/01/87)
Artificially setting the time off by an hour for three weeks is for the birds. (This is what several vendors are recommending.) If I wanted to set my system clock periodically to account for DST, I'd run VMS. Automatically switching to DST is not what makes UNIX better than VMS. Arthur Olson's solution may be the greatest thing since sliced bread, and when all the vendors install it, the Golden Age will be upon us. In the meantime, the vendors are correct. This is an administrative and political problem, not a technical one. Either put up with the difference, or run on GMT like the military and scientific types who *really care* what time it is. Do you want vendors and/or employees working on this crap or doing real work, fixing real bugs and adding real functionality? Steve Summit stevesu@copper.tek.com (Root Boy) Jim "Just Say Yes" Cottrell <rbj@icst-cmr.arpa> I hope I bought the right relish...zzzzzzzzz..."
scott@tg.UUCP (04/04/87)
Then there is always the optimal solution that would be nice to
have in all Unixes:
SHARED LIBRARIES!
One change and *POOF* the problem is gone!
Scott Barman
{philabs, pyrnj}!tg!scottlcc.rich-wiz@CS.UCLA.EDU (04/04/87)
> From: Root Boy Jim <rbj@icst-cmr.arpa> > Artificially setting the time off by an hour for three > weeks is for the birds. (This is what several vendors > are recommending.) If I wanted to set my system clock > periodically to account for DST, I'd run VMS. > In the meantime, the vendors are correct. This is an administrative > and political problem, not a technical one. Either put up with the > difference, or run on GMT like the military and scientific types > who *really care* what time it is. The vendors are not correct if someone tries running a "make" in the one hour after the time is set back on April 26. (Run a make just before the change; then edit a .c file right after the change; a following make will screw up. This gets especially bad if you touch a lot of files and don't notice that a few of them didn't recompile.) A better solution (for temporarily fixing the problem until the next release), at least on System V systems, has been suggest by AT&T for binary sites: change the TZ environment variable from, for example, TZ=PST8PDT to TZ=PDT7. Using the short form of TZ tells ctime() that it should ignore its own daylight savings rules. Changing the number from 8 to 7 and using PDT in the first field will then simulate being on year round daylight savings time. Since most users don't set TZ in their .profile/.cshrc/.whatever, changing the default TZ and rebooting will be enough to get it into everyone's environment. The problem with this is that dates before April 5 will also be displayed as if DST had been in effect at the time. I like the flexibility that TZ gives. It allows for different users on the same machine (or distributed system) to be in different timezones. Its biggest drawbacks are that it only allows timezones which are an integral number of hours away from GMT (they should have used minutes or hours:minutes, not just hours) and that your only choices are U.S. daylight savings rules or no DST at all. Even so, it is a lot better than putting the timezone in the kernel, as with BSD. I haven't seen Arthur Olson's code, but it would be a good idea for it to accept an environment variable which specifies an alternate name for the file with the DST data. It would also be good for it to recognise Sys V's "TZ" to override the kernel's idea of timezone. This would then seem to be the best of all worlds. Richard M. Mathews Locus Computing Corporation lcc.richard@LOCUS.UCLA.EDU lcc.richard@UCLA-CS {ihnp4,trwrb}!lcc!richard {randvax,sdcrdcf,ucbvax,trwspp}!ucla-cs!lcc!richard
guy@gorodish.UUCP (04/05/87)
>A better solution (for temporarily fixing the problem until the next >release), at least on System V systems, has been suggest by AT&T for >binary sites: change the TZ environment variable from, for example, >TZ=PST8PDT to TZ=PDT7. Using the short form of TZ tells ctime() that >it should ignore its own daylight savings rules. Changing the number >from 8 to 7 and using PDT in the first field will then simulate being >on year round daylight savings time. Since most users don't set TZ >in their .profile/.cshrc/.whatever, changing the default TZ and rebooting >will be enough to get it into everyone's environment. This assumes, of course, that you *have* some way of setting the default TZ - i.e., "init" had better put TZ in its environment, or you had better have some other way of ensuring that *every* process on the system gets it stuck in its environment by default. "/etc/profile" just doesn't cut it, since a user may not have the Bourne or Korn shell as their login shell (and no, I'm not just talking about the C shell; some site may use some special application as a login shell for some users). >Even so, it is a lot better than putting the timezone in the kernel, as >with BSD. Or V7, which is the AT&T release where the timezone-in-the-kernel idea first appeared publicly. >I haven't seen Arthur Olson's code, but it would be a good idea for it to >accept an environment variable which specifies an alternate name for the >file with the DST data. It's such a good idea that Arthur Olson put it in when he first implemented it. >It would also be good for it to recognise Sys V's "TZ" to override the >kernel's idea of timezone. In fact, the name of the environment variable in question is "TZ". The files can be given names like EST5EDT if you want. It doesn't parse TZ, it just uses it as a file name; if you want to use some zone not in the tables supplied with the code, you have to edit the table source and recompile the tables, providing a name for the new zone. Olson's code permits timezones to be any number of minutes away from GMT, and permits you to specify pretty arbitrary DST rules. The file whose name is specified by TZ gives, in effect, both the DST rules and the offset from GMT. (Actually, it gives a list of transition times and, for each time, the GMT offset and time zone abbreviation valid starting at that transition time.) It doesn't bother with the kernel's idea of time zone at all, so there's nothing to override.
kre@munnari.UUCP (04/06/87)
Shared libraries aren't enough to fix ctime. What they give you is the ability to replace ctime(3) in all your binaries very quickly, assuming that you somehow have the source of ctime.c in order to compile the new version. For something that everyone is likely to want to be able to change with almost no notice sometimes (daylight saving rules in Australia have been known to change with 2 weeks warning) and binary only systems who don't have the source for ctime.c to recompile, some kind of external file that can be edited is clearly a better solution. Putting the ctime.o that uses this file in a shared library so it can be updated easily if needed is certainly even better, and compiling the editable text so ctime doesn't need to each time its called better still. kre
peter@citcom.UUCP (04/07/87)
In article <176@tg.UUCP>, scott@tg.UUCP (Scott Barman) writes: > Then there is always the optimal solution that would be nice to > have in all Unixes: SHARED LIBRARIES! > One change and *POOF* the problem is gone! > Scott Barman Shared libraries for UNIX has been implemented in the past; one of the CCI 5/20 units had this; it involved a custom version of "ld" among other things. Does anyone remember more details? btw, our SUN user community here is a little tired of 700K a.out files from graphics programs that are much less than 200 lines. -- Peter Klosky, Citcom Systems (materiel de telecommunications) seismo!vrdxhq!baskin!citcom!peter
njh@root44.UUCP (04/09/87)
In article <176@tg.UUCP> scott@tg.UUCP (Scott Barman) writes: >Then there is always the optimal solution that would be nice to >have in all Unixes: > SHARED LIBRARIES! Shared libraries have been available for UniPlus+ since V.0. It doesn't rely on any specific UniPlus+ extra, so it should work on any Un*x system. > >One change and *POOF* the problem is gone! As you rightly say.... > >Scott Barman >{philabs, pyrnj}!tg!scott -- Nigel Horne, Divisional Director, Root Technical Systems. <njh@root.co.uk> G1ITH Fax: (01) 726 8158 Phone: +44 1 606 7799 Telex: 885995 ROOT G BT Gold: CQQ173
gwyn@brl-smoke.UUCP (04/11/87)
In article <18271@ucbvax.BERKELEY.EDU> bostic@ucbvax.BERKELEY.EDU (Keith Bostic) writes:
- Shared libraries are not the solution to software updates. Think about
- what happens when your C compiler (let alone init) depends on a shared
- library that you've just "updated". The biggest advantage of shared
- libraries is that they allow you to simultaneously update all of your
- software. The biggest disadvantage of shared libraries is that they
- allow you to simultaneously update all of your software.
There shouldn't be any problem if the shared library implements a well-
defined interface and is tested against the interface specs before being
installed. Or is that too organized?bzs@bu-cs.BU.EDU (04/14/87)
Doug Gwyn writes... >There shouldn't be any problem if the shared library implements a well- >defined interface and is tested against the interface specs before being >installed. Or is that too organized? Agreed, another consideration is that it should be possible to load software w/o using the shared libarary interface. This could give some confidence to things like init (which can be supplied whole to reflect changes) while other programs can chance the new shared library. And, of course, the panic button of easily backing out of an "upgrade", maybe a good rule of thumb would be that anything needed to change it from single-user mode should be independantly resolved, or an independantly resolved version should exist and be automatically used for single user. Vendor's choice, I suspect the issues are subtle. Let's face it, that's why pencils have rubout keys. -Barry Shein, Boston University