Безнадёжно низкое качество ОС Линупс, Enterprise!

IvanOFF · 19-05-10 10:40:07

spoilt пишет:

Сугубо на взаимном уважении. Если разраб будет уважать пользователя, а пользователя будет уважать разраба, то их отоношения будут очень плодотворными.

О, куда вас понесло... Это уже нечто из области фантастики. В большинстве случаев разработчик ПО, особенно свободного, пользователю неинтересен, работает - хорошо, будем использовать, нет - не будем. Что, например вы, знаете о разработчиках какого нибудь пакета? Да ровным счетом ничего. И это нормально. У пользователя согласно принятой им негласной оферты одна обязанность - использовать ПО, у разработчика обязанностей побольше, но в общем и целом они сводятся к одному - сделать так, чтобы ПО максимально удовлетворяло потребности пользователя. Пользователь - существо капризное, чуть что не так - сразу снесет софтину и побежит к конкуренту.

MOP3E пишет:

В GPL оговорены пути получения прибыли: поддержка и продажа дистрибутивов (Emacs продавали по 5 долларов).

Оба пути получения прибыли, как бы это помягче, несостоятельны. Зачем платить за то, что можно взять бесплатно? Те, кто ищут бесплатный софт вряд ли купят поддержку к нему. Второе - чтобы продавать поддержку нужно иметь ресурсы для оказания этой поддержки и убедить клиента в том, что вы способны в случае чего эту поддержку оказать. А это далеко не просто, да и поддержка не всем нужна, это более востребовано для серверных и деловых продуктов, а если я пишу офисный пакет или графический редактор?

spoilt пишет:

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

Гладко было на бумаге... Один раз вляпавшись в GPL отмыться (закрыть код или выпустить его под другой лицензией) практически невозможно. Ибо все что вы написали уже не ваше, а дядюшки Столмана. Ну если только переписать весь код с нуля...

spoilt пишет:

Да тут один аргумент: серверная Ubuntu - это практически слепок Debian Squeeze где обитают только камикадзе. Вот в принципе и все.

Да, линуксаргументы - это сила! Это правильно потому что правильно, а это неправильно потому что это не "правоверно". Ваши высказывания дают основания заподозрить в вас фанатика, но никак не специалиста. Я все еще жду аргументов и фактов по вопросу: "почему Ubuntu Server не стоит использовать на серверах" или можно защитывать очередной слив?

spoilt · 19-05-10 17:35:03

IvanOFF пишет:

Что, например вы, знаете о разработчиках какого нибудь пакета?

Обычно в дистрах такую информацию узнают через сайт или багтрек. В Debian и в некоторых других имя мейнтейнера записывается в пакет (вместе с адресом мыла). Так что если у вас проблемы, то обращайтесь к мейнтейнеру проблемного пакета.

IvanOFF пишет:

Пользователь - существо капризное, чуть что не так - сразу снесет софтину и побежит к конкуренту.

С этим соглашусь. Лично я не стал ждать того когда разрабы почешутся и сделают Amarok 2 вменяемым. Перелез на Audacious.

IvanOFF пишет:

Оба пути получения прибыли, как бы это помягче, несостоятельны. Зачем платить за то, что можно взять бесплатно?

С этим конечно существуют проблемы и не всякий проект с ними справляется. Но есть пример и успешного использования открытого ПО в бизнесе: Red Hat.

IvanOFF пишет:

Ибо все что вы написали уже не ваше, а дядюшки Столмана.

Да вы просто Столмана не любите. Вот и все.
А вообще все в руках разраба (до первого релиза). Хочет берет BSD лицензию или вообще закрывает исходники.

IvanOFF пишет:

Да, линуксаргументы - это сила!

