В ядро Linux будет включён аналог D-Bus

И что «наоборот»? Людям с деньгами спокойно обошли какую-то там меритократию.

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

Линус всегда говорил - сначала внедряйте свои креативы в вендорные ветки - а там посмотрим.

Здесь Линус (и не только Линус) уже посмотрел и вынес вердикт.

Ага, вердикт «ненужно - идите внедряйтей там где нужно, мне пофиг»

Собственно с точки зрения ядра описанные изменения это чтото вроде прикладного приложения.

Что, говорите, в генте загрузка с systemd не работает?

загрузка - работает, нету многих сервисов и есть проблемы с реализацией, тех юзкейсов, которые были сделаны с openrc, но это ведь проблема системд и переходящего, а не генты.

Так мы уже знаем, какие из себя ментейнеры генты, про проекту eudev и его презентации на FOSDEM.

ты там не был, видео ещё нету, презентацию ты не видел.. да именно твое мнение важно и показательно.

лучше бы дальше про clang/gcc писал, там тебя хоть читать интересно.

Людям с деньгами спокойно обошли какую-то там меритократию.

Обошли?? Они ей даже не «воспользовались»

Назови это как хочешь.

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

ЯННП.жпг

Ага, вердикт «ненужно - идите внедряйтей там где нужно, мне пофиг»

Это путь к форку. Линус против корпов - лично мне исход не ясен.

кстати, а что по мнению тех, кто хочет dbus в ядре нужно по сравнению с multicast socket-ами (если сделать их).

1). единообразный протокол?

2). интроспекция сообщений?

3). API на подписывание к любому сервису существующими в системе?

Лучше бы ядерные /dev/tcp/ и /dev/udp/ с возможностью прослушивания портов запилили. А если уж гулять так гулять, пусть VM питона в ядро запихнут, больше пользы будет.

Microsoft ещё не запатентовала «идею» о написании WM на HTML5+JavaScript?

Боян. <trolling-mode>Кстати, было бы неплохо. Даёшь вебкит в ядре!</trolling-mode>

Лучше бы ядерные /dev/tcp/ и /dev/udp/ с возможностью прослушивания портов запилили. А если уж гулять так гулять, пусть VM питона в ядро запихнут, больше пользы будет.

Кому прослушивать, а не выпендриваться, давно есть tcpdump/pcap. Но без забавных файлов, да.

Насколько я помню матчасть, это невозможно. А VM питона в ядре не нужна хотя бы потому, что она не одна и не выиграет особо.

ммм... а добавить мультикаст к Unix domain socket-ам не было бы достаточно?

неа. еще нужен стандарт на ФОРМАТ данных. в socket можно пихать любые данные как левая нога захотела, а в DBus только стандартными пакетами.

Но и d-bus похудеет, а в сумме, может быть, ничего не поменяется. Все равно в памяти у всех висит.

вероятно DBus как демон просто будет не нужен. приложения будут юзать либу, а ядро заменит демона.

ЯННП.жпг

«Меритократия» как система имеет явно выраженные дефекты. Ими не воспользовались - а просто система так работает.

Это путь к форку. Линус против корпов - лично мне исход не ясен.

Это путь не к форку а к банальным вендорским ядрам которых и так целая куча. То есть я не понимаю что с твоей точки зрения изменилось что Линус стал против корпов.

еще нужен стандарт на ФОРМАТ данных

Если ты ходил по ссылке - скажи, где там о формате данных? Там просто сказано «a reliable multicast and point-to-point messaging system».

Вот интересно, а этот Kernel DBus умеет сохранять сообщения между перезагрузками? Оно может заменить MQ-софт?

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

+1.

Формат может задаваться на уровне либы, а в ядро будет приходить бинарные данные.

еще нужен стандарт на ФОРМАТ данных

Если ты ходил по ссылке - скажи, где там о формате данных? Там просто сказано «a reliable multicast and point-to-point messaging system».

Тогда это не замена DBus. Это перенос его части на уровень ядра.

Вообще-то под прослушиванием портов имелся в виду аналог nc -l. С унифицированными файлами доступа к TCP/UDP-портам можно безо всяких костылей писать клиент-серверные приложения на любом ЯП, поддерживающем работу с файлами. Хоть на sh, хоть на поцкале. Пока что это достигается только через посредников типа tcpsvd/udpsvd, (x)inetd или того же nc. Было бы гораздо лучше, если бы напрямую.

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

Походу часть embedded пользуется DBus для передачи данных между подсистемами. И ускорение этого процесса влечет ускорение работы железки.

А сам bus позволяет втыкать в очередь обработки любые промежуточные обработчики, даже те, которые еще не существовали в момент создания цепочки. К примеру в цепочку передачи данных от одного сетевого интерфейса к другому можно воткнуть NAT, затем файрвол, затем антивирь, и самописный скриптик, который считает количество пакетов с чексуммой с модулем 7. Поскольку цепочка работает по общему формату, то все промежуточные обработчики пишутся и легко внедряются. Последнее - няшка для корпораций.

