Представьте себе, что вы работаете над довольно сложной программой. Например, с мудрёными математическими расчётами. Вы её компилируете, запускаете в первый раз, она выдаёт ожидаемый результат и работает без ошибок. Скорее всего, в такой ситуации опытный программист сильно удивится и начнет перепроверять свой код: так не бывает, чтобы сложная программа сразу скомпилировалась, заработала, да ещё и не содержала багов.

Действительно, такое случается довольно редко. Как однажды сказал один очень хороший разработчик с моей прошлой работы: «Код хороший, жаль только, что не работает». Если у вас получается сразу писать сложные программы, которые не содержат ошибок, то вы — уникальный специалист.

Баги в программах — это любимая тема программистского фольклора. Они сопровождают разработчиков всю жизнь. Ошибки бывают разные: совсем глупые описки, которые отлавливаются при первой же компиляции; более серьёзные, которые можно найти при прогоне на тестовых примерах; системные, которые связаны со сложными аспектами взаимодействия разных систем. Самые неприятные — это плавающие ошибки, которые появляются неожиданно и так же неожиданно исчезают. Этакие привидения программной среды.

Для того, чтобы отловить все баги в программах, придумано множество различных методик и приёмов. Серьёзные программы проходят через несколько этапов тестирования: функциональное, регрессионное, интеграционное. Есть множество систем автоматизации тестирования. Придуманы даже специальные методики разработки, нацеленные на то, чтобы минимизировать количество ошибок ещё на уровне создания программного кода.

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

Но иногда возникают такие баги, которым удалось укорениться в базовых системах: в процессорах, ядре ОС. Их обнаруживают не сразу, и они имеют гораздо более критические последствия. О нескольких таких эпических багах, которые мне показались интересными и забавными, я и хочу рассказать.

Самый первый компьютерный баг / Wikimedia Commons
Самый первый компьютерный баг / Wikimedia Commons

1900 год всё ещё високосный

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

В 1983 году компания Lotus Software выпустила для компьютеров IBM PC своё знаменитое приложение для работы с таблицами, которое называлось «Lotus 1-2-3». В своё время эта программа считалась самым надёжным и быстрым табличным процессором. К сожалению, она содержала маленькую, но очень серьёзную ошибку.

По какой-то причине 1900 год в ней считался високосным. Пользователи сообщили об этой ошибке, но её так никто и не исправил. Разработчики утверждали, что исправление этого бага приведёт к необходимости переписывать почти весь код программы. Почему — это вопрос, на который нет ответа. Календари и даты — это вообще больная тема для многих разработчиков.

В 1995 году компанию Lotus Software приобрела фирма IBM, но к тому времени уже набирал свои обороты Microsoft Excel. Многие пользователи переходили с Lotus 1-2-3 на Microsoft Excel, а это значит, что нужно было обеспечить их совместимость. Именно для обеспечения совместимости разработчики Microsoft приняли осознанное взвешенное решение аккуратно транслировать эту ошибку в пакет Microsoft Office.

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

Вы можете спросить: «Кто же использует в своих таблицах даты в начале XX века?» Оказалось, что исправление ошибки затронет и другие даты. Как написано на сайте Microsoft, если ошибку исправить, то «почти все даты в текущих Microsoft Excel и других документах будут уменьшены на один день».

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

В некоторых источниках утверждается, что эта ошибка была исправлена ещё в 2007 году, но в моём рабочем Excel 2016 она всё ещё воспроизводится. Проведём эксперимент: если у вас есть Excel, откройте новую таблицу и введите в ячейки две даты: 29.02.1900 и 29.02.1901. Первая тут же выравнивается по правому краю, а значит Excel воспринимает эту строку как валидную дату. Вторая дата так и останется строкой — такой даты не бывает даже по версии Lotus. Так что баг, о котором известно уже больше 30 лет, всё ещё с нами.

В Microsoft Excel 1900 год всё ещё високосный
В Microsoft Excel 1900 год всё ещё високосный

Рассеянный процессор

Не печалься, Барт, все совершают ошибки. Просто твои публичные и дорого стоят.
Гомер Симпсон

Мы все давно привыкли к тому, что сложные математические программы могут содержать ошибки. Это, конечно, неприятно, но этого можно ожидать. Где-то программист забыл перевести градусы в радианы, где-то ошибся в размерности. Такие баги бывают и их несложно исправить — главное вовремя их отловить.

Но когда речь заходит о процессоре, ошибок в расчётах мы никак не ожидаем. Мы твёрдо верим, что уж на аппаратном уровне всё должно быть чётко и надёжно. К сожалению, так бывает далеко не всегда. Довольно широкую известность получила ошибка, возникавшая при выполнении операций над числами с плавающей запятой в процессорах Intel Pentium. Этот баг обнаружили и обнародовали в 1994 году.

Процессор при использовании ассемблерной команды FDIV в некоторых случаях неправильно делил одно число на другое. Не всегда, только для определённых чисел, но, согласитесь, что это слабое утешение. Одно дело, если деление выполнено неправильно при расчёте домашнего бюджета. А если это расчёт траектории спутника?

