GTK2-NG: форк библиотеки GTK2

З.Ы. к чистому Си он прикручивается через одно место, см dbus-codegen

А вы знаете примеры, когда RPC без кодегенов к С прикручивается?

gtk3-to-gtk2.

Мля! :) Чего только народ ни придумает.

А в обратную сторону - тоже есть?

По вашей идее, вместо демона шиной используется ФС. Ну ок, какие из этого плюсы (ну кроме повышения уровня абстрагирования и, соответственно, куда больших тормозов, уж и DBus-то тут не подарок, хотя с брокером получше)?

Понижения же. Вместо XML для настройки и отправки через промежуточный сервис клиент просто отправляет запрос напрямую.

А основной плюс в том, что внутри chroot или внутри каталога пользователя интерфейс через файл работает автоматически. А в DBus чтобы после su или chroot обращалось куда надо, приходится плясать с бубном.

Сервер в этот сокет отправил пакет, n-цать клиентов должны его получить. Только они, не вся шина.

Так отправить пакет можно в соединение, а не сокет. Какая шина в файле?

Насилуем себя multicast-ом.

Он только для передачи по сети нужен.

Да хоть пайпы, хоть shm. Сериализацию и синхронизацию это как-то отменило?

Посмотри исходники syslog. Синхронизация на уровне соединения через сокет. TCP там не нужен. А сериализация нужна в объёме, необходимом для протокола. JSON нужен только для иерархических данных. В простейшем варианте хватает printf и scanf.

Структура из двух uint32_t, между которыми два uint16_t и пять строк.

Ненамного больше информации, чем «возвращает строку с ответом».

Там cJSON пашет. Велик для того

Меньше, чем D-Bus.

Допустим API немного поменялся. Резко и решительно переписываем всё, что использует наш кастомный бинарный протокол? Да ну, нафиг.

Так всё равно переписывать. Стал у тебя вместо uqqusssss, например, uusssssqq. И всё, надо переписывать.

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

А в документации описывать как эта структура (де)сериализуется. И тут готовых сериализаторов от protobuf до capnproto.

Стандартизировать-то и унифицировать это всё равно надо.

Зачем? Вот не понимаю этой мании всё привести к единому виду. То всё в XML паковали, теперь в JSON. Для grep тоже надо параметры сделать в виде grep '{"regexp": "abc", "recurse": true}'? И ответ в JSON для стандартизации.

Уже есть МАТЕ, и на диверсию это никак не тянет

Ну да - но под вейландом он не работает. Скажем так запускается и подает признаки жизни, но это жалкая тень того что было под иксом….

А вы знаете примеры, когда RPC без кодегенов к С прикручивается?

https://man.archlinux.org/man/rpc.3.en

Так речь про то, что это лишний слой.

Как есть браузер, который поверх Gtk. И лучше интерфейс писать на Gtk, а не на HTML для браузера.

Так вот, dbus для пересылки байт требует демона

Такого «потока мысли» давно не слышал. Фраза достойна цитатника. :) Хоть бы потратили 2 минуты на чтение основ дбас.

А основной плюс в том

И пожалуй единственный. В остальном сплошные минусы.

Какая шина в файле?

Цитата: Шина в программировании — это единый канал, через который передаются данные, адреса и управляющие сигналы между различными компонентами системы.

Предлагается задействовать файлы и, в принципе, структуру ФС для этого. Т.е. использовать ФС, как шину.

Он только для передачи по сети нужен.

В такой модели я перестаю понимать необходимость uds сокетов. Выкидываем?

Посмотри исходники syslog.

Это топология много-один. Я говорил про обратный вариант.

Ненамного больше информации, чем «возвращает строку с ответом».

Которую мы парсим как … а как собственно?

Меньше, чем D-Bus.

Но это на любом Линуксе работает и писал это не я, и мозг себе сношать маршаллингом и корректностью передачи мне не надо.

И всё, надо переписывать.

И я могу об этом узнать прямо в рантайме из интроспекции.

Вот не понимаю этой мании всё привести к единому виду.

Будешь выяснять как в каждую конкретную программу данные заслать и получить обратно. Вот одна будет хотеть json, другая XML, третья вообще кастом на строках: поддерживаем все? Тоже идея - агонь.

Такого «потока мысли» давно не слышал. Фраза достойна цитатника. :) Хоть бы потратили 2 минуты на чтение основ дбас.

Теоретически можно не использовать демон шины, но таких приложений я не видел.

https://man.archlinux.org/man/rpc.3.en

Сэр, вам тут не детский сад. :) Я-то этим пользовался, и знаю, что санрпц, на который вы ссылку даёте, работает в связке с rpcgen. Так что man rpcgen для начала.

