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

[metaclass]

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

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

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

Comments

[kiryl.livejournal.com]

Ещё раз -- соберите пяток пакетов под все дистрибутивы, которые встречаются у заказчиков. Это пол дня работы, если с нуля разбираться.

[vp.livejournal.com]

Вот то то и оно что не знаем, что у клиента встречается.
А "собрать пяток пакетов" я расскажу что такое. Это минимально 10 дней работы. Потому как у нас политика качества требует билда + 2 дня тестирования того что набилдилось тестами в т.ч. и с участием человека. Все это неслабо отразится в денежном выражении на стоимости продукта.

[kiryl.livejournal.com]

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

[vp.livejournal.com]

Ответ
Выходит исправление программного продукта, которое тянет за собой если нужно обновленные библиотеки, которые будут заменены при обновлении. Пользователю это даже знать не нужно.
Зато исключается ситуация, когда пользователь сам поменял commoncoollib32.dll на "более свежую" и не тестировавшуюся, и все сдохло. Это много хуже.
Подходы совсем иные, сборки тестируются и ГАРАНТИРУЮТСЯ производителем софта.

[kiryl.livejournal.com]

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

Про гарантию рассмешили.

[metaclass.livejournal.com]

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

[metaclass.livejournal.com]

Админ в норме всегда должен поддерживать контакт с вендорами софта, а не обновлять по велению задней левой пятки.

[kiryl.livejournal.com]

Библиотеку обновляет не админ, а мэйнтэйнер библиотеки в дистрибутиве, т.е. человек понимающий что-то в abi.
А изолироваться от безопастности -- это отличная идия!

[theiced.livejournal.com]

Ребе, я вам таки рассказываю как делать.

1. Внимательно смотрим на скайпы, оперы и прочую `гнойную пропиетарщину` (ц) и разбираемся как сделано там. Смотеть на LD_LIBRARY_PATH, LD_PRELOAD и статическую линковку. В принципе виндовз/макос-лайк подход - всё своё носим с собой.

2. Сразу ложим ху*й на поддержку 100500 дистрибутивов. Отдаём тарболл или инсталлируемый сш скрипт (аля нвидия например). Если кому будет надо - опакетируют сами.

3. Обязательно тестируем на 2-3ёх версиях глибц (ну или его с собой тоже таскаем, но это моветон и оверкилл уже имхо).

4. Не забываем потестировать на 64битных x86 дистрах (на экзотику вида ппц мы же как разумные люди забьём, правда).

PS. Список дистрибутивов на которых надо тестировать (в порядке убывания важности): Ubuntu, Fedora, OpenSUSE. Всё. Больше ничего в принципе нигде не используется.

PPS. Дебиан как замена убунту не катит - это уже, к счастью, совсем разные дистрибутивы.

[theiced.livejournal.com]

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

Для гикодминов - держать спец версиюю без разных там либ, а то вони не оберёшься - а как же без секса то.

[vp.livejournal.com]

Тебе смешно, а нам жизнь

[theiced.livejournal.com]

>Да ладно тебе, "правильней организовано", WinSxS появился для решения проблемы dll-hell'а.

Кто кстати мешает в виндовзе называть lib-1.dll, lib-2.dll, ...? Кое что так и называется (mfc, dx, libc).

>В лине dll-hell by-design невозможен.

Возможен. Плюс к этому возможен так же dependency hell и zealot hell.

>Сюрприз - ldconfig автоматически завоётся при установке пакета.

Сюрприз - не запускается, а его кто-то таки запускает.

>Какой путь правильный? Собрать инсталятор! Это deb пакет.

Вот - zealot hell в чистом виде. Если уж мы говорим о самом распространённом формате - то это будет очень даже rpm а ни разу не deb, но фанатикам этого не понять.

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

И все `если дебиан такой то - то зависимости такие то`. А потом приезжаем к кастомеру - а у него - сюрприз - не дебиан а слакваре.