А у вас есть контраргументы? Рекомендую привести их немедля.
Вот недавно прошла конференция разработчиков Ubuntu, на которой также присутствовал президент проекта Debian. Было рассмотрено взаимодействие двух проектов и приведены такие цифры: 75% пакетов Ubuntu берутся из Debian без изменений.
Ссылка (документ PDF): upsilon.cc/~zack/stuff/debian-uds-m.pdf
По версиям пакетов сразу становится ясно что основным пулом пакетотв для Ubuntu становятся нестабильные ветки типа testing/squeeze и experimental/sid.
Недавно ветка Squeeze была заморожена, до исправления основного массива багов. Также было подсчитано количество критических багов: 370. Из этих критических багов уже исправлено 75.
Ссылка (вторая новость сверху): www.debian.org/News/project/2010/03/
Вы станете использовать дистр с таким количеством критических багов на сервере?

Отредактировано spoilt (19-05-10 17:35:31)

Manve · 19-05-10 19:53:44

spoilt пишет:

Вы станете использовать дистр с таким количеством критических багов на сервере?

А какое кол-во багов допустимо? Назовите, плиз, точное число. И что делать, если найдут еще один из-за которого будет превышен критический предел?

Отредактировано Manve (19-05-10 19:54:38)

spoilt · 19-05-10 20:02:56

Manve пишет:

А какое кол-во багов допустимо?

Шутите? На момент релиза критические баги должны быть полностью вычищены (именно поэтому Squeeze выйдет только к концу года). Менее критические или неклассифицырованные баги могут в принципе опустить. Если какой-то баг вскроется после релиза, то выйдет обновление для стабильной ветки.

IvanOFF · 19-05-10 21:32:04

За прошедшие два года, а мы начали использовать в продакшене Ubuntu Server начиная с 8.04, нареканий данный дистрибутив не вызывал. Из плюсов отмечу его логичность и отсутствие "фирменных" утилит управления, как показала практика, лучше уж по старинке, без них. С критическими багами не сталкивались. Обнаруженные нами проблемы, в т.ч. и с Самба, не являются проблемами Ubuntu, с Самбой точно такие же грабли в SuSE. Хотя результаты тестирования 3.4.7 с протоколом SMB2 (Win 7 / Vista) нас удовлетворили, на SMB (Win XP и ниже) есть проблемы со скоростью записи.

spoilt пишет:

Да вы просто Столмана не любите. Вот и все.

Честно? Столман мне глубоко параллелен, стараюсь не иметь дел с невменяемыми товарищами, однако Столман - фигура публичная, посему не упоминать его имени всуе не получится...

spoilt пишет:

Так что если у вас проблемы, то обращайтесь к мейнтейнеру проблемного пакета.

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

spoilt пишет:

Сугубо на взаимном уважении. Если разраб будет уважать пользователя, а пользователя будет уважать разраба, то их отоношения будут очень плодотворными.

Какие отношения, с кем? С мифическим разрабом, который где-то есть?

spoilt · 19-05-10 21:53:33

IvanOFF пишет:

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

Ну логичность там врядли сильно отличная от других дистров. А вот различными программами управления занимаются в лагере RPM.

IvanOFF пишет:

нареканий данный дистрибутив не вызывал

Значит вам очень повезло с дистрибутивом. Или с выбором ПО.

IvanOFF пишет:

Я не о том, в свете сказанного вами я решил поинтересоваться, а что вы знаете о разработчиках, кроме имени записанного в пакете, выяснилось - ничего. Что и требовалось доказать.

А что собственно я должен знать? Где он живет? Или сколько раз он нарушал правила ПДД? Или вы знаете все и вся о разработчиках Windows к примеру?

IvanOFF пишет:

С мифическим разрабом, который где-то есть?

Почему же сразу мифический? С разрабами всегда можно связатся либо по почте либо сразу на багтреке.

Отредактировано spoilt (19-05-10 21:55:25)

Manve · 19-05-10 23:40:19

spoilt пишет:

Шутите? На момент релиза критические баги должны быть полностью вычищены (именно поэтому Squeeze выйдет только к концу года). Менее критические или неклассифицырованные баги могут в принципе опустить. Если какой-то баг вскроется после релиза, то выйдет обновление для стабильной ветки.