Т.е. в рантайме никак? К каждому калькулятору будем сокеты в /var/run/ создавать (а также семафоры, но уж хрен с ними)?

Прога вдруг в рантайме сама решила что ей надо куда-то обратиться? Программист не в курсе. что она может это захотеть? Очень странная ситуация и скорее всего плохой программист.

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

Нет, я понимаю что всё будет норм. А сокеты я использовал «со всех сторон»: и с клиентской, и с серверной, и с п2п, и со стороны реализации TCP/IP стека. Нигде почему-то не запутался.

О передаче сообщений один-много. Трахаемся с мультикаст группами?

Ладно, чуть-чуть убедил. Такое и правда иногда нужно. Однако, всё же, есть что возразить.

Широковещания в юникс-сокетах вроде действительно нет, и наверно было бы полезным если бы оно было (в ядре, через обычное сокетное апи без дополнительных надстроек). Но ладно, его нет.

Сообщения один-много нужны крайне редко, и в большинстве случаев это какие-то системные демоны, связанные с глобальным состоянием. И вот почему бы к ним и не прикрутить пулы клиентских подписок для юзерспейсного широковещания? Можно даже выделить это всё в библиотеку и тогда в коде самого демона всё будет совсем просто. Чем это лучше dbus:

1) не требуется запускать дополнительную прогу,

2) учёт доступов файловой системы, опять же на примере сислога: в сислог можно слать из тех chroot-ов, где есть его сокет, список поднимаемых сокетов можно указать и таким образом выбрать кто им пользуется, а так же можно запустить второй, третий итд сислоги для отдельных клиентов - всё это делается на стороне ОС, клиенты же просто коннектятся к дефолтному сокету и не думают об этих подробностях.

Да, иногда всё-таки хочется отдельный демон, несмотря на всё вышенаписанное, но это редко. Во всех остальных случаях (не говоря уж о тех, где обычные p2p сообщения) - он не нужен, незачем его сувать ради мнимого единообразия.

В тоже время клиент курит бамбук?

Можно сделать большой сокет-буфер (чтобы в него всё влезло) или слать через shm например. Кстати shm можно ещё для один-много использовать.

Ну так если никогда ничего практического не делал, так и не замечал.

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

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

И вот этот весь траходром, ты предлагаешь реализовывать в каждой софтине, с ФС в роли шины, с кастомным протоколом сериализации в каждой, без четкого маршалинга и корректной отработки ошибок? Сильно.

Ты так пишешь, как будто «протокол сериализации» это какая-то отдельная огромная сущность, заслуживающая внимания. И с чего ты взял что без корректной обработки ошибок?

Вообще, как мини-пример: вот (gitflic.ru) плагины к моему пет-проекту.

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

json

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

Так речь про то, что это лишний слой.

Кто, дбас - лишний слой? В каком смысле? Вы на голом транспорте будете RPC делать? Вообще, нельзя ли яснее выражаться, чтобы мне не гадать, а что, в вашем понимании, вообще RPC, и что есть в нём «не лишний слой»?

Теоретически можно не использовать демон шины, но таких приложений я не видел.

Он написал, что демон требуется, цитирую: «для пересылки байт». Это верх идиотизма. В архитектуре дбас, демон может требоваться (а может и нет, если kdbus), но уж точно не для пересылки байт. Этот чел вообще не в теме, я не счёл нужным даже объяснять.

Которую мы парсим как … а как собственно?

Вот именно, как парсить твоё uqqusssss совершенно непонятно. От того, что мы узнаём, что там идут указанные целые типы в указанном порядке, пользы немного - ну получили мы пачку чисел, что с ними дальше делать, что они означают? Это в любом случае может быть указано только в документации в проге, которая это послание принимает (или шлёт).

Вот одна будет хотеть json, другая XML, третья вообще кастом на строках: поддерживаем все? Тоже идея - агонь.

dbus никак эту проблему не решает, он только добавляет обёрточный протокол к передаваемым данным, а данные всё так же могут быть какими угодно. Одна прога принимает картинки только в jpeg, другая только в png, а какое-нить гуглоподелие решило попиарить webp и принимает только его. Поддерживать всё варианты и линковать в свою прогу конвертер? Зато всё - через dbus.

ну получили мы пачку чисел, что с ними дальше делать, что они означают? Это в любом случае может быть указано только в документации в проге, которая это послание принимает (или шлёт).

И как, по вашему, работает dbus audit? А, ну да, у вас же dbus-демон байты пересылает, о чём это я…

