судьба softupdates

[netch80]

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

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

Судьба softupdates - отличный пример воздействия гордыни на результат.
Неплохая и полезная технология убита качеством реализации и заморочкой на
непогрешимость её автора, при непригодном к сопровождению и отладке коде:
- Включение и выключение требует сложных манипуляций с перемонтированием.
- Код ведёт свою ничем не управляемую жизнь. Даже обычный sync на него
не действует, хотя, казалось бы, что может быть проще.
- Рантайм-статистики нет.
- Средств рантайм-диагностики нет (даже просто снять список задержанных
микроопераций с их таймаутами и зависимостями). Так называемые опции
DIAGNOSTICS и DEBUG включают дай бог чтобы 2% необходимых проверок.
- Самоконтроля нет.
- Даже заготовок для подключения всего вышеперечисленного нет, из чего
можно сделать однозначный вывод - если автору потребуется что-то
диагностировать, ему придётся всё вписывать с самого начала.
- Код предельно сложной подсистемы (у которой и собственные нетривиальные
структуры и соотношения данных, и работа в условиях сложной ядерной модели
данных, и работа с нижними уровнями, у которых собственная сложная логика)
написан предельно неструктурно (не в смысле функций, но в смысле блоков и
подсистем). О том, что код такого типа всё-таки можно так писать, чтобы
выделять и тестировать основные блоки ещё до запуска программы - автор
представления не имеет.

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

Хотел бы я обойтись тут без комментариев про определённые личные качества
автора данной реализации, но когда его ближайший друг уже 20 лет всеми
силами избегает элементарного рефакторинга там, где слои реализации
громоздятся друг на друге уже в 4-5 слоёв и отдельные части может понять
только тот, кто работает с этим уже лет десять - не могу обойтись.;)

P.S. А самая большая фигня тут в том, что в соседнем лагере ничуть не
лучше.

Comments

[blacklion.livejournal.com]

но когда его ближайший друг
Ржал так, что чуть не разбудил дочку…

[blacklion.livejournal.com]

Впрочем, разве не весь UFS написан этим автором?.. Эх.

[netch80.livejournal.com]

Я старался говорить предельно корректно:)

[egorfine.livejournal.com]

"P.S. А самая большая фигня тут в том, что в соседнем лагере ничуть не лучше"

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

Нетч отправдал, Нетч последовательный!

[netch80.livejournal.com]

Нее, если кто-то тут последовательный то это ты:) когда решил, что "соседний лагерь" это именно Linux.:))

[egorfine.livejournal.com]

...а если серьезно, то в соседнем лагере более-менее сходная картина наблюдается с glibc. Дреппер очень жесток.

[netch80.livejournal.com]

Ты в первую очередь вспоминаешь тему с проблемами mysql?

[egorfine.livejournal.com]

да, потому что

a) весьма показательна
b) человек тот же

[blacklion.livejournal.com]

Кстати, интересно — каких сил будет стоить написать almost drop-in sendmail replacement? Ну, almost, потомучто ВСЁ покрыть невозможно, но, с другой стороны, куому нкжна поддержка битнетов и полных path-адресов в наше время?
А вот так, что бы любой разумный конфиг на инсталляции последних 5-6 лет подцепился бы и заработал…

[netch80.livejournal.com]

А смысл делать именно так? Если делать replacement - надо взять текущий и применить к нему напильник "рефакторинг" нужное количество раз в нужных местах. А если нужна замена и допускается другой конфиг и многое другое - так на это есть exim...

[blacklion.livejournal.com]

Рефакторинг требует покрытия кода юнит-тестами. Иначе это не рефакторинг, а чёрт знает что.

[netch80.livejournal.com]

Ну я систематически использую рефакторинг без всяких юнит-тестов. Ты исходишь в понимании этого слова из полной методики Фаулера & Co, а мне это малоинтересно - я так назову любое преобразование структуры программы без изменения функциональности, но в сторону, способствующую новому изменению.

А тесты... я не думаю, что что-то сильно мешает применить их к sendmail'у.:)

[blacklion.livejournal.com]

Мне было бы просто СТРАШНО рефакторить такой код без тестов :)

А тесты ещё написать надо. И, боюсь, при сложности сендмейла это очень нетривиальная задача.

[netch80.livejournal.com]

Для того, чтобы можно было тестировать, надо вывести внутри достаточное количество модулей типа "белый ящик" с понятной логикой, но при этом завязанной на фиксированное количество внешних сущностей. Например, код отработки алиасов будет получать окружение в виде режима работы (насколько он влияет); раскрываемые алиасы; затычку, которая вместо реального лукапа на диск лезет к специально придуманному map'у; контроль выходного результата Всё это, конечно, не так просто реализуемо, как "подать 2 и 3 и проверить, что функция выдала 6", но таки реализуемо.

И в любом случае это лучше понимаемо и тестируемо в итоге, чем тот многослойный бред, который, например, внутри sendall().

[p1r4nh4.livejournal.com]

А зачем? Чтоб конфиг тот же оставить?

[anatoly borodin (from livejournal.com)]

чоrт, желание написать диссер про кодогенерацию драйверов файловых систем с каждым днём всё больше и больше :)

[knyar.livejournal.com]

ZFS нас спасёт.

[netch80.livejournal.com]

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

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

[blacklion.livejournal.com]

На 64-х битных платформах у ZFS проблем немного…

[knyar.livejournal.com]

У меня уже на полудюжине тазиков (7-stable, amd64, 2-4G RAM) ZFS безо всяких нареканий колбасится. Есть zpool'ы и на mirror'е, и на raidz, активно используются снапшоты. Главное вдумчиво нарисовать boot.config.