>В общем, берёшь cmake, настраиваешь билдинг-систему (в windows cmake генерирует на сборку студийные проджекты, в лине make-файлы, дружит), а все разработчики просто чекаутят сорцы.

У ребе какбэ Qt в котором есть qmake. Нахрена ему ещё и cmake затачивать?

[theiced.livejournal.com]

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

[zamotivator.livejournal.com]

Кто кстати мешает в виндовзе называть lib-1.dll, lib-2.dll, ...? Кое что так и называется (mfc, dx, libc).
Если бы рантайм CRTшный также назывался.
И если бы все так свои библиотеки называли.
Да и сборок mfc сущесвует как бы больше четырёх, и их называют одинаково...

[zamotivator.livejournal.com]

Возможен. Плюс к этому возможен так же dependency hell и zealot hell.
Также существует штатный, чёткий путь решения этой проблемы. В отличие От.

Сюрприз - не запускается, а его кто-то таки запускает.
Сюрприза нет, но есть вопрос - а что меняется?

Вот - zealot hell в чистом виде. Если уж мы говорим о самом распространённом формате - то это будет очень даже rpm а ни разу не deb, но фанатикам этого не понять.
Фанатики вообще не вникают. Речь про debian? Про debian. Вот потому про дебы и говорю. А вообще говоря форматов три штуки - tar.gz, rpm, deb. +некоторое количество под каждый из дистров.

И все `если дебиан такой то - то зависимости такие то`. А потом приезжаем к кастомеру - а у него - сюрприз - не дебиан а слакваре.
См. выше, плюс данная проблема решается один раз - под следующий слякварь у нас уже есть сборка . Число разных дистров (продакшн) меньше десяти.

У ребе какбэ Qt в котором есть qmake. Нахрена ему ещё и cmake затачивать?
Вы явно не работали с Qt и линуксом плотней. Самого qmake достаточно для qt аппликух, и достаточно кое-как. Как только нужно подключать ещё парочку сторонних библиотек и делать сборки - qmake начинает резко не хватать.

[theiced.livejournal.com]

>Также существует штатный, чёткий путь решения этой проблемы. В отличие От.

Но имеем то что имеем - жуткий dependency и zealot hellы в дебиане. У вас там амарок от мусикль клиента зависеть уже перестал? Не?

>Сюрприза нет, но есть вопрос - а что меняется?

То что инсталлера может не быть.

>Фанатики вообще не вникают. Речь про debian? Про debian. Вот потому про дебы и говорю. А вообще говоря форматов три штуки - tar.gz, rpm, deb. +некоторое количество под каждый из дистров.

Я ж грю - zealot hell - увидел слово debian и моск затмило совсем. Речь тут не про бебиан ни разу а про установку софта линупс-кастомерам.

>См. выше, плюс данная проблема решается один раз - под следующий слякварь у нас уже есть сборка . Число разных дистров (продакшн) меньше десяти.

И поддерживать весь этот зоопарк? .deb (под пару бебианов и убунту), .rpm (под федору, сусю и мандриву), .ebuild (ага), ... Лучше застрелиться сразу.

>Вы явно не работали с Qt и линуксом плотней. Самого qmake достаточно для qt аппликух, и достаточно кое-как. Как только нужно подключать ещё парочку сторонних библиотек и делать сборки - qmake начинает резко не хватать.

11 лет с линуксом (9 лет как основная система), пара лет программинга на Qt... Но вопрос не в этом. Вопрос в том что у ребе уже есть Qt, qmake и QtCreator - и впиливать туда ещё и cmake - это ещё доболнительные усилия и шаманство.

[zamotivator.livejournal.com]

Но имеем то что имеем - жуткий dependency и zealot hellы в дебиане. У вас там амарок от мусикль клиента зависеть уже перестал? Не?
amarok + kde живут поверх mysql в текущем раскладе.
раньше amarok имел в своих зависимостях на выбор pgsql либо mysql клиентов, а то и ввовсе без них (sqlite). Так что Вы говорите про установку их "по умолчанию", а зависимость вида "одна из баз".
В текущей ситуации не повыбираешь, увы.