Вот очень наглядный пример:

  • 4195835 / 3145727 × 3145727 = 4195835 — правильный расчёт;

  • 4195835 / 3145727 × 3145727 = 4195579 — то, что выдавал процессор Intel.

График, иллюстрирующий ошибку выполнения FDIV в процессорах Intel Pentium / Wikimedia Commons
График, иллюстрирующий ошибку выполнения FDIV в процессорах Intel Pentium / Wikimedia Commons

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

Это вызвало такую волну недовольства и критики, что представители компании пошли на попятную: принесли публичные извинения и заявили, что каждый может обменять процессор бесплатно. Всё это стоило компании 475 миллионов долларов. О подробностях этой истории можно почитать здесь.

Замена процессора — дело хлопотное. Так что программисты исправили проблему самым простым доступным им способом: в компиляторах Delphi и Visual Basic была добавлена проверка наличия этой ошибки и её автоматическое исправление на уровне приложения. Если ошибка обнаруживается, то программа просто корректирует результат выполнения операции FDIV. Конечно, это несколько замедляет работу приложений, но правильный результат дороже.

После того, как весь этот кошмар закончился, руководство фирмы Intel раздало главным инженерам компании брелоки с впаянным злополучным процессором и надписью: «Кризисы разрушают плохие компании. Хорошие компании переживают их. Великие компании от кризисов становятся лучше».

Купертино с нашими итальянскими товарищами

— Тупой словарь: «калевалу» знает, а «коленвал» — нет.
— Он не тупой, просто гуманитарный.
bash.im

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

Здесь же речь пойдёт не о быстром обмене сообщениями в мессенджерах, а о государственных документах. Ошибка, о которой я хочу рассказать, оставила свой след во многих официальных бумагах.

В английском языке есть вполне обычное слово «cooperation» — «сотрудничество». По правилам английского языка его можно написать и так: «co-operation». В моём словаре Lingvo есть обе версии написания. Соответственно, и программы проверки орфографии английских текстов должны содержать оба варианта.

К сожалению, долгое время в некоторых приложениях (например, в Microsoft Word примерно с 1989 года) вариант «cooperation» в списке правильных слов отсутствовал. В общем-то, ничего страшного в этом бы не было, если бы умная система не предлагала заменить вариант «cooperation» на «Cupertino» — название города в Калифорнии.

Эффект Купертино в действии / https://revealingerrors.com/cupertino_effect
Эффект Купертино в действии / https://revealingerrors.com/cupertino_effect

Теперь представим, что у многих пользователей настроена автозамена неправильно набранных слов на правильный вариант. Стоит ли удивляться, что в архивах ООН, НАТО, Евросоюза сохранилось немалое количество официальных документов со словом «Купертино» вместо слова «сотрудничество».

Вот вам несколько примеров:

  • Купертино с нашими итальянскими товарищами было очень плодотворным.

  • Азиатская ассоциация регионального Купертино.

  • Презентация афро-немецкого Купертино.

Эта ошибка была настолько распространена, что даже получила своё собственное название: «эффект Купертино». Есть и другие примеры подобных автозамен в английском языке. Американский лингвист Бенжамин Зиммер даже коллекционирует такие случаи. В его коллекции есть пример публикации из газеты New York Times, в которой вместо «Voldemort» написано «Voltmeter».

Очень умный ксерокс

— Добрый день, а у нас ксерокс не печатает.
— Он и не должен печатать, он делает копии.
— Ой, да, спасибо!
bash.im

Вернёмся обратно к аппаратному обеспечению. Как вам ксерокс, который при копировании заменяет цифры в оригинале? Вам кажется, что такое невозможно? К сожалению, в современной гонке за оптимизацией алгоритмов работы офисной техники такой фантастический вариант стал реальностью.

Мы привыкли к тому, что ксерокс, хоть и технологичное устройство, но в общем его функции достаточно банальны — сделать копию с оригинала. Интуитивно мы предполагаем, что ксерокс работает как связка сканера с принтером: отсканировали изображение, получили картинку и отправили её на принтер. Именно так, видимо, и работали ранние ксероксы.

Но устройства усложнялись, появились МФУ, в которых уже была встроена довольно сложная программная начинка. Видимо, в этом и заключалась причина ошибки, которую в 2013 году обнаружил немец Дэвид Крисель в МФУ фирмы Xerox.

Совершенно случайно Дэвид заметил, что при ксерокопировании некоторых документов с цифрами устройство периодически заменяло цифру «6» на «8», а цифру «2» на «1». Согласитесь, что это крайне странное поведение для ксерокса. Тем более, что в нём был отключён алгоритм распознавания текста и пользователь выполнял простое ксерокопирование.

Оказалось, что в устройстве использовался алгоритм компрессии графики JBIG2. Этот алгоритм фактически выполняет распознавание текста и заменяет графическое изображение на символы. При появлении схожих символов алгоритм подбирал им замену из библиотеки уже распознанных букв и цифр.