Вы написали, что с "таким" кол-во багов систему использовать нельзя. Меня интересует позволительное кол-во багов. Какое оно? Или это переменная, изменяющаяся от названия операционки?

Кстати, то, что сечас обсуждается в этой ветке, хорошо изложено в следующей статье:

www.ixbt.com/editorial/fishday/fishday-16.shtml

Уверен, что многие линуксоиды ее читали. Но содержимое статьи у них быстро забывается.

Manve · 19-05-10 23:53:11

spoilt пишет:

Почему же сразу мифический? С разрабами всегда можно связатся либо по почте либо сразу на багтреке.

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

Вот вам и уважение.

spoilt · 20-05-10 00:13:57

Manve пишет:

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

Если мейнтейнер дистра такое выскажет в публичном багтреке, то автоматом вылетит из проекта.
Хотя увы, неадекваты бывают везде.

Manve пишет:

Вы написали, что с "таким" кол-во багов систему использовать нельзя. Меня интересует позволительное кол-во багов. Какое оно? Или это переменная, изменяющаяся от названия операционки?

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

Manve пишет:

Кстати, то, что сечас обсуждается в этой ветке, хорошо изложено в следующей статье:

Спасибо, я уже читал. Мое мнение можете увидеть на соответствующей странице обсуждения (на главвной).

Отредактировано spoilt (20-05-10 00:15:22)

Manve · 20-05-10 00:53:23

spoilt пишет:

Если мейнтейнер дистра такое выскажет в публичном багтреке, то автоматом вылетит из проекта.
Хотя увы, неадекваты бывают везде.

А если он один? Скажете такого не бывает?

Да даже если и не один - вы считаете нормальным "вышвырнуть" человека, который пилил проект не из-за денег, экономя тем самым на разработке?

spoilt пишет:

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

Так все-таки? 370 - это по-вашему "неприемлимо".

А 50 ? 100? 150?

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

Очень мне хочется знать это число "Х", а также понять почему Х+1 - уже неприемлимое кол-во багов.

Отредактировано Manve (20-05-10 00:56:29)

IvanOFF · 20-05-10 01:04:41

spoilt пишет:

Или вы знаете все и вся о разработчиках Windows к примеру?

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

spoilt · 20-05-10 01:10:54

Manve пишет:

вы считаете нормальным "вышвырнуть" человека, который пилил проект не из-за денег, экономя тем самым на разработке?

Если он постоянно будет хамить пользователям и переводить баги из категории Critical в Unclassified просто потому что у него плохое настроение, то на месте руководителя я бы его выгнал.

Manve пишет:

Так все-таки? 370 - это по-вашему "неприемлимо".
А 50 ? 100? 150?

Вы невнимательное читаете. Я же русским по-белому написал что 370 - число критических багов. Также я написал что все эти 370 багов должны быть исправлены до выхода Squeeze в релиз. Следовательно ваше X=0. Я доходчиво обьяснил?

Manve · 20-05-10 06:25:14

spoilt пишет:

все эти 370 багов должны быть исправлены до выхода Squeeze в релиз. Следовательно ваше X=0. Я доходчиво обьяснил?

Должны? Разве вам разработчики ПО что-то должны? Ведь все основано на уважении )))

А если серьезно, то при рассмотрении использования того или иного ПО наличие в нем багов играет далеко не первостепеную роль.

spoilt пишет:

то на месте руководителя я бы его выгнал

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

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

MOP3E · 20-05-10 06:48:59

spoilt пишет:

Также я написал что все эти 370 багов должны быть исправлены до выхода Squeeze в релиз.

Ты здесь также писал, что:

spoilt пишет:

А с какого перепугу сообщество что-то должно? Читайте лицензию GPL, там прямым текстом написано что AS IS.

Такие дела...

spoilt · 20-05-10 09:47:22