А какова альтернатива? Вы хотите сказать msi - решение лучше? Или rpm - лучше?
На мой взгляд - deb - наименьшее зло.

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

И поддерживать весь этот зоопарк? .deb (под пару бебианов и убунту), .rpm (под федору, сусю и мандриву), .ebuild (ага), ... Лучше застрелиться сразу.
Можете проконсультироваться с vitus_wagner насчёт того, как оно делает.
А вообще - система сборки настраивается один раз и в дальнейшем всё собирается одной кнопкой.
Даже Спольски и тот про это писал.

11 лет с линуксом (9 лет как основная система), пара лет программинга на Qt... Но вопрос не в этом. Вопрос в том что у ребе уже есть Qt, qmake и QtCreator - и впиливать туда ещё и cmake - это ещё доболнительные усилия и шаманство.
Если qmake + QtCreator достаточно - я снимаю шляпу и рад за Вас.
Я лично таких проектов не припомню - как минимум boost ещё тащиться.

[theiced.livejournal.com]

>amarok + kde живут поверх mysql в текущем раскладе.
раньше amarok имел в своих зависимостях на выбор pgsql либо mysql клиентов, а то и ввовсе без них (sqlite). Так что Вы говорите про установку их "по умолчанию", а зависимость вида "одна из баз".
В текущей ситуации не повыбираешь, увы.

Раньше, увы, в нормальных дистрах это были опциональные зависимости (USE флаги), в бебиане - обязательная.

>А какова альтернатива? Вы хотите сказать msi - решение лучше? Или rpm - лучше?
На мой взгляд - deb - наименьшее зло.

Всё говно. Что я будут с твоим .говноdeb делать в rhel?

>Я рад, что Вы читаете между строк, однако в постах и комментах я видел обсуждение вида "как сделать сборку под debian", а не кастомерам вообще.

Вам фанатизм мешает увидеть вопрос (и проблему) и вынуждает обсуждать то что обсуждается.

>Можете проконсультироваться с [info]vitus_wagner насчёт того, как оно делает.
А вообще - система сборки настраивается один раз и в дальнейшем всё собирается одной кнопкой.
Даже Спольски и тот про это писал.

Угу, только бебианисты (да и все остальные) постоянно клепают новые дистры и меняют зависимости. Удачи в поддержке. Хинт - НЕТ возможности садить отдельную обезьянку для поддержки всего этого говна - ДЕНЕГ НЕТ, тупо нет.

>Если qmake + QtCreator достаточно - я снимаю шляпу и рад за Вас.

QtCreator не видел даже, для моих Qt проектов мне хватало qmake, для своего единственного for fun C проекта я использую cmake, для основных (java) проектов мы используем свою билд систему с блэкджеком и шлюхами (если соберусь с силами про неё можно будет услышать на LVEE).

>Я лично таких проектов не припомню - как минимум boost ещё тащиться.

Если в проект тащится буст - то мне шота видится проблема на этапе проектирования :)

[zamotivator.livejournal.com]

Раньше, увы, в нормальных дистрах это были опциональные зависимости (USE флаги), в бебиане - обязательная.
Во-первых конкретно эта зависимость была в том числе и селективной.
Во-вторых - что есть нормальный дистр для вас? судя по всему - это gentoo. Если вы сдаете систему "под ключ" (игровые автоматы казино, к примеру) то gentoo идеал, согласен. Если же Ваш софт требуется выкатывать на продакш - то это будет rhel/debian на выбор, может быть ещё slackware.
Половина игровых авоматов в Питере - gentoo.
В Максидоме debian стоит,к примеру.
Видео-реклама в маршрутках в Питере - gentoo.

Всё говно. Что я будут с твоим .говноdeb делать в rhel?
Что я буду делать с твоим говноrpm в debian? +))))
На вопрос-то ответьте. Назовите мне меньшее зло.

