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

[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 в одном флаконе. То есть, значительно сложней.

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

[vp.livejournal.com]

Сравним, например, количество софта под Линукс и Виндовс. Под Линукс по умолчанию его больше на порядок

"Софт", которого "на порядок" больше - это 99% мелкие утилиты для потоковой обработки чего-либо из одной в другую. А прикладного софта - на порядок меньше.

[thesz.livejournal.com]

Не "всего софта на свете", а того, что идёт с дистрибутивом.

[vp.livejournal.com]

Ну, 1001 программа с исходниками в 500 строк. Что страшного? :)

[metaclass.livejournal.com]

Софта под линукс больше на порядок, а как что-то сделать - так народ wine ставит. Под линукс специфического рода софта много - мелкие утилиты, софт системного уровня, сервера там всякие. А прикладной обычно безумен, и страдает от той шизы, что я описал.

[thesz.livejournal.com]

По моему мнению, наша дискуссия страдает от излишней опоры на анекдоты.

Причём, самоопровергающиеся - человек по твоей ссылке жалуется на командную строку и маны, а сам делает sudo apt-get что-то-там.

Кстати, если у тебя есть возможность: присмотрись к "виндовой проприетарной фигне". У неё внутри, в случае сложной штуки, ровно такая же шиза.

Например, в исходниках того, что все считали одной из версий HL2 были аж две сторонних библиотеки физики. ;)

Я тут подумал, что то, о чём ты говоришь, на самом деле просто желание иметь единый рычаг "управления качеством". Так это и в мире открытых исходников есть: Red Hat, например.

Правда, я не могу за деньги для RHEL купить поддержку Хаскеля. Мне придётся заплатить сверху.

Не вижу проблем.

Более того, не вижу разницы в проблемах открытых исходников и частного софта.

[metaclass.livejournal.com]

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

[1847a.livejournal.com]

Зачем вайн? Можно же просто рядом положить ящик с виндой, от неё же никто не заставляет отказываться при использовании линукса.

[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]

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

[nivanych.livejournal.com]

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

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

[nivanych.livejournal.com]

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

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

[gds.livejournal.com]

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

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

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

[metaclass.livejournal.com]

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

[dmzlj.livejournal.com]

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

[metaclass.livejournal.com]

Так в том и суть - что у опен-сорсной поделки есть один автор. У тебя ж узкоспецифическая софтина, для отладки микроконтроллеров - радуйся, что она не зависит от всего комьюнити и не зависит строго от пакета с набором иконок с портретами торвальдса и столлмана версии 2.x.x:)
Я с разработчиками Firebird точно так же контактирую - они сами баги исправляют к очередному релизу (софт немелкий, сразу не исправишь), но если сильно нужно - можно самостоятельно исходники править.
У нашего софта цикл "обнаружение бага или требование фичи -> изготовление, документирование -> тестирование -> релиз и обновление" где-то от недели до двух занимает, если багофича мелкая. А крупные обычно за собой тянут еще и архитектурные исправления, поэтому месяц-два могут занять.

[dmzlj.livejournal.com]

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

[lupus-lupusum.livejournal.com]

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

[metaclass.livejournal.com]

Финансирование производителями процов - это очевидная идея, чем больше софта, тем больше их прибыль :)

[lupus-lupusum.livejournal.com]

Еще они могут хотеть, чтобы юзер покупал больше новых и дорогих процессоров. То есть, допоним: чем больше тормозного софта, тем больше их прибыль.

[dmzlj.livejournal.com]

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

Странно только, что самым быстрым компилятором при таком раскладе является именно icc, это как-то не вписывается в конь-цепцию.

[lupus-lupusum.livejournal.com]

ты не благородного происхождения и имеешь отвратительные манеры

[dmzlj.livejournal.com]

Ты норкоман что ле?

[metaclass.livejournal.com]

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

примерно так, ога :)

[max-posedon.livejournal.com]

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

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

[metaclass.livejournal.com]

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

[dmzlj.livejournal.com]

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

[guamoka.livejournal.com]

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


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

[lionet.livejournal.com]

http://lionet.livejournal.com/34978.html

[guamoka.livejournal.com]

Я думаю, моя оценка- всего лишь частное мнение, скажем так, среднего пользтователя в конкретно (правда, усредненной) ситуации. По крайней мере, я выступал в роли "среднего пользователя" в том, что не касалось непосредственно моей работы. Больше чем уверен, что с проблемами, с которыми столкнулся я, пытаясь выполнить свою скромную работу на SuSE, столкнется (и сталкиваются) большинство "средних" пользователей. Не говоря уже про тех, которые не имеют даже моего опыта. Я отнюдь не выступаю адвокатом дьявола:) Просто в моем данном конкретном случае Win платформа доставляла мне меньше неудобств, никак не зависящих от моего опыта работы с платформой, и которые, я считаю, не должны были отнимать у меня время на нахождение их причин/разрешение (если таковое вообще существовало).

[slonopotamus.livejournal.com]

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

[metaclass.livejournal.com]

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

[lionet.livejournal.com]

Что мне делать? http://lionet.livejournal.com/34978.html

[metaclass.livejournal.com]

Залогинится на машину локально и посмотреть event log для начала. Там могут быть всякие нездоровые коды ошибок в логах.
Гугл знает только про такие же проблемы, ответов там вроде бы нет.

Такое ощущение, что в висте неправильный код ошибки где-то возвращается, т.к. эта ошибка из совершенно другой оперы(удаление сетевого диска). Я бы сел на той машине локально с procmon и попытался бы отследить, что происходит при попытке логиниться в rdp.

[lionet.livejournal.com]

Залогинился "нормально". После этого RDS сразу стал работать. В эвент логе без исходников того, что привело к проблеме, думаю, разобраться нереально:



А ведь этим операционным граблям уже больше пятнадцати лет! Я имею ввиду, что с виндами нельзя рассчитывать на полностью удалённую работу: обязательно должен быть доступ к телу.

[metaclass.livejournal.com]

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

[vp.livejournal.com]

в принципе физический доступ по опыту не нужен кроме случая включить комп после пропадания питания.

[metaclass.livejournal.com]

Отключить файрволл еще.
И еще всякие действия связанные с безопасным режимом, удаленно их просто не сделаешь.

[vp.livejournal.com]

У нас сценарий внедрения проприетарщины сугубо законодательства РБ: внедрение, затем обязательный год гарантии (не сделаеш - суд - шишка -продажа почки). Затем по законодательству мы, как производитель продукта, ОБЯЗАНЫ обеспечить сервисную поддержку не менее чем 10 лет работы проприетарной системы.
Вот так и живем...

[lupus-lupusum.livejournal.com]

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

[metaclass.livejournal.com]

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

[dwatcher.ru (from livejournal.com)]

Кстати - если у юзера прога не работает, он полюбому пойдет иметь мозг разработчику. Даже если рядом исходники лежат - на себе прошел)