MOP3E, а что вас собственно смущает? Первое - результат эффективного взаимодействия с пользователем (исправление багов). А второе - это прекращение такого взаимодействия по причине неадекватности какой-либо стороны.

MOP3E · 20-05-10 17:46:34

spoilt пишет:

MOP3E, а что вас собственно смущает? Первое - результат эффективного взаимодействия с пользователем (исправление багов). А второе - это прекращение такого взаимодействия по причине неадекватности какой-либо стороны.

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

Manve · 20-05-10 20:00:20

Spoilt, скажите, а вы даете себе отчет в том, что выпустить ОС с нулевым кол-вом багов просто нереально?

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

Linups_Troolvalds · 20-05-10 22:05:23

Manve пишет:

Spoilt, скажите, а вы даете себе отчет в том, что выпустить ОС с нулевым кол-вом багов просто нереально?

Нулевым не нулевым...но вот скажите, каково количество багов в ОС QNX версии 4.25?

spoilt · 20-05-10 23:33:33

Manve пишет:

Spoilt, скажите, а вы даете себе отчет в том, что выпустить ОС с нулевым кол-вом багов просто нереально?

Кажется вы не очень знакомы с тем как выявляются и учитывается баги в ПО. Позвольте обьяснить. В любой какой-либо сложной системе (будь то программа или микросхема) всегда найдутся ошибки. Это практически аксиома. Часть ошибок проявляются сразу при тестировании новой версии ПО. Такие баги висят в багтреке и разработчики исправляют их в зависимости от критичности бага. Те 370 багов в Debian Squeeze состоят в категории Critical. Это означает, что установленное ПО неправильно собрано или же есть конфликт с библиотеками, иначе говоря таким ПО пользоватся зачастую невозможно. Такие баги были обнаружены при тестировании и известны разработчику. Но тестирование не может зачастую охватить весь функционал ПО или же не может проверить все состояния программы. То есть тестирование не может охватить все 100% багов. Какая-то часть багов остается скрытой, до тех пор пока в системе не наступит необходимое состояние, при котором баг себя проявит.
То есть 370 - это цифра известных багов, сколько же сокрытых багов - величина неизвестная (это так называемая неопределенность). Путем увеличения эффективности тестирования ПО являются: увеличение участников тестирования или увеличение времени тестирования. В некоторых дистрах устроена мощная система внутреннего тестирования пакетов, что сильно уменьшает количество багов в итоговом продукте. Но так как всегда существует неопределенность, то скрытые баги всегда могут себя проявить. И это реальность практически для любой системы.

МОРЗЕ пишет:

любые требования что-то улучшить в "свободной" программе являются априори неадекватными.

Да нет. Это просто таким вы желаете видеть СПО, Вот и все.

Отредактировано spoilt (20-05-10 23:35:18)

Manve · 21-05-10 00:18:57

spoilt пишет:

Кажется вы не очень знакомы с тем как выявляются и учитывается баги в ПО. Позвольте обьяснить. В любой какой-либо сложной системе (будь то программа или микросхема) всегда найдутся ошибки. Это практически аксиома. Часть ошибок проявляются сразу при тестировании новой версии ПО. Такие баги висят в багтреке и разработчики исправляют их в зависимости от критичности бага. Те 370 багов в Debian Squeeze состоят в категории Critical. Это означает, что установленное ПО неправильно собрано или же есть конфликт с библиотеками, иначе говоря таким ПО пользоватся зачастую невозможно. Такие баги были обнаружены при тестировании и известны разработчику. Но тестирование не может зачастую охватить весь функционал ПО или же не может проверить все состояния программы. То есть тестирование не может охватить все 100% багов. Какая-то часть багов остается скрытой, до тех пор пока в системе не наступит необходимое состояние, при котором баг себя проявит.
То есть 370 - это цифра известных багов, сколько же сокрытых багов - величина неизвестная (это так называемая неопределенность). Путем увеличения эффективности тестирования ПО являются: увеличение участников тестирования или увеличение времени тестирования. В некоторых дистрах устроена мощная система внутреннего тестирования пакетов, что сильно уменьшает количество багов в итоговом продукте. Но так как всегда существует неопределенность, то скрытые баги всегда могут себя проявить. И это реальность практически для любой системы.