По сути аналог принципа ESB, но на одной машине.

Тогда это не замена DBus.

Никто и не говорил, что это «замена DBus». Вполне очевидно, что «замена DBus» - этот IPC + libdbus.

Никто и не говорил, что это «замена DBus». Вполне очевидно, что «замена DBus» - этот IPC + libdbus.

А разве IPC обладает достаточными возможностями для замены «серверной» части DBus? Если да, то нафига subj?

Интересно, а как живет *BSD без этих ихних dbus? Что там вместо этого?

Можно ли Linux kernel обратить в микроядро?

не можно

ибо не нужно

развиваемом разработчиками GNOME проекте по организации работы самодостаточных пакетов приложений

в правильном направлении движутся товарищи

api dbus - это трындец и ужас, его пьяные дети разрабатывали. я пробовал копать и плюнул.

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

Одна надежда, что Линус таки дырявый говногод в ядро не пустит.

А сам bus позволяет втыкать в очередь обработки любые промежуточные обработчики, даже те, которые еще не существовали в момент создания цепочки. К примеру в цепочку передачи данных от одного сетевого интерфейса к другому можно воткнуть NAT, затем файрвол, затем антивирь, и самописный скриптик, который считает количество пакетов с чексуммой с модулем 7. Поскольку цепочка работает по общему формату, то все промежуточные обработчики пишутся и легко внедряются. Последнее - няшка для корпораций.

Реализовать сетевой стек через dbus? Вдоль, пожалуйста.

А разве IPC обладает достаточными возможностями для замены «серверной» части DBus?

Я подозреваю, что «серверной часть DBus» (что бы не подразумевалось по этим) будет systemd.

Ну. 9p, хоть и не в ядре, но есть же

Накладные расходы уменьшаться. Только надо уже думать о микроядре.

ЧТобы скомпенсировать уменьшение накладных расходов?

api dbus - это трындец и ужас, его пьяные дети разрабатывали.

Будем надеяться на то, что появится альтернативное api, и про legacy все со временем забудут.

а когда ожидать включение gtk в ядро?

Ну. 9p, хоть и не в ядре, но есть же

libixp не считаем ибо нет возможности без юзерспейсового сервера экспортить устройства.

А разве IPC обладает достаточными возможностями для замены «серверной» части DBus?

Я подозреваю, что «серверной часть DBus» (что бы не подразумевалось по этим) будет systemd.

ИМХО DBus будет заменен на клиентскую либо + подсистемы ядра. Без промежуточных обработчиков в userspace.

Не толщина, с systemd мои волосы стали шелковистее, а make -j8 больше не сказывается на системе никак.

Чтоа?! Ты обкурился?

а когда ожидать включение gtk в ядро?

Сразу после wayland вестимо.

Специально поискал в комментах хоть слово про QNX - но нет, никому и в голову не пришло, что эта «шина» уже 20 лет как там реализована.

QNX [...] эта «шина» уже 20 лет как там реализована.

А давно там есть мультикастинг?

Специально поискал в комментах хоть слово про QNX - но нет, никому и в голову не пришло, что эта «шина» уже 20 лет как там реализована.

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

Вот-вот. Ты очень четко мою мысль уловил.

получиться

тормаз

контент свитчей

*facepalm*

Ну вот у меня не висит

очень двусмысленное заявление, я бы сказал

Ух ты. Но зачем? Чем им так не нравится dbus?

Вот именно. Поэтому и обсуждать эти «новшества» нужно с социологической точки зрения.

в технической сфере ? Твоё утверждение тянет на новую дисциплину

openrc это init на стероидах.

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

Сразу надо было микроядерную архитектуру делать, как дядька Таненбаум говорил, а теперь-то что: как мёртвому припарки.

пусть VM питона в ядро запихнут, больше пользы будет

Исполнять приложения в пространстве ведра?! Кто вас понарожал?

api dbus - это трындец и ужас, его пьяные дети разрабатывали. я пробовал копать и плюнул.

сам то api ещё ничего, а вот реализация... Да ты и сам в том году жаловался не на api, а как раз на говнокод.

Интересно, а как живет *BSD без этих ихних dbus? Что там вместо этого?

dbus, это же userspace-демон, почему бы ему не быть в *bsd?

ога
он же не нужен, так же как, например, Цитрикс... oh wait...

а код под LGPL как статическую или смешанную со своим кодом (для кастомизации).

Кто тебе мешает код под LGPL смешивать со своим? Лицензию только не забудь поставить совместимую и всё. Это как раз и уменьшает фрагментацию в мелочах. Если нужно какую-то мелочь в опенсорсной библиотеке, то становится проще коммитить в апстрим или выкладывать под GPL, а не разводить проприентарщину.

Кто-нибудь может внятно объяснить, почему для IPC не хватает возможностей SysV-IPC и UNIX-сокетов, что в ядре надо городить аналог dbus?

Ну то есть «reliable multicast and point-to-point messaging system for the kernel», зачем она нужна ядру-то?