И третий раз Грег пытается протолкнуть kdbus...

А по сути: на кой оно нужно?

Регистранты уже настолько обленились, что не читают не только документацию, но и новости?

Читал, еще как читал. Но все равно не понял. Зачем оно, когда есть нормальный dbus?

Ну, слушай, если ты читал это

http://www.opennet.ru/opennews/art.shtml?num=41478
https://lkml.org/lkml/2015/1/16/488

и ничего не понял, то я уже не знаю, чем тебе помочь.

Теперь понял. Не нужно. Как и systemd

:D

Теперь я понял, что тебе уже никто не поможет.

Обоснуй.

Что характерно - так же говорили про dbus. И хейтили его еще больше. А теперь:

Зачем оно, когда есть нормальный dbus?

В основе стратегии systemd-хейтеров почти всегда лежат двойные стандарты.

Кто-нибудь, кроме systemd его использует? Можно ли заменить обычный дыбас кадыбасом?

И в третий раз Линус его завернет?

Грег же второй человек после Линуса, неужели они не договорились.

ХЗ. Да.

Просто ОП балбес и перепутал Грега с другим поссажиром.

«Пытается»? Я слышал, что всё уже на мази.

Да.

А как? Демон какой-нибудь всё равно нужен?

А когда это Линус заворачивал что-нибудь от Грега?

dbus тоже не нужен.

Насколько я помню, он его несколько раз посылал с этим kdbus'ом

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

Они с Сиверсом из одной банды, если что)

На пару пилят. Кстати да, спутал. Сорри. Но пилят-то они с ГКеем Сиверсом этот kdbus вместе

Тотальное недосыпание дает о себе знать. Извиняюсь.

Вообще, есть мнение, если бы никто не вы...ся с IPC типа shared memory и всё делал через сокеты прямыми руками, их скорость и пропускная способность была бы достаточной для любых задач systemd и gnome, и в итоге kdbus не понадобился в принципе. Но в мире много программеров, и теперь конечно же kdbus торт.

И в третий раз Линус его завернет?

Не факт.

А по сути: на кой оно нужно?

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

Хитрый план по началу создания systemd-kernel?

Это к этому вообще никак не относится.

Ждём ksystemd.

Но пилят-то они с ГКеем Сиверсом этот kdbus вместе

Если брать по количеству строк, то большую часть работы делает Daniel Mack, ещё примерно же столько кода, но на двоих, дали Kay Sievers и David Herrmann, остальные на фоне этих троих теряются ибо намного меньше вложили.

это... не слыхали когда systemd откажется от такой ненужной зависимости, как kernel?

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

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

Разве не взаимоисключающие параграфы?

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

kdbus - это только часть dbus (самая простая - пересылка данных), так что без поцеринговского говнокода никак.

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

Но зачем оно нужно, когда уже есть ipc plan9? Это практически оно и есть, вид в профиль. Портировать его на линукс и готово.

Не пали малину, пусть изобретают, изобретатели. ;)

чуть менее, чем все.

Я в dbus не копался, но гложат меня сомнения, что после рефакторинга k-... не понадобится - и так полетит!

Пихать в ядро == как минимум заглянуть в самые кишки дбаса, ужаснуться, и невольно отрефакторить многое.

Чушь.

Спорное утверждение.

Покажи мне рефакторинг кода dbus, вызванный написанием kdbus.

Я не слежу практически за разработкой dbus/kdbus. Это сказано из общих соображений: Надо запихнуть часть кода в ядро. Окей, смотрим какую, как это ложится на текущий API, делаем драфт, пускай даже наспех, с активным применением копипасты. Кернель-ребята выносят диагноз - наркоманы (это уже было несколько раз, и каждый раз активно обсуждалось), просят что-то поменять. Это наверняка поломает какое-то апи, и в любом случае что-то надо будет доделывать. Мелкий рефакторинг невольно выйдет даже из-за того, что многие места придется просто прочитать, чтобы вспомнить как они работают.

Надо запихнуть часть кода в ядро

То есть ты считаешь, что часть кода из libdbus и/или демона dbus попала в ядро. Даже не стану спрашивать, почему ты так считаешь.

Это наверняка поломает какое-то апи

У kdbus изначально ни с чем не совместимый API, его слом никого не волнует пока.

То есть ты считаешь, что часть кода из libdbus и/или демона dbus попала в ядро. Даже не стану спрашивать, почему ты так считаешь.

Если и попало, то минимум, например код который со структурками данных работает.

У kdbus изначально ни с чем не совместимый API, его слом никого не волнует пока.

Окей, тогда ждем что из него выйдет, и как из этого будут делать drop-in замену для libdbus, которую обещали изначально.

Демон не нужен. Наверно надо с другой библиотекой собирать. Вроде как api у них похожий.

Просто соответствующий хэдер будет предоставлен ядром, а не демоном дыбаса?

Наверное, я не сильно в теме. Только по новостям ориентируюсь.

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

Я так понимаю, чуваки хотят свой COM с блэкджеком и шлюхами.

Узрели в нем фатальный недостаток.

Узрели в нем фатальный недостаток.

В COM? Ну да, технология из венды 20-летней давности, как же не увидеть недостаток и не переписать для себя с нуля.

Портировать его на линукс и готово.

Всего-то. Как просто.

А вот dbus засунуть в ядро это работа на пару вечеров)

Наконец-то появится нормальный IPC на уровне ядра. Надеюсь, патчи вскоре попадут в апстрим.

Но зачем оно нужно

Кто пилит - тому и нужно.

когда уже есть ipc plan9? Это практически оно и есть, вид в профиль. Портировать его на линукс и готово.

Портируй, закинь патчи в апстрим, запости на ЛОРе историю успеха.