среди которых afterstep, Double Commander, fpc, gkrellm, gmpc, hexchat, lazarus, mplayer, navit, pidgin, sane-frontends, scim, sylpheed, tickr, tilem, uim, usermode, xsane, xzgv и z88

Slurm Workload Manager, Chemtool, Asunder, Gnome Paint, gFTP, XQF, Choosewm.

Типа все так, но у меня достаточно несбалансированная конфигурация, игры упираются в цп и память, видяшка напрягается хорошо если на 60%. Т.е. даже не сжигая и напрягая видяху есть разница в ФПС. Сразу говорю, энергопотребление видяхи не смотрел.

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

игры упираются в цп и память

Вулкан как раз позволяет гораздо лучше мультитредить задачи на проце - подключать больше ядер в параллель а значит эффективнее грузить видюху. Точь в точь твой случай.

Человеку нравится GTK2 под иксами, что делать?

• типичный пользователь ЛОРа: начинает ныть в темах, какой вяленый плохой

• этот тип из дивана: форкает GTK2 и начинает его допиливать под современные системы

В результате практического смысла ноль что в одном действии что в другом. Фарш невозможно провернуть назад…

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

3.. 2.. 1.. до момента когда авторов форка отменят и объявят nazi.

У нас есть какой-то более другой стандартный IPC ?

Юникс сокеты, шаред мемори, пайпы, удп/тисипи сокеты

Для чего нужен дбас? Чтоб можно было адрес указать?

Какой в нём смысл, если технически он нормально работать не будет (спасибо шизе галлиума с его несовместимостью с вулканом)?

ну вообще тут речь идёт о RPC, а не IPC (dbus - именно RPC)

А в обратную сторону - тоже есть?

ну тебе надо - сделай

на деле xul'овые браузеры gtk используют только для подхватывания темы, а сам gtk оттуда выпидивается за неделю

У нас есть какой-то более другой стандартный IPC ?

Юникс сокеты, шаред мемори, пайпы, удп/тисипи сокеты

Всё так.

Для чего нужен дбас? Чтоб можно было адрес указать?

Проблема в том, что тут господа «обсуждальщики» не владеют даже базовой терминологией, и мало себе представляют, чем IPC отличается от RPC. Зря вы пытаетесь им вопросы позадавать.

Если совсем коротко, то дбас - RPC, а под ним лежит транспорт в виде IPC. В систему RPC обычно (исключения мне не известны) входит так же кодогенератор, например dbus-codegen, rpcgen.

ну вообще тут речь идёт о RPC, а не IPC (dbus - именно RPC)

О! Вижу здорового человека в триде, наконец. :)

ну тебе надо - сделай

Мне как раз вообще не надо. Это некрофилия.

Не system d.

Ну не знаю. У меня работает. Сижу на Wayfire c экспериментальным вулкановым рендерером. Пока не все свистоперделки самого wayfire работают учитывая что они на gles сделаны и портировать их та еще боль, но в целом работает.

Каких либо проблем ну кроме рабочих моментов оптимизации с тем же фоксом рендерящим через gles нет пока. Стеллариум работает. Всякие кикады-прусаслайсеры через xwayland - тоже. Чего там у вас не работает с ним - не знаю. Может игрульки - да тьфу на них, даром не надь богомерзость эту.

спасибо шизе галлиума с его несовместимостью с вулканом

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

Сложно назвать это пользой.

когда я последний раз пробовал - они не справились, куча потрохов systemd осталась

Может с конкретным драйвером повезло? У меня opengl приложеия упорно отдают вместо drm_modifier -1, в вулкане с таким значением можно только нахрен послать

Интел обычный - причем пробовал и на i915 и на новом xe2. на амд честно говоря не пробовал но по идее на амд вулкан должен быть только лучше. Нвидии как обычно - средний палец Линуса в глаз, себе не куплю посему не знаю.

Ну да, RPC - то в определении высокоуровневый IPC. Собственно, как определяют сами авторы (цитата с gitlab).

D-Bus is a simple system for interprocess communication and coordination.

Да это понятно, и господа обсуждальщикам, я уверен понятно, просто, как по мне, общаться между процессами с помощью дбас, это создавать себе больше проблем, чем решать, какие у него плюсы супротив общения вручную по ipc?

Почему-то большинство раз, когда я слышал слово RPC, оно упоминалось в контексте описания какой-нить очередной дыры (причём не важно на какой основе - что в ядре, что в пхп-скриптах). Видимо это плохая штука и её надо избегать.

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

Алиллуя. Так и смысл в том, что ПОЛУЧИЛИ и ПЕРЕДАЛИ делается единым универсальным способом, который НИКАК не зависит от исходной и конечной программы. И их никак не забтит, каким образом оно будет транспортироваться.

