Для затравки загадка: почему 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. Те, кто изменил поведение де-факто без оповещений заранее.

Ствол поставил. Многие непонятные раньше вещи типа «смешная китайская приблуда хз зачем» при установке стали нужными и понятными =)

Завтра сборка гирбокса.