Вам фанатизм мешает увидеть вопрос (и проблему) и вынуждает обсуждать то что обсуждается.
Мой рационализм мешает мне додумывать за собеседника, и приписывать ему мои фантазии. Как это делаете Вы в мой адрес, к примеру =) Ну, про qt разве что я неправильно диагноз поставил, за это прошу прощения. metaclass спрашивал КОНКРЕТНЫЕ ТЕХНИЧЕСКИЕ ПРОБЛЕМЫ при работе с DEBIAN. Он не спрашивал "Как правильно организовывать дистрибьюцию клиентам". В рамках этого обсуждения мы с ним и беседовали. Я чуть-чуть затронул её - но лишь в контексте debian. А по всем остальным вопросам дал ссылку на более компетентного, чем я, товарища - vitus_wagner.

Угу, только бебианисты (да и все остальные) постоянно клепают новые дистры и меняют зависимости. Удачи в поддержке. Хинт - НЕТ возможности садить отдельную обезьянку для поддержки всего этого говна - ДЕНЕГ НЕТ, тупо нет.
Потому наужно организовать процесс сборки одной кнопкой, а шевелить Вы это будете максимум раз в месяц.

QtCreator не видел даже, для моих Qt проектов мне хватало qmake, для своего единственного for fun C проекта я использую cmake, для основных (java) проектов мы используем свою билд систему с блэкджеком и шлюхами (если соберусь с силами про неё можно будет услышать на LVEE).
Давайте поговорим про билд-системы.

Если в проект тащится буст - то мне шота видится проблема на этапе проектирования :)
Вы бы сказали пораньше что-нибудь подобное, я бы не терял своё время на стереотипного воинствующего...

[theiced.livejournal.com]

>Во-вторых - что есть нормальный дистр для вас? судя по всему - это gentoo.

Для определённого класса задач (десктоп, дев машинка, свой сервер) - да - генту, для других задач - другие дистры (например десктоп для обычного юзера - openSUSE итд).

>Если вы сдаете систему "под ключ" (игровые автоматы казино, к примеру) то gentoo идеал, согласен. Если же Ваш софт требуется выкатывать на продакш - то это будет rhel/debian на выбор, может быть ещё slackware.

Тут чуть чуть другая проблемка - у ребе есть софт который он будет ставить кастомерам у которых будет всё что угодно вплоть до LFS.

>На вопрос-то ответьте. Назовите мне меньшее зло.

sh инсталлер (аля нвидия).

>Мой рационализм мешает мне додумывать за собеседника, и приписывать ему мои фантазии. Как это делаете Вы в мой адрес, к примеру =) Ну, про qt разве что я неправильно диагноз поставил, за это прошу прощения. [info]metaclass спрашивал КОНКРЕТНЫЕ ТЕХНИЧЕСКИЕ ПРОБЛЕМЫ при работе с DEBIAN.

А фанатизм помогает не замечать ключевые фразы. Цитирую.

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

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

И тестировать новый билд на всём этом зоопарке? Соре - нет лишних ресурсов.

>Давайте поговорим про билд-системы.

Давайте - на LVEE ;) Тема интересная. Тока я ша могу говорить тока с точки зрения жабы. И говорить что то вида `Все билд системы под жабу - унылое говно для психов`.

>Вы бы сказали пораньше что-нибудь подобное, я бы не терял своё время на стереотипного воинствующего...

Ну я просто очччень не люблю C++, шота да. Но тут мы говорим какбэ про Qt и если в Qt проект тащится boost - то это явно что то не так в консерватории. А вообще - там в конце смайлик стоит.

PS. Я не стереотипный ни разу и не воинствующий. Я просто дико не люблю фанатизм и фанатиков. В OS бОльшая часть фанатиков почему то дебианисты.

Масла ў агонь!

[ex-biespart.livejournal.com]

