http://www.codeproject.com/KB/web-security/StuxnetMalware.aspx

Ну, да, баян. Тем не менее, считаю статью интересной. В ней описывается сложнейший червь, известный даже на данный момент, который является ответственным за поломки центрифуг в иранской ядерной программе в 2009-2010 годах.

Одно из свидетельств того, что делали это серьёзные люди с серьёзными целями — вирусная часть червя была подписана сертификатом, выданным корпорацией Verisign корпорации Realtek. Говорят, что сертификат был украден напрямую из офиса последней.

Must have for anyone.

Ну, по крайней мере, для любого, кто называет себя «разработчиком на t-sql».

В проект papirus.net ищу разработчика. Полный рабочий день, офис на м. Сокол, Москва.

Что делать:

• Писать хороший и удобный для обычных юзеров (не айтишников) UI на JS + CSS + HTML. UI под мобильники и нет. Под разные браузеры под разными ОС
• Писать не тормозящий бэкенд на C#.
• Иногда писать запросы к БД (но редко) на t-SQL.
• Искать и внедрять новые технологии, которые улучшат проект.

Что дадим:

• Денег (базовая вилка 70-90 т.р., но всё обсуждается в конце с директором фирмы индивидуально).
• Хорошее рабочее место (кампутер, почти безлимитный инет, 24″ монитор).
• Немного еды за счёт фирмы (бутерброды, каши быстрого приготовления, йогурты, твороги, сыры, колбасы, фрукты, чай, кофе).
• Относительно свободный график (после испытательного срока).
• Замечательный коллектив (всего около 20 человек, но над этим проектом работают трое).
• Отлаженный рабочий процесс (недельные релизы, скрум-митинги по четвергам, автобилд, перфорц и прочие радости).

Для затравки загадка: почему Windows Vista и Windows 7 занимают по 20 и более гигабайт? Ответ в конце поста.

Итак, один из штатных троллей канальчека danvolodar сделал вброс на тему полугодовой давности. Тема следующая: разработчики glibc в линуксе привели поведение memcpy в соответствие со стандартом и всякий софт начал из-за этого падать (потому что клухацкеры полагались на недокументированное поведение). Для начала закопипастю свою позицию по данному конкретному случаю:

Есть много денег, как у Майкрософта — лепи костыль для каждого кулхацкера (как, например, поддержка SimCity и прочего). Нет много денег, как обычно, следи, чтобы документированное работало как работало. В целом, виноваты, кулхацкеры, использовавшие недокументированные фичи.

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

У нас есть стандарт языка Си. Этот стандарт нужен не только для линукса на х86 и х86-64, но также и для линукса на всех остальных архитектурах, а также для Винды, юникса и прочих поделок. Это удобно. Ты пересаживаешься на новую ОС/другую архитектуру и ты знаешь, какого поведения ожидать от той или иной функции рантайма. Именно для этого стандарт и был создан. Поэтому, если находим баг в реализации стандарта, его надо исправлять. Обязательно. Или документировать различие, в случае если исправление нецелесообразно.

Тут сразу же встаёт проблема совместимости, когда сторонние разрабы-кулхацкеры, которые использовали твою реализацию стандарта, полагаясь на недокументированные бажные фичи, начнут плакать «аааа, у нас всё упало, верните как было». Так было, есть и будет. Разработчика-кулхацкера не интересует соответствие стандартам, его не интересует, что реализацию стандарта использует куча других людей. Ему нужно, чтобы его маленький хак работал и не надо было ничего делать. Вполне логичное поведение.

Эту проблему можно решать двумя способами.

1. Мы вносим в документацию изменение: «идите нахер со своими стандартами, у нас будет вот так». Этот вариант хорош тем, что не надо ничего делать. Плох тем, что наша реализация отличается от стандарта, новый человек будет неприятно удивлён, когда об этом узнает => кривая обучения становится круче. Надо знать не только стандарт, но и кучу маленьких хачков, прикрученных ради неумех.
2. Придумать способ сосуществования разных версий одного и того же модуля, даже если атрибут «версия» у них одинаковый. Это стоит а) денег (в виде работы проектировщиков, разработчиков и т.д.); б) места на жёстком диске юзера. Именно поэтому последние версии виндов так дохера занимают место.

