Показательные выступления на льду.

[metaclass]

Но надо сказать, что последние пляски с Qt, glibc и дебианами, а так же закономерная реакция линукс-френдленты на описание оного хорошо демонстрируют почему с софтом под линукс все так "хорошо".
Софт для end-юзеров и прочие приземленные вещи далеко не всегда пишут отмороженные гики с десятилетним опытом решения бессмысленных безумных проблем. Достаточно походить по форумам по .NET например - там огромное количество вопросов, показывающих, что в ИТ работает много _начинающих_ людей. И вот оным начинающим развлечения, подобные тому, чем я занимался вчера - совершенно ни к чему. Не должен обобщенный "программист кульных прог для бухгалтерии Вася Пупкин" сразу разбираться в тонкостях библиотек, порядка их поиска, версий компиляторов и прочей хреновине. Это должно идти потом, когда софт уже заработал, был продан и надо его улучшать, выпускать новую версию и есть на этот бабки, полученные от продажи первой версии.

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

Не говоря уже о факапах вроде "приехали показывать софт тендерной комиссии, а там НИЧЕГО не запустилось, потому что линукс не той системы" - такое вообще недопустимо, между прочим.

Comments

[vp.livejournal.com]

Изначально, в корне разная постановка задачи. Мы ставим задачу как распространение СОФТА для ЦЕЛЕВЫХ СИСТЕМ. То есть считается, что у клиента уже есть система, и техника есть, и мы не вправе напрягать его покупкой +1 компьютера и тем более, навязывать систему. Потому что если мы станем навязывать, то для простоты и мейнстримовости мы навяжем винду. А тут именно замах на совершенно другой рынок.

[abbra]

О том и речь -- хотите быть совместимым с как можно большим числом платформ "по-правильному"? Используйте LSB -- последняя редакция 3.1. "Не по-правильному"? Таскайте все необходимое с собой в /opt/, так делают многие проприетарные приложения. "Совсем не по-правильному"? Собирайтесь статически.

[theiced.livejournal.com]

Ещё один фанатик - они хотят (и правильно хотят) просто зарабатывать денюжку. И то что кастомер может и не поставить LSB-compatible дистр не должно этому мешать. Поэтому `по-правильному` - это все-либы-с-собой или статика, а LSB как раз - удел фанатиков.

[abbra]

Я фанатик? :)

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

Но какое это имеет отношение к персонификации комментариев?

[theiced.livejournal.com]

То что сферических лсб-компатибл (да ещё и ПОСЛЕДНЕЙ версии) в природе мало. А у кастомера будет стоять слакварь какой

[abbra]

А вот это все зависит от толщины вендора, как я говорил выше. Сферических мало, а вполне конкретных -- достаточно много. LSB3.1 -- это приблизительно 2006 год. Вот список формально сертифицированных для x86: http://ldn.linuxfoundation.org/lsb/distro-component-matrix?filter0=25&filter1=695

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

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