Разбіраюся з статычнай лінкоўкаю Qt/Embedded. Google выдае:
I have similar problems with Qt-4.5.1 and Boost-1.38 too, statically linking it’s just a complete mess and i wonder on how developers could be attracted to port their software on the Linux platform if they need to solve problems as these, rather than being able to focus on their own code: i’m writing a software for image manipulation and i’m willing to port to other platforms than Windows, but this whole mess really make me think dropping support would be just an advantage. (http://chrishowells.co.uk/?p=239)

[zamotivator.livejournal.com]

Тут чуть чуть другая проблемка - у ребе есть софт который он будет ставить кастомерам у которых будет всё что угодно вплоть до LFS.
...
sh инсталлер (аля нвидия).
Извините, но я как бы ВООБЩЕ не в курсе какой они там софт пишет и для кого. Так что вы располагаете куда большей информацией чем я.
Nvidia - sh, skype - пакеты, что есть правильней? Я не могу судить, зависит от приложения.

Давайте - на LVEE ;) Тема интересная. Тока я ша могу говорить тока с точки зрения жабы. И говорить что то вида `Все билд системы под жабу - унылое говно для психов`.
Ну насчёт жабы и её системы пакетирования наслышан разного, судить в любом случае не могу.
А из пощупанных билд систем (MS build, ant, automake, cmake, scons) cmake имеет оптимальное, на мой взгляд, соотношение вида "функциональность/кактусы", и у него лучшее из виденных решение для интеграции с другими системами сборки.
Например IncrediBuild для распределённой сборки под студию понимает только студийные солюшины. cmake генерирует студийные проджекты и солюшин, и cmake, таким образом, с IncrediBuild дружит.

Ну я просто очччень не люблю C++, шота да. Но тут мы говорим какбэ про Qt и если в Qt проект тащится boost - то это явно что то не так в консерватории. А вообще - там в конце смайлик стоит.
Конкретно gui-application на qt буста практически не требует. А если и требует (concept_check/etc) - это всё хидер онли.
Если конкретно под проект Qt достаточно - я только рад, т.к. это означает что trolltech (nokia) своей цели достигли - у них есть хороший framework.

PS. Я не стереотипный ни разу и не воинствующий. Я просто дико не люблю фанатизм и фанатиков. В OS бОльшая часть фанатиков почему то дебианисты.
Фанатики тут выш по треду.
А если аккумулировать обсуждение - то я был введен в заблуждение постановкой задачи - в постах она выглядит "какой ваш debian гадость" - я то вообще ubuntu/gentoo юзаю, но на дебиане несколько лет посидел - и перечисленные проблемы классифицирую "ты жрёшь кактус иголками наружу" - т.е. конкретно стандартные решения под debian выглядят иначе.

Если же задача стоит как "поставлять продукт всем подо всё" то sh скрипт это наиболее простое и удобное решение.

[theiced.livejournal.com]

>Извините, но я как бы ВООБЩЕ не в курсе какой они там софт пишет и для кого. Так что вы располагаете куда большей информацией чем я.
Nvidia - sh, skype - пакеты, что есть правильней? Я не могу судить, зависит от приложения.

Я тоже в курсе постолько-поскольку - всё из постов уважаемых ребе. Ситуация простая - приходим к кастомеру в их рассадник жаб и червей (ака серверная) и ставим софт. Просто софт. Дистр свой мы поставить НЕ МОЖЕМ.

>Ну насчёт жабы и её системы пакетирования наслышан разного, судить в любом случае не могу.

Там всё ОЧЕНЬ плохо.

>А из пощупанных билд систем (MS build, ant, automake, cmake, scons) cmake имеет оптимальное, на мой взгляд, соотношение вида "функциональность/кактусы", и у него лучшее из виденных решение для интеграции с другими системами сборки.

Для C/C++ - да - cmake лучший, бесспорно. Мне в нём только одно не нравится - имя билд скрипта :)

>Конкретно gui-application на qt буста практически не требует. А если и требует (concept_check/etc) - это всё хидер онли.

Нууууу дааааа - смартпоинтеры ещё, можно согласиться.

>Если конкретно под проект Qt достаточно - я только рад, т.к. это означает что trolltech (nokia) своей цели достигли - у них есть хороший framework.

Угу - Qt очень хорош. Язык бы ещё нормальный (не с++)...