dbus никак эту проблему не решает, он только добавляет обёрточный протокол к передаваемым данным

Пляшу от радости негритянками на столе. А ты весь тред предлагаешь каждому приложению вот это всё о чём мы дискутируем (ака сериализацию/маршаллинг, контроль клиентов, проверка корректности, обработку ошибок протокола и т.д.), т.е. этот самый протокол реализовать вот прямо самим (ну, чтобы вот без демона)? Уверен что все реализуют корректно и вообще захотят это делать?

Поддержание форка позволит продолжить поставку в Devuan приложений, завязанных на GTK2

А поезд приложений еще не ушел?

$ pacman -Qi gtk2 | grep "Required"
Required By     : gtkmm  # --> nitrogen

Ну да, RPC - то в определении высокоуровневый IPC. Собственно, как определяют сами авторы (цитата с gitlab).

Этот момент действительно надо пояснить, так как он, с ходу, не очевиден. То, что вы нашли на гитхабе - реализация дбас. Она включает в себя небольшую айписи-надстройку в виде демона, и тд. Далее, поверх неё лепят RPC, например, sd-bus.

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

Что имеем в итоге:

• реализацию дбас, что вы нашли, где и написано, что это IPC
• спеку dbus, охватывающую весь RPC-стек, а не только найденную вами реализацию
• реализацию sd-bus - это уже RPC, но сделана она по спекам обычного dbus

Согласен, путаница тут, и правда, есть. И это я ещё не указал на то, что и сокеты, поверх которых всё это добро работает - тоже называются IPC… В общем, любой бы запутался, кто с этим не работал.

надеюсь, ты не путаешь RPC и RCE?
RPC это удалённый вызов сперциально предназначенных для этого процедур, дыр он не создаёт, если какой-нибудь идиот явно на нём дыру не сделает

Нет, не путаю. Реально, я слово RPC больше всего раз слышал именно в том контексте что в нём (точнее, в чьём-то модуле со словом RPC в названии) нашли дыру. Причём это какая-то всеобъемлющая корреляция, одинаково применимая от ядер до вебни.

Это конечно вполне вероятно, что неграммотно сделанные rpc функции приводят к возможным уязвимостям. Но это лишь потому, что RPC это канал взаимодействия с процессом, причём довольно простой - не через сообщения, а через команды с ответом

какие у него плюсы супротив общения вручную по ipc?

Такие, как и у любого другого RPC. Вам их прям перечислять? Ну хотя бы тот же аудит. Но это так, 1 пункт из 100.

Предлагается задействовать файлы и, в принципе, структуру ФС для этого. Т.е. использовать ФС, как шину.

Тогда какие-такие «n-цать клиентов» у одного соединения полученного через файловый сокет?

В такой модели я перестаю понимать необходимость uds сокетов. Выкидываем?

В смысле? UDS как раз для работы внутри компьютера. А нужны они для организации соединений между программами (выше про синхронизацию упоминалось).

Это топология много-один. Я говорил про обратный вариант.

Один клиент к многим серверам и одно сложное сообщение ко всем разом? А можно какой-то пример зачем такое может понадобиться?

Вроде всегда лучше к каждому отдельно подключиться.

Которую мы парсим как … а как собственно?

А как мы парсим 5 последних строк из вышеприведённого описания?

Но это на любом Линуксе работает

Логика та же, что для программ в браузере: работает на любом Линуксе и даже не Линуксе. А то, что калькулятор 200 МБ весит, это не важно.

И я могу об этом узнать прямо в рантайме из интроспекции.

А если последние 5 строк теперь в другом порядке? И даже если узнал, это как-то позволит не переписывать?

Тогда вот: https://github.com/haiwen/libsearpc

Кто, дбас - лишний слой? В каком смысле? Вы на голом транспорте будете RPC делать? Вообще, нельзя ли яснее выражаться, чтобы мне не гадать, а что, в вашем понимании, вообще RPC, и что есть в нём «не лишний слой»?

Почти всегда полнофункциональный RPC с произвольными функциями не требуется. У программы есть некий протокол, который почти всегда проще сделать на байтовых строках UDS (с возможностью указать отдельный файл для каждого chroot и даже для каждого отдельного пользователя). Для работы сторонних клиентов пишется libmyprogclient с нормальным комментированным сишным API.

Syslog уже приводили как пример. Ещё есть https://github.com/avahi/avahi/blob/master/avahi-client/client.h

А какой-нибудь libmysqlclient на RPC D-Bus я с ужасом представляю.

просто это портал в ад || астрал