Способ 2, реализованный в Майкрософте относительно прост и туп. При линковке в EXE записывается не только версия dll, но и хеш той конкретной длл, с которой мы линкуемся. А винда хранит кучу версий этот длл и умеет найти нужную дллку по хешу. В результате, у нас есть более новые версии библиотек с исправленными багами и старые версии библиотек для софта, который использует недокументированные фичи. Все довольны и счастливы. Почему так нельзя сделать в линупсе мне непонятно.

Способ 2, реализованный у Apple, проще и тупее. Там просто каждая программа таскает за собой все необходимые ей библиотеки с собой. И никаких проблем нет.

Вернёмся к нашим баранам. Предложенное Линусом решение — сделать memcpy алиасом memmove — абсолютно неприемлимо. Потому что, кроме 1% от всех десктопов, у Линукса есть ещё минимум 18% «встраиваемых устройств» (роутеры, свитчи, мобилы, пылесосы, станки, военные чипы всякие и пр.), которые ещё не вылезли в рай двухгигагерцовых процов и гигабайтов памяти. И, скорее всего, не вылезут. И им разница между memcpy и memmove важна и критична до сих пор. И эти 18% в абсолютном исчислении в разы больше, чем 1% от десктопов. Наиболее правильное решение в условиях линуксоидов (малый бюджет, етс) было предложено на рсдн тогда же, полгода назад:

1. На уровне молока матери билд-системы разделение на DEBUG и RELEASE билды, вместо самописных велосипедов в половине make-файлов.
2. За год до изменения модифицируем debug-версию memcpy(), чтобы там вылетал ASSERT() в случае пересекаюшихся буферов.
3. Даем девелоперам год на фикс. Пишем об этом явно и везде.
4. Спустя год, меняем release-реализацию.

Но линуксоидам же нахер не надо этого делать, им надо поорать друг на друга «ты мудак и твоя реализация говно». Это, кстати, показывает всю суть текущей реализации опен-сорца в большинстве проектов. Когда Линусу или ещё кому предъявляешь претензии (например, по дохера не закрытых критических багов годами), они говорят: это опен-сорц, возьми да исправь сам, а не хочешь — жри, что дают, бесплатно же. Когда же делаешь так с ними (см. разрабов glibc), то вой до небес: «как вы смели, моя софтинка падает, мне править некогда, вы — мудаки».

Теперь не менее важное, кто виноват в данном конкретном случае (в порядке убывания):

1. Те, кто посадил в 1993м году багу и 17 лет не правил.
2. Те, кто использовал этот баг.
3. Те, кто изменил поведение де-факто без оповещений заранее.

Вы знаете, тут везде плач Ярославны по поводу смерти Symbian’a. Я скажу как разработчик. За такое надо убивать. И нажмёшь ты кнопочку сразу, или через пять минут — это не важно и ни на минуту не приблизит тебя к моменту старта эмулятора. Эмуляторы iPhone, Blackberry и Windows Mobile так не делают.

Надо кому? А то я вчера поставил всё. Всё удовольствие — 11 гигабайт.

Шрёдинбаг (англ. Schrödinbug) — термин, используемый в программировании для описания программной ошибки, которая никак не проявляет себя, однако внезапно возникает, если кто-то наткнётся на неё в исходном коде или попытается использовать программу в необычных условиях и осознаёт, что система вообще не могла работать при наличии такой ошибки. После этого программа перестаёт работать вообще до тех пор, пока ошибка не будет исправлена.

Вот у меня проект только из них и состоит.

С бубном, плясками и двумя ребутами вогнал ногами Mac OS в VMWare.

А автокорреция iPad’a предлагает менять aensidhe на webforms.

Знаете, вот иногда я готов убивать. Например, за код вида:
private void F()
{
    if (condition)
    {
        // do nothing
    }
    else
    {
        if (condition2)
        {
            // do nothing...
        }
        else
        {
            ....
        }
    }
}


Сложно написать так что ли?
private void F()
{
    if (condition)
        return;
    if (condition2)
        return;
    ...
}