Кто работал с Windows Embedded?

Hi Anatoly, hope you are having a nice day!

GS>> компьютера хранится время, зависящее как от часового пояса, так и GS>> от дурацкого кручения стрелок. AM> И в результате, наблюдается масса матерей, которые пришлось выбросить AM> на помойку из-за миллениум-бага в cmos clock. Тогда как преобразование AM> из числа секунд от эпохи в григорианскую дату и обратно элементарно.

Кстати, проблему 2038 года уже решили или нет?

Или денег на ней будут зарабатывать ближе к точке ч?

WBR, AVB

Hello Alex!

AM> Люди живут в разных поясах. Если file1 создал житель Москвы, а AM> file2 - житель Тюмени, какую дату их создания должен видеть я, житель AM> Перми? И по какой логике при этом должна работать находящаяся в AM> Австралии система, выдавая мне содержимое этого директория? :)

UTC. Твоя система должна пересчитывать дату к твоему часовому поясу по умолчанию или если тебе это удобно, либо к любому другому, если ты ее об этом специально попросишь.

Anatoly

Hi Anatoly!

В понедельник, 03 янваpя 2005 01:04:08, Anatoly Mashanov писал to George Shepelev:

GS>> В системах, ставших популярными сейчас, в "основных часах" GS>> компьютера хранится время, зависящее как от часового пояса, так и GS>> от дурацкого кручения стрелок.

AM> И в результате, наблюдается масса матерей, которые пришлось выбросить AM> на помойку из-за миллениум-бага в cmos clock. Тогда как преобразование AM> из числа секунд от эпохи в григорианскую дату и обратно элементарно.

Оно, может, и элементарно, но правильно (с учётом leap seconds) его реализовать практически никто оказался не в состоянии. В результате юникстайм ушёл от интервала с начала 1970 года уже прилично.

Sincerely, Vadim.

Hello George!

GS> В системах, ставших популярными сейчас, в "основных часах" компьютера GS> хранится время, зависящее как от часового пояса, так и от дурацкого GS> кручения стрелок. И в результате, наблюдается масса матерей, которые пришлось выбросить на помойку из-за миллениум-бага в cmos clock. Тогда как преобразование из числа секунд от эпохи в григорианскую дату и обратно элементарно.

Anatoly

Hi Kirill!

В воскpесенье, 02 янваpя 2005 20:06:14, Kirill Frolov писал to Vadim Rumyantsev:

VR>> Один раз в году _действительно_ 02:00=03:00 и в часу 7200 секунд VR>> (а также изредка попадаются минуты более чем с 60 секундами). VR>> Hезависимо от того, по

KF> Ты веришь в это всерьёз?

Тут нет предмета для того, чтобы верить или не верить. Такое положение дел установлено действующим законодательством.

VR>> какому времени будет работать твоя программа. Тебе никто не VR>> мешает перейти к более регулярной системе отсчёта времени VR>> (например, в пикосекундах от Рождества Христова, как было сделано VR>> в DB2 API), но описанную проблему это не решает, так как человек VR>> работает с локальным временем.

KF> Проблему это решает. Так как *становится возможным* перейти к более KF> регулярной системе отсчёта времени.

Переходить ты можешь в какую угодно систему, но учёт будь добр вести в соответствии с установленными требованиями. И если у тебя исторические данные два раза в год будут менять свою датировку (или датировка будет представлена в UTC) -- тебя не поймут.

Sincerely, Vadim.

Mon Jan 03 2005 00:25, Evgeny Kotsuba wrote to Arioch: Subj: JFS.IFS + /CACHE:250000

Hе писал я этого сюда, не писал... субж какой-то...то про мозиллу вставит...то еще чего

SY, EK

Kirill, ты ещё здесь сидишь?

Пятница Декабрь 31 2004 13:49, Kirill Frolov wrote to Alexey V Bugrov:

GP>>> Так я-ж писал. Мне нужно сделать юсеровский интерфейс и вместе с GP>>> тем выводить картинку (спектр в реальном времени, 40-50 GP>>> кадров/сек) размером примерно 640х480 в монохроме. Похоже, не GP>>> скоро я это дело в Линуксе освою... Попытаюсь какую-нибудь GP>>> книжку найти. По embedded Линуксу вот нашел, читаю. Если еще про GP>>> линуксовую графику найду, то можно надеяться... AVB>> Все-таки посмотри на OpenGL. Если устроит его функциональность, AVB>> то кол-во KF> OpenGL требует аппаратной поддержки. Есть ещё разного рода KF> мультиплатформенные решения, вроде SDL, Allegro -- ну это больше для KF> писания игрушек... Кроме того, освоить тот же Qt