Понятно, что распознавание текста позволяет существенно сжать исходный файл. Другой вопрос, зачем этот алгоритм применялся при простом ксерокопировании. Интересно, что при недостаточном качестве сканирования алгоритм может заменить ещё и «2» на «7» или даже «1» на «3».

Ксерокс корректирует вашу зарплату / http://www.dkriesel.com
Ксерокс корректирует вашу зарплату / http://www.dkriesel.com

Компания Xerox повела себя аналогично Intel — не сразу признала свою ошибку. Поупиравшись какое-то время, Xerox всё-таки выпустили обновлённую прошивку для своих устройств. Но многочисленные пользователи должны её скачать и установить, а это делают далеко не все.

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

Ядерный Ганди

Кстати, о «Цивилизации». Поначалу мне нравилась третья часть, до того самого момента, как рота элитных мушкетёров, окопавшихся в городе, сбила ракету с ядерной боеголовкой.
bash.im

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

По легенде в ранних версиях популярной стратегии Sid Meier’s Civilization существовала ошибка, из-за которой один из самых миролюбивых лидеров цивилизаций Махатма Ганди при определённом стечении обстоятельств превращался в самого агрессивного персонажа и не задумываясь использовал ядерные боеголовки против других цивилизаций.

Пример интернет-мема про «Ядерного Ганди» / Wikimedia Commons
Пример интернет-мема про «Ядерного Ганди» / Wikimedia Commons

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

Для Ганди, понятное дело, по умолчанию был установлен минимальный уровень агрессии — 1. При переходе к демократии уровень агрессии по игровому алгоритму снижался на два пункта. Уровень агрессии Ганди при этом должен был стать отрицательным, но для хранения этого показателя использовалась однобайтовая беззнаковая целочисленная переменная. А это означало, что после такой операции уровень агрессии становился равным 255. Из-за этого бедный Ганди становился в 25 раз более агрессивным, чем самые отрицательные лидеры в игре.

Разработчики игры утверждали, что всё это только миф. Сам Сид Мейер говорил, что этого бага в ранних версиях игры никогда не существовало, что в коде применялись знаковые целочисленные переменные, и что государственный строй по игровому алгоритму вообще не влиял на агрессивность лидеров.

Миф об этой ошибке появился после выхода Sid Meier’s Civilization V и постепенно стал распространяться в сети. Выяснилось, что разработчики решили пошутить и специально добавили эту ошибку в качестве пасхалки. В этой версии Ганди был таким же незлобливым и миролюбивым, как Нед Фландерс в сериале «Симпсоны», но при этом вероятность создания и применения ядерного оружия у него установлена максимальная — 12. Это самое большее из возможных значений.

Ошибка под названием «Ядерный Ганди» стала источником множества мемов в сети. Сам же Махатма Ганди был очень мудрым человеком. Когда-то он сказал: «Ценность идеала в том, что он удаляется, по мере того как мы приближаемся к нему».

Статья была впервые опубликована на другом ресурсе 1 июня 2021.

