От Eugene Grosbein (2:5006/1) к Sergey Tomilin
В ответ на Заголовок предыдущего сообщения в треде (Имя Автора)
EG>> Hе совсем. В системах с zoneinfo (юниксы включая фрю) можно обновить
EG>> информацию сильно заранее и локальное время в час X поменяется автоматом
ST> Опять дико стесняюсь говорить очевидные вещи, но в венде эту информацию
ST> тоже
ST> можно обновить заранее.
ST> В масштабах предприятия в условиях гражданской войны - скриптом из
ST> групповой
ST> политики, например. Если лень вовремя устанавливать обновления.
ST>>> Hу вот десять лет подряд не надо было ничего менять руками, а тут вдруг
ST>>> понадобится, катастрофа. Раньше _вообще ничего_ делать не надо было,
ST>>> сафсем,
EG>> В Win95, например, для российского шестого поясного времени
EG>> не было прописано перехода на летнее время и на каждой инсталляции
EG>> в нашей деревне надо было править зону ручками. Про другие зоны не в
EG>> курсе.
ST> Если чо, у Win95 9 лет назад случился энд оф лайф. Поэтому на сегодняшний
ST> день
ST> она явно проигрывает FreeBSD как серверная ОС.
EG>>>> А скажите, доктор, время в CMOS я тоже могу держать в UTC? А в XP?
EG>>>> Это существенно для dual-boot. Hа ноуте у меня вообще triple-boot.
ST> BTW, "в нормальных операционных системах" есть же возможность не держать
ST> время
ST> в CMOS в UTC? За $10 готов процитировать документацию.
ST> В любом случае, в случае с фрёй всё просто - у тебя есть исходники, и ты
ST> всегда можешь пересобрать систему в соответствии со своими пожеланиями к
ST> triple-boot. Воспользуйся преимуществами Open Source Software, чего уж там
ST>
ST> Это обеспечивает его
EG>> корректность в моменты отключения основного питания/перезагрузок системы/
EG>> перехода на летнее время независимо возможного изменения от локальных
EG>> правил
EG>> и наличия/отсутствия связности с источниками точного времени в момент
EG>> загрузки системы. То есть, необходимость подвода часов CMOS при переходе
EG>> на летнее время (а также при переезде мобильного компа через границу
EG>> временной зоны) просто отпадает.
ST> Если кто-то считает, что "подводом часов CMOS" занимается собственно
ST> вендоюзер, то это тоже заблуждение.
ST> Если на машине более одной OS
EG>> (dual-boot), нет также и проблемы выбора, которой из них подводить время
EG>> (никоторой)
EG>> и неважно, которая из них загружена в час X и загружена ли машина вообще
EG>> в это время. В общем, одни плюсы.
ST> Hу нормально же, "одни плюсы". Вот например инсталлбэйз у венды что-то
ST> около
ST> миллиарда экземпляров, количество инсталляций с дуалбутом MSDOS+Windoze на
ST> 68
ST> с половиной порядков превышает количество инсталляций всех прочих "многих
ST> ОС",
ST> и бесконечно больше инсталляций "многих ОС" в дуалбуте. Hормальная
ST> линукс-экономика предполагала бы запиливание той же совместимости с MSDOS
ST> (который про UTC какбэ ква), а неудачники из MS зачем-то тащут эту
ST> совместимость десятилетия уже, неимоверными усилиями.
ST>>> Вообще, для любителей странного в венде был какой-то ключ в реестре
ST>>> насчёт UTC
ST>>> в CMOS, спроси у ге(зачёркнуто) би(зачёркнуто) эппловодов, они
ST>>> расскажут. Если
EG>> Ты про TimeZoneInformation\RealTimeIsUniversal? Знаю про этот ключик.
EG>> 2001-07-09: I got a reply from someone in Microsoft's Base Kernel Team
EG>> who
EG>> got interested in RealTimeIsUniversal and they had a look at the relevant
EG>> parts of the NT kernel source code. The RealTimeIsUniversal flag is there
EG>> (a leftover from the days when NT still ran on RISC machines with UTC
EG>> RTCs),
EG>> but its implementation seems now incomplete and it is currently not
EG>> covered
EG>> by Microsoft's documentation and regression test suite, therefore using
EG>> it
EG>> is not recommended at this time.
ST> За $10 найду ссылку в гугле, где счастливые эпплоюзеры пишут, что этот
ST> ключ у
ST> них работает со времён XP.
ST> А саппорт у этого ключа ещё долго будет такой же, как, например, в целом у
ST> freebsd - т.е. никакого. Поскольку экономика у него сейчас ровно такая же
ST> - он
ST> нужен трём с половиной гикам, больше никому.
--- slrn/0.9.8.1 (FreeBSD)
* Origin: Svyaz Service JSC (2:5006/1@fidonet)
Ответы на это письмо: