Comments 70
3.5 можно сменить быстрее)
UFO just landed and posted this here
Хорошо ещё, что число дней в году до 256 не сократили.
Самым правильным вариантом было бы сокращать номер года. Всё равно древний FAT до 2107 года не доживёт, можно было бы лишний бит высвободить, передвинув крайний срок на 2043-й год.
Всё равно древний FAT до 2107 года не доживёт, можно было бы лишний бит высвободить, передвинув крайний срок на 2043-й год.
а потом найдётся древний девайс, у которого давным давно вместо харда стоит эмулятор на 100мегабайт да и управляющий софт запущен в виртуалке… но эта зараза помрет в 43 году
так что надо гнать от себя такие мысли в стиле 'да всёравно помрет'… вспомните сколько раз ATA спецификацию апдейтили по причине 'да 300мб хватит всем, нет 3гб хватит, ну 150гб полюбому...'
Древний это какой?
ФАТ12/16, ФАТ32?
Первые используются на малых разделах (обычно с них стартуют всякие разные хитрые софтины), второй — умирать не собирается.
А в 2107 древними будут все нынешние версии разделов.
ФАТ12/16, ФАТ32?
Первые используются на малых разделах (обычно с них стартуют всякие разные хитрые софтины), второй — умирать не собирается.
А в 2107 древними будут все нынешние версии разделов.
а потом найдётся древний девайс, у которого давным давно вместо харда стоит эмулятор на 100мегабайт
А чего его искать, даже далеко ходить не надо.
в биосе сократили номер года до двух цифр, что привело к проблеме 2000 =)
что привело к проблеме 2000 =)
А «проблема 2000» была придумана дабы попилить чьи-нибудь бюджеты :) Ибо ужасы последствий были сильно-пресильно преувеличены.
сам участвовал в борьбе с 2к в двух софтинах.
в одной решилось всё довольно просто, а вот вторая была бухгалтерская система, а там отчетный период не совпадает с годом, то есть надо было чтоб и 1999 и 2000 существовали одновременно. софт, естественно, закрытый.
не помню уж как, но решили.
в одной решилось всё довольно просто, а вот вторая была бухгалтерская система, а там отчетный период не совпадает с годом, то есть надо было чтоб и 1999 и 2000 существовали одновременно. софт, естественно, закрытый.
не помню уж как, но решили.
Что произошло бы, не справится вы с проблемой? Может быть прогремел ядерный взрыв? Или вся техника взбунтовалась и устроила джихад человечеству? Или деньги со счетов убежали в неизвестном направлении? Самолёты упали, корабли утонули?
:)
Нет. Всего лишь отчёт криво сформировался. А разрекламировано было, словно все выше перечисленное — разминка перед реальными последствиями.
Понятно, что проблема была. Каждый день возникают какие-то проблемы. Вон в том году meltdown открыли. Тоже вроде бы проблема. Вроде бы даже очень серьезная. Вроде бы даже шумиха была. Но по накалу страстей до 2k0 не дотягивает вообще никак
Нет. Всего лишь отчёт криво сформировался.
Простите, вы когда-нибудь с налоговой дело имели?
Или кроме того, чтобы получить зарплату вас вообще никогда не интересовало, как бизнес зарабатывает деньги и откуда они берутся?
Я нисколько не умаляю ваших заслуг. И проблема, безусловно, была (о чем я и написал). Я всего лишь написал о сильно раздутой шумихе вокруг данной проблемы. Вы может забыли, но по ТВ, чуть ли не криминальные сюжеты крутили на тему. Вплоть до падений самолётов и взрывов реакторов.
Ну шумиху раздували, потому что проблема двухтысячного года — не бизнес требование, а техническая проблема. Обычно под решение технических проблем бизнес выделяет деньги с трудом, потому что «и так же работает, как-нить пронесет, а вот мне для клиента вот тут нужно новую кнопочку, вот это мегасрочно и сейчас».
Поэтому да, все кто были в теме, раздували опасность, чтобы нормально выделили денег и наконец пообновляли и софт и железо.
Насчет взрывов реакторов — ну а мало ли что. Вы можете гарантировать, что система управления автоматическим ответом на ядерный удар, при переходе с 99 года на 00 не заглючит, ее мониторинг не посчитает, что все вокруг перестало отвечать и не бахнет?
Ну и если не про ядерное.
Сколько систем было настроено, оставлено без мониторинга и забыто? Не забывайте, что зарубежом «умные дома» были уже тогда, даже в фильме «Хакеры» 95 года, взломав управление домом можно было писать светом в окошках квартир удаленно.
Поэтому да, все кто были в теме, раздували опасность, чтобы нормально выделили денег и наконец пообновляли и софт и железо.
Насчет взрывов реакторов — ну а мало ли что. Вы можете гарантировать, что система управления автоматическим ответом на ядерный удар, при переходе с 99 года на 00 не заглючит, ее мониторинг не посчитает, что все вокруг перестало отвечать и не бахнет?
Ну и если не про ядерное.
Сколько систем было настроено, оставлено без мониторинга и забыто? Не забывайте, что зарубежом «умные дома» были уже тогда, даже в фильме «Хакеры» 95 года, взломав управление домом можно было писать светом в окошках квартир удаленно.
Ну шумиху раздували, потому что проблема двухтысячного года — не бизнес требование, а техническая проблема.
Ключевое здесь: рядовая проблема. Каких миллионы. Например, meltdown пресловутый, на мой взгляд посерьезнее будет. Но проблему 2000 освещали по всем новостям, по всем каналам рассказывали ужасы и т.д. Меня это коробит исключительно несоответствием последствий раздуваемому шуму.
Обычно под решение технических проблем бизнес выделяет деньги с трудом,
Это какой бизнес? ШаражМонтажКонтора из 2 с половиной человек? Не страшно. Если крупный бизнес не понимает, что нужно поддерживать в том числе инфраструктуру — такого не видел. Наверно потому что такой «бизнес» не жизнеспособен.
Насчет взрывов реакторов — ну а мало ли что. Вы можете гарантировать, что система управления автоматическим ответом на ядерный удар
Могу. К подобного рода системам заведомо применяются завышенные требования по безопасности. И такие системы априори должны быть спроектированы так, что их ничего не заглючит. А если и заглючит, то не критично. Это как с самолетом. Молния может вышибить что угодно. Но нарушить нормальный полет не имеет права. Если самолет спроектирован иначе — это хреновый самолет, который не должен летать.… А не исправлять судорожно ошибку 2000, потому что щас в Землю воткнется с эшелона.
Не забывайте, что зарубежом «умные дома» были уже тогда
Да ну? А мне кажется, что тогда тупо не было подходящей элементной базы. Я что-то не припомню вайфаев в 95м году и прочих прелестей, так необходимых для создания умного дома.
даже в фильме «Хакеры»
В фильме «Хакеры» не сомневаюсь, что были.
Еще раз: Да, проблема была. Крохотная техническая проблемка. Из-за которой, реально, могли отчетики для налоговой неправильно формироваться (да, это — крохотная проблема. Не надо раздувать. Я 19 лет занимаюсь автоматизацией этих самых отчетиков. За неправильный отчет вам ни штраф не вкатят, ни казнят. Просто сдадите уточненку и все.). Но раздута она была так, будто на Землю несется метеорит, который уничтожит планету. Это — не правильно.
1975 году шотландская Pico Electronics разработала первый специализированный стандарт управления домашними устройствами: X10. Для передачи сигналов использовались обычная электрическая сеть. Кроме того, создатели предусмотрели беспроводное управление на радиочастоте 433 МГц (в США 310 МГц).
Наиболее известными были «Дом с кнопками» (Push-Button Manor, 1950) американского инженера Эмиля Матиаса, где расположенные по всему дому кнопки автоматизировали выполнение основных бытовых задач, и компьютер Echo IV (1966) американского инженера Джеймса Сазерленда, который мог регулировать работу домашней климатической техники, включать и выключать некоторые приборы и распечатывать списки покупок.
Это какой бизнес? ШаражМонтажКонтора из 2 с половиной человек?
Простите, вы вообще в курсе на каком уровне была компьютеризация в 2000 году? Сколько вообще контор вели бухгалтерию на компьютере?
Те конторы, которые в то время вели учет на компе — были далеко не шараш конторы. Но решения, предлагаемые на рынке были далеки от того, что сейчас. Не в последнюю очередь еще и потому, что уровень разработки и подход к ней был не очень.
Например одна из популярных баз FoxPro — у нее была та же проблема. А сколько было написано систем на базе FoxPro?
19 лет — это видимо вы только начали уже после того, как эта проблема ушла. Проблему ж решали не в 2000, а в середине-конце девяностых. И вот в то время, я практически уверен, что вы не могли работать в крупной конторе, чтобы понять масштаб проблемы.
Опишу один из случаев. Крупная контора, автоматизировала свой склад, вложив несколько сот тысяч долларов. Через 5-7 лет выясняется, что существует проблема 2000 года, и нужно вложить еще столько же, чтобы купить другую систему, написанную с нуля.
Потому что те, кто писали систему 7 лет назад уже не поддерживают DOS и вообще, ключевые люди разбежались делать свои «стартапы». Пришлось вложить еще полмиллиона долларов.
Проблему ж решали не в 2000, а в середине-конце девяностых.Работал я тогда в небезызвестной на тот момент конторе, пишущей бухсофт. Так все «лечение проблемы» было абсолютно трехкопеечным, но выкатили его в 1999, чуть не в конце (специально ждали), что привело к активизации огромного числа давно уже мертвых, как казалось, клиентов. Ну и на таких наварились от души, не помню уже достоверно, но вроде бы даже в оракловом стиле — кто в теме ораклового БД прайсинга, оценит размах :)
Заголовок спойлера
И да, естественный вопрос сразу всплыл: а как же так вышло, что клиенты, давно не платящие за поддержку, сдавали постоянно обновляемые формы отчетности?
Формы отчетности поправить непроблема усилиями местных DBA.
А вот движок базы изменить — это совсем другая задача.
Опять же, был софт, который рассчитывал на BIOS дату, а BIOS у компов 7-8-летней давности мог не поддерживать 4 цифры.
Я совершенно согласен, что проблему раздули и наварились. Но вот говорить, что если бы ее не решать, НИЧЕГО бы серьезного не случилось — это совершенно не правильно. Могло бы случиться много чего.
А вот движок базы изменить — это совсем другая задача.
Опять же, был софт, который рассчитывал на BIOS дату, а BIOS у компов 7-8-летней давности мог не поддерживать 4 цифры.
Я совершенно согласен, что проблему раздули и наварились. Но вот говорить, что если бы ее не решать, НИЧЕГО бы серьезного не случилось — это совершенно не правильно. Могло бы случиться много чего.
Формы отчетности поправить непроблема усилиями местных DBAДа бросьте, DBA тут совсем не при делах. Ну разве что это такой DBA, что по совместительству в бухучете разбирается на уровне минимум очень хорошего первого зама главбуха, зная все тонкости учета ОС/зарплаты/отчислений/фондов и еще 100500 мелких, но множественных специфических закорюк, прописанных в еще большем количестве противоречачих друг другу нормативных (и ненормативных во всех смыслах) документах, постановлениях, решениях, а задно и форумных и журнальных размышлизмов на тему. Скорее уж все эти отчетные формы где-то по-тихому, но масштабно успешно распространялись между всеми заинтересованными лицами, а к ним еще и все апгрейдные скрипты (без них никак).
Но вот говорить, что если бы ее не решать, НИЧЕГО бы серьезного не случилосьТак я ничего подобного и не утверждал.
кстати подтвержу.
например в Парус проблема была.
очень серьезная система в те времена
например в Парус проблема была.
очень серьезная система в те времена
Простите, вы вообще в курсе на каком уровне была компьютеризация в 2000 году?
Вообще, в курсе.
Сколько вообще контор вели бухгалтерию на компьютере?
До фига. Включая самые крохотулечные.
Те конторы, которые в то время вели учет на компе — были далеко не шараш конторы.
Это близко не так. Я бы понял, если бы вы про 95й говорили, но не про 2000. Да и в 95м уже полно контор вело бухучет на компе.
Но решения, предлагаемые на рынке были далеки от того, что сейчас. Не в последнюю очередь еще и потому, что уровень разработки и подход к ней был не очень.
Например, 1С: Предприятие 7.7 было выпущено в 1997году. Используется до сих пор. С глюками там все ровно. Что не так?
Например одна из популярных баз FoxPro — у нее была та же проблема. А сколько было написано систем на базе FoxPro?
FoxPro — это инструмент для ШаражМонтажКонтор. Я верю, что в FoxPro есть проблема 2000. Но что произойдет, в случае, если косяк не исправить?… В худшем случае вшивые отчетики для налоговой будут формироваться неправильно :) И это при том, что FoxPro развивался дольше чем до 2000 года. Т.е Microsoft таки могла поправить косяки в фоксе. И я думаю, правила. Например, я успешно работал с фоксом в 2002 году.
19 лет — это видимо вы только начали уже после того, как эта проблема ушла.
Я прекрасно помню ту шумиху. Очередной раз повторяю: да, действительно. Есть такая проблема. Редкая очень. Например, в 1С начало столетия приходится на 1980 год. И 00 трактуется как 2000. Например, 2 знака можно трактовать как угодно. И реальная проблема вылезет только при попытке посчитать разность дат. Или сравнить даты на больше/меньше. Это ж еще попасть надо на глючные операции.
Я ровно про то, что масштаб шумихи вообще никак не соответствует масштабу проблемы. Да и лечение, честно говоря, не требует миллионов долларов. В отличии, от того же meltdown'а, который многократно серьезнее и вообще никак не освещался по тв.
а в середине-конце девяностых
Да ну бросьте! Шевелиться реально стали в 99м. В 95м даже думать об этом не думали. И потом, ну в самом деле, поменять тип данных и пару операций к нему — ну вообще никак не вселенский масштаб. Да, код надо рефакторить. Но, например, 1С балуется изменением сигнатур методов в своих решениях раз в месяц и ничего. Значит не сложно это делать. Здесь проблема ровно того же порядка.
Крупная контора, автоматизировала свой склад, вложив несколько сот тысяч долларов.
Выглядит как откат. Или как полная некомпетентность руководства.
Потому что те, кто писали систему 7 лет назад уже не поддерживают DOS и вообще, ключевые люди разбежались делать свои «стартапы».
В 2000м использовать DOS? Бояться перейти на винду? Так это проблемы конторы, а не 2000года.
ришлось вложить еще полмиллиона долларов.
Ну так это не проблема 2000. Это проблема конторы, которая забила на процесс поддержки своего ПО. А потом внезапно из-за мелочи клюнул жареный петух.
Да ну бросьте! Шевелиться реально стали в 99м. В 95м даже думать об этом не думали.Если вы не думали — то это не значит, что никто не думал. По поводу 2038года думают и делают уже сейчас… а на дворе — далеко не 2037й год.
В 2000м использовать DOS? Бояться перейти на винду?Нет. Использовать OS/360 и не собираться переходить на винду в принципе. Вот это был настоящий challenge.
Вот все эти системы учёта в разных Citibank'ах и Deutche Bank'ах на коболе, медицинские программы на MUMPSе, системы заказа авиабилетов и прочее — вот где основные проблемы и затраты случились.
А отчётики в FoxPro — действитлеьно мелочь на этом фоне.
То, что вас проблема зацепила лишь самым краешком и вы вообще не видели систем где она, в принципе, была серьёзной — ваше счастье.
В отличии, от того же meltdown'а, который многократно серьезнее и вообще никак не освещался по тв.Meltdown принципиально отличается от «проблемы 2000го года» или преслувутого FDIVа тем, что никак, ну вот совсем никак не проявляет себя в случае отсуствия злоумышленника.
Так что это проблема совсем другого рода.
Если вы не думали — то это не значит, что никто не думал. По поводу 2038года думают и делают уже сейчас…
Я про то, что о проблеме 2000 заговорили во всех источниках именно в 99м году. До — даже термина такого не было. Кто там что делал внутри команд разработчиков — не знаю. И то, что в линухе задумались о проблеме 2038 именно сейчас — это как раз здравый подход. Начать решать заранее. До того, как петух клевать начнет.
Нет. Использовать OS/360 и не собираться переходить на винду в принципе. Вот это был настоящий challenge.
Поделитесь сложностями. Использовать legacy-систему и не собираться с нее переходить — звучит именно как челлендж.
вот где основные проблемы и затраты случились.
Во всех этих ситибанках и прочих массачусетских клиниках видимо есть исходники сих творений.
В таком случае упорно не вижу, где ж там миллионы долларов?
Meltdown принципиально отличается от «проблемы 2000го года» или преслувутого FDIVа тем, что никак, ну вот совсем никак не проявляет себя в случае отсуствия злоумышленника.
Равно как проблема 2000 никак себя не проявляет, пока вы не начинаете интерпретировать даты, что делается далеко не всегда.
Подборочка, из-за значения переменной может стать всё плохо…
Истребители F-22 не смогли пересечь 180 меридиан
При попытке перегнать истребители F-22 «своим ходом» с Гавайских островов на базу ВВС Kadena на японском острове Окинава программный сбой в навигационном обеспечении вынудил пилотов развернуться и возвратиться туда, откуда вылетели. Теперь стала известна истинная природа этой «навигационной аномалии».
Как выяснилось, истребители не сумели преодолеть так называемую линию перемены дат — условную линию, по разные стороны которой местное время одно и то же (с точностью до часового пояса), но календарные даты различаются на одни сутки. Линия перемены дат проходит по меридиану 180 градусов с отдельными отклонениями.
Перемена дат осуществляется (и вообще имеет смысл) лишь при использовании местного времени. При пересечении линии перемены дат необходимо либо прибавлять, либо вычитать одни сутки – в зависимости от того, в каком направлении осуществляется движение. По всей видимости, этот парадокс Земного шара, осознанный еще участниками экспедиции Магеллана, был позабыт разработчиками F-22 Raptor.
Последствия такой забывчивости оказались весьма ощутимыми. У истребителей в полете вышли из строя топливная и навигационная системы, а также частично связь.
Лишь одному пилоту удалось связаться с экспертами разработчика (компании Lockheed Martin). Несколько пилотов попытались перезагрузить ПО истребителя в полете.
«Победить» ошибку не удалось, однако сами истребители и их пилоты уцелели, что в подобной ситуации следует считать несомненной удачей. Возвращение на Гавайские острова потребовало дополнительной дозаправки в воздухе.
Впоследствии «навигационную аномалию» удалось исправить, и F-22 всё-таки прибыли на авиабазу назначения.
Как выяснилось, истребители не сумели преодолеть так называемую линию перемены дат — условную линию, по разные стороны которой местное время одно и то же (с точностью до часового пояса), но календарные даты различаются на одни сутки. Линия перемены дат проходит по меридиану 180 градусов с отдельными отклонениями.
Перемена дат осуществляется (и вообще имеет смысл) лишь при использовании местного времени. При пересечении линии перемены дат необходимо либо прибавлять, либо вычитать одни сутки – в зависимости от того, в каком направлении осуществляется движение. По всей видимости, этот парадокс Земного шара, осознанный еще участниками экспедиции Магеллана, был позабыт разработчиками F-22 Raptor.
Последствия такой забывчивости оказались весьма ощутимыми. У истребителей в полете вышли из строя топливная и навигационная системы, а также частично связь.
Лишь одному пилоту удалось связаться с экспертами разработчика (компании Lockheed Martin). Несколько пилотов попытались перезагрузить ПО истребителя в полете.
«Победить» ошибку не удалось, однако сами истребители и их пилоты уцелели, что в подобной ситуации следует считать несомненной удачей. Возвращение на Гавайские острова потребовало дополнительной дозаправки в воздухе.
Впоследствии «навигационную аномалию» удалось исправить, и F-22 всё-таки прибыли на авиабазу назначения.
Об ошибках деления на ноль
Фирма Motorola испытывала новый процессор для автопилота на истребителе в Израиле. Всё было отлажено. Пилоты на испытаниях отправились «огибать рельеф» с севера до юга Израиля. Истребитель прекрасно пролетел на автопилоте над равнинной частью, над горной частью, над долиной реки Иордан и приближался к Мёртвому морю. Однако при подлете к нему неожиданно происходит общий сброс процессора, автопилот выключается на полном ходу, пилоты переходят на ручное управление и сажают истребитель.
Процессор отправили на доработку и тестирование. Все тесты прошли снова без сбоев. Снова начали реальную проверку. Истребитель пролетел над всеми территориями, но при подлете к Мёртвому морю ситуация повторилась: общий сброс, выключение автопилота, ручная посадка.
Длительные тесты не могли выявить никаких изъянов. После продолжительных попыток было найдено, что программы автопилота при вычислении параметров управления по глубоко научным секретным формулам производили деление на значение текущей высоты истребителя над уровнем океана. При подлете к Мёртвому морю высота над уровнем океана становилась нулевой (Мёртвое море расположено ниже уровня океана), и процессор при делении на ноль давал общий сброс. До этого случая никому не приходило в голову, что самолеты могут летать ниже уровня океана…
Процессор отправили на доработку и тестирование. Все тесты прошли снова без сбоев. Снова начали реальную проверку. Истребитель пролетел над всеми территориями, но при подлете к Мёртвому морю ситуация повторилась: общий сброс, выключение автопилота, ручная посадка.
Длительные тесты не могли выявить никаких изъянов. После продолжительных попыток было найдено, что программы автопилота при вычислении параметров управления по глубоко научным секретным формулам производили деление на значение текущей высоты истребителя над уровнем океана. При подлете к Мёртвому морю высота над уровнем океана становилась нулевой (Мёртвое море расположено ниже уровня океана), и процессор при делении на ноль давал общий сброс. До этого случая никому не приходило в голову, что самолеты могут летать ниже уровня океана…
F-16 вверх ногами
Испытания американского истребителя F-16 проводились, понятное дело, в северном полушарии. На заключительном этапе самолет решили проверить где-то в Латинской Америке – с другой стороны экватора. При переводе самолета в режим автопилота он автоматически развернулся «вверх ногами».
У них было 32 бита на дату, если бы не записывали по-отдельности все компоненты даты и времени, а считали бы секунды, то хватило бы как раз примерно до 2107 года, но без пропуска каждой второй секунды.
Не хватило бы, в POSIX так и поступили.
ru.wikipedia.org/wiki/Проблема_2038_года
ru.wikipedia.org/wiki/Проблема_2038_года
Знаковое 32-битное время POSIX начинается где-то в 1901 году и заканчивается в 2038-м.
Время в FAT беззнаковое и начинается в 1980-м, поэтому 32 бит хватило бы где-то до 2110.
а почему не 70-м?
Это DOS, а не Unix
ЕМНИП, дисковая подсистема была заимствована в ДОС-е именно из Юникса. Странно, что не перетянули всё.
ЕМНИП, дисковая подсистема была заимствована в ДОС-е именно из Юникса.Подводит вас память, подводит… Впрочем речь идёт о временах аж до моего (и, возможно, вашего) рождения, 60е годы… так что если специально не копать, то можно и напутать.
Странно, что не перетянули всё.Не могли. PC DOS 1.x — базировался не на Unix, а вовсе даже на CP/M. А та — базоровалась на RT-11. Которая выросла из OS/8. Которая уходит корнями в TOPS-10… Откуда пришли и расширение
EXE и двоеточие для имени диска и многое другое.А вот уже когда разрабатывалась PC DOS 2.0 — она была сделана на основе Unix. Но должна была быть совместимой c PC DOS 1.1, очевидно… отсюда всё и пошло.
Вот тут это всё разбирается.
P.S. Если посмотреть на API MS-DOS 2.0, то можно увидеть, что почти все функции продублированы. Более старые — пришли из TOPS-10, более новые — из Unix. Там же была опция, позволявшая переключать — как задаются опции: через слеш или через минус. Но… не взлетело, в MS DOS 3.0 эту опцию убрали…
Буду краток. CP/M
Вопрос про 1901 год? Потому что тип time_t знаковый. Может хранить не только положительно смещение от 01.01.70, но и отрицательное.
В 1970-ом нуль POSIX time. Но отрицательный диапазон ещё есть.
Вот только на 16-битном процессоре все эти вычисления занимали бы изрядно места, а если учесть, что MS DOS 1.0 должна была поддерживать комптютеры с 16K памяти (причём это и под операционку и под программы)… в общем они такой роскоши себе позволить не могли.
Интереснее другое: если посмотреть на формат файловой системы, то можно обнаружить, что на каждый файл там отводилось по 32 байта — из который куча была «зарезервирована на будущее». Что мешло дату и время писать не в 4 байта, а в 5 или даже 6 байт?
Интереснее другое: если посмотреть на формат файловой системы, то можно обнаружить, что на каждый файл там отводилось по 32 байта — из который куча была «зарезервирована на будущее». Что мешло дату и время писать не в 4 байта, а в 5 или даже 6 байт?
Не доживёт? Ню-ню.
Когда наши разрабы так говорят, я напоминаю им про одну нашу систему. На словах, её хоронили чаще, чем Аллу Пугачёву. Но старушка всё ещё пашет, являясь одной из самых высоконагруженных АС.
Когда наши разрабы так говорят, я напоминаю им про одну нашу систему. На словах, её хоронили чаще, чем Аллу Пугачёву. Но старушка всё ещё пашет, являясь одной из самых высоконагруженных АС.
Неоднократно натыкался на ситуацию, когда при смене дискеты в 5,25" дисководе на PC-клоне «Искра 1030» оглавление новой дискеты перезаписывалось содержимым старой, т.е. файлы портились. Вряд ли дискеты менялись быстрее чем за две секунды, скорее дело в особенностях реализации INT 8.
UFO just landed and posted this here
В файловой системе FAT метки времени тоже хранятся с точностью до двух секунд. Совпадение?
Самая быстрая рука на диком западе :) помню ещё практиковали быстро открывать.и закрывать затвор дисковода на 5“ для чтения битых секторов и это определенно как то работало.
Если разрешение часов 1 секунда, то если подождать от текущего момента до следующий секунды, то ожидание будет длится от 0 до 1 секунды. Т.е. в худшем случае оно будет 0 секунд.
Таким если мы хотим выждать любое гарантировано ненулевое время, то нужно к текущему времени прибавлять минимум 2 секунды.
Это и сейчас актуально, часто пользовался.
Таким если мы хотим выждать любое гарантировано ненулевое время, то нужно к текущему времени прибавлять минимум 2 секунды.
Это и сейчас актуально, часто пользовался.
Не очень понял, что вы имеете в виду, но, очевидно, если «ожидание длится от 0 до 1 секунды», то есть ненулевая вероятность того, что для любого N>0 ожидание между 0 и N будет 0 секунд. Поэтому «прибавить 2 секунды» не работает.
видимо да, не очень поняли
Предположим что реальное время сейчас 00:00:00.9999. Мы хотим подождать одну секунду. Так как точность часов для нас — одна секунда, то мы видим 00:00:00 и будем ждать до 00:00:01. Сколько реально времени пройдет?
Сколько реально времени пройдет?
Меньше секунды, но строго больше нуля, это понятно. Поэтому авторское высказывание
Т.е. в худшем случае оно будет 0 секунд…все еще, очевидно, неверно.
Таким если мы хотим выждать любое гарантировано ненулевое время, то нужно к текущему времени прибавлять минимум 2 секунды.
Прибавить «минимум 2 секунды к часам» нужно, чтобы «гарантированно прождать не менее секунды реального времени», но ведь это не то, о чем товарищ vsespb пишет.
В MS-DOS прерывание по таймеру имело 18.2 тиков в секунду.
Однажды разбирал промышленную программу в которой использовалось, что в 1 часе ровно 65535 тиков таймера.
Однажды разбирал промышленную программу в которой использовалось, что в 1 часе ровно 65535 тиков таймера.
Выходит, что MS-DOS так и было: 65535/3600=18,2041666…
Не было. В MS-DOS было 18.2065 тиков в секунду, а в часу было, соотвественно, 65544 тика. Потому что несущая частота в NTSC была 3.579545 MHz±10Hz и её треть делилась на 65536 (16-битный счётчик).
Интересно как эта промышленная программа работала… как Patriot?
Интересно как эта промышленная программа работала… как Patriot?
Это были внутренние таймеры для выполнения периодических вспомогательных действий.
В переменную unsigned int влезало только 65535.
В переменную unsigned int влезало только 65535.
Это 0.02% точность если что, для большинства применений не страшно.
Интересно это совпадение такое или нет, что 2^32 тактов NTSC это 20 минут с точностью меньше секунды?
Случайность, но не слишком случайная. Частона NTSC — это (5*7*9)/(8*11)MHz. Получилась как попытка минимизировать количество электронных компонент (и привела, кстати, к снижению частоты NTSC с изначальной частоты кадров в 30Hz до 29.97Hz.
То есть и 65536 (2^16) и 65544 — это соотношения небольших целых чисел. То есть вероятность того, что эти числа окажутся близкими — гораздо больше, чем кажется на первый взгляд… но нет, специально так не подбирали. Главное что привело к такому совпадению — это как раз вот эти 30Hz и 525строк в NTSC — отсюда множители 5 и 6 появились в достаточном количестве.
Если бы разработка велась в Европе и частота была бы 25Hz, а строк было бы 625… скорее всего такого совпадения не было бы…
То есть и 65536 (2^16) и 65544 — это соотношения небольших целых чисел. То есть вероятность того, что эти числа окажутся близкими — гораздо больше, чем кажется на первый взгляд… но нет, специально так не подбирали. Главное что привело к такому совпадению — это как раз вот эти 30Hz и 525строк в NTSC — отсюда множители 5 и 6 появились в достаточном количестве.
Если бы разработка велась в Европе и частота была бы 25Hz, а строк было бы 625… скорее всего такого совпадения не было бы…
к снижению частоты NTSC с изначальной частоты кадров в 30Hz до 29.97Hz.
AFAIK 29.97 это 30/1.001. Причем 29.97 это значение округленное до 2 знаков и если его использовать как мы пишем, то это приведет к заметной накапливающейся ошибке. Как разработчик одного очень известного видео софта могу сказать, что мы в коде используем целочисленные rational типы со значениями 30000/1001.
Откуда взялось это значение 1.001 можно почитать на википедии. В двух словах, при изобретении цветного телевидения им нужно было с одной стороны сделать обратную совместимость с черно-белыми телевизорами, с другой добавить в существующий сигнал видео+звук еще и цветовую информацию. Причем нужно было это сделать на таких частотах, которые бы не интерферировали друг с другом. Решили одну из несущих сдвинуть самую малось, в эти самые 1.001 раза.
Вот тут еще есть рассуждения на эту тему, только немного с другой стороны.
Я не знаю, является ли современная двухсекундная политика очистки кэша прямым следствием того соревнования в офисеА можно подробнее?
Современная двухсекундная — это про что речь?
А на SUN дискеты не доставались пока не дашь команду отмонтировать..
Не только на Sun. У Apple в принципе не было механической кнопки извлечения диска. Он вынимался только программно. Например, таким забавным способом как положить его на десктопе в корзину. Если же что то было не так, скажем система зависала, то приходилось вытаскивать дискету разогнутой скрепкой. Но зато не было такой проблемы как система внезапно обнаружила, что диска то нету, а она не успела записать что то на него.
Вроде в оригинале про экономию в 25 центов, а не в 1 цент. Не настолько они экономные. Хотя с 25-ти устройств будет уже 25 центов.
Интересно, почему нельзя было отловить факт установки дискеты от самого дисковода?
В спецификации были предусмотрены статусы для открытия дверцы дисковода, но IBM не реализовала эту часть спецификации, чтобы сэкономить один логический вентиль.
Потому что IBM устроила экономию и соотвествующего сенсора там не было. Появился в более поздних моделях (кажется не в IBM PC XT, а в IBM PC AT… но врать не буду — ни одну из этих систем я не застал), так что разговоры про то — можно ли с помощью продвинутого дисковода заменить дискету достаточно быстро для того, чтобы DOS «не заметил» особого смысла не имеют…
Sign up to leave a comment.
Почему MS-DOS именно две секунды хранит буфер чтения флоппи?