![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Показательные выступления на льду.
Но надо сказать, что последние пляски с Qt, glibc и дебианами, а так же закономерная реакция линукс-френдленты на описание оного хорошо демонстрируют почему с софтом под линукс все так "хорошо".
Софт для end-юзеров и прочие приземленные вещи далеко не всегда пишут отмороженные гики с десятилетним опытом решения бессмысленных безумных проблем. Достаточно походить по форумам по .NET например - там огромное количество вопросов, показывающих, что в ИТ работает много _начинающих_ людей. И вот оным начинающим развлечения, подобные тому, чем я занимался вчера - совершенно ни к чему. Не должен обобщенный "программист кульных прог для бухгалтерии Вася Пупкин" сразу разбираться в тонкостях библиотек, порядка их поиска, версий компиляторов и прочей хреновине. Это должно идти потом, когда софт уже заработал, был продан и надо его улучшать, выпускать новую версию и есть на этот бабки, полученные от продажи первой версии.
Я так понимаю, не всем очевидна конечная цель работы: "написать софт, внедрить клиентам, получить бабки". И что чем меньше времени уйдет на это - тем больше бабок в единицу времени получится. И что время на "чтение гугла и манов", "пересборку QT", "изучение тонкостей поиска shared objects" - это все кем-то должно оплачиваться. Я не знаю, по моему, видеть во всем в первую очередь бизнес-смысл и енд-юзеров - достаточно полезная вещь, хорошо вправляет мозги и компенсирует техно-гиковские перегибы.
Не говоря уже о факапах вроде "приехали показывать софт тендерной комиссии, а там НИЧЕГО не запустилось, потому что линукс не той системы" - такое вообще недопустимо, между прочим.
Софт для end-юзеров и прочие приземленные вещи далеко не всегда пишут отмороженные гики с десятилетним опытом решения бессмысленных безумных проблем. Достаточно походить по форумам по .NET например - там огромное количество вопросов, показывающих, что в ИТ работает много _начинающих_ людей. И вот оным начинающим развлечения, подобные тому, чем я занимался вчера - совершенно ни к чему. Не должен обобщенный "программист кульных прог для бухгалтерии Вася Пупкин" сразу разбираться в тонкостях библиотек, порядка их поиска, версий компиляторов и прочей хреновине. Это должно идти потом, когда софт уже заработал, был продан и надо его улучшать, выпускать новую версию и есть на этот бабки, полученные от продажи первой версии.
Я так понимаю, не всем очевидна конечная цель работы: "написать софт, внедрить клиентам, получить бабки". И что чем меньше времени уйдет на это - тем больше бабок в единицу времени получится. И что время на "чтение гугла и манов", "пересборку QT", "изучение тонкостей поиска shared objects" - это все кем-то должно оплачиваться. Я не знаю, по моему, видеть во всем в первую очередь бизнес-смысл и енд-юзеров - достаточно полезная вещь, хорошо вправляет мозги и компенсирует техно-гиковские перегибы.
Не говоря уже о факапах вроде "приехали показывать софт тендерной комиссии, а там НИЧЕГО не запустилось, потому что линукс не той системы" - такое вообще недопустимо, между прочим.
no subject
Но имеем то что имеем - жуткий 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
amarok + kde живут поверх mysql в текущем раскладе.
раньше amarok имел в своих зависимостях на выбор pgsql либо mysql клиентов, а то и ввовсе без них (sqlite). Так что Вы говорите про установку их "по умолчанию", а зависимость вида "одна из баз".
В текущей ситуации не повыбираешь, увы.
А какова альтернатива? Вы хотите сказать msi - решение лучше? Или rpm - лучше?
На мой взгляд - deb - наименьшее зло.
Я рад, что Вы читаете между строк, однако в постах и комментах я видел обсуждение вида "как сделать сборку под debian", а не кастомерам вообще.
Можете проконсультироваться с
А вообще - система сборки настраивается один раз и в дальнейшем всё собирается одной кнопкой.
Даже Спольски и тот про это писал.
Если qmake + QtCreator достаточно - я снимаю шляпу и рад за Вас.
Я лично таких проектов не припомню - как минимум boost ещё тащиться.
no subject
раньше 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
Во-первых конкретно эта зависимость была в том числе и селективной.
Во-вторых - что есть нормальный дистр для вас? судя по всему - это gentoo. Если вы сдаете систему "под ключ" (игровые автоматы казино, к примеру) то gentoo идеал, согласен. Если же Ваш софт требуется выкатывать на продакш - то это будет rhel/debian на выбор, может быть ещё slackware.
Половина игровых авоматов в Питере - gentoo.
В Максидоме debian стоит,к примеру.
Видео-реклама в маршрутках в Питере - gentoo.
Что я буду делать с твоим говноrpm в debian? +))))
На вопрос-то ответьте. Назовите мне меньшее зло.
Мой рационализм мешает мне додумывать за собеседника, и приписывать ему мои фантазии. Как это делаете Вы в мой адрес, к примеру =) Ну, про qt разве что я неправильно диагноз поставил, за это прошу прощения.
Потому наужно организовать процесс сборки одной кнопкой, а шевелить Вы это будете максимум раз в месяц.
Давайте поговорим про билд-системы.
Вы бы сказали пораньше что-нибудь подобное, я бы не терял своё время на стереотипного воинствующего...
no subject
Для определённого класса задач (десктоп, дев машинка, свой сервер) - да - генту, для других задач - другие дистры (например десктоп для обычного юзера - openSUSE итд).
>Если вы сдаете систему "под ключ" (игровые автоматы казино, к примеру) то gentoo идеал, согласен. Если же Ваш софт требуется выкатывать на продакш - то это будет rhel/debian на выбор, может быть ещё slackware.
Тут чуть чуть другая проблемка - у ребе есть софт который он будет ставить кастомерам у которых будет всё что угодно вплоть до LFS.
>На вопрос-то ответьте. Назовите мне меньшее зло.
sh инсталлер (аля нвидия).
>Мой рационализм мешает мне додумывать за собеседника, и приписывать ему мои фантазии. Как это делаете Вы в мой адрес, к примеру =) Ну, про qt разве что я неправильно диагноз поставил, за это прошу прощения. [info]metaclass спрашивал КОНКРЕТНЫЕ ТЕХНИЧЕСКИЕ ПРОБЛЕМЫ при работе с DEBIAN.
А фанатизм помогает не замечать ключевые фразы. Цитирую.
`Не говоря уже о факапах вроде "приехали показывать софт тендерной комиссии, а там НИЧЕГО не запустилось, потому что линукс не той системы" - такое вообще недопустимо, между прочим.`
>Потому наужно организовать процесс сборки одной кнопкой, а шевелить Вы это будете максимум раз в месяц.
И тестировать новый билд на всём этом зоопарке? Соре - нет лишних ресурсов.
>Давайте поговорим про билд-системы.
Давайте - на LVEE ;) Тема интересная. Тока я ша могу говорить тока с точки зрения жабы. И говорить что то вида `Все билд системы под жабу - унылое говно для психов`.
>Вы бы сказали пораньше что-нибудь подобное, я бы не терял своё время на стереотипного воинствующего...
Ну я просто очччень не люблю C++, шота да. Но тут мы говорим какбэ про Qt и если в Qt проект тащится boost - то это явно что то не так в консерватории. А вообще - там в конце смайлик стоит.
PS. Я не стереотипный ни разу и не воинствующий. Я просто дико не люблю фанатизм и фанатиков. В OS бОльшая часть фанатиков почему то дебианисты.
no subject
Извините, но я как бы ВООБЩЕ не в курсе какой они там софт пишет и для кого. Так что вы располагаете куда большей информацией чем я.
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
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
Это лишь косвенно по комментам выясняется. Писал я свой первый коммент не владея этой информацией.
Верю.
=)
Ну они тоже хидер-онли. Я так и упомянул (concept_check/etc). А то ведь и circular_buffer неплох, function/bind.
С++ - язык, а использовать его можно по-разному. Тролли его используют хорошо. Но это всё-таки не единственный способ его использовать хорошо.
Это я как бэ и не спорю. Просто конкретно упомянутые проблемы - must read из серии idl в COM или manifest в SxS.
Система пакетирования в дебиане (убунте) очень удобна для конечного пользователя. Программисту/дистрибьютору сложней, конечно, но решается проблема ровно один раз.
Для конечного пользователя ясен пень удобней пакеты.
nvidia - sh, skype - пакеты. Но skype себе это позволить может, а в ситуациях типа описанной sh единственное приемлимое решение. Постепенно, со временем, пакетик за пакетиком можно под все дистры спеки и прочее наколбасить, и собирать их по кноке.
no subject
Ну это из поста следовало, из последней его фразы.
>С++ - язык, а использовать его можно по-разному. Тролли его используют хорошо. Но это всё-таки не единственный способ его использовать хорошо.
Ну они не юзают с++ные извращения. А совсем правильное использование с++ - это не использовать его совсем.
>Это я как бэ и не спорю. Просто конкретно упомянутые проблемы - must read из серии idl в COM или manifest в SxS.
Не-а. Тут проблема в том что красноглазые (в основном бебианисты) преподносят их как ПРЕИМУЩЕСТВА.
>Система пакетирования в дебиане (убунте) очень удобна для конечного пользователя. Программисту/дистрибьютору сложней, конечно, но решается проблема ровно один раз.
Особенно у того у которого rhel :))) Ну ладно - тут уже поняли что не поняли друг друга сразу :)
no subject
Значит прочитал невнимательно =)
У меня перед глазами есть production использование "С++-извращений". Самая близкая аналогия - Haskell type classes. Написана на boost.mpl (metaprogramming library) - Александреску, превед!
Польза от неё несомненная - она уже съэкономила человеко-месяцы, а то и человеко-годы - а занимается эта хрень кодогенерацией и статической верификацией.
Задача - реализация вычислителей SQL-выражений.
Так что у меня есть положительный опыт промышленного использования так называемых "извращений" - и польза от них несомненная, а то, что нужна редко и готовить её толком мало кто умеет - дело десятое.
Я написал кодогенератор (eDSL) в рамках С++, остальные просто пользуют интерфейсы и радуются жизни.
В сравнении с системой манифестов или idl - это ПРЕИМУЩЕСТВО.
А то, что с ней пришлось столкнутся - не является НЕДОСТАТКОМ, а является признаком ДРУГИХ ИНСТРУМЕНТОВ.
Ну в этом мы разобрались, слава богу.
no subject
no subject
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
Вот мааааааленький кусочек реализации 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
no subject
Он весь спрятан как детали реализации.
no subject
typedef qd::dsd::Function< bool, const CompareScheme&,
qd::mpl::vector< const qd::pplan::Scheme&, const qd::pplan::Scheme& > >
CompareSchemeFunction;
Всё. Моск выключился. Тут спецсимволов больше чем в типичном перловом коде.
no subject
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
no subject
Типа множественного dynamic_cast. Паттерн-матчинг многих аргументов, другими словами - мультиметоды
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
А так вроде все понятно
(no subject)
(no subject)
(no subject)
no subject
А то, что с ней пришлось столкнутся - не является НЕДОСТАТКОМ, а является признаком ДРУГИХ ИНСТРУМЕНТОВ.
Я вообще то про плесень которая начинает произрастать при попытке сделать our-mighty-propietary-app.installer который будет ставиться и рабоать везде. Да - для OS софта это не проблема - есть майнтэйнеры дистров, есть исходники, ... - другая проблема, другие решиения.
no subject
Это не может не радовать =)
no subject
no subject
Для меня линуксы и С++ - инструменты, а не религия.
no subject