Очень кратко суть: однажды на форуме ixbt заметили очень странную штуку, что оказывается есть файл, который, если записать его на CD-R(W) на большом количестве приводов потом нормально не считывается и это не связано с качеством болванки и записи, а только с уникальной сигнатурой внутри.
Причем ошибка чтения такого диска происходит в любых ОС и с любыми драйверами.
Я удивлен, но в 2003-м году еще не перевились настоящие спецы и багу раскопали. Проблема оказалась в том, что в очень уникальном случае эта сигнатура при записи на CD-R совпадает с сигнатурой для сектора синхронизации и происходит сбой. Видимо, те кто писал прошивки к приводам дисков, полагали, что раз вероятность совпадения настолько низкая, что за все время существования cd-rom технологии она может не встретиться, то и принимать меры на столь потенциально редкий случай не стоит. Обезьяны не напечатают случайно барабаня по клавишам "Войну и Мир".
Тонкая ошибка в рассуждениях здесь заключалась в том, что действительно вероятность случайно встретить специфическую последовательность байт невелика, но она может возникнуть и неслучайно! Конкретно в той статье она возникла из-за поломки привода, который выдал синхропоследовательность вместо данных на диске. И вероятность такой поломки оказалась не так и мала.
Мораль сей басни такова: даже если некое событие имеет чрезвычайно низкие шансы встретиться, но не вовсе невозможно, в хорошей программе, стоит предусмотреть реакцию на него. Хотя бы потому что с оценкой шансов можно и ошибиться, причем так, что в голову не придет.
Здравствуйте, Michael7, Вы писали:
M>По результатам этой статьи: http://www.ixbt.com/optical/magia-chisel.shtml
M>Очень кратко суть: однажды на форуме ixbt заметили очень странную штуку, что оказывается есть файл, который, если записать его на CD-R(W) на большом количестве приводов потом нормально не считывается и это не связано с качеством болванки и записи, а только с уникальной сигнатурой внутри.
Спасибо за статью.
M>Мораль сей басни такова: даже если некое событие имеет чрезвычайно низкие шансы встретиться, но не вовсе невозможно, в хорошей программе, стоит предусмотреть реакцию на него. Хотя бы потому что с оценкой шансов можно и ошибиться, причем так, что в голову не придет.
Вывод неверный. В первую очередь нужно сосредоточиться на основных сценариях в приложении, которые возникают в 80%+ случаев. Те сценарии, которые возникают в 0.00001% случаев можно просто игнорировать. При появлении проблем просто поправить, ведь большая часть софта умеет обновляться проще, чем алгоритм записи дисков в CD-приводах.
Здравствуйте, Michael7, Вы писали:
M>Мораль сей басни такова: даже если некое событие имеет чрезвычайно низкие шансы встретиться, но не вовсе невозможно, в хорошей программе, стоит предусмотреть реакцию на него. Хотя бы потому что с оценкой шансов можно и ошибиться, причем так, что в голову не придет.
Еще веселее получается, когда разработчик, считая какую-либо величину случайной, строит поверх нее защищенность своего приложения. Из последнего: http://habrahabr.ru/company/pt/blog/149746/
Здравствуйте, kochetkov.vladimir, Вы писали: KV>Еще веселее получается, когда разработчик, считая какую-либо величину случайной, строит поверх нее защищенность своего приложения. Из последнего: http://habrahabr.ru/company/pt/blog/149746/
это баян еще времен первого нетскейпа
G>Вывод неверный. В первую очередь нужно сосредоточиться на основных сценариях в приложении, которые возникают в 80%+ случаев. Те сценарии, которые возникают в 0.00001% случаев можно просто игнорировать. При появлении проблем просто поправить, ведь большая часть софта умеет обновляться проще, чем алгоритм записи дисков в CD-приводах.
It depends.
Не дай бог разработчики ПО для АЭС примут такую рекомендацию .
Для банков, впрочем, тоже.
Здравствуйте, Michael7, Вы писали:
M>Мораль сей басни такова: даже если некое событие имеет чрезвычайно низкие шансы встретиться, но не вовсе невозможно, в хорошей программе, стоит предусмотреть реакцию на него. Хотя бы потому что с оценкой шансов можно и ошибиться, причем так, что в голову не придет.
Если я правильно понял, проблема в самой идее использовать какую бы то ни было последовательность в качестве основы синхронизации. Такой подход изначально некорректен.
Впрочем, я не очень разбираюсь в физике CD-привода, поэтому допускаю, что иного выбора просто нет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, gandjustas, Вы писали:
G>>Вывод неверный. В первую очередь нужно сосредоточиться на основных сценариях в приложении, которые возникают в 80%+ случаев. Те сценарии, которые возникают в 0.00001% случаев можно просто игнорировать. При появлении проблем просто поправить, ведь большая часть софта умеет обновляться проще, чем алгоритм записи дисков в CD-приводах.
PD>It depends.
PD>Не дай бог разработчики ПО для АЭС примут такую рекомендацию . PD>Для банков, впрочем, тоже.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, gandjustas, Вы писали:
PD>>>Для банков, впрочем, тоже.
G>>Ни те, ни другие этот форум не читают.
PD>Я знаю по крайней мере одного человека с RSDN, который принимал (правда, небольшое) участие в написании ПО для банка. Хорошо его знаю
Я тоже принимал участие в разработке по для банка, но это был не проессинг и для него верно то, что я написал.
M>Мораль сей басни такова: даже если некое событие имеет чрезвычайно низкие шансы встретиться, но не вовсе невозможно, в хорошей программе, стоит предусмотреть реакцию на него. Хотя бы потому что с оценкой шансов можно и ошибиться, причем так, что в голову не придет.
как бы то ни было на нижних (железных и околожелезных) уровнях это неизбежно.
Другой хороший пример -- это git -- он считает, что хэш двух разных коммитов не может совпадать, хотя чрезвычайно маленькая вероятность этого есть.
В твоем примере планируемая вероятность сбоя была видимо чрезвычайно низка и допустима.
Но из-за неправильной реализации она оказалась недопустимо высокой.
Скажем, если бы при записи привод шифровал информацию с новым сгенерированным паролем, то этого бы не произошло.
Но зато у такого решения были бы другие проблемы.
Здравствуйте, Pavel Dvorkin, Вы писали:
G>>Вывод неверный. В первую очередь нужно сосредоточиться на основных сценариях в приложении, которые возникают в 80%+ случаев. Те сценарии, которые возникают в 0.00001% случаев можно просто игнорировать. При появлении проблем просто поправить, ведь большая часть софта умеет обновляться проще, чем алгоритм записи дисков в CD-приводах.
PD>It depends.
PD>Не дай бог разработчики ПО для АЭС примут такую рекомендацию .
Такую рекомендацию используют, скажем, разработчики железяк для самолетов, и, наверное, ПО тоже. У них правда пороги не 80%, а повыше, но тем не менее, у них есть понятие "очень редко встречающийся дефект".
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Еще веселее получается, когда разработчик, считая какую-либо величину случайной, строит поверх нее защищенность своего приложения. Из последнего: http://habrahabr.ru/company/pt/blog/149746/
Использование в генераторе сессионных токенов md5 не является фактором, определяющим успешность той конкретной атаки. Ошибка разработчиков PHP заключалась не в использовании этого алгоритма. А вот цитате из статьи в википедии же следовало бы звучать так: MD5 should be considered cryptographically broken and unsuitable for further cryptographic use.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Не дай бог разработчики ПО для АЭС примут такую рекомендацию . PD>>Для банков, впрочем, тоже.
DM>В банках порой качество внутреннего софта ниже плинтуса.
Софт бывает разный. Один бумажки учитывает, другой процессит платежи или управляет активами. В последних случаях одно неловкое движение и огребете по полной.
Здравствуйте, gandjustas, Вы писали:
G>Вывод неверный. В первую очередь нужно сосредоточиться на основных сценариях в приложении, которые возникают в 80%+ случаев. Те сценарии, которые возникают в 0.00001% случаев можно просто игнорировать. При появлении проблем просто поправить, ведь большая часть софта умеет обновляться проще, чем алгоритм записи дисков в CD-приводах.
С точки зрения маркетинга — да, с точки зрения программиста — нет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не дай бог разработчики ПО для АЭС примут такую рекомендацию . PD>Для банков, впрочем, тоже.
О, Павел, вы, право же, переоцениваете банковский софт. Его глюкавость значительно выше среднего — по банальным причинам:
1. Во главу угла ставится вовсе не надёжность, а скорость обновления в ответ на быстроменяющиеся требования
2. Огромный объём функционала. Грубо говоря, для MS Word мы имеем примерно 500.000.000 пользователей. Даже если поделить их на ~1500 операций, доступных в ворде, и даже если учесть то, что самые редкие из них используются примерно на четыре порядка реже самых частых, мы всё ещё видим как минимум ежедневное использование каждой операции. Для банковского софта типична ситуация, когда количество возможных операций на порядок превышает количество пользователей. Тем более, что примерно 80% функций в нём делаются под запросы конкретного клиента.
3. Отсутствие возможности полного тестового покрытия. У типичного банка — терабайты данных; возможности "накатить апгрейд" на реальную базу и прогнать все регрессионные тесты нет даже в теории.
4. Низкая квалификация персонала. Из-за большого объёма работы, возможности держать маленькую сплочённую команду профессионалов нет; набирается народ с минимальными техническими познаниями, и после краткого натаскивания на используемые тулзы и библиотеки бросается в бой. Текучка кадров — значительная, т.к. задачи неинтересные, оплата невысокая, мораль — низкая.
В итоге, результат вполне предсказуем: низкокачественное ПО с огромным количеством ошибок.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
.