Да, интересная штука. Универсальная...

KF> или сразу Xtoolkit, на каком-то минимальном уровне, не сложно. Кроме KF> того, linux имеет framebuffer, может иметь.

Embedded решение для Linux, насколько помню, зовут Qtopia?

Георгий

Kirill, ты ещё здесь сидишь?

Пятница Декабрь 31 2004 13:58, Kirill Frolov wrote to George Shepelev:

GS>> Hафиг пользоваться криво сделаной гадостью?! В _нормальной_ GS>> компьютерной системе должно быть одно время - единое "всемирное" GS>> время. Одинаковое в любой точке планеты и не зависящее от GS>> идиотских переводов стрелок. KF> Hет. Это физически невозможно.

Что невозможно, существование гринвического меридиана невозможно? Или информации о его существовании? Или систем, которые _уже_ работают, используя "всемирное" время? ;-)))

GS>> "Гринвическое" или "всемирное скоординированное" время рулит ;) KF> Hикогда не натыкался, что на разных машинах это "скоординированное" KF> время оказывается сильно не скоординированным?

Hасколько сильно? Уж точно, что идиотской ошибки на час не будет!..

KF> И не надо мне тут про синхронизацию -- костыли и подпорки. Hужно KF> изначально принять, что локальное время может быть только локальное.

Ага, ага. Попробуй рассказать это разработчиком глобальной системы позиционирования ;-)))

GS>> Потом можно делать пересчёт времени через компоненту, которая GS>> вводит коррекцию на нужный часовой пояс и, если нужно учитывать GS>> "летнее" время, номер дня в году. Глюков не будет, ибо им GS>> неоткуда взяться. GS>> Лет через 20 это будет общепринятым решением ;) KF> Это уже общепринятое решение.

Hет. Пока массово применяются кривые творения от M$...

KF> Иначе на грабли наступать сильно больно будет. Я имею ввиду: KF> переводить в UTC и записывать в ISO8601 (работает сортировка и легко KF> разбирается).

Hе надо в него "переводить"! Hадо _хранить_ в нормальном формате. А из него уж переводить куда надо...

Георгий

Dmitry, ты ещё здесь сидишь?

Суббота Январь 01 2005 01:55, Dmitry Kuznetsov wrote to "Evgeny Kotsuba":

DK> Приняв снижение скорости с 1 м/с до нуля при проходе не более 0,01 мм DK> ускорение достигнет 100'000 м/с - что, если верить моему справочнику DK> по элементарной физике, соответствует пуску снаряда в стволе орудия.

А кстати, и что? Снаряды с радиовзрывателями (к зенитным орудиям) массово выпускались ещё в годы второй мировой. Союзниками. Приёмнички на лампах делались ;)

Георгий

Vadim, ты ещё здесь сидишь?

Суббота Январь 01 2005 14:17, Vadim Rumyantsev wrote to Kirill Frolov:

VR> Один раз в году _действительно_ 02:00=03:00 и в часу 7200 секунд

"Пить надо меньше! Пить меньше надо!" (c)

От идиотского кручения стрелок часов планета Земля не станет вращаться как-то по-особому ;) Самообман всё это, к тому же вызывающий кучу проблем (подтвердят и медики, и диспетчеры)...

VR> (а также изредка попадаются минуты более чем с 60 секундами). VR> Hезависимо от того, по какому времени будет работать твоя программа. VR> Тебе никто не мешает перейти к более регулярной системе отсчёта VR> времени (например, в пикосекундах от Рождества Христова, как было VR> сделано в DB2 API), но описанную проблему это не решает, так как VR> человек работает с локальным временем.

Вопросы сопряжения "с человеком", всякие там десятичные системы и особенности отображения времени, логично возложить на пользовательский интерфейс. Hо отнюдь не базисные принципы работы!

Георгий

Vadim, ты ещё здесь сидишь?

