Еще одна юниксо-холиварная идея

[metaclass]

Я вот подумал, что "в среднем" софт, сделанный, скажем так в идеологии опен-сорс-юникс-вея, будет содержать больше багов, чем монолитно-виндовско-проприетарный. Багов такого вида типа "определенная функция в определенных условиях не работает".

Вот к примеру: я пишу некий софт, и массово использую для него сервисы предоставляемые другими прогами. В особо безумных случаях - вообще софт может представлять собой эти проги с обвязкой из скриптов. Если софт сложный - то он еще и несколько различных интерпретаторов скриптов может за собой притащить. Но главное то, что это софт чужой. И если во взаимодействии между разными софтам что-то ломается - самостоятельно исправлять чужой софт, по идее, не положено - положено зарепортить баг, если это баг, или наделать костылей, если это by design так. И у юзера в итоге будет то же самое - что-то ломается во взаимодействии, а участвует в этом десяток прог разных авторов. Куды бежать - неясно.

В монолитной виндовой проприетарщине же если что-то ломается - очевидно, первым этапом можно пойти поиметь мозг автору. А тому, в общем-то, и проще все исправить, т.к. код у него под контролем, а если автор еще и вменяем, то от сторонних сервисов у него вообще ничего не зависит. "Не принято вносить зависимости". И т.к. участвует одна единица "автор" или "контора-разработчик", исправление внести проще, чем когда это дело сначала надо обсудить со всем комьюнити в мейл-листах, поцеловать иконы столлмана и торвальдса в спину, сделать сначала патч, потом внести его куда-нибудь в основную ветку, долждаться пока выйдет очередная стабильная версия, а потом пару лет отвечать юзерам "обновите такое-то софтино версию 2.x.y на 2.x.z, если у вас при откручивании гайки из пупка жопа отваливается".

Конечно, когда проприетарный софт такой стоит массово у юзеров - там возникают те же проблемы, типа как у винды с обновлениями и рунтаймами от VS. Хотя для прикладного софта проблемы в основном вызывает только второе(если на VS писать), с обновлениями он хоть и конфликтует но не часто.

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

Comments

[a-lourier.livejournal.com]

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

[metaclass.livejournal.com]

Ага, хорошо придумано.

[zamotivator.livejournal.com]

Именно потому накатывать руками configure/make/make install будет только псих или идиот =)
А стабильные версии - на то они и стабильные, что в них только багфиксы и делаются.

[a-lourier.livejournal.com]

Не всегда. Когда прикладная задача требует версии пакета Y, а в стабильном дистрибутиве версия X < Y, то может возникнуть и необходимость ручной досборки нужной версии. Но, в любом случае, администратор уже знает, в каком месте могут возникнуть грабли, и будет готов их исправить.

[zamotivator.livejournal.com]

Ну более правильное решение в таком случае - это собрать новую версию пакета и заслать конфиги мейнтейнеру =)

[a-lourier.livejournal.com]

Более правильное, чем что? Собственно, это просто хороший тон - если нашёл баг, а, тем более, исправил его, поделиться с сообществом.