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

[metaclass]

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

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

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

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

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

Comments

[thesz.livejournal.com]

http://metaclass.livejournal.com/367978.html
http://metaclass.livejournal.com/367787.html
http://metaclass.livejournal.com/367187.html
http://metaclass.livejournal.com/366207.html

Вот я твои (и не очень твои) проблемы привёл. Что-то я там не вижу "В монолитной виндовой проприетарщине же если что-то ломается - очевидно, первым этапом можно пойти поиметь мозг автору."

Сравним, например, количество софта под Линукс и Виндовс. Под Линукс по умолчанию его больше на порядок, а то и на два. И всё это воспринимается, как один Линукс. Тогда как Виндовс с такой же функциональностью будет восприниматься, как Виндовс/MS+MinGW/Cygwin+Adobe+много, кто ещё.

Теперь сравним ядра. XP/Vista это одно, а WinCE - другое. А linux kernel - это и XP, и Vista, и WinCE в одном флаконе. То есть, значительно сложней.

Так что за опровержением твоего тезиса не надо далеко ходить. Даже по твоему журналу. ;)

[a-lourier.livejournal.com]

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

[nivanych.livejournal.com]

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

Скоро закон выпустят.
Сейчас как раз формулируют.
"За разжигание..."

[nivanych.livejournal.com]

> самостоятельно исправлять чужой софт, по идее, не положено

Гм.
Вроде, Open Source изначально на том и построен...
Толкьо вот сейчас софт стал сложнее и исправлять сложнее.

[gds.livejournal.com]

тут есть несколько аспектов проблемы.
Первое, главное, психологическое -- заметно явное нежелание зависеть как-либо от других людей. Перекладывать на них часть своих обязанностей (это из какого-то соседнего поста), пользоваться результатами их трудов, заставлять их фиксить их баги. Если простор деятельности будет увеличиваться и дальше, можно просто утонуть в этих говномелочах. Это не слишком хороший вариант жизни.
Тут можно провести аналогию с распараллеливанием: пока задача влезает в один проц -- можно её решать в пределах одного проца эффективным алгоритмом, но если не влезает, то нужно распараллеливать на несколько процессоров, пусть даже применяя гораздо менее эффективные алгоритмы, но добиваясь хорошего времени отклика.

Второе -- можно хотя бы понять проблемы опенсорса (не говорю про "простить"). Объёмы и возможности кода несопоставимы. Чистая винда -- это очень малая функциональность. Сравнима разве что с linux kernel + libc + X Window (мог забыть что-то ещё). Версий винды мало по сравнению с версиями разного опенсорсного. Винда имеет концептуально одинаковые возможности, тогда как разные юниксы предоставляют разное.

Третье -- не обязательно лобызать тохес автору опенсорс-библиотеки. Для критичных по времени вещей я делаю так: собираю библиотеку с нужным мне патчем, и либо линкую статически, либо подкладываю динамически-загружаемые библиотеки рядом с программой. Даже билд-систему написал, которая эти патчи применяет при нужных условиях, собирает с ними, учитывает взаимные зависимости и всё такое. На 19 опенсорс-софтин у меня сейчас 25 патчей. Конечно, при наличии времени и желания и в зависимости от упоротости автора я отправляю эти патчи наверх.
Забавно бывает видеть, как патч на то, что я исправил, но не отправил, начинает обламываться из-за того, что авторы независимо от меня исправили это в новой версии :)
И в свете этого становится удивительно -- а как же изголяются пользователи закрытого софта, когда обнаруживают баг в каких-нибудь виндах или дельфях? Поправить-то нельзя. Только ждать новую версию или делать разной степени гадости обходные маневры.

[dmzlj.livejournal.com]

А на практике получается, что конторам, которые пишут софт который продают тебе за большие деньги - на тебя положить. А вот автора какой-нибудь опенсорсной как бы поделки вполне удается склонить сделать какие-то обновления и добавления, которые от конторы не дождешься никогда. Да и качество тоже, почему-то не в пользу проприетарщины. Чего далеко ходить - я вот прямо сейчас бурно переписываюсь с TI, Rowley и авторами "опенсорсных поделок". От последних, почему-то, толку больше. А чем больше контора - тем сильнее ей на тебя плевать.

[lupus-lupusum.livejournal.com]

а кстати, такое ли оно оупен, это ваше линукс.
компилируется оно gcc, к-й туда добавляет хз что, но похожее на мусор (зачем? про то неизвестно). gcc выпускается fsf а fsf финансируется производителями процессоров (опять же зачем? неясно).

[max-posedon.livejournal.com]

в теории на практике будет тоже самое что в теории, на практике получается иначе

Т.е. Идея конечно интересная, и вроде правильная, но вкорне расходится с суровой действительностью.

[guamoka.livejournal.com]

"определенная функция в определенных условиях не работает"


Именно такое впечатление создалось от использования SuSE:) В очередной момент без видимой причины что-то совершенно обыденное вдруг начинает идти наперекосяк.

[slonopotamus.livejournal.com]

> В монолитной виндовой проприетарщине же если что-то ломается - очевидно, первым этапом можно пойти поиметь мозг автору
Ну не смешно даже. Пофигу им что там у вас сломалось.

[lupus-lupusum.livejournal.com]

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