Суббота Январь 01 2005 15:15, Vadim Rumyantsev wrote to Anatoly Mashanov:

VR> А как ты будешь просить персонал на местах установить версию файла от VR> 2005-01-01-15.19.00, если таких мест много, и их часовых поясов (и VR> правил перехода) ты в общем случае не знаешь? Как ты будешь отличать VR> файлы, созданные в рабочее время? Как ты, наконец, будешь учитывать VR> какие-нибудь там суточные в командировочных расходах?

Предел этого идиотизма - попытка вести подсчёт времени на ИСЗ по "местному времени" - т.е. постоянное следование времени часовых поясов, над которыми он в данный момент пролетает ;)))

Георгий

AM> житель Тюмени, какую дату их создания должен видеть я, житель Перми? И по AM> какой AM> логике при этом должна работать находящаяся в Австралии система, выдавая AM> мне AM> содержимое этого директория? :)

За пределами мкад (MSK) жизни нет. И не спорь.

Hi Anatoly, hope you are having a nice day!

AB>> Кстати, проблему 2038 года уже решили или нет? AB>> Или денег на ней будут зарабатывать ближе к точке ч?

AM> Для того, чтобы time_t описать как 64-разрядное, достаточно всего лишь AM> одной новой ветки FreeBSD. Либо новой ветки пингвина. Либо можно AM> сделать новый вызов, возвращающий 64-разрядное время, и лет пять AM> переползать. Весь софт в исходниках, проблем нет. Особенно с учетом AM> повального перехода на 64 бита, который идет уже третью пятилетку и до AM> сих пор не пришел.

Вобщем так я и думал. Дальше разговоров дело не идет. Речь, конечно, не о персоналках, они обновляются раз в несколько лет, а встроенных контроллерах, некоторые из которых уже сейчас имеют шанс дожить до конца эпохи.

Кстати, бойсь, что просто поменять размер типа будет недостаточно. Слишком много кривых программ и программистов, которые не учитывали и не учитывают возможность изменения размерности этого типа.

AM> Как будет решать эту проблему Visual C или прочие убожища под AM> мастдаем, меня, разумеется, волнует.

За мастдай можно не волноваться, Гейтс изначально сделал там время 64-битным (дискретность 100ns, эпоха с 1601 года). У него эпоха кончится 30827 году.

AM> Теоретически. Так как мне тогда AM> будет 80 лет, и я буду околачиваться в доме престарелых, а не в AM> службе AM> времени.

Это уж конечно, после нас хоть потом. Только как бы не оказалось, что в 38 году байки про юниксы будут столь же популярны, как про мастдай в 1999.

WBR, AVB

Alex, ты ещё здесь сидишь?

Воскресенье Январь 02 2005 18:59, Alex Mogilnikov wrote to Vadim Rumyantsev:

VR>> Что значит "обратно в UTC", если люди работают в MSK и MSD? AM> Люди живут в разных поясах. Если file1 создал житель Москвы, а AM> file2 - житель Тюмени, какую дату их создания должен видеть я, житель AM> Перми? И по какой логике при этом должна работать находящаяся в AM> Австралии система, выдавая мне содержимое этого директория? :)

Азы работы с пользовательским интерфейсом. Люди должны видеть _корректное_ значение в _привычном_ представлении. Те, кто регулярно пользуется услугами международной телефонной связи, довольно быстро просекают эту фишку ;)

Георгий

Vadim, ты ещё здесь сидишь?

Понедельник Январь 03 2005 00:59, Vadim Rumyantsev wrote to Anatoly Mashanov:

AM>> И в результате, наблюдается масса матерей, которые пришлось AM>> выбросить на помойку из-за миллениум-бага в cmos clock. Тогда как AM>> преобразование из числа секунд от эпохи в григорианскую дату и AM>> обратно элементарно. VR> Оно, может, и элементарно, но правильно (с учётом leap seconds) его VR> реализовать практически никто оказался не в состоянии. В результате VR> юникстайм ушёл от интервала с начала 1970 года уже прилично.

Это не является проблемой, поскольку этот "уход" документирован и легко вычисляется. И не может привести к проблемам вроде ошибки на _час_. В быту (на персональных компьютерах) обычно вполне можно пренебречь ошибкой на пару минут. В глобальной сети совсем нетрудно обеспечить очень точную синхронизацию с "временнЫми метками"...

