Показательные выступления на льду.
May. 9th, 2009 09:13 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassНо надо сказать, что последние пляски с Qt, glibc и дебианами, а так же закономерная реакция линукс-френдленты на описание оного хорошо демонстрируют почему с софтом под линукс все так "хорошо".
Софт для end-юзеров и прочие приземленные вещи далеко не всегда пишут отмороженные гики с десятилетним опытом решения бессмысленных безумных проблем. Достаточно походить по форумам по .NET например - там огромное количество вопросов, показывающих, что в ИТ работает много _начинающих_ людей. И вот оным начинающим развлечения, подобные тому, чем я занимался вчера - совершенно ни к чему. Не должен обобщенный "программист кульных прог для бухгалтерии Вася Пупкин" сразу разбираться в тонкостях библиотек, порядка их поиска, версий компиляторов и прочей хреновине. Это должно идти потом, когда софт уже заработал, был продан и надо его улучшать, выпускать новую версию и есть на этот бабки, полученные от продажи первой версии.
Я так понимаю, не всем очевидна конечная цель работы: "написать софт, внедрить клиентам, получить бабки". И что чем меньше времени уйдет на это - тем больше бабок в единицу времени получится. И что время на "чтение гугла и манов", "пересборку QT", "изучение тонкостей поиска shared objects" - это все кем-то должно оплачиваться. Я не знаю, по моему, видеть во всем в первую очередь бизнес-смысл и енд-юзеров - достаточно полезная вещь, хорошо вправляет мозги и компенсирует техно-гиковские перегибы.
Не говоря уже о факапах вроде "приехали показывать софт тендерной комиссии, а там НИЧЕГО не запустилось, потому что линукс не той системы" - такое вообще недопустимо, между прочим.
Софт для end-юзеров и прочие приземленные вещи далеко не всегда пишут отмороженные гики с десятилетним опытом решения бессмысленных безумных проблем. Достаточно походить по форумам по .NET например - там огромное количество вопросов, показывающих, что в ИТ работает много _начинающих_ людей. И вот оным начинающим развлечения, подобные тому, чем я занимался вчера - совершенно ни к чему. Не должен обобщенный "программист кульных прог для бухгалтерии Вася Пупкин" сразу разбираться в тонкостях библиотек, порядка их поиска, версий компиляторов и прочей хреновине. Это должно идти потом, когда софт уже заработал, был продан и надо его улучшать, выпускать новую версию и есть на этот бабки, полученные от продажи первой версии.
Я так понимаю, не всем очевидна конечная цель работы: "написать софт, внедрить клиентам, получить бабки". И что чем меньше времени уйдет на это - тем больше бабок в единицу времени получится. И что время на "чтение гугла и манов", "пересборку QT", "изучение тонкостей поиска shared objects" - это все кем-то должно оплачиваться. Я не знаю, по моему, видеть во всем в первую очередь бизнес-смысл и енд-юзеров - достаточно полезная вещь, хорошо вправляет мозги и компенсирует техно-гиковские перегибы.
Не говоря уже о факапах вроде "приехали показывать софт тендерной комиссии, а там НИЧЕГО не запустилось, потому что линукс не той системы" - такое вообще недопустимо, между прочим.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2009-05-11 07:11 am (UTC)Также существует штатный, чёткий путь решения этой проблемы. В отличие От.
Сюрприза нет, но есть вопрос - а что меняется?
Фанатики вообще не вникают. Речь про debian? Про debian. Вот потому про дебы и говорю. А вообще говоря форматов три штуки - tar.gz, rpm, deb. +некоторое количество под каждый из дистров.
См. выше, плюс данная проблема решается один раз - под следующий слякварь у нас уже есть сборка . Число разных дистров (продакшн) меньше десяти.
Вы явно не работали с Qt и линуксом плотней. Самого qmake достаточно для qt аппликух, и достаточно кое-как. Как только нужно подключать ещё парочку сторонних библиотек и делать сборки - qmake начинает резко не хватать.
no subject
Date: 2009-05-11 07:22 am (UTC)Но имеем то что имеем - жуткий 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 - это ещё доболнительные усилия и шаманство.
no subject
Date: 2009-05-11 07:29 am (UTC)amarok + kde живут поверх mysql в текущем раскладе.
раньше amarok имел в своих зависимостях на выбор pgsql либо mysql клиентов, а то и ввовсе без них (sqlite). Так что Вы говорите про установку их "по умолчанию", а зависимость вида "одна из баз".
В текущей ситуации не повыбираешь, увы.
А какова альтернатива? Вы хотите сказать msi - решение лучше? Или rpm - лучше?
На мой взгляд - deb - наименьшее зло.
Я рад, что Вы читаете между строк, однако в постах и комментах я видел обсуждение вида "как сделать сборку под debian", а не кастомерам вообще.
Можете проконсультироваться с
А вообще - система сборки настраивается один раз и в дальнейшем всё собирается одной кнопкой.
Даже Спольски и тот про это писал.
Если qmake + QtCreator достаточно - я снимаю шляпу и рад за Вас.
Я лично таких проектов не припомню - как минимум boost ещё тащиться.
no subject
Date: 2009-05-11 07:36 am (UTC)раньше 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 ещё тащиться.
Если в проект тащится буст - то мне шота видится проблема на этапе проектирования :)
no subject
Date: 2009-05-11 07:47 am (UTC)Во-первых конкретно эта зависимость была в том числе и селективной.
Во-вторых - что есть нормальный дистр для вас? судя по всему - это gentoo. Если вы сдаете систему "под ключ" (игровые автоматы казино, к примеру) то gentoo идеал, согласен. Если же Ваш софт требуется выкатывать на продакш - то это будет rhel/debian на выбор, может быть ещё slackware.
Половина игровых авоматов в Питере - gentoo.
В Максидоме debian стоит,к примеру.
Видео-реклама в маршрутках в Питере - gentoo.
Что я буду делать с твоим говноrpm в debian? +))))
На вопрос-то ответьте. Назовите мне меньшее зло.
Мой рационализм мешает мне додумывать за собеседника, и приписывать ему мои фантазии. Как это делаете Вы в мой адрес, к примеру =) Ну, про qt разве что я неправильно диагноз поставил, за это прошу прощения.
Потому наужно организовать процесс сборки одной кнопкой, а шевелить Вы это будете максимум раз в месяц.
Давайте поговорим про билд-системы.
Вы бы сказали пораньше что-нибудь подобное, я бы не терял своё время на стереотипного воинствующего...
no subject
Date: 2009-05-11 08:01 am (UTC)Для определённого класса задач (десктоп, дев машинка, свой сервер) - да - генту, для других задач - другие дистры (например десктоп для обычного юзера - openSUSE итд).
>Если вы сдаете систему "под ключ" (игровые автоматы казино, к примеру) то gentoo идеал, согласен. Если же Ваш софт требуется выкатывать на продакш - то это будет rhel/debian на выбор, может быть ещё slackware.
Тут чуть чуть другая проблемка - у ребе есть софт который он будет ставить кастомерам у которых будет всё что угодно вплоть до LFS.
>На вопрос-то ответьте. Назовите мне меньшее зло.
sh инсталлер (аля нвидия).
>Мой рационализм мешает мне додумывать за собеседника, и приписывать ему мои фантазии. Как это делаете Вы в мой адрес, к примеру =) Ну, про qt разве что я неправильно диагноз поставил, за это прошу прощения. [info]metaclass спрашивал КОНКРЕТНЫЕ ТЕХНИЧЕСКИЕ ПРОБЛЕМЫ при работе с DEBIAN.
А фанатизм помогает не замечать ключевые фразы. Цитирую.
`Не говоря уже о факапах вроде "приехали показывать софт тендерной комиссии, а там НИЧЕГО не запустилось, потому что линукс не той системы" - такое вообще недопустимо, между прочим.`
>Потому наужно организовать процесс сборки одной кнопкой, а шевелить Вы это будете максимум раз в месяц.
И тестировать новый билд на всём этом зоопарке? Соре - нет лишних ресурсов.
>Давайте поговорим про билд-системы.
Давайте - на LVEE ;) Тема интересная. Тока я ша могу говорить тока с точки зрения жабы. И говорить что то вида `Все билд системы под жабу - унылое говно для психов`.
>Вы бы сказали пораньше что-нибудь подобное, я бы не терял своё время на стереотипного воинствующего...
Ну я просто очччень не люблю C++, шота да. Но тут мы говорим какбэ про Qt и если в Qt проект тащится boost - то это явно что то не так в консерватории. А вообще - там в конце смайлик стоит.
PS. Я не стереотипный ни разу и не воинствующий. Я просто дико не люблю фанатизм и фанатиков. В OS бОльшая часть фанатиков почему то дебианисты.
no subject
Date: 2009-05-11 08:15 am (UTC)Извините, но я как бы ВООБЩЕ не в курсе какой они там софт пишет и для кого. Так что вы располагаете куда большей информацией чем я.
Nvidia - sh, skype - пакеты, что есть правильней? Я не могу судить, зависит от приложения.
Ну насчёт жабы и её системы пакетирования наслышан разного, судить в любом случае не могу.
А из пощупанных билд систем (MS build, ant, automake, cmake, scons) cmake имеет оптимальное, на мой взгляд, соотношение вида "функциональность/кактусы", и у него лучшее из виденных решение для интеграции с другими системами сборки.
Например IncrediBuild для распределённой сборки под студию понимает только студийные солюшины. cmake генерирует студийные проджекты и солюшин, и cmake, таким образом, с IncrediBuild дружит.
Конкретно gui-application на qt буста практически не требует. А если и требует (concept_check/etc) - это всё хидер онли.
Если конкретно под проект Qt достаточно - я только рад, т.к. это означает что trolltech (nokia) своей цели достигли - у них есть хороший framework.
Фанатики тут выш по треду.
А если аккумулировать обсуждение - то я был введен в заблуждение постановкой задачи - в постах она выглядит "какой ваш debian гадость" - я то вообще ubuntu/gentoo юзаю, но на дебиане несколько лет посидел - и перечисленные проблемы классифицирую "ты жрёшь кактус иголками наружу" - т.е. конкретно стандартные решения под debian выглядят иначе.
Если же задача стоит как "поставлять продукт всем подо всё" то sh скрипт это наиболее простое и удобное решение.
no subject
Date: 2009-05-11 08:30 am (UTC)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 скрипт.
no subject
Date: 2009-05-11 10:23 am (UTC)Это лишь косвенно по комментам выясняется. Писал я свой первый коммент не владея этой информацией.
Верю.
=)
Ну они тоже хидер-онли. Я так и упомянул (concept_check/etc). А то ведь и circular_buffer неплох, function/bind.
С++ - язык, а использовать его можно по-разному. Тролли его используют хорошо. Но это всё-таки не единственный способ его использовать хорошо.
Это я как бэ и не спорю. Просто конкретно упомянутые проблемы - must read из серии idl в COM или manifest в SxS.
Система пакетирования в дебиане (убунте) очень удобна для конечного пользователя. Программисту/дистрибьютору сложней, конечно, но решается проблема ровно один раз.
Для конечного пользователя ясен пень удобней пакеты.
nvidia - sh, skype - пакеты. Но skype себе это позволить может, а в ситуациях типа описанной sh единственное приемлимое решение. Постепенно, со временем, пакетик за пакетиком можно под все дистры спеки и прочее наколбасить, и собирать их по кноке.
no subject
Date: 2009-05-11 11:37 am (UTC)Ну это из поста следовало, из последней его фразы.
>С++ - язык, а использовать его можно по-разному. Тролли его используют хорошо. Но это всё-таки не единственный способ его использовать хорошо.
Ну они не юзают с++ные извращения. А совсем правильное использование с++ - это не использовать его совсем.
>Это я как бэ и не спорю. Просто конкретно упомянутые проблемы - must read из серии idl в COM или manifest в SxS.
Не-а. Тут проблема в том что красноглазые (в основном бебианисты) преподносят их как ПРЕИМУЩЕСТВА.
>Система пакетирования в дебиане (убунте) очень удобна для конечного пользователя. Программисту/дистрибьютору сложней, конечно, но решается проблема ровно один раз.
Особенно у того у которого rhel :))) Ну ладно - тут уже поняли что не поняли друг друга сразу :)
no subject
Date: 2009-05-11 11:49 am (UTC)Значит прочитал невнимательно =)
У меня перед глазами есть production использование "С++-извращений". Самая близкая аналогия - Haskell type classes. Написана на boost.mpl (metaprogramming library) - Александреску, превед!
Польза от неё несомненная - она уже съэкономила человеко-месяцы, а то и человеко-годы - а занимается эта хрень кодогенерацией и статической верификацией.
Задача - реализация вычислителей SQL-выражений.
Так что у меня есть положительный опыт промышленного использования так называемых "извращений" - и польза от них несомненная, а то, что нужна редко и готовить её толком мало кто умеет - дело десятое.
Я написал кодогенератор (eDSL) в рамках С++, остальные просто пользуют интерфейсы и радуются жизни.
В сравнении с системой манифестов или idl - это ПРЕИМУЩЕСТВО.
А то, что с ней пришлось столкнутся - не является НЕДОСТАТКОМ, а является признаком ДРУГИХ ИНСТРУМЕНТОВ.
Ну в этом мы разобрались, слава богу.
no subject
Date: 2009-05-11 12:00 pm (UTC)no subject
Date: 2009-05-11 12:04 pm (UTC)struct CompareScheme { bool operator()( const impl::Scheme< qd::common::eChar >& a_left, const impl::Scheme< qd::common::eChar >& a_right ) const { return a_left.size() == a_right.size(); } bool operator()( const impl::Scheme< qd::common::eVarchar >& a_left, const impl::Scheme< qd::common::eVarchar >& a_right ) const { return a_left.size() == a_right.size(); } bool operator()( const impl::Scheme< qd::common::eDecimal >& a_left, const impl::Scheme< qd::common::eDecimal >& a_right ) const { return ( a_left.precision() == a_right.precision() ) && ( a_left.scale() == a_right.scale() ); } template< qd::common::EType dataType > bool operator()( const impl::Scheme< dataType >& , const impl::Scheme< dataType >& ) const { return true; } template< qd::common::EType leftDataType, qd::common::EType rightDataType > bool operator()( const impl::Scheme< leftDataType >&, const impl::Scheme< rightDataType >& ) const { return false; } }; typedef qd::dsd::Function< bool, const CompareScheme&, qd::mpl::vector< const qd::pplan::Scheme&, const qd::pplan::Scheme& > > CompareSchemeFunction; namespace { CompareSchemeFunction g_compareSchemeFunction; } bool operator==( const qd::pplan::Scheme& a_left, const qd::pplan::Scheme& a_right ) { return g_compareSchemeFunction( CompareScheme(), a_left, a_right ); }no subject
Date: 2009-05-11 12:07 pm (UTC)Вот мааааааленький кусочек реализации dsd::Function
template< typename Argument, typename Tag = typename tag< Argument >::type > struct size; template< typename Argument > struct size< Argument, other_tag > : public mpl::integral_c< RuntimeIndex, 1 > { }; template< typename Argument > struct size< Argument, enum_tag > : public mpl::integral_c< RuntimeIndex, mpl::size< typename get_values< Argument >::type >::value > { }; struct template_size_step { template< typename CurrentSize, typename CurrentDepende > struct apply { typedef mpl::integral_c< RuntimeIndex, CurrentSize::value * size< CurrentDepende >::value > type; }; }; template< typename Argument > struct template_size { private: typedef typename get_dependes< Argument >::type Dependes; public: typedef typename mpl::fold< Dependes, mpl::integral_c< RuntimeIndex, 1 >, template_size_step >::type type; }; template< typename Argument > struct size< Argument, template_tag > : public template_size< Argument >::type { };no subject
Date: 2009-05-11 01:32 pm (UTC)no subject
Date: 2009-05-11 01:35 pm (UTC)Он весь спрятан как детали реализации.
no subject
Date: 2009-05-11 01:40 pm (UTC)typedef qd::dsd::Function< bool, const CompareScheme&,
qd::mpl::vector< const qd::pplan::Scheme&, const qd::pplan::Scheme& > >
CompareSchemeFunction;
Всё. Моск выключился. Тут спецсимволов больше чем в типичном перловом коде.
no subject
Date: 2009-05-11 01:45 pm (UTC)bool operator==( const qd::pplan::Scheme& a_left, const qd::pplan::Scheme& a_right ) { typedef qd::dsd::Function< /* Return Type */; bool, const CompareScheme& /* Function object for call */, qd::mpl::vector< const qd::pplan::Scheme& /* Argument 1 */, const qd::pplan::Scheme& /* Argument 2 */ > > CompareSchemeFunction; static CompareSchemeFunction g_compareSchemeFunction; return g_compareSchemeFunction( CompareScheme(), a_left, a_right ); }Так понятней?
Это уже детали реализации функции сравнения =)
no subject
Date: 2009-05-11 01:49 pm (UTC)(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2009-05-11 02:55 pm (UTC)А так вроде все понятно
(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2009-05-11 01:37 pm (UTC)А то, что с ней пришлось столкнутся - не является НЕДОСТАТКОМ, а является признаком ДРУГИХ ИНСТРУМЕНТОВ.
Я вообще то про плесень которая начинает произрастать при попытке сделать our-mighty-propietary-app.installer который будет ставиться и рабоать везде. Да - для OS софта это не проблема - есть майнтэйнеры дистров, есть исходники, ... - другая проблема, другие решиения.
no subject
Date: 2009-05-11 01:39 pm (UTC)Это не может не радовать =)
no subject
Date: 2009-05-11 01:42 pm (UTC)no subject
Date: 2009-05-11 01:46 pm (UTC)Для меня линуксы и С++ - инструменты, а не религия.
no subject
Date: 2009-05-11 01:53 pm (UTC)