Комментарии 47
Если стабильность — главная боль рынка, значит, всё внимание нужно сосредоточить на архитектуре, управлении памятью, обработке потоков и реконнектах. Не “новые фичи ради рекламы”, а устойчивость 24/7.
есть такая присказка по этому поводу, которая прилично звучит примерно так: "Кого беспокоит чужая боль?". Интересно на сколько вас хватит с отказом от "новых фичь ради рекламы". К сожалению за борьбу с болью, даже самой главной, денег почему-то особо не дают, насколько мне известно, а научиться их самим зарабатывать, ой как не просто. И ладно бы было только не просто, так вами же все будут недовольны если вы эти деньги начнете действительно зарабатывать, вы станете практически врагом всего прогрессивного сообщества разработчиков!
Ну вообще на рынке всегда продают "лекарства от боли". И новые успешные продукты обычно именно решают чью-то "боль". И у инвесторов тоже довольно часто возникает вопрос "а чью боль это решает и сколько у него денег"?
И это мы ещё не пошли в медицину, где денег на боль дают и очень даже много.
если продолжать эту аналогию может получиться очень интересно:
Лекарства от боли создают зависимость (обычно) и впоследствии сами становятся главной причиной боли, но потребитель уже не может адекватно идентифицировать эти лекарства как причину боли, а просто требует еще больше лекарства (поэтому ценность их быстро повышается) и очень плохо относится к тому кто пытается ему-больному реально помочь, то есть устранить причину боли, а не просто заглушить боль на время. Собственно вот мы и описали модель развития любого недовольства адекватными действиями, того кто реально пытается решать проблемы, в психологическом плане.
неужели нельзя рекламироваться через "повысили надежность 20%". Обязательно свистоперделки? Ненавижу!!!
Посмотрите мое libwui.org возможно то что вам нужно. По крайней мере, у меня 30+ потоков видео плиткой воспроизводятся без проблем на i5-3550, каждый декодер в отдельном треде, рендеринг однопоточный по таймеру. Для ресайза без фризов есть фликер буфер.
Если интересно, попробую сделать демо приложение (native win / lin x64) для проигрывания видео файлов плиткой до 10x10. Изначально заточено под прием RTP стримов как раз.
Интересно!
Очень круто!
в DirectShow все это было уже 25 лет назад и никуда не делось причем с максимальной интеграцией с уровнем "железа" (аппаратным уровнем) через DirectX.
В начале 2000-х, уже, мы делали плеер где каждый декодер в отдельном треде (или даже в двух тредах если можно распараллелить декодирование последовательных фреймов с буферизацией), рендеринг однопоточный и по таймеру и по синхронизации со звуком на выбор, ... Причем примерно тот же самый код из DirectShow фильтров не так уж сложно портировать и под Линукс например, у меня тогда и пример приложения под Линукс тоже был, там под qt тогда были интерфейсы похожие на DirectX-овские (сюрфейсы, прямое копирование-запись в видеопамять,...).
Интересно, зачем вам мультиплатформа?
Ведь если продукт специфический или профессиональный, то платформа выбирается под продукт. Соответственно, лучше заточка и меньше проблем.
а на какой стек технологий перешли вместо использования Qt?
Какой бред.... Тысячи приложений (и vms тоже) работают на qt, месяцами и годами сервера молотят без багов и проблем, но именно у вас посыпались баги... Может дело было не в бабине?
Не бред, а суровая реальность.
Увы, большой опыт разработки в т.ч. vms, в .т.ч. с видеоаналитикой, в т.ч. с мобильным клиентом и т.д. и т.п.... Работает как часы.
Но вот некоторые заявления автора вызывают мягко говоря удивление: "Тогда внезапно выясняется, что сигналы между потоками теряются, QTimer не срабатывает, если объект живёт не в “главном” QThread, а QObject вообще не переносится между потоками без приключений." - читая подобное, кажется, что у парней память бьётся и отсюда нелепые баги в рандомных местах и только.
P.S. посмотрите на "фризы и лаги" в мультимедии и камерах например в Мерседесах или Теслах))
Можно конкретную ссылку на вашу программу для тестов? Сколько десятков тысяч пользователей у вашей сиcтемы?
А можно на примере опенсурсного Telegram Desktop Client, который использует QT и QT-Multimedia, может работать 24/7 хоть год и не имеет проблем с QTimer, QObject и другими описанными проблемами?
Telegram Desktop Client
Он даже нативный для Андроида с багами, из самого бесячего: постоянно пропадает подпись на строке с архивными каналами. Уже не один год. А в вебе ещё и постоянно счётчик непрочитанного показывает непрочитанные сообщения, когда их нет. Десктопным клиент при проигрывании видео вообще иногда отправлял ноут в ребут, хотя это спасибо амдешным драйверам
Telegram Desktop - это не VMS. Там максимум одно видео проигрывается в плеере и весит telegram.exe файл ~ 150 Mb. В ветке выше человек приводил пример сборки приложения для видеоконференций на libwui.org - там вся программа умещается в 12 Mb. Для кого-то и cupcat стабильное приложение.
Телега под виндой регулярно крашится, какой там год.
а вы пробовали собирать жалобы на qt? вы попробуйте. Баги и проблемы посыпались у пользователей продукта на основе qt если вы не заметили. Само по себе qt не является продуктом, потому что его никто не продает и никто за него не берет на себя ответственность, поэтому у qt не может быть багов и проблем. Баги и проблемы бывают только у того кто берет на себя ответственность за продукт, софтовый в данном случае.
Помните, как в том кино: "Кто ж его посадит? Он же памятник!".
Qt Group (ранее известна как The Qt Company, Qt Software, Trolltech и Quasar Technologies) — компания по производству программного обеспечения, базируется в Осло, Норвегия. Компания предоставляет платформы для разработки программ и фреймворки, а также предлагает консультационные услуги.
Основной продукт — Qt, мультиплатформенный графический C++ фреймворк.
Если денег заплатил за коммерческую лицензию, можно жаловаться.
хм.., судя по тому что мы не слышали о проблемах тех кто заплатил у них все просто замечательно или... может они стесняются того что заплатили, или... их тут просто нет как явления - они живут в другом мире, я, кстати, думаю это самый вероятный вариант с другим миром.
Спасибо за сарказм :)
К примеру, в ветке Qt 5.15 после минорной версии 5.15.2 для всех, Qt Group продолжила выпускать минорные версии только для обладателей коммерческой лицензии, вплоть до 5.15.19.
Так что, никто не стесняется, просто работают.
Не всех в целом устраивает Qt, и это вполне нормально. Кто-то уходит, как автор статьи, кто-то допиливает под свои нужды, как 2ГИС или Felgo.
И всё это — глубоко спрятано в DLL-файлах, закрытых от разработчика. Никакой отладки, никаких патчей. Просто смирись и живи с этим.
Или собери из исходников? И отлаживай / патчи, что нужно. Можно также собрать со статической линковкой, и по-прежнему можно будет соответствовать требованиям LGPL, если не хотите со своими пользователями делиться исходниками по GPL (если в РФ вообще хоть кому-то есть дело до требований GPL/LGPL).
Qt обожает плагины и динамические библиотеки, тонкие настройки путей к плагинам и зависимостям. Добавьте мультимедиа, кодеки, QML — и вот уже дистрибутив весит больше чем Chrome.
Со статической линковкой должно получиться меньше, не говоря уже о более простом деплое/распространении.
На Windows под капотом — WMF, на Linux — GStreamer, на macOS — AVFoundation
Qt5 никогда не использовал "родной" FFmpeg
В Qt6 вроде бы FFmpeg теперь как раз таки основной бекенд? Или там тоже не всё благополучно?
Запрет на использование Qt в России
А он прямо запрещён? Я несколько отстал от стремительно развивающейся российской специфики, так что я правда не знаю.
Я, на самом деле, не прямо чтобы защищаю Qt, потому что для вашего проекта он действительно может иметь все описанные вами проблемы с производительностью / стабильностью. Я только хотел прокомментировать, что особенно бросилось в глаза из общих претензий.
Ну да, странно звучит.
Qt без проблем собирается своими руками из исходников.
Если есть проблемы - можно собрать с отладочными символами и с санитайзерами.
Можно вообще собрать минималистичный билд для себя только с тем что тебе надо.
И нет никаких проблем использовать свою копию Qt в составе своего софта.
Просто надо один раз настроить conf и все положить в нужные места.
Другое дело если у вас нет требования кроссплатформенности - тогда Qt может быть излишним.
Но если такое требование есть, то Qt является очевидным выбором.
Послушаешь — всё звучит просто. Вот только там LGPLv3, и не зря большинство в коммерческих продуктах используют библиотеки Qt, подписанные самим Qt Company.
Поддерживать свои сборки Qt-фреймворка нужны огромные ресурсы.
Есть такая проблема с lgplv3.
Если вы делаете продукт, который может быть использован в dwelling (human habitat) то вы должны предоставлять пользователю право на обновление библиотек Qt, проблемы при использовании таких сборок Qt ложатся на плечи пользователя.
Вашего кода это не касается, если вы линкуетесь динамически.
Другого варианта тут и нет, если конечно не хотите выложить свой код под gpl.
Не вижу никаких проблем в поддержке своих сборок Qt, как человек лично поддерживающий подобные сборки на протяжении десятка лет.
Равно как и не понимаю ваш хейт в отношении данного фреймворка.
"Вы не любите кошек? Может вы просто не умеете их правильно готовить?" (C) Альф.
Поддерживать свои сборки Qt-фреймворка нужны огромные ресурсы
vcpkg install qtdeclarative:x64-windows
vcpkg install qtdeclarative:x64-linux-dynamic
del
Как будто все законодатели мод все клиентсткие приложения адаптируют к вебу. Все звонилки, следилки. Если бы мне завтра поставили задачу давай сделаем чтобы жить в будущем было проще. Я бы использовал веб технологии или максимально к ним близкие по духу. Qt насколько я знаю это древний фреймворк времен extjs или даже раньше. Как написано в статье франкенштейн.
И для того чтобы в будущем не столкнуться с этой проблемой использовать современные подходы разделения кода. Отделить логику от представления на клиенте. В вебе пришли к этому спустя лет 10 после популярности js. На текущий момент архитектура клиента пошла ещё дальше, из актуального FSD.
Веб технологии врядли запретят.
А кому-то Qt помешало вступить в реестр отечественного ПО? Мы просто скоро будет подаваться, интересно узнать опыт других.
Уважаемый автор, видимо, таким образом трактует запрет, введенный The Qt Company на скачивание своих бинарных сборок со своего официального сайта через свой официальный инсталлятор. Каким образом в воображении автора это выливается в проблемы с регистрацией в реестре, решительно непонятно, т.к. код по-прежнему распространяется под свободной лицензией (L)GPL и дополнительные ограничения (на использование кода, а не бинарных сборок) даже сама The Qt Company вводить не вправе. Та же Astra Linux со своим нескучным десктопным окружением Fly, написанным на Qt, всё ещё там находится и вряд ли оттуда исчезнет.
Если очень нужны бинари, можно скачивать с любого зеркала с помощью aqtinstall. А вообще можно самим собирать через vcpkg.
В актуальной версии Export Control of Qt Framework and Tools Qt перечисляет, куда нельзя экспортировать продукты и техданные Qt. В списке стран под полным эмбарго фигурирует и Russian Federation (рядом с Кубой, Ираном, Сирией, Беларусью и т.д.). Там чёрным по белому: продукты Qt не могут быть экспортированы/пере-экспортированы лицам или компаниям, находящимся в этих странах, если только нет специального разрешения компетентных органов.
Т.е. собранные dll, подписанные сертификатом Qt формально использовать нельзя. Нужно собирать все dll и подписывать их самим из исходников
То, что вы написали, относится к коммерческой версии Qt, которую действительно теперь нельзя купить. В приведенной вами политике прямо написано, что страной экспорта является Ирландия, т.к. там находится сервер с коммерческими сборками.
Если мы используем Qt Community Edition, то после скачивания (даже через VPN) open-source версий DLL мы вправе их распространять как нам заблагорассудится, см. соответствующий раздел на странице лицензий:
Four freedoms of Open-Source
...
Redistribute copies so you can help other open-source users
...
These four degrees of freedom are absolute and non-negotiable. One cannot enjoy freedom without offering it to others, thus, freedom is also an obligation.
Qt Company не имеет права поставлять / передавать / экспортировать подписанные официальные сборки Qt в Россию (Community Edition тоже является экспортируемым продуктом). Это прямо указано в их Export Control Statement, где Россия входит в список стран под запретом. В Community Edition все собранные dll подписаны сертификатом Qt.
Это означает, что вы можете использовать только те Qt DLL, которые уже у вас уже были до момента введения запрета, либо собирать и подписывать все модули самостоятельно непосредственно из исходников.
Qt Company не имеет права вам их предоставлять заново, обновлять или передавать; Qt не может официально взаимодействовать с российскими юрлицами по поводу Community Edition; Qt не может предоставлять подписанные сборки российским разработчикам.
Community Edition тоже является экспортируемым продуктом
Уточните, пожалуйста, на основании чего сделан данный вывод.
Community Edition все собранные dll подписаны сертификатом Qt
И каким образом это накладывает ограничения, которые противоречат лицензии LGPL?
Коммерческая и Community-версии Qt разрабатываются из единой кодовой базы. Разделение осуществляется исключительно по лицензированию, а не по составу или функциональному наполнению исходного кода. Вследствие этого требования экспортного контроля применяются ко всем веткам Qt одинаково.
В состав Qt включены модули, использующие криптографические механизмы и функциональность защиты данных, в том числе QtNetwork, QtWebEngine, QtWebSockets, QtBluetooth, QtPositioning, QtRemoteObjects и другие компоненты. Согласно классификации ЕС, такие средства отнесены к категории 5A002 / 5D002 Перечня продукции двойного назначения, регулируемого Регламентом (EU) 2021/821 (Dual-Use Regulation), что автоматически накладывает экспортные ограничения.
Qt Group прямо указывает:
“The Qt Group products or related technical data may not be exported, re-exported or transferred, either directly or indirectly, to any person or entity located, established, or resident in a country or territory subject to a comprehensive trade embargo maintained by the United Nations, the United States, or the European Union (including, but not necessarily limited to, Cuba, Belarus, Iran, North Korea, Russian Federation, Syria and any territories of Ukraine occupied by the Russian Federation, such as Crimea).”
Даже, если теоретически существует альтернативное зеркало или репозиторий, поддерживаемый где-нибудь в Китае с комментариями на мандарине, аудитом и самостоятельной перекомпиляцией, — юридическая действительность остаётся неизменной: исходное правообладание, механизм распространения и экспортные ограничения исходят из европейской юрисдикции.
На практике Qt Community Edition представляет собой устаревший вариант коммерческой ветки Qt, преимущественно разработанный и собранный сотрудниками на территории Финляндии и Ирландии. Эти территории подпадают под действие европейского экспортного регулирования. Разработчик Qt вам прямо говорит: "мы вам не рады, мы не будем отвечать на ваши письма и оказывать поддержку, нам пофиг на международное право и то что вы у нас покупали ранее, скачивание закрыто вне зависимости от наличия предыдущих лицензий или правомерных покупок…."
Только для создания красивого GUI вы включаете в свой продукт 500 метров всякой бинарной дряни, которая не тестировалась ни вами, ни ФСТЭК на предмет закладок. Вспомните примеры с выходом из строя оборудования Siemens на ядерных объектах Ирана, или когда доступ с камер с режимного объекта становится доступен кому не надо.
Пока ваш продукт местечковый - риска претензий почти нет. Однако, при выходе на более серьезный уровень (как Telegram), могут быть претензии и меры задержания где-нибудь в Таиланде.
Вследствие этого требования экспортного контроля применяются ко всем веткам Qt одинаково
По-моему, это снова субъективное суждение с вашей стороны. Двойное лицензирование это распространенный подход к коммерциализации ПО, и наличие коммерческого варианта не должно ограничивать использование исходного кода, распространяемого под свободной лицензией. Есть коммерческий продукт, есть свободное ПО. Код используется один, но сущности разные. Авторы (через Contribution Agreement) наделили The Qt Company правами распространять код как по коммерческой, так и по свободной лицензии.
Если рассматривать свободное ПО, то я бы ориентировался на разъяснения, данные The Linux Foundation (по-моему, источник весьма авторитетный):
What kind of open source projects are not subject to the EAR and export restrictions?
All of them.
По поводу остальных рассуждений могу сказать, что каждый решает сам, важна ли платная поддержка (доступ в багтрекер бесплатный, если что) или насколько критичный размер бинарников получается в эпоху, когда из альтернатив по сути только Electron.
Никто не запрещает вам работать с открытым исходным кодом — пожалуйста, собирайте. Но вместе с вашим собственным кодом там неизбежно присутствуют и бинарные модули, содержащие криптографию, которая попадает в перечень продукции двойного назначения ЕС. Теоретически можно использовать всё это «на свой страх и риск», и в Qt об этом действительно никто не узнает. Но есть большие риски и будет непонятна позиция регулятора, если он разрешит это использовать на определенных объектах.
Не помню, чтобы в Qt была какая-то нестандартная криптография (а ограничения именно на нестандартную криптографию накладываются). Могу ошибаться, но для целей шифрования вроде как используется либо нативное API операционной системы, либо OpenSSL. Т.е. все шифрование за пределами Qt, никаких кастомных алгоритмов нет, поэтому и ограничения не должны распространяться.
The Qt Company юридически является правообладателем фреймворка Qt, в том числе версии Community Edition (речь не про лицензию распространения). Теперь смотрим внимательно "Методические рекомендации по работе с Федеральной государственной информационной системой «Реестры программ для электронных вычислительных машин и баз данных» (ФГИС Реестры ПО). В них четко написано: “Запрещено использовать любое ПО, имеющее ограничения на распространение или использование на всей территории РФ”
“Разрешено ПО, относительно которого его правообладатель официальным письмом гарантировал отсутствие любых ограничений на его распространение и использование на всей территории РФ, включая Республику Крым, Севастополь, ЛНР, ДНР, Запорожскую и Херсонскую области”
Вы немного промахнулись, Qt Community Edition попадает под графу "ПО с открытой лицензией". Соответственно, гарантийное письмо нужно для других случаев (когда лицензия не открытия, а это не наш случай). Иначе пришлось бы запрашивать письма у всех авторов всех свободных библиотек, используемых программами, зарегистрированными в реестре.
Qt Community Edition, как и любое другое свободное/открытое ПО, распространяемое под любой лицензией, одобренной Open Source Initiative, не имеет и не может иметь ограничений использование по географическому принципу.
Вы же не делаете полную пересборку Qt из исходников в России, а берете чужие бинарики. Какие там закладки никто не знает. Самое простое решение - сделать официальный запрос в Минцифры по поводу возможности их использования из qt framework.
у всяких технологий есть свои плюсы и минусы, по другому не бывает
и выбор стека это всегда про их понимание и компромисс
перед тем, как куда-то инвестировать, надо быть уверенным, что это хорошая идея и учтены все риски
реальный опыт бесценен
написать PoC на Qt с возможностью протестировать любое количество одновременных потоков + эмуляция вещей типа потери пакетов -- ну неделя работы

Пять лет спустя: почему мы всё переписали с нуля