Qt и демоны

Используй QtService и «завись» от Qt - не вижу никакой проблемы. Ты же не ядро подсистемы дистрибутива пишешь, а прикладную софтину.

Словно Qt не установлено в каждом дистрибутиве.

в каждом телефоне, же!

да вообще везде!

сарказм

Ты не согласен с моим утверждением?

А boost типа не толстый?

В бусте большинство вещей header-only, так что его «толщина» зависит от того, что ты используешь (как и с STL). Хотя «кошерность» буста (и С++ вообще) для написания демонов нисколько не выше, чем кошерность Qt (только си, только сисколлы)

Хм. Qt мне в основном нужен для d-bus и для event loop.

Посмотрел примеры использования d-bus на С, ужаснулся. Всё-таки мне кажется что d-bus заточен под объекты.

Влинкуй статически, чо. Никто ничего не узнает.

Название треда кстати очень интересное. Форум сатанистов какой-то :°

I have a dream! Что бы программеры забыли про кошерность, фанатизм, амбиционизм, перфекционизм и прочие изм. А просто бы писали код теми средствами, которые наиболее подходящие под ситуацию. В общем не вижу ничего плохого в использовании кути и в демонах. :)

я вообще за QT Everywhere

Можно и динамически. Почему бы и нет. А перед этим собрать QtCore без неиспользуемых мной фич. Я думаю она будет тощей. Вопрос только в конфликтах с системной. Хотя кчёрту системную, всё равно там кроме меня никто Qt использовать не будет.

Shared object, не даром зовётся shared. А если кроме твоего демона из ада самособранную кутю никто не будет юзать, зачем тогда shared object вообще? Хотя, делай как знаешь.

Ну, всякие там LGPL. Или LGPL позволяет статическую линковку?

Я Qt-фил, но вижу что Qt не может быть вообще для всего, хотя это и так понятно. Но сую я Qt везде где только можно.

Если в коде кутей ничего не меняешь, то можно.

а вот на сервере без GUI вполне может не быть его

Бабушкин тоже батники впилил внутрь dll'ек, тоже думал не узнают... ТС, без знания что это за служба - подсказать не можем. Может оказаться, что Qt там из пушки по воробьям. Например, на эмбеддед безгуевый я бы Qt тащить не стал.

Работа с com портом и отдача результатов по d-bus.

Раз уж зацепил qt - для управления состояниями устройства использовал State Machine Framework.

Соответственно, тащу только QtCore и QtDbus. В перспективе, возможно, ещё QtNetwork.

А я бы стал, еще как стал бы, и уже так поступаю. Лучше потрачу дополнительные 5% ОЗУ и 10% флэшка, чем буду страдать без Qt.

Ну не совсем понимаю на кой для этого вообще нужен дбус, ну да ладно. помоему TCP/IP было бы проще в этом случае.

Дело твое, я для мелочи использую lualibusb + lua + luci для вебморды, выходит и проще, и быстрее, и легко умещается даже в 4MiB SPI флеша.

. помоему TCP/IP было бы проще в этом случае.

Согласен. Подключаем QtScript, QtNetwork, связываем их и засовываем в js-среду объект с необходимым API, и вуаля — у нас есть js-шелл, к которому можно коннектиться обычным netcat'ом.

Ну, там на коме висит модем, купюроприёмник, диспенсер (который банкноты выдаёт), ещё watchdog. Саму совтину, которая должна с этим железом работать, пишет совершенно другой человек. Изобретать велосипеды для обмена инфой с ним не очень охота - поэтому d-bus.

Тогда думаю сойдет более чем.

что это за библиотеки? мне вероятно предстоит создать web-интерфейс к прибору, пока не думал на чем и как...

Пацаны пишут демонов на java/python/like_that. Или ты не посан?

OpenWRT'шный webui на luaшном фреймворке LUCI сделан. штука приятная, хотя не особенно хорошо документирована. lualibusb - расширение, чтобы можно было из луа окружения через libusb общаться с девайсом. Соотсветственно OpenWRT тут рулит и педалит, ибо связка на ура умещается в 4MiB, а 8MiB хватит и на блекджек со шлюхами.

Для D-Bus, наверное, на питоне писать кошерно. Все равно производителность никакая.

Просто не обращайте внимания на кукарекания тулкитофобов. Qt прекрасно подходит для десктопа.

com, подскажи, в QtService есть «install» - оно работает с upstart и systemd? в Qt4.8.* успели интегрировать поддержку?

Неа, не работает. QtService, как я понял, как и большинство Solutions, забросили. При этом релизнули под BSD.

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

Я писал демоны с Qt. Полёт отличный, всё хорошо работает. Qt haters gonna hate.

Upstart? systemd?

Debian, sysvinit + start-stop-daemon

жуть

А я писал демона на haskell, kekeke. У кого толще?

на асме слабо?

Асм ненужен.

Асм ненужен.

Этож подумай: для браузера отдельная машина, для js в нём — отдельный системник с js-машиной, ну для лиспа уже всё разработано, только ЭБ обновить. И системные perl, python, bash, etc — на них тоже по системнику.

Я ничего не понял из этого дампа сознания, извините.

Подозреваю что анон имел ввиду что дескать современные языки типа JS - это абстракция над абстракцией, поэтому асм нужен для максимальной производительности.

Но я не согласен, лучше просто взять нормальные C/C++ компилятор и спокойно писать быстрый код.

поэтому асм нужен для максимальной производительности.

Тут недавно был тред про Kolibri OS. Тамошние асмофаги так и не смогли привести ни одного примера, как переписыванием на асм можно что-то ускорить. Myth is busted, ящитаю.

Ятожетакщитаю ^_^

Почему?)

потому что Upstart, так как systemd