Комментарии (83)


  1. SShtole
    12.01.2022 16:01
    +11

    По какой-то причине 1900 год в ней считался високосным. Пользователи сообщили об этой ошибке, но её так никто и не исправил. Разработчики утверждали, что исправление этого бага приведёт к необходимости переписывать почти весь код программы. Почему — это вопрос, на который нет ответа.

    Считается, что это из-за «640К должно хватить для всех!»:

    1900 wasn’t a leap year.

    “It’s a bug in Excel!” I exclaimed.

    “Well, not really,” said Ed. “We had to do it that way because we need to be able to import Lotus 123 worksheets.”

    “So, it’s a bug in Lotus 123?”

    “Yeah, but probably an intentional one. Lotus had to fit in 640K. That’s not a lot of memory. If you ignore 1900, you can figure out if a given year is a leap year just by looking to see if the rightmost two bits are zero. That’s really fast and easy. The Lotus guys probably figured it didn’t matter to be wrong for those two months way in the past. It looks like the Basic guys wanted to be anal about those two months, so they moved the epoch one day back.”


    1. SalazarMAX
      15.01.2022 14:32
      +1

      Интересно, до 2100 года ошибка доживёт? Если да, то последствия могут быть печальными


  1. F0iL
    12.01.2022 16:29
    +19

    Странно, что не упомянули эпичные баги с Ariane-5 и с Therac-25. В одном случае всрали 370 миллионов долларов из-за переполнения переменной, во втором случае десяток человек получили передозировку радиацией и отправились на тот свет из-за говнокода.


    1. v1000
      12.01.2022 16:35
      +18

      Баг с Ariane-5 еще более эпичен, потому что переполнение произошло потому, что софт писался для Ariane-4, и на ней это не могло произойти. Зато на Ariane-5 это произошло, потому что это была более мощная ракета.

      Вообщем, баг не проявлялся, потому что железо тормозило.


      1. corvair
        12.01.2022 18:02
        +4

        С Therac-25 аналогично: код был написан для предыдущей модели Therac-20, где были механические блокировки, не позволявшие запускать ускоритель в неверной конфигурации и баг там проявлял себя только срабатыванием защиты - система в целом вела себя безопасно, несмотря на серьёзные проблемы с ПО. А вот в Therac-25 резработчики решили возложить критичные с точки зрения безопасности функции на "проверенное" ПО и понеслась...

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


        1. ClearAirTurbulence
          12.01.2022 19:56
          +1

          баг там проявлял себя только срабатыванием защиты

          Интересно, а это срабатывние там что ли не логировалось?


          1. Sdima1357
            12.01.2022 19:59
            +7

            Это 1982 год .Это было переполнение байта. И жёсткий диск стоил дороже этого ускорителя. Ну почти.


            1. PendalFF
              13.01.2022 02:37
              +1

              Бумага тогда была недорогой и в критичных системах лог печатался/строился на лету.


              1. nochkin
                13.01.2022 18:04
                +2

                В то время критерии критичности были другие в силу малого опыта с такими ситуациями.


                1. Sdima1357
                  14.01.2022 00:37
                  +4

                  Кроме того, критичность обычно мы осознаем постфактум...


                  1. nochkin
                    14.01.2022 07:15
                    +2

                    И это правильный ответ.


          1. ilialin
            13.01.2022 10:52
            +2

            Там была совокупность проблем:
            — зависело от опытности оператора: у неопытных, медленно нажимающих кнопки интернов, проблемы не было — поворотный круг успевал повернуться в нужное положение
            — сообщения об ошибках выводились в виде «ошибка № такой-то», без описания в документации что это значит и что с этим делать


          1. Goupil
            13.01.2022 11:39
            +1

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


        1. Earthsea
          13.01.2022 10:47
          +1

          код был написан для предыдущей модели Therac-20, где были механические блокировки

          А вот в Therac-25 резработчики решили возложить критичные с точки зрения безопасности функции на "проверенное" ПО и понеслась

          Сам по себе отказ от механической блокировки - вопиющая халатность. Странно, что по итогам расследования не полетели головы, вроде не 19-й век (когда всем по барабану было на безопасность).


          1. ilialin
            13.01.2022 10:56

            Не помню точно, но кажется, при всём этом не было зарегистрировано доказанных смертельных случаев, вызванных именно прибором. Были серьезные ожоги, были смерти от основного заболевания (онкология) и от попадания в ДТП.


      1. nochkin
        13.01.2022 18:02
        +1

        Там было обычное переполнение (64-битное значение пытались запихнуть в 16-битную переменную).

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


        1. quillon45
          13.01.2022 19:39
          +2

          ну, железо не тормозило в другом направлении


    1. Akon32
      12.01.2022 17:40
      +5

      В других подборках много эпичных багов. Например (ссылок не приведу, возможно, мифы):

      • Самолёт перевернулся при отрицательной координате по GPS

      • Ракета не туда улетела (оказалось, что запуск не с того космодрома)

      • Марсоход разбился из-за дюймов/метров

      • Boeing 737 MAX не очень хорошо летал в редких случаях

      Ну и чисто ИТ-баги (вообще см. список CVE, бывает эпично):

      • Spectre/Meltdown

      • Что-то не то c OpenSSL

      • Удаление каталога /usr драйвером

      Тысячи их! В каждой компании. Все не перечислить. И по крайней мере 3 бага из 5, что в этой подборке, уже описывались на хабре.


      1. zorn-v
        12.01.2022 19:01
        +5

        Что-то не то c OpenSSL

        Heartbleed

        Удаление каталога /usr драйвером

        Bumblebee

        Ну и в догонку log4j

        Тысячи их!

        Но не все эпичные )


      1. F0iL
        12.01.2022 19:44
        +5

        Boeing 737 MAX не очень хорошо летал в редких случаях

        Вот это кстати интересный пример, нюанс в том, что там был не сколько баг в софте, сколько баг в ТЗ. А именно, для работы системы поддержания устойчивости использовался сигнал только с одного единственного датчика (!) вместо двух, без какого-либо сравнения значений и даже без индикации показаний пилотам, то есть если один датчик неисправен - то всё, самолет начинает вести себя непредсказуемо.

        Учитывая, что разработка ПО в авиации очень сильно зарегулирована и там в принципе не может быть никакой самодеятельности и отступления от спецификации, то весьма вероятно можно предположить, что корни проблемы не в говнокоде, а в кривых требованиях, которые дали программистам.

        И да, указания о том, что делать в таком случае, в инструкции по эксплуатации к самолету были, вот только пилоты в критический момент не сопоставили происходящее с той ситуацией и не вспомнили то что обязаны были вспомнить.


        1. Alexmaru
          12.01.2022 20:48
          +3

          Бойнг, в целом, так близко к государству, что регулирует сам себя.


          И нет, из того же блога, цитата:


          согласно описанию, представленном производителем /лишь после катастрофы в Индонезии

          документации не было. Если бы она была, то по правилам, пришлось бы переобучать всех пилотов. Смысл этой фигни был в том, чтобы не тратить денег на переобучение пилотов, потому что это дорого — тогда бы купили более дешевые эйрбасы. Поэтому разницу в поведении самолёта закрыли программными компенсациями, которые повесили на показания одного единственного датчика. Который мог быть в виде нескольких датчиков, но только в виде допов.


          1. F0iL
            12.01.2022 23:34
            +7

            Не совсем верно

            Который мог быть в виде нескольких датчиков, но только в виде допов.

            У Boeing 737MAX с завода два этих датчика (для упавшего борта Lion Air в расшифровке данных бортового самописца видны сигналы обоих из них), но при каждом полете для работы MCAS сигнал использовался только с одного из них без какого-либо сравнения со вторым.

            документации не было

            Конкретно про эту систему - не было. Но было все необходимое, чтобы распознать отказ этой системы и принять меры для решения проблемы. Грубо говоря, некорректная работа MCAS проявлялась в определенных признаках, а именно в "убегающем стабилизаторе" (ranaway stabilizer). О том, что делать в случае runaway stabilizer в документации было написано ещё с древних времён вообще задолго до появления 737MAX, и описанный там алгоритм действий в том числе и решал проблему с MCAS отключая ее.

            Поэтому разницу в поведении самолёта закрыли программными компенсациями

            Для современных самолётов это абсолютно нормально. Управление в обычном режиме и в direct mode (без "программных компенсаций") отличается в наши дни почти у всех современных лайнеров (что у A350, что у SSJ-100). А некоторые виды (в основном из военных) вообще без таких "программных компенсаций" летать не способны в принципе по причине аэродинамической неустойчивости планера.


          1. Angmarets
            13.01.2022 01:02
            +21

            О, ещё одно слово изувечили. Можно дополнят пасту.
            Войн-андройд на стеройдах выйграл биткойн, купил руберойд, сел в бойнг и свалил на астеройд.


            1. Squoworode
              13.01.2022 06:31
              +6

              выйграл биткойн

              в Тайланде, у гуманойда Украйны.


      1. vikarti
        13.01.2022 08:08
        +4

        Обновление к EVE Online после которого Windows не загружалась (потому что обновление правило файл boot.ini не в каталоге EVE Online а в корне диска).
        Яндекс.Диск при обновлении не только старую версию удаляет но и Windows https://habr.com/ru/post/204580/ (пострадавшим дали +200 Gb вечно)


      1. Goupil
        13.01.2022 11:42
        +1

        Не марсоход, а Mars Polar Lander. Пришлось повторять миссию с Phoenix.
        Вообще изрядно космической техники было погублено кривым программным обеспечением, а уж нефатальные баги происходили все время.


      1. tundrawolf_kiba
        14.01.2022 01:11
        +2

        Ракета не туда улетела (оказалось, что запуск не с того космодрома)

        Это у нас, запуск в Восточного в 17 году. Там просто при запуске с Байконура данная ситуация вообще не могла сложиться (и не складывалась), а вот с Восточного, как оказалось — зависело от того, на какую орбиту выводить, т. е. даже на том космодроме при той же технике и алгоритме все могло пройти штатно. Там, если не изменяет память — проблема была в том, что алгоритм не мог условно повернуть на минус 10 градусов, он мог повернуть только на 350(цифры не точные). А из-за этого — разворот занял заметно дольше времени, чем можно было позволить, и поэтому где-то на середине разворота пришла команда на отделение разгонного блока, и он со всей старательностью и усердием был запущен не вверх, а вниз, в океан.


      1. nickolaym
        14.01.2022 03:21
        +1

        Ракета не туда улетела - комплекс Пэтриот, у него за время работы набегала погрешность в часах. Пока комплексы работали в детском режиме, на полевых испытаниях, всё было хорошо. Как поставили на боевое круглосуточное дежурство в Ираке, так и доигрались: промахнулись мимо саддамовского скада - тупой баллистической цели без помех.


      1. nickolaym
        14.01.2022 03:26
        +3

        Самолёт не самолёт, а вот один парапланерист жаловался, что у него полётный прибор сошёл с ума, когда он летал около Мёртвого моря и пересёк уровень 0.

        Он пожаловался производителю, а тамошний ступпорт ответил, что парапланерные приборы не предназначены для полётов в пещерах!

        Пруф: https://paraplan.ru/forum/topic/167588


  1. tsurugi-no_ken
    12.01.2022 16:30
    +10

    Самый первый компьютерный баг

    На Хабре была статья про баг найденный в самой первой программе написанной Адой под аналитическую машину Бэбиджа.


    1. ubivas
      15.01.2022 14:51
      +1

      То был нулевой


  1. minusnaminus
    12.01.2022 16:37
    +3

    Презентация афро-немецкого Купертино

    Может в этом конкретном случае это была не автозамена, а эвфемизм XD

    Можно ещё вспомнить про баги в военном ПО. Когда истребитель в полете у Мёртвого моря заглючил из-за высоты полета ниже уровня моря, что не было заложено разработчиком, к примеру. Эпично в физическом выражении


    1. dvserg
      12.01.2022 16:57
      +6

      Ну и аналогично бага в F-16 при пролете экватора, когда самолеты переворачивались вверх ногами.


    1. zikasak
      12.01.2022 18:40
      +6

      Про истребитель - это вроде шутка. Как минимум, никаких подтверждений найти не удалось.



  1. Gritsuk
    12.01.2022 17:19
    +5

    Ну автозамены это уже не эпик, а норма жизни — сейчас ведь спеллчекеры учатся на том, что писал раньше пользователь. Так у меня однажды «водички» стало превращаться в «водочки»


    1. Sdima1357
      12.01.2022 18:24
      +4

      Мультиканальный:

      https://tarnavsky.livejournal.com/7696.html


      1. PKav
        12.01.2022 21:03
        +9

        "Шестиканальный" звучит интереснее.


        1. roswell
          13.01.2022 05:17
          +4

          Порочнее...


      1. trankov
        13.01.2022 06:48
        +7

        У меня однажды Ворд предложил разбить на две части слово "темпоральный".


        1. Gritsuk
          13.01.2022 15:51
          +1

          Про шестики и мультики помню, а вот это ново!


    1. Rikhmayer
      13.01.2022 13:17
      +5

      Недавно публиковали проект обновления свода правил орфографии. Там среди слов-исключений было "юдьячий". Это слово когда-то было неверно отсканированным словом "подьячий" и потом кочевало из словаря в словарь, пока не попало на одобрение в госдуму...


      1. Goupil
        13.01.2022 13:23
        +5

        Вечный подпоручик Киже.


    1. Vaitek
      14.01.2022 22:35
      +1

      Я пару лет сдавал работы в "Отрытый" университет, вместо открытого. Пока сам не заметил, кто эти титульные листы читает? ????


  1. NivER
    12.01.2022 17:39
    +1

    Миф об этой ошибке появился примерно в 2012 году и постепенно стал распространяться в сети. В итоге разработчики решили пошутить и специально добавили эту ошибку в качестве пасхалки в новую версию игры Sid Meier’s Civilization V.

    В статье явно нарушена причинно-следственная и временная связь. Пятая "Цивилизация" с описанной шуткой вышла в 2010 году, и уже после этого через пару лет появился миф о баге в первой части.


  1. alextrof94
    12.01.2022 21:59

    Подождите, а разве проблемы с делением чисел не связаны с ограниченной точностью чисел с плавающей запятой? Можно просто 0.1+0.2 сделать и уже получить неверный результат... Есть даже сайт с результатом вычисления в адресе: https://0.30000000000000004.com/


    1. tyomitch
      12.01.2022 22:12
      +2

      Проблема в Пентиуме была в том, что он правильно вычислял только старшие 14 битов частного, тогда как обязан был правильно вычислить старшие 52 бита.


      1. sergej_pipets
        13.01.2022 12:22
        +2

        И появился анекдот, почему процессор именуется не следующим числом "586", а словом...


        1. tyomitch
          13.01.2022 13:13
          +2

          У меня на эту тему даже был хабрапост: habr.com/ru/post/388527


          1. sergej_pipets
            13.01.2022 14:49
            +3

            Анекдота про 486+100=585,99999999999 в нем нет...


  1. lxsmkv
    13.01.2022 01:31
    +14

    Нельзя не вспомнить также и эту поучительную историю:

    При подготовке полета «Аполлона-8», первого пилотируемого космического корабля, добравшегося до орбиты Луны, Маргарет Гамильтон удалось обнаружить серьезную уязвимость, но никто не поверил, что она представляет реальную угрозу. Найти эту уязвимость помогла дочь Гамильтон, которая играла с симулятором компьютера «Аполлона-8», пока ее мать работала. В какой-то момент она включила последовательность P01, запускаемую перед стартом космического корабля, когда симулятор был уже в «полете». Запуск P01 в неподходящий момент привел к сбою; и хотя у космонавтов нет никаких причин допускать такую ошибку, Гамильтон решила добавить несколько строчек кода — сделать своего рода «защиту от дурака». В NASA воспротивились, сочтя, что прекрасно подготовленные астронавты никогда в жизни не смогут так ошибиться. Тогда Гамильтон включила строчку «Не запускайте P01 во время полета» в документацию, но и это показалось руководству излишней мерой предосторожности. Вскоре после Рождества в 1968 году, когда «Аполлон-8» должен был покинуть орбиту Луны и отправиться на Землю, астронавт Джеймс Ловелл сделал именно то, чего от него никак не ждали — по ошибке запустил P01

    Маргарет Гамильтон: «Пацаны, я вас на Луну отправлю»

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


  1. shemharon
    13.01.2022 08:55
    -10

    Что ещё за "ксерокс"? Нет такого устройства, есть принтеры, сканеры и копиры.


    1. Earthsea
      13.01.2022 10:52
      +10

      В Монголии вообще канон вместо ксерокса.


    1. drWhy
      13.01.2022 10:55
      +1

      А как же «отРЭМить на ксероксе»?


      1. paulsv77
        13.01.2022 13:59
        +3

        Мама у меня говорила отЭРИть. Был у них на работе какой-то древнесоветский копир Эра.


        1. Paul_Arakelyan
          13.01.2022 18:09
          +2

          Да, было такое, ЭРА и РЭМ - сами агрегаты не видел, но чертежи на бумаге дома пробегали - А1 или А0. Качество - "жить можно", напоминало жестоко замучанный ксерокс (куча чёрточек-точечек-помех вместо "белого") чёрно-белые чертежи и странного пурпурного вместо чёрного с светло-розовым вместо белого (кто из них ). Качество самой бумаги - "просто бумага" (не ватман, не "80г/м2" а что-то довольно рыхлое и тонкое, похожее на обёрточную), ксерокс бы от неё сдох, наверное. Исходный чертёж был на кальке (полупрозрачная бумага). За работу там - сначала доплачивали за вредность, потом, вроде, убрали - и мужской контингент сменился женским.

          А по теме - эпичные приколы бывают у автозамен при неправильном выборе клавиатуры (и, соответственно, языка ввода) у похожих языков - а чё её там выбирать, если буквы, в основном, одинаковые? В одном украинском сериале это обхихикали - "Салон крысы" вместо "Салон краси" (Будиночок на щастя). Из личного опыта - магазин (или кафе?) КАТРУСЯ. То ли "Катюша", то ли "палач Руся" :) - кому как нравится. А уж многозначность ТМ "Господарочка" :).


          1. drWhy
            13.01.2022 18:57
            +1

            Застал в здании проектного института, где когда-то использовались РЭМы и где собственно слышал фразу «отРЭМить на ксероксе», ящик новеньких пятикиловаттных трубчатых ламп 1,2 м и тридцатилитровую бутыль спирта для их протирки.


      1. sergej_pipets
        13.01.2022 14:11
        +1

        отЭРИть... (ЭРА - электро-репродукционный аппарат)


        1. drWhy
          13.01.2022 14:19
          +3

          «Начиная с 1965 года в СССР производились копировальные аппараты собственной разработки. Первопроходцем в этой области стал Казанский оптико-механический завод с аппаратом «РЭМ» (ротационная электрографическая машина)… Позже выпуск похожих аппаратов наладили и другие заводы, в частности БелОМО и Грозненский завод полиграфических машин (под маркой «ЭРА»).»


    1. tommyangelo27
      13.01.2022 12:21
      +7

      Унитаза тоже нет, есть санитарно-техническое приспособление для удаления продуктов дефекации и мочеиспускания.

      Заголовок спойлера
      Имеются две версии происхождения русского слова «унитаз»:
      1) В 1883 году англичанин Томас Твайфорд (фирма Twyford Bathrooms) изобрёл новую модель туалета — цельную (компакт), вместо более ранних, включавших чашу и трубу-поддон. Новую модель назвали «Unitas» — единство;
      2) По версии словаря Ушакова, слово произошло от названия фирмы «Unitas» (лат. единство), производившей данные изделия, и по ассоциации со словом «таз»


      1. tyomitch
        13.01.2022 13:39
        +1

        Упоминания «фирмы Unitas под Барселоной, начавшей производство санфаянса в 1909» я встречал только в русскоязычных источниках; тогда как о выпуске модели Unitas в 1883 заявлено прямо на официальном сайте Twyford Bathrooms; и «Ватеръ-клозетъ „Унитасъ“, состоящій изъ англійскаго фаянсоваго горшка, гладкаго, бѣлаго...» — упоминается в печатном источнике 1903, за шесть лет до предполагаемого запуска испанской продукции. Поэтому одна из двух версий отсекается, несмотря на авторитет Ушакова.


    1. tvr
      13.01.2022 15:52

      Что ещё за «ксерокс»? Нет такого устройства, есть принтеры, сканеры и копиры.

      Ага, и контора по имени Xerox уже давно канула в лету и не производит офисную технику под этим брендом.


      1. shemharon
        13.01.2022 19:39

        Так она какую технику производит, ксероксы? Нет, она наверное производит принтеры, сканеры и копиры, да? А МФУ включают в себя функционал сканеров, принтеров и, внезапно, "ксероксов", да?


    1. monah_tuk
      13.01.2022 17:24
      +2

      Зануда!)


    1. lxsmkv
      13.01.2022 18:11
      +2

      1. shemharon
        13.01.2022 19:44

        Ну так мы же наверное сейчас не в 90-х и нашего интеллекта и образования должно хватать, чтобы понимать разницу между фирмой и оборудованием? Мы же не называем системные блоки процессорами, потому что понимаем разницу между этими вещами. Так же, как вместо "системный блок" некорректно использовать слово "процессор", так и вместо "копир"/"копировальный аппарат" некорректно использовать слово "Ксерокс" — потому что, например, я с огромным трудом вспомнил, что же подразумевается под словом "ксерокс"


        1. lxsmkv
          13.01.2022 21:32
          +1

          Для меня, когда читаю слова вышедшие из обихода, это как прикосновение к истории. Мне кажется без этого язык беднеет.


  1. Int_13h
    13.01.2022 08:58
    +16

    Мой любимый эмбеддед-баг, в бесперебойниках (цытирую из офф. документа):

    Когда к порту RS232 подключено устройство которе неверно сконфигурировано (напрмиер 19200 бод вместо нужных 9600) имеет место следующая неприятность:
    Данные, поступающие в порт, вызовут переполнение приемного буффера в DSP, что приведет к потере DSP управления.
    Через несколько секунд ИБП выйдет из строя с характерным хлопком.
    В фильтре инвертора разнесет вклочья конденсатор.
    Рекомендацыи: обновить прошывку.

    Вообще начинал статью по подобным хардварно-софтварным багам, по мотивам чтения мануалов, но с новым редакоторм это сплошная боль…


    1. drWhy
      13.01.2022 11:03
      +2

      При такой официальной документации как-то боязно что-либо обновлять или вообще трогать.


    1. Archy_Kld
      13.01.2022 12:38
      +3

      Писать всё локально в .md, в новый редактор копипастить прямо перед публикацией.


    1. sergej_pipets
      13.01.2022 15:36
      +1

      Написать хоть в блокноте, а потом скопипастить?..


    1. DrGluck07
      13.01.2022 16:53
      +1

      Но ведь в сериал порте есть стартовый и стоповый бит. Поэтому далеко не все последовательности битов будут складываться в валидные данные. Кроме того, приёмник же всё равно работает на скорости 9600, никакого переполнения тут быть не должно. Хотелось бы каких-то пояснений.


  1. hard_sign
    13.01.2022 11:52
    +2

    в которой вместо «Voldemort» написано «Voltmeter».

    «Указания товарища Сталина, – прочел Ермолкин, – для всего народа нашего стали мерином мудрости и глубочайшего постижения объективных законов развития».


    1. Goupil
      13.01.2022 12:31

      За одну перепутанную букву в официальной кличке тов. Джугашвили как-то целую редакцию газеты отправили в ссылку. А могли и расстрелять.


    1. Wizard_of_light
      13.01.2022 12:32
      +1

      Да его просто нельзя по имени называть, вот и зашифровались.


  1. stanislavskijvlad
    13.01.2022 14:49
    +1

    Помню, на IT Happens читал про баг одной каретки, которая двигалась под потолком склада с дорогим оборудованием. По какой-то причине бит знака изменился, и каретка вместо замедления начала ускоряться. От этого выбило вертикальную опору, и крышу полностью сложило.


  1. AlexanderS
    13.01.2022 15:21
    +2

    С ксероксом баг отличный. Хотя на самом деле это даже не воспринимается как баг — к ошибкам распознавания ты как-то изначально морально готов. Морально не готов, что функция «копия» реализуется так шибко умно, а не сырым потоком данных с модуля сканера на модуль печати.


    1. Goupil
      13.01.2022 15:40
      +3

      Всем любителям нарушить KISS посвящается.


    1. tyomitch
      13.01.2022 16:44

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


      1. AlexanderS
        13.01.2022 20:44
        +1

        Да даже если так… ну ёжкин-кот! Это что такое? Тут даже… экономия на памяти? А если рисунок сложный будет — всё равно буфер же надо запиливать адекватного объёма.


    1. DrGluck07
      13.01.2022 16:56
      +3

      — Вас, вероятно, изумляет столь древняя дата моего рождения?
      — Нет, не изумляет. У нас писарь в уезде был, в пачпортах год рождения одной только циферкой обозначал. Чернила, шельмец, вишь, экономил. Потом дело прояснилось, его в острог, а пачпорта переделывать уж не стали. Документ все-таки. Ефимцев, купец, третьего года рождения записан, Куликов — второго… Культякин — первого. Да, много тут долгожителей.


  1. Sabin
    13.01.2022 21:09
    +3

    Как-то купил для работы "диктофон" (в кавычках потому что его можно использовать в качестве занятного металлического брелока, подставки под клавиатуру, метательного снаряда, но не диктофона) со стерео записью от продающего на каждом углу хлам производителя "***mix" вместо провереного. Сбоку у него были рычажки питания и записи. Если остановить запись и в течение пары секунд выключить питание или просто выключить питание во время записи - это инженерное чудо создавало битый файл от 1600 года нулевой длины. Ни photorec, ни r.saver не смогли ничего восстановить из сделанных сотрудницей во время командировки записей. И натыкался на положительные отзывы, где упоминали, что битые файлы создаются даже просто так спустя несколько десятков записей, исправляет форматирование. Но. Это ещё не всё. Официальный сервис не только отказался восстанавливать записи и ремонтировать брак, но и заявил, что такое поведение - норма, ведь в инструкции написано сначала остановить запись, потом выключить питание.


  1. MShevchenko
    13.01.2022 23:40
    +4

    Аполлон-11, вернее Орёл, садился на Луну в ручном режиме из за того что нерасчетно включили перед посадкой прогрев стыковочного (!) радара. Бортовой компьютер не мог справиться с таким потоком информации и уходил в fail safe. У Нила и Базза стальные пуканы были. Они этот компьютер, падая на Луну, сбрасывали с полдюжины раз.