[sisyphus] startup

Alexey Morozov =?iso-8859-1?q?morozov_=CE=C1_novosoft=2Eru?=
Пн Май 26 15:40:42 MSD 2003


On Mon, May 26, 2003 at 01:53:03PM +0400, Dmitry V. Levin wrote:
> On Mon, May 26, 2003 at 05:52:41PM +0700, Alexey Morozov wrote:
> > Ну, с существующей схемой я не вижу, как сделать иначе.
> > Можно, конечно, вытащить описание таймзоны куда-нить на /,
> > но это требует известного напряжения мыслительных процессов.
> Для этого мы здесь и собрались. :)
Да? Как я угадал с выбором тусовки :-).
Ну, в общем, наверное, можно использовать схему, когда при выборе
таймзоны (в инсталляторе) соответствующий файлик просто копируется
в /etc/localtime, и /etc/init.d/clock не пытается даже использовать
данные из /usr/share/zoneinfo...

Но тогда автоматически встает вопрос корректных апдейтов этого файла
при апдейтах glibc-timezones.

Я так вот вижу возможные пути решения проблемы.

> Только если
> is_yes "$HWCLOCK_SET_AT_HALT"
В случае домашних машинок без внешних ntp-серверов это единственный
более-менее приемлемый способ поддерживать системные часы. Если верить
докам на hwclock, величина убегания цмосовских часов более-менее постоянна,
так что и бороться с этим тоже можно... Но тогда встает во весь рост вопрос
DST. Наверное, можно где-либо сохранять последнюю использовавшуюся таймзону,
и, с одной стороны, при апдейте glibc-timezones копировать в /etc/localtime
нужный файлик (по правилам config(noreplace)), а с другой, при "перещелке"
DST переводить соответственно хардварные часы. Переводить их нужно, потому
что использоваться это вся конструкция (часы не в GMT, отсутствие NTP) будет
преимущественно на дуалбутных домашних машинках, а Windows (TM) часы
переводит. Ну, в общих чертах вот так вот, но но на оформление этого всего
аккуратно меня сейчас не хватит.




Подробная информация о списке рассылки Sisyphus