![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Еще одна юниксо-холиварная идея
Я вот подумал, что "в среднем" софт, сделанный, скажем так в идеологии опен-сорс-юникс-вея, будет содержать больше багов, чем монолитно-виндовско-проприетарный. Багов такого вида типа "определенная функция в определенных условиях не работает".
Вот к примеру: я пишу некий софт, и массово использую для него сервисы предоставляемые другими прогами. В особо безумных случаях - вообще софт может представлять собой эти проги с обвязкой из скриптов. Если софт сложный - то он еще и несколько различных интерпретаторов скриптов может за собой притащить. Но главное то, что это софт чужой. И если во взаимодействии между разными софтам что-то ломается - самостоятельно исправлять чужой софт, по идее, не положено - положено зарепортить баг, если это баг, или наделать костылей, если это by design так. И у юзера в итоге будет то же самое - что-то ломается во взаимодействии, а участвует в этом десяток прог разных авторов. Куды бежать - неясно.
В монолитной виндовой проприетарщине же если что-то ломается - очевидно, первым этапом можно пойти поиметь мозг автору. А тому, в общем-то, и проще все исправить, т.к. код у него под контролем, а если автор еще и вменяем, то от сторонних сервисов у него вообще ничего не зависит. "Не принято вносить зависимости". И т.к. участвует одна единица "автор" или "контора-разработчик", исправление внести проще, чем когда это дело сначала надо обсудить со всем комьюнити в мейл-листах, поцеловать иконы столлмана и торвальдса в спину, сделать сначала патч, потом внести его куда-нибудь в основную ветку, долждаться пока выйдет очередная стабильная версия, а потом пару лет отвечать юзерам "обновите такое-то софтино версию 2.x.y на 2.x.z, если у вас при откручивании гайки из пупка жопа отваливается".
Конечно, когда проприетарный софт такой стоит массово у юзеров - там возникают те же проблемы, типа как у винды с обновлениями и рунтаймами от VS. Хотя для прикладного софта проблемы в основном вызывает только второе(если на VS писать), с обновлениями он хоть и конфликтует но не часто.
В общем, идея в том, чтобы не плодить множество зависимостей и разных версий - тогда получится, что если проблема в какой-то версии есть - она есть у всех и у всех ее можно однообразно исправить, а не разбираться, не поломается ли от исправления все остальное.
Вот к примеру: я пишу некий софт, и массово использую для него сервисы предоставляемые другими прогами. В особо безумных случаях - вообще софт может представлять собой эти проги с обвязкой из скриптов. Если софт сложный - то он еще и несколько различных интерпретаторов скриптов может за собой притащить. Но главное то, что это софт чужой. И если во взаимодействии между разными софтам что-то ломается - самостоятельно исправлять чужой софт, по идее, не положено - положено зарепортить баг, если это баг, или наделать костылей, если это by design так. И у юзера в итоге будет то же самое - что-то ломается во взаимодействии, а участвует в этом десяток прог разных авторов. Куды бежать - неясно.
В монолитной виндовой проприетарщине же если что-то ломается - очевидно, первым этапом можно пойти поиметь мозг автору. А тому, в общем-то, и проще все исправить, т.к. код у него под контролем, а если автор еще и вменяем, то от сторонних сервисов у него вообще ничего не зависит. "Не принято вносить зависимости". И т.к. участвует одна единица "автор" или "контора-разработчик", исправление внести проще, чем когда это дело сначала надо обсудить со всем комьюнити в мейл-листах, поцеловать иконы столлмана и торвальдса в спину, сделать сначала патч, потом внести его куда-нибудь в основную ветку, долждаться пока выйдет очередная стабильная версия, а потом пару лет отвечать юзерам "обновите такое-то софтино версию 2.x.y на 2.x.z, если у вас при откручивании гайки из пупка жопа отваливается".
Конечно, когда проприетарный софт такой стоит массово у юзеров - там возникают те же проблемы, типа как у винды с обновлениями и рунтаймами от VS. Хотя для прикладного софта проблемы в основном вызывает только второе(если на VS писать), с обновлениями он хоть и конфликтует но не часто.
В общем, идея в том, чтобы не плодить множество зависимостей и разных версий - тогда получится, что если проблема в какой-то версии есть - она есть у всех и у всех ее можно однообразно исправить, а не разбираться, не поломается ли от исправления все остальное.
no subject
no subject
Я с разработчиками Firebird точно так же контактирую - они сами баги исправляют к очередному релизу (софт немелкий, сразу не исправишь), но если сильно нужно - можно самостоятельно исходники править.
У нашего софта цикл "обнаружение бага или требование фичи -> изготовление, документирование -> тестирование -> релиз и обновление" где-то от недели до двух занимает, если багофича мелкая. А крупные обычно за собой тянут еще и архитектурные исправления, поэтому месяц-два могут занять.
no subject