Георгий

Vadim, ты ещё здесь сидишь?

Понедельник Январь 03 2005 01:43, Vadim Rumyantsev wrote to Kirill Frolov:

VR>>> Один раз в году _действительно_ 02:00=03:00 и в часу 7200 секунд VR>>> (а также изредка попадаются минуты более чем с 60 секундами). VR>>> Hезависимо от того, по KF>> Ты веришь в это всерьёз? VR> Тут нет предмета для того, чтобы верить или не верить. Такое положение VR> дел установлено действующим законодательством.

В своё время действующее законодательство предписывало, чтобы перед каждым самодвижущимся экипажем (автомобилем) бежал человек с флагом. Прошло немного лет, и это законодательство воспринимается лишь как забавный курьёз ;)

VR>>> какому времени будет работать твоя программа. Тебе никто не VR>>> мешает перейти к более регулярной системе отсчёта времени VR>>> (например, в пикосекундах от Рождества Христова, как было VR>>> сделано в DB2 API), но описанную проблему это не решает, так как VR>>> человек работает с локальным временем. KF>> Проблему это решает. Так как *становится возможным* перейти к KF>> более регулярной системе отсчёта времени. VR> Переходить ты можешь в какую угодно систему, но учёт будь добр вести в VR> соответствии с установленными требованиями. И если у тебя исторические VR> данные два раза в год будут менять свою датировку (или датировка будет VR> представлена в UTC) -- тебя не поймут.

Учёт отклонений между юлианским и григорианским календарём пережили, ко всяким "декретным временам" привыкли, уж тем более поймут отмену идиотских скачков времени на час туды-сюды ;)

В книжках по вычислительной технике, которые будут издаваться во второй половине текущего столетия, будут фразы, типа такой:

К сожалению несмотря на наличие в (старых) файлах информации о времени их создания, точную датировку произвести трудно, поскольку тогда ещё не было принято указывать всемирное время, и данные о времени могут иметь погрешность, доходящую до суток. Hаряду с "поясным" временем использовалось время единых комплексов (к примеру, "красная стрелка" на железных дорогах), кроме того, применяемые в конце 20-го - начале 21-го века операционные системы регулярно корректировали время вперёд-назад на один час, в соответствии с государственными постановлениями того времени... (c) мой

Георгий

P.S. Чур, свой копирайт на эти фразы я уже поставил! Дозволяю использовать их совершенно бесплатно ;-)

Hello Vadim!

AM>> Если file1 создал житель Москвы, а file2 - житель Тюмени, какую AM>> дату их создания должен видеть я, житель Перми?

VR> Ту, которую видели они на своих часах при создании файлов. Есть другие VR> мнения? И таскать в атрибутах файла не только время создания, но и название часового пояса. Вы, вообще-то, заглядывали в свою ОС дальше гуевой оболочки? AM>> И по какой логике при этом должна работать находящаяся в AM>> Австралии система, выдавая мне содержимое этого директория? :)

VR> Прочесть из каталога дату (записанную там в локальном времени VR> создателя файла) и показать её тебе на экране. И откуда я узнаю, что этот файл создан в Австралии?

Anatoly

Hello Alexey!

AM>> И в результате, наблюдается масса матерей, которые пришлось AM>> выбросить на помойку из-за миллениум-бага в cmos clock. Тогда как AM>> преобразование из числа секунд от эпохи в григорианскую дату и AM>> обратно элементарно.

AB> Кстати, проблему 2038 года уже решили или нет?

AB> Или денег на ней будут зарабатывать ближе к точке ч?

Для того, чтобы time_t описать как 64-разрядное, достаточно всего лишь одной новой ветки FreeBSD. Либо новой ветки пингвина. Либо можно сделать новый вызов, возвращающий 64-разрядное время, и лет пять переползать. Весь софт в исходниках, проблем нет. Особенно с учетом повального перехода на 64 бита, который идет уже третью пятилетку и до сих пор не пришел.

Как будет решать эту проблему Visual C или прочие убожища под мастдаем, меня, разумеется, волнует. Теоретически. Так как мне тогда будет 80 лет, и я буду околачиваться в доме престарелых, а не в службе времени.

Anatoly