>А если аккумулировать обсуждение - то я был введен в заблуждение постановкой задачи - в постах она выглядит "какой ваш debian гадость"

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

>я то вообще ubuntu/gentoo юзаю, но на дебиане несколько лет посидел - и перечисленные проблемы классифицирую "ты жрёшь кактус иголками наружу" - т.е. конкретно стандартные решения под debian выглядят иначе.

Вот видишь - тяжёлое наследие дебиана до сих пор сказывается. Убунту кстати ОК - тама вместо фанатизма целью является удобство конечного юзера.

>Если же задача стоит как "поставлять продукт всем подо всё" то sh скрипт это наиболее простое и удобное решение.

Наиболее удобное - пакеты под всё что можно, но это ДОРОГО. Так что ТОЛЬКО sh скрипт.

[zamotivator.livejournal.com]

Я тоже в курсе постолько-поскольку - всё из постов уважаемых ребе. Ситуация простая - приходим к кастомеру в их рассадник жаб и червей (ака серверная) и ставим софт. Просто софт. Дистр свой мы поставить НЕ МОЖЕМ.
Это лишь косвенно по комментам выясняется. Писал я свой первый коммент не владея этой информацией.

Там всё ОЧЕНЬ плохо.
Верю.

Для C/C++ - да - cmake лучший, бесспорно. Мне в нём только одно не нравится - имя билд скрипта :)
=)
Нууууу дааааа - смартпоинтеры ещё, можно согласиться.
Ну они тоже хидер-онли. Я так и упомянул (concept_check/etc). А то ведь и circular_buffer неплох, function/bind.

Угу - Qt очень хорош. Язык бы ещё нормальный (не с++)..
С++ - язык, а использовать его можно по-разному. Тролли его используют хорошо. Но это всё-таки не единственный способ его использовать хорошо.

Ну ребе как раз делают очень полезное дело. Они смотрят на линупсы с точки зрения ведения бизнеса по разработке коммерческого ПО и тыкают мордой в найденные рассадники червей, которые опытные линупсоиды уже не замечают (глаза замылены). И, есть мнение, от них OSSу пользы больше чем от 100500 беларуских красноглазых бебианистов.
Это я как бэ и не спорю. Просто конкретно упомянутые проблемы - must read из серии idl в COM или manifest в SxS.

Вот видишь - тяжёлое наследие дебиана до сих пор сказывается. Убунту кстати ОК - тама вместо фанатизма целью является удобство конечного юзера.
Система пакетирования в дебиане (убунте) очень удобна для конечного пользователя. Программисту/дистрибьютору сложней, конечно, но решается проблема ровно один раз.

Наиболее удобное - пакеты под всё что можно, но это ДОРОГО. Так что ТОЛЬКО sh скрипт.
Для конечного пользователя ясен пень удобней пакеты.
nvidia - sh, skype - пакеты. Но skype себе это позволить может, а в ситуациях типа описанной sh единственное приемлимое решение. Постепенно, со временем, пакетик за пакетиком можно под все дистры спеки и прочее наколбасить, и собирать их по кноке.

[theiced.livejournal.com]

>Это лишь косвенно по комментам выясняется. Писал я свой первый коммент не владея этой информацией.

Ну это из поста следовало, из последней его фразы.

>С++ - язык, а использовать его можно по-разному. Тролли его используют хорошо. Но это всё-таки не единственный способ его использовать хорошо.

Ну они не юзают с++ные извращения. А совсем правильное использование с++ - это не использовать его совсем.

>Это я как бэ и не спорю. Просто конкретно упомянутые проблемы - must read из серии idl в COM или manifest в SxS.

Не-а. Тут проблема в том что красноглазые (в основном бебианисты) преподносят их как ПРЕИМУЩЕСТВА.

>Система пакетирования в дебиане (убунте) очень удобна для конечного пользователя. Программисту/дистрибьютору сложней, конечно, но решается проблема ровно один раз.

Особенно у того у которого rhel :))) Ну ладно - тут уже поняли что не поняли друг друга сразу :)