Именно это я вам и пытался объяснить. Вы же назвали цифру 370 как неприемлимую. Более того, вы утверждали, что все 370 ДОЛЖНЫ быть исправлены:

spoilt пишет:

все эти 370 багов должны быть исправлены до выхода Squeeze в релиз

Кто должен и почему должен вы отказываетесь говорить. Более того, вы приводите GPL как доказательство того, что никто никому не должен. Для меня тут явно выраженное противоречие.

Также у вас всплывает термин "уважение". Каким образом это уважение влияет на качество продукта для меня все так же непонятно.

spoilt · 22-05-10 17:13:14

Manve пишет:

Более того, вы утверждали, что все 370 ДОЛЖНЫ быть исправлены

Все правильно и они будут исправлены.

Manve пишет:

Кто должен и почему должен вы отказываетесь говорить. Более того, вы приводите GPL как доказательство того, что никто никому не должен. Для меня тут явно выраженное противоречие.

Вообще толкование о багах в Squeeze было доказательством существования определенного риска в использовании Ubuntu в рабочей сфере. Не более того.
Касательно GPL: там есть такой пункт, что ПО поставляется на условиях AS IS (как есть). То есть разраб может выпустить одну единственную версию и преспокойно забить на ее поддержку. Но такое почти нереально. Все проекты СПО длительны по времени и выпускают много версий, поэтому разработчики, заинтересованные в развитии своего продукта, организовывают службы поддержки, пишут документацию и ночуют на багтреке. Вот и все.
Также эти условаия AS IS служат для открещивания от последствий использования программного продукта. То есть если на создателей ext4 накинется пользователь с аргументами типа: "Суки, фаша ФС грохнула мне весь фотоархив!! Я требую компенсации!!!", то, увы, разработчики его пошлют на основании условий лицензии.

Невропаразитолог · 22-05-10 17:34:51

spoilt пишет:

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

И эти люди смеют критиковать Майкрософт?!

spoilt · 22-05-10 18:35:23

Невропаразитолог пишет:

И эти люди смеют критиковать Майкрософт?!

Microsoft тебя пошлет в первый очередь.

Невропаразитолог · 22-05-10 19:06:11

spoilt пишет:

Microsoft тебя пошлет в первый очередь.

Как и вы. Так что вы (линуксята) от Майкрософта сильно не отличаетесь... Такие же сволочи. wink

spoilt · 22-05-10 19:16:45

Невропаразитолог пишет:

Как и вы. Так что вы (линуксята) от Майкрософта сильно не отличаетесь... Такие же сволочи.

А это текущая праткика программирования. Ничего более.

Форум StopLinux

Объявление

#101 19-05-10 10:40:07

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#102 19-05-10 17:35:03

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#103 19-05-10 19:53:44

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#104 19-05-10 20:02:56

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#105 19-05-10 21:32:04

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#106 19-05-10 21:53:33

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#107 19-05-10 23:40:19

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#108 19-05-10 23:53:11

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#109 20-05-10 00:13:57

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#110 20-05-10 00:53:23

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#111 20-05-10 01:04:41

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#112 20-05-10 01:10:54

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#113 20-05-10 06:25:14

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#114 20-05-10 06:48:59

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#115 20-05-10 09:47:22

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#116 20-05-10 17:46:34

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#117 20-05-10 20:00:20

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#118 20-05-10 22:05:23

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#119 20-05-10 23:33:33

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#120 21-05-10 00:18:57

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#121 22-05-10 17:13:14

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#122 22-05-10 17:34:51

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#123 22-05-10 18:35:23

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#124 22-05-10 19:06:11

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

#125 22-05-10 19:16:45

Re: Безнадёжно низкое качество ОС Линупс, Enterprise!

Подвал форума