форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Третий выпуск реализация kdbus для ядра Linux "	+/–
Сообщение от opennews (??) on 17-Янв-15, 09:59
Грег Кроа-Хартман (Greg Kroah-Hartman) представил (https://lkml.org/lkml/2015/1/16/488) в списке рассылки разработчиков ядра Linux третью версию патчей с реализацией kdbus, надёжной, быстрой и безопасной системы обмена сообщениями, поддерживающей доставку сообщений в режиме точка-точка и в режиме мультикаст (от одного отправителя к группе получателей). Kdbus может использоваться как в самодостаточном виде, например, данная система уже поддерживается в systemd, так и в качестве основы для реализации D-Bus, не требующей запуска отдельного демона в пространстве пользователя. В третьей версии патчей добавлен флаг  FS_USERNS_MOUNT, при помощи которого пользователи могут примонтировать собственные обособленные экземпляры kdbusfs. Переписана большая часть кода, связанная с обработкой метаданных, что позволило обеспечить возможность трансляции привязанных к получателям пространств имён.  Идентификаторы PID и TID перемещены из KDBUS_ITEM_CREDS в KDBUS_ITEM_PIDS, что дало возможность отслеживать ситуации с повторным использованием PID другим процессом. Прекращена поддержка интерфейса KDBUS_CMD_CANCEL, вместо которого следует использовать CANCEL_FD с ioctl CMD_SEND. Вызов KDBUS_CMD_MSG_SEND переименован в KDBUS_CMD_SEND, а KDBUS_CMD_MSG_RECV в KDBUS_CMD_RECV. Из основных достоинств реализации шины kdbus на уровне ядра отмечается: -  Высокая производительность за счёт минимизации переключения контекста процессов, меньшего выполнения операций копирования, сокращения системных вызовов, использования memfd; -  Высокая безопасность из-за исключения влияния пользовательских процессов на содержимое шины и использования механизмов ядра для управления передачей данных, в том числе с возможностью контроля со стороны модулей LSM; -  К сообщениям может быть прикреплено больше метаданных; -  Пригодность для приложений, обрабатывающих большие потоки данных, с возможностью расстановки сообщений в очереди на основании приоритетов и задания глобального упорядочивания сообщений. Например, некоторые разработчики нашли применение в kdbus даже для передачи звука в системе; -  Неподверженность многим состояниям гонки, которые трудно устранить в реализации на уровне пользователя. Например, ситуация отсоединения клиента от шины только при условии отсутствия сообщений в его очереди; -  Возможность мониторинга на уровне ядра. Привилегированные пользователи могут подключить к потоку сообщений без создания специализированных механизмов в пространстве пользователя; -  Возможность прямой доставки сообщения без помещения в очередь, что удобно при организации обработки запросов активации по шине; -  Возможность раннего доступа к шине, на этапе выполнения  initrd. URL: https://lkml.org/lkml/2015/1/16/488 Новость: http://www.opennet.ru/opennews/art.shtml?num=41478
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по ответам | RSS]

	2. "Третий выпуск реализация kdbus для ядра Linux "	–3 +/–
	Сообщение от Аноним (??) on 17-Янв-15, 10:53
	Почему бы не вынести _это_ в юзерспейс?
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Третий выпуск реализация kdbus для ядра Linux "	+14 +/–
	Сообщение от Аноним (??) on 17-Янв-15, 11:07
	> Почему бы не вынести _это_ в юзерспейс? Потому что это в  юзерспейсе уже есть и пытаются наоборот из юзерспейс в ядро перенести, так как безопасность, надёжность (race condition в DBus источник многих проблем) и производительность у DBus в юзерспейс никакая.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "Третий выпуск реализация kdbus для ядра Linux "	+5 +/–
	Сообщение от Аноним (??) on 17-Янв-15, 11:07
	> Почему бы не вынести _это_ в юзерспейс ... весь текст скрыт Потому что от костыли _такого_ размера становится только хуже. Впрочем, даже будь такое решение удобным, просто началась бы война вокруг того, чей интерфейс лучше. У ядерного IPC уйма преимуществ, не зря его перым делом реализовали в Android (см. https://lkml.org/lkml/2009/6/25/3) и уже черте сколько лет пилят в Венде.
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Третий выпуск реализация kdbus для ядра Linux "	+2 +/–
	Сообщение от Аноним (??) on 17-Янв-15, 11:29
	это не объясняет зачем оно нужно в ядре. ну плохой dbus, значит надо переписать так чтоб был хороший и быстрый. но в ядро-то зачем пихать все подряд.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	6. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от anonymous (??) on 17-Янв-15, 11:35
	>У ядерного IPC уйма преимуществ Ты это так говоришь, будто его там сейчас нет.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	7. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Kroz (??) on 17-Янв-15, 11:40
	> Высокая производительность Тесты есть? Чтобы было понятно на сколько и в каких ситуациях. А то бывает, что некоторые повыкидывают NOP'ы из своих программ, и начинают вопить про "высокую производительность", а потом выясняется, что производительность улучшилась-то на целых 0.0001%.
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Третий выпуск реализация kdbus для ядра Linux "	+2 +/–
	Сообщение от anonymous (??) on 17-Янв-15, 11:41
	>> Почему бы не вынести _это_ в юзерспейс? > Потому что это в  юзерспейсе уже есть и пытаются наоборот из > юзерспейс в ядро перенести, так как безопасность, надёжность (race condition в > DBus источник многих проблем) и производительность у DBus в юзерспейс никакая. Ты это так говоришь, будто при переносе кода в ядро вдруг исчезнут race condition. Наоборот, можно будет валить ещё и ядро, если удачно их использовать. Всё то, за что 5 лет поливали грязью венду, стало вдруг "хорошим" и "годным" в линуксе.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	9. "Третий выпуск реализация kdbus для ядра Linux "	+3 +/–
	Сообщение от anonymous (??) on 17-Янв-15, 11:46
	> Высокая производительность Производительность в dbus вообще не нужна. dbus предназначен для обмена небольшими структурированными данными. Если надо скорость и объём, то для этого есть Unix domain socket. Впрочем, сейчас найдутся умники, которые будут гонять по нему фильмы и удивляться, что ой как оно тормозит. Однозначно надо в ядро пихать!
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от ferux (ok) on 17-Янв-15, 12:26
	> Впрочем, сейчас найдутся умники, которые будут гонять по нему фильмы конечно будут. Где это видано - гонять управляющие потоки по одному IPC, а потоки данных - по другому, в рамках решения одной задачи? Другое дело - если будет тормозить, то нужно ждать/писать новый, более гибкий в этом плане IPC.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	12. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Аноним (??) on 17-Янв-15, 13:06
	>Например, некоторые разработчики нашли применение в kdbus даже для передачи звука в системе; >Впрочем, сейчас найдутся умники, которые будут гонять по нему фильмы и удивляться, что ой как оно тормозит. Уже погоняли, похоже.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	14. "Третий выпуск реализация kdbus для ядра Linux "	+4 +/–
	Сообщение от Аноним (??) on 17-Янв-15, 13:17
	> но в ядро-то зачем пихать все подряд. Вы же сами ответили > ну плохой dbus, значит надо переписать так чтоб был хороший и быстрый. А "хороший и быстрый dbus" в юзерспейсе - это несбыточная хотелка, противоречащая объективной реальности. Типа вечного двигателя. Ну нельзя его сделать. Нель-зя.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	15. "Третий выпуск реализация kdbus для ядра Linux "	–1 +/–
	Сообщение от Аноним (??) on 17-Янв-15, 13:18
	>>У ядерного IPC уйма преимуществ > Ты это так говоришь, будто его там сейчас нет. Высокоуровневого IPC - нет. А каждый раз велосипедить высокоуровневый протокол поверх низкоуровневого IPC, предназначенного для обмена сырыми данными - обезьянья работа.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	16. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от Аноним (??) on 17-Янв-15, 13:20
	> Ты это так говоришь, будто при переносе кода в ядро вдруг исчезнут race condition. Подучите матчасть, тогда у вас и не будет таких глупых вопросов.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	17. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от Аноним (??) on 17-Янв-15, 13:21
	Венду поливали грязью 15 лет за реестр и за то, что сейчас творит Поттер в GNU/Linux.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	18. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Аноним (??) on 17-Янв-15, 13:22
	> Почему бы не вынести _это_ в юзерспейс? Пока что есть более важные вещи, которые определенно стоит вынести в юзерспейс раньше - сетевой стек, фаервол, стек блочных устройств (DM, mdraid, LVM).
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	19. "Третий выпуск реализация kdbus для ядра Linux "	–1 +/–
	Сообщение от Аноним (??) on 17-Янв-15, 13:24
	> Венду поливали грязью 15 лет за реестр и за то, что сейчас > творит Поттер в GNU/Linux. То, что сейчас творит Поттер - это вообще не винда, а BSD. Когда вместе с ядром ставится куча левых прог на все случаи жизни, и хрен чего удалишь без пересборки. Между прочим, BSDшники этим гордятся - все под рукой из коробки.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	20. "Третий выпуск реализация kdbus для ядра Linux "	–2 +/–
	Сообщение от Аноним (??) on 17-Янв-15, 13:35
	> dbus предназначен для обмена небольшими структурированными данными. Если надо скорость и объём, то для этого есть Unix domain socket. Звучит примерно так же грамотно, как и "HTTP предназначен для обмена небольшими структурированными данными. Если надо скорость и объём, то для этого есть UDP."
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	21. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от cmp (ok) on 17-Янв-15, 14:22
	оу,оу, полегче, давайте еще планировщик процессорного времени в юзерспей вынесем, или даже лучше все ядро как процесс запускать, а какойнить command.com пусть будет ядром, назовем это линукс 98 фор ворк груп. атличная идея. Бил.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	23. "Третий выпуск реализация kdbus для ядра Linux "	–2 +/–
	Сообщение от ццц on 17-Янв-15, 15:47
	не нужно а то этих системд-упорышей не остановить - навалят в ядро своего *овнокода
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 17-Янв-15, 15:58
	> Привилегированные пользователи могут подключить к потоку сообщений без создания специализированных механизмов в пространстве пользователя что подключить?
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "Третий выпуск реализация kdbus для ядра Linux "	+8 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 17-Янв-15, 16:03
	> апример, некоторые разработчики нашли применение в kdbus даже для передачи звука в системе; если можно систему заюзать каким-нибудь неестественным способом и всё сделать через задницу, то всегда найдётся олигофрен который это сделает и будет считать сие творение Ъ. Так что это скорее минус и упоминать о привлечении таких придурков на рекламируемую технологию лишний раз не стоит. И не звука, а видео.
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	26. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от ibujhbygblfh0 on 17-Янв-15, 16:05
	>не нужно возможно и не нужно >а то этих системд-упорышей не остановить - навалят в ядро своего *овнокода kdbus ваяет не САМ системд-поделкин, а "некто" Greg KH, так что очень велика вероятность, что г-нокода там не будет совсем. если что я совсем не фанат поделки потера, но и не хэйтер, смотреть на это дело надо объективно, может быть в обозримом будующем таки будет толк от всей этой хрени.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	27. "Третий выпуск реализация kdbus для ядра Linux "	+2 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 17-Янв-15, 16:06
	Везде это видано. Например, стандартные пайпы  типа cmd | cmd2 | cmd3. В сложных приложениях состоящих из нескольких процессов механизмы ещё больее разнообразны.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	28. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 17-Янв-15, 16:12
	> HTTP предназначен для обмена небольшими структурированными данными > ... Если надо скорость и объём, то для этого есть UDP такое мог ляпнуть тольтко клинический идиот. Вообще HTTP действительно какое-то время не был приспособлен для передачи больших объёмов данных и для этого использовали другие протоколы вроде FTP с раздельными контрольным каналом и каналом передачи данных.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	29. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 17-Янв-15, 16:18
	> реализация kdbus для ядра Linux > так как безопасность, надёжность отлично поделил на ноль. Какие ещё вспомнишь фичи из существующих для чего-либо? Можешь смело продолжать ими свой список.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	30. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от ццц on 17-Янв-15, 16:49
	поток сообщений :) раньше для этого вещества требовались, а теперь kdbus и вперед...
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	32. "Третий выпуск реализация kdbus для ядра Linux "	+2 +/–
	Сообщение от anonymous (??) on 17-Янв-15, 17:00
	>>>У ядерного IPC уйма преимуществ >> Ты это так говоришь, будто его там сейчас нет. > Высокоуровневого IPC - нет. > А каждый раз велосипедить высокоуровневый протокол поверх низкоуровневого IPC, предназначенного > для обмена сырыми данными - обезьянья работа. Осиль наконец преимущества разделяемых библиотек, школьник.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	33. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от ццц on 17-Янв-15, 17:04
	> kdbus ваяет не САМ системд-поделкин, а "некто" Greg KH, так что очень велика вероятность, что г-нокода там не будет совсем. https://lkml.org/lkml/2014/4/2/420 в компании у Грега те еще г-нокодеры :) Так что еще как будет...
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	34. "Третий выпуск реализация kdbus для ядра Linux "	+3 +/–
	Сообщение от Crazy Alex (ok) on 17-Янв-15, 17:04
	Это не всё подряд. Это просто ещё один механизм IPC. Давно пора.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	35. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от Crazy Alex (ok) on 17-Янв-15, 17:07
	kdbus имиет к Поттеру весьма косвенное отношение. Это универсальная основа для всех, кому надо. А заменять разносортицу сокетов, файлов-флагов и черт знает чего ещё давно пора.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	36. "Третий выпуск реализация kdbus для ядра Linux "	+8 +/–
	Сообщение от ццц on 17-Янв-15, 17:08
	> То, что сейчас творит Поттер - это вообще не винда, а BSD. То, что сейчас творит Поттер - это вообще не винда, а BDSМ исправил во имя справедливости!
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	37. "Третий выпуск реализация kdbus для ядра Linux "	–2 +/–
	Сообщение от Crazy Alex (ok) on 17-Янв-15, 17:12
	Вот в результате таких верований всё имеет свои форматы обмена и, кроме велосипедизма и сопутствующих багов, нет универсального механизма мониторинга и модификации на лету.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	41. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Mirraz (ok) on 17-Янв-15, 19:02
	Что такого предоставляет этот kdbus, чего нельзя было реализовать с помощью сокетов? Пусть даже новым типом или протоколом, но в рамках системы сокетов?
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	42. "Третий выпуск реализация kdbus для ядра Linux "	+2 +/–
	Сообщение от Crazy Alex (ok) on 17-Янв-15, 20:40
	Исправил на синоним, я бы сказал
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	43. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Crazy Alex (ok) on 17-Янв-15, 20:40
	Генод - в соседней новости. Здесь о линуксе речь. Арихтектура которого уже показала свою эффективность где только можно.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	45. "Третий выпуск реализация kdbus для ядра Linux "	–3 +/–
	Сообщение от Crazy Alex (ok) on 17-Янв-15, 20:44
	Их все осилили. И каждый ваяет свой велосипед. А вот эмулировать, скажем, сокеты как-то в голову не приходит, даже если голова совсем больная. Потому что ежу ясно, что эффективнее не будет - максимум можно сверху что-то наворотить, как в ZeroMQ. Вот и kdbus - будет стандартная реализация - больше народу уйдёт от самопала. А самопал в IPC - глупость редчайшая, так как IPC - это о взаимодействии и, соответственно, совместимости.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	46. "Третий выпуск реализация kdbus для ядра Linux "	–1 +/–
	Сообщение от Crazy Alex (ok) on 17-Янв-15, 20:45
	Ну тем более какие пробелмы - есть кому контролировать процесс.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	47. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Аноним (??) on 17-Янв-15, 20:51
	Это вы сейчас binder хотите с kdbus сравнить? Опять сравнили теплое с мягник
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	48. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Аноним (??) on 17-Янв-15, 21:56
	чем sysv ipc не угодил ?
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	49. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Аноним (??) on 17-Янв-15, 21:59
	> Ну тем более какие пробелмы - есть кому контролировать процесс. правильно. Есть - RedHat - как работодателю Лени и Грега. Вот и контролируют - что бы все попало. Не потрудившись даже разработать как следует API. Главное свое запихнуть в ядро - другим будет сложнее и пофик что сырое суем - как с kpatch..
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	50. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от freehck (ok) on 17-Янв-15, 22:07
	Линукс98? Зачем же. Назовём это Хурд.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	51. "Третий выпуск реализация kdbus для ядра Linux "	–2 +/–
	Сообщение от freehck (ok) on 17-Янв-15, 22:13
	>> HTTP предназначен для обмена небольшими структурированными данными >> ... Если надо скорость и объём, то для этого есть UDP > такое мог ляпнуть тольтко клинический идиот. Вообще HTTP действительно какое-то время не > был приспособлен для передачи больших объёмов данных и для этого использовали > другие протоколы вроде FTP с раздельными контрольным каналом и каналом передачи > данных. Кгхм. Вы что, считаете, что он сейчас приспособлен для передачи больших объёмов данных? Это при том, что он не поддерживает, например, докачку? Я посмотрю на Вас, когда Вы будете скачивать LiveDVD по http, и на 95% у вашего провайдера случится обрыв канала. То-то радости будет всё заново качать.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	52. "Третий выпуск реализация kdbus для ядра Linux "	–2 +/–
	Сообщение от freehck (ok) on 17-Янв-15, 22:17
	> Что такого предоставляет этот kdbus, чего нельзя было реализовать с помощью сокетов? > Пусть даже новым типом или протоколом, но в рамках системы сокетов? Вы неправильно задаёте вопрос. Шина как раз и нужна для того, чтобы избавиться от изобилия сокетов. Если у вас каждая программа общается с каждой, то у вас количество сокетов будет n!, а в случае системной шины - только n. С другой стороны, действительно не понятно, зачем это в ядре.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	53. "Третий выпуск реализация kdbus для ядра Linux "	+4 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 17-Янв-15, 22:18
	> Это при том, что он не поддерживает, например, докачку? поддерживает. Тебе после разморозки разве ещё не сообщили?
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	54. "Третий выпуск реализация kdbus для ядра Linux "	–1 +/–
	Сообщение от Аноним (??) on 17-Янв-15, 22:22
	В юзерспейсе и иксы есть. Может их тоже в ядро...
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	55. "Третий выпуск реализация kdbus для ядра Linux "	+3 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 17-Янв-15, 22:25
	> Вот и kdbus - будет стандартная реализация - больше народу уйдёт от самопала. никто не уйдёт от нормальных реализаций IPC, хотя бы лишь из-за отсутствия этого kdbus для других posix'оподобных ос. Ниша (?)dbus это максимум десктопная интеграция + некоторые стандартные системные задачи, в общем где он и сейчсс спокойно живёт. Сервисы которым нужен IPC для масштабирования и/или изоляции процессами никто на (?)dbus переводить не будет, это мечты дилетантов.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	56. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 17-Янв-15, 22:55
	> Если у вас каждая программа общается с каждой, то у вас количество сокетов будет n!, Вот же еврей безграмотный, не n!, а n(n  1)/2. > а в случае системной шины - только n. Типа замёл гогно под ковёр и сделал вид что не нагадил? Нет, такого в инженерии не бывает, полный mesh никак не масштабируется линейно даже с общей "системной шиной" не смотря на видимые N сокетов из юзерспейса. Внутри это всё равно будет ощутимо больше O(N) и по потреблению ресурсов и по локам/cpu. Можно только снизить коэффициенты по памяти за счёт шаренной памяти при передачи больших объёмов данных, чего видимо и делает kdbus.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	57. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от Аноним (??) on 17-Янв-15, 23:44
	С июня 1999 товарищ был в криогенном сне, сделайте ему скидку, не отошел еще.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	58. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от Аноним (??) on 18-Янв-15, 01:11
	>kdbus имиет к Поттеру весьма косвенное отношение. Это универсальная основа для всех, кому надо. Дело в том, что по большому счету это не надо никому, кроме системдэшных хипстеров, которые и начали пропихивать dbus в ведро. Даже в новости написано, что автор этой спичечно-желудевой поделки - Грег КХ, который тоже системдэшный хипстер. Кдбус - это проект системдэшников для системдэшников. Но так как системд не нужен, то не нужен и кдбус. >А заменять разносортицу сокетов, файлов-флагов и черт знает чего ещё давно пора. Заменять чем (и вообще, зачем)? Другой разносортицей?
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	59. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от maximnik0 on 18-Янв-15, 02:06
	> В юзерспейсе и иксы есть. Может их тоже в ядро... Так уже X в ядре есть - правда полузакрытая платная разработка ,вроде называется микроX или миниX .Думал разработка закрылась нет еще шевелятся (смотрел в октябре  прошлого года) заказы у них есть ,правда не много .Совместимость с классическими X не полная ,приложения нужно собирать под их версию X и либ,но и правда маленькое и шустрое -600кб модуль ядра ,3,5 либы ,из класических минусов нет сетевой потдержки ,за счет чего сделали гораздо шустрее .
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	60. "kdbus vs. amqp"	+/–
	Сообщение от fi (ok) on 18-Янв-15, 03:50
	Если добавить сеть, то можно уже сравнивать с amqp :))
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	61. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от Аноним (??) on 18-Янв-15, 04:37
	> но в ядро-то зачем пихать все подряд. На этот вопрос хорошо описано в списке достоинств в новости. Если кто-то не умеет читать - нет смысла орать на ухо глухому.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	63. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от Аноним (??) on 18-Янв-15, 04:38
	> Венду поливали грязью 15 лет за реестр А где у поттера реестр? Коронный вопрос.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	65. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от Аноним (??) on 18-Янв-15, 08:35
	> В юзерспейсе и иксы есть. Может их тоже в ядро... Ну как бы ядро и само нынче по минимуму рисовать может. См. drm и kms.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	66. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Аноним (??) on 18-Янв-15, 08:39
	> чем sysv ipc не угодил ? Тем же чем не угодила отправка сырых кадров эзернета для того чтобы отправить сообщение на опеннет. Да, можно сказать что ну его нафиг - TCP/IP стек в ядре. Нехай программа сама его реализует. Ну вот использовать sysv ipc для того для чего используют dbus - это примерно как отсылать сообщения на опеннет путем компоновки всех необходимых кадров эзернета самолично. Без использования соотв. услуг ядра. Тyпoй пуризм и баранья упертость еще и не до такого доводит.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	68. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Аноним (??) on 18-Янв-15, 08:44
	> никто не уйдёт от нормальных реализаций IPC, "Никто не уйдет от компоновки сырых фреймов эзернета к дерганию вызовов ядра для работы с TCP/IP".
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	69. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Аноним (??) on 18-Янв-15, 08:45
	Переключения контекста - штука напряжная. Одна из причин по которой микроядра перманентно в ж...е.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	70. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от Аноним (??) on 18-Янв-15, 08:47
	> Это при том, что он не поддерживает, например, докачку? А про HTTP код 206 "partial content" - не, не слышали? У, хорошая у вас там криокамера.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	71. "Третий выпуск реализация kdbus для ядра Linux "	–1 +/–
	Сообщение от Аноним (??) on 18-Янв-15, 08:50
	> правильно. Есть - RedHat - как работодателю Лени и Грега. Вообще-то KH насколько я помню из зюзи, так что FAIL - побиение редхата не состоится. Или придется сразу двух пинать. А вообще их таких много. Просто вы их не видите, потому что отморозились в вашем узком мирке где есть только вы и ваши потребности. А на планете более 6 миллиардов людей. И у них потребности иные. Вот они и делают то что надо им а не вам.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	72. "Третий выпуск реализация kdbus для ядра Linux "	–2 +/–
	Сообщение от Аноним (??) on 18-Янв-15, 08:51
	> что подключить? Нечто типа дебагера/трассира, позволяюшего оптом сгрести сообщения на шине и изучать кто, что, куда и почему. В случае ядра такую штуку проще сделать, потому что ядро - в нужном месте и в нужное время.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	73. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от Аноним (??) on 18-Янв-15, 08:53
	> Что такого предоставляет этот kdbus, чего нельзя было реализовать с помощью сокетов? Если заново сделать протокол с множесвенными отправителями и подписчиками ... получится как раз нечто типа dbus. А нафига его еще раз делать?
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	74. "Третий выпуск реализация kdbus для ядра Linux "	–1 +/–
	Сообщение от Ph0zzy (ok) on 18-Янв-15, 09:00
	L4 вполне себе так успешны
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	76. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от Andrey Mitrofanov on 18-Янв-15, 11:27
	>> Венду поливали грязью 15 лет за реестр > А где у поттера реестр? Коронный вопрос. http://www.freedesktop.org/wiki/Software/Elektra/
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	79. "kdbus vs. amqp"	+/–
	Сообщение от Аноним (??) on 18-Янв-15, 13:00
	Вопрос в том почему бы туда сразу его и не впилить, вместо дбас.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	80. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 18-Янв-15, 13:59
	Гуманитарное днище, угомонись уже со своими тупыми аналогиями.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	81. "Третий выпуск реализации kdbus для ядра Linux "	–1 +/–
	Сообщение от Kodir (ok) on 18-Янв-15, 14:28
	То ли у меня с русским проблема, то ли у автора.... "Kdbus может использоваться как в самодостаточном виде, например, данная система уже поддерживается в systemd" Непонятно, причём тут "самодостаточность" и то, что модуль поддерживается посторонней прогой?? Самодостаточность - это значит программе не нужны внешние зависимости. Каким боком тут системД?
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	82. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Аноним (??) on 18-Янв-15, 16:11
	Историю успеха в студию
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	83. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Аноним (??) on 18-Янв-15, 16:20
	> А на планете более 6 миллиардов людей. Вас в каком году заморозили, уже более 7 млрд людей на планете земля. Так что с разморозкой. > И у них потребности иные. Вот они и делают то что надо им а не вам. О да у 7 млрд иные потребности: пожрать, место где поспать и потрахатся. Им на kdbus вообе пофигу.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	84. "Третий выпуск реализация kdbus для ядра Linux "	–1 +/–
	Сообщение от Алоним on 18-Янв-15, 17:28
	В других ОС будуть использовать dbus. Сюрпрайз. :-)
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	85. "Третий выпуск реализация kdbus для ядра Linux "	–2 +/–
	Сообщение от Олег (??) on 18-Янв-15, 17:52
	> А "хороший и быстрый dbus" в юзерспейсе - это несбыточная хотелка, противоречащая > объективной реальности. Типа вечного двигателя. Ну нельзя его сделать. Нель-зя. Это ещё почему? Процессор в юзерспейсе медленнее работает?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	86. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Олег (??) on 18-Янв-15, 18:19
	> Если у вас каждая программа общается с > каждой, то у вас количество сокетов будет n!, а в случае > системной шины - только n.   Стоп-стоп. Может проблема как раз в кривой архитектуре ПК, если у Вас каждая программа вынуждена общаться с каждой?
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	87. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 18-Янв-15, 18:24
	С головой дружишь хоть немного? Если в других ОС можно использовать сам dbus, то и тут kdbus тоже не нужен ибо вместо него можно использовать dbus.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	88. "Третий выпуск реализации kdbus для ядра Linux "	+/–
	Сообщение от Пыщь on 18-Янв-15, 19:07
	Ну оно для сустемд и задумано вообще-то... Такой вывод можно сделать рассматривая контингент просящих "dbus в вЯдро".
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	89. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Ананас on 19-Янв-15, 08:04
	> ещё один > Давно пора
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	90. "Третий выпуск реализации kdbus для ядра Linux "	+/–
	Сообщение от Аноним (??) on 19-Янв-15, 08:22
	> "Kdbus может использоваться как в самодостаточном виде, например, данная система уже поддерживается в systemd" > Непонятно, причём тут "самодостаточность Всмысле как самодостаточный IPC без симуляции интерфейса D-Bus.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	91. "Третий выпуск реализации kdbus для ядра Linux "	–1 +/–
	Сообщение от Аноним (??) on 19-Янв-15, 12:32
	Пока эмулятор dbus через kdbus есть только у systemd. Остальные подтянутся. Кстати: на kdbus хотят переводить pulseaudio и gvfs :-) gdbus будет тоже поддерживать kdbus.
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	93. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от arisu (ok) on 19-Янв-15, 14:30
	потому что дбас — дерьмо.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	94. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от arisu (ok) on 19-Янв-15, 14:33
	> Вот и kdbus - будет стандартная реализация - больше народу уйдёт от > самопала. тоже правильно: будет легче детектировать идиотов. в принципе, использование в программе dbus — уже признак нехилого идиотизма. а с kdbus идиотизм вообще будет ядерный.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	95. "Третий выпуск реализация kdbus для ядра Linux "	+2 +/–
	Сообщение от arisu (ok) on 19-Янв-15, 14:35
	> конечно будут. Где это видано - гонять управляющие потоки по одному IPC, > а потоки данных - по другому, в рамках решения одной задачи? везде, где данных много, а архитекторы вместо жопы внизу и жопы на шее имеют нормальное анатомическое строение.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	96. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от arisu (ok) on 19-Янв-15, 14:37
	> Вот в результате таких верований всё имеет свои форматы обмена и, кроме > велосипедизма и сопутствующих багов, нет универсального механизма мониторинга и модификации > на лету. а, да-да, я знаю. «у нас есть 14 стандартов, и мы придумали один универсальный…»
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	97. "Третий выпуск реализации kdbus для ядра Linux "	+3 +/–
	Сообщение от arisu (ok) on 19-Янв-15, 14:38
	> Кстати: на kdbus хотят переводить pulseaudio и gvfs :-) отличный список ненужно.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	98. "Третий выпуск реализация kdbus для ядра Linux "	–1 +/–
	Сообщение от freehck (ok) on 19-Янв-15, 22:11
	>> Это при том, что он не поддерживает, например, докачку? > А про HTTP код 206 "partial content" - не, не слышали? У, > хорошая у вас там криокамера. Да. Я, пожалуй, и в самом деле в бункере зимовал. =)
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	99. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от freehck (ok) on 19-Янв-15, 22:25
	>> Если у вас каждая программа общается с каждой, то у вас количество сокетов будет n!, > Вот же еврей безграмотный, не n!, а n(n  1)/2. Точно. Я зачем-то связи перемножил, вместо того, чтобы сложить. Да и взять сочетание из n по 2 было бы разумнее по смыслу. Спасибо. Я вчера был не в своей тарелке. >> а в случае системной шины - только n. > Типа замёл гогно под ковёр и сделал вид что не нагадил? Нет, > такого в инженерии не бывает, полный mesh никак не масштабируется линейно > даже с общей "системной шиной" не смотря на видимые N сокетов > из юзерспейса. Внутри это всё равно будет ощутимо больше O(N) и > по потреблению ресурсов и по локам/cpu. ну так про O(N) никто и не говорил. Но если уж сложность анализировать, то она очевидно будет как раз между n и n^2,  что в любом случае какой-никакой, а плюс. > Можно только снизить коэффициенты по памяти за счёт шаренной памяти при передачи > больших объёмов данных, чего видимо и делает kdbus. А разумно ли передавать по шине большие объёмы данных? Мне казалось, что изначально цель была - пересылка большого количества маленьких управляющих конструкций. Запуск программ, пересылка событий и т.п.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	100. "Третий выпуск реализация kdbus для ядра Linux "	–1 +/–
	Сообщение от Crazy Alex (ok) on 19-Янв-15, 23:03
	Не надо потому, что нет. Тот D-Bus,  что сейчас есть, используется на все свои 100%. Будут новые возможности у ядерного (прежде всего в плане идентификации адресата и скорости) - будут и новые применения. systemd (который, таки ненужен) и так живёт. А заменять - именно стандартной шиной. Которую всегда можно стандартными инструментами просмотреть, запротоколировать, а при необходимости - и воткнуть модуль модификации сообщений. Чтобы странная идея рисовать свой очередной формат обмена через сокеты в голову никому не приходила. Но для этого нужна гарантия, что эта самая стандартная шина будет всегда и везде, в работоспособном состоянии и т.д. По факту в линуксе такую гарантию могут дать только разработчики ядра.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	101. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Crazy Alex (ok) on 19-Янв-15, 23:08
	Вы с ним разбирались? Мало того, что опять неструктурированные блобы гоняет, так еще и буфер очереди совершенно смехотворный.Да и отправителя там не узнать - ни pid, ни uid.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	102. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Crazy Alex (ok) on 19-Янв-15, 23:11
	Первое, где сейчас нужна вменяемая компонентная архитектура - это как раз десктоп. И хорошая изоляция, идентфикация адресата и т.п. для этого абсолютно критичны. А другие POSIX-системы - не смешите. Нет их. Из живого есть ещё макось - но там обычно совсем свой софт. У *BSD ниша только уменьшается, что там осталось? Подыхающий солярис и изолированный мирок AIX?
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	103. "Третий выпуск реализация kdbus для ядра Linux "	–1 +/–
	Сообщение от Crazy Alex (ok) on 19-Янв-15, 23:20
	Не знаю, как ты, а я был бы очень рад, если бы всё, что у меня умеет сейчас управляться через сокеты, начиная с rtorrent того же, умело какие-то более структурированные механизмы. Да и те же нотификации с DBus выглядят куда как логичнее, чем фридесктоповская механика, подразумевающая существование иксов и окна, принимающего сообщения. В сущности, современную систему как раз вокруг такой (ладно, почти такой) шины надо целиком строить, на событийной рахитектуре. От аналога udev, нотификаций DHCP-клиента и прочей системщины до выставления всего пользовательского интерфейса в виде интерфейсов D-Bus, а уже потом - гуя поверх них. Чтобы для всего этого дела возможна была вменяемая единая конфигурация.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	104. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от arisu (ok) on 19-Янв-15, 23:22
	разве ж я когда был против идеи нормальной общей шины? но когда мне вместо неё впаривают дбас, я начинаю кусаться. а когда вдобавок говорят, что шина теперь в ядро будет засунута… тут я уже не кусаться хочу, а убивать.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	105. "Третий выпуск реализация kdbus для ядра Linux "	–1 +/–
	Сообщение от Crazy Alex (ok) on 19-Янв-15, 23:22
	Ну скажи, какие есть плюсы у, скажем, сокетного IPC i3 перед шиной? А вот недостатки очевидны - автору пришлось наляпать велосипед по приему, отправке и базовому парсингу сообщений, и нет простого средства отмониторить в случае нужды, что за фигню ему туда шлют.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	106. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от arisu (ok) on 19-Янв-15, 23:25
	а всё почему? потому что дбас — говно. есть также мнение, что если говно засунуть в ядро, то не говно превратится в конфетку, а в ядре будет куча говна.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	107. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от pavlinux (ok) on 20-Янв-15, 04:14
	> В юзерспейсе и иксы есть. Может их тоже в ядро... http://filemare.com/browse/131.114.56.15/pub/Linux/fbui-0.11... FramebufferUI 0.11.2 FBUI is a small, fast in-kernel GUI windowing system for Linux. FramebufferUI     FBUI is a small, in-kernel graphical user interface for Linux. It permits you to put windows in each framebuffer-based virtual console, to read keyboard input, track a mouse pointer, and respond to typical GUI events. Each process may have more than one window. · FBUI exists to reduce the software bloat that plagues modern operating systems. It does this by virtue of its being a simple windowing system in the form of a small, 32 kilobyte driver which for some purposes may be quite sufficient. Liberation from bloat is desirable for a number of reasons that I explain in the Philosophy section. · FBUI exists to assists people who are prohibited from using X Windows because they are using resource-limited platforms such as old computers and embedded devices. On these, X is an impossible burden. However a vanilla framebuffer is often too primitive. FBUI is "just right", and libfbui makes using FBUI even easier to use by providing abstractions and additional functions. · FBUI exists to correct a flaw in the Linux operating system architecture. The traditional GUI -- X Windows -- is unlike any other subsystem of Linux in that the hardware-accelerated video drivers it uses are located within the X server, outside the kernel. Notice: normally Linux drivers and vital subsystems such as keyboard, USB, filesystem, serial I/O, et cetera are all located inside the kernel. FBUI simply puts the graphics UI driver where it belongs: inside the kernel with all the other drivers. Here are some key features of "FramebufferUI": · Unlike X Windows, FBUI supports windows on every virtual console. · Each program may have more than one window. · Overlapping windows are currently not supported, but I am adding support for them now. · There is no concept of parent and child windows. · Programs can receive raw keystrokes from FBUI which they can then translate to ASCII using a library routine. One process is permitted to have keyboard focus. · Each process accesses its windows completely independently of all other processes. · In X, the library has to send all drawing commands to the server process, which puts them in a queue and executes them whenever it has a chance. If the server is busy, or another X application is flooding the queue, then an X application must wait. Not so with FBUI, where the ioctl takes a list of drawing commands that go directly to be executed if the window is visible and irregardless of what any other window is doing. To further ensure the above concurrency is the norm, use of semaphores within FBUI to access common data is made as brief as possible. · Each virtual console can have its own optional window manager process. But this is not necessary and for instance many programs that I've written are also designed to run in standalone mode, examples being fbcalc, fbview, fbscribble, and the my FBUI variant of mpeg2decode. · I'm providing a fairly basic window manager fbwm, but current development is centered on fbpm, which is my panel-based window manager. FBUI offers a sufficient set of drawing routines: · draw point, line, horizontal line, vertical line, rectangle · draw text (8-bit) · window clear, fill rectangle, clear rectangle · copy area · put pixels (3-byte RGB, and 4-byte (unsigned long) RGB, and native) · wait for event · poll for event · the window manager process can hide and unhide other processes' windows, move, resize, re-expose, and delete windows. · read point · FBUI is currently written for 8,16,24, and 32-bit directcolor and truecolor. I am presently adding 4-bpp VGA. (Note : on VESA, I've done testing for 24 bit only.) Sample programs provided (I suppose I've gotten carried away) : · panel-based window manager (current focus of work) · conventional window manager · JPEG+TIFF image viewer · very simple MPEG playback based on circa 1995 MPEG2 library · terminal emulator (based on ggiterm) · load monitor · "scribbler" drawing program · analog clock · simple calculator · "Start" button program, which invokes fblauncher menu program · POP3 mail checker · "to do list" displayer program Requirements: · FBUI requires kernel 2.6.9.  :) What's New in This Release: · This release adds overlapping windows and transparent drawing. Так что, баян дикий, но для кофеварок и холодильников вполне.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	108. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от Vkni (ok) on 20-Янв-15, 04:33
	> А заменять - именно стандартной шиной. Понятно дело. Только пропускная способность этой шины всё равно лимитирована кольцевой топологией. Нафиг её в ядро-то засовывать? Тот же sed вполне себе стандартизован, а в ядре его почему-то нет.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	109. "Третий выпуск реализация kdbus для ядра Linux "	–1 +/–
	Сообщение от Crazy Alex (ok) on 20-Янв-15, 04:58
	Там не такая уж и кольцевая топология. Большинство сообщений летает всё же не броадкастами, а подписчикам. Зато эта топология даёт хорошую реалтаймовую интроспекцию и при нужде - возможность модификации на лету.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	110. "Третий выпуск реализация kdbus для ядра Linux "	–1 +/–
	Сообщение от Crazy Alex (ok) on 20-Янв-15, 05:02
	Ну так с реальностью надо дружить. Был бы выбор "DBus или вменяемая шина" - я бы тоже кусался. Но здесь - "DBus или вообще без стандартной шины". Кстати, насколько я помню, kdbus - это не DBus, а довольно обобщённый механизм шины, на нём, пожалуй, и что-то получше, чем DBus, можно сделать. Не уверен, правда, не повлечёт ли это очередной зоопарк.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	111. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Crazy Alex (ok) on 20-Янв-15, 05:05
	Вообще-то скорее потому, что там, где есть i3 (и, соответственно, нет DE) DBus вполне может и не быть. Да, а чем он тебя так раздражает? Я в реализацию не лез, но API там вполне вменяемые. ну разве что интерфейсов хотелось бы, как в COM - но это уже мои заморочки.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	112. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от arisu (ok) on 20-Янв-15, 05:07
	> Ну так с реальностью надо дружить. Был бы выбор "DBus или вменяемая > шина" - я бы тоже кусался. Но здесь - "DBus или > вообще без стандартной шины". нафиг-нафиг. лучше вообще без, чем с таким. > Кстати, насколько я помню, kdbus - это не DBus, а довольно обобщённый > механизм шины есть мнение, что «обобщённый вариант шины» называется «сокет». по какому поводу не пойти бы господам улучшайзерам в задницу с их прибитым гвоздями к пингвинусу решением.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	113. "kdbus vs. amqp"	+/–
	Сообщение от Crazy Alex (ok) on 20-Янв-15, 05:07
	Потому что это монстр, на фиг не нужный в рамках ПК и часто даже для проиводственных задач адски избыточный
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	114. "kdbus vs. amqp"	+/–
	Сообщение от Crazy Alex (ok) on 20-Янв-15, 05:12
	Вот этого не надо. Еслу уж впиливать сеть - так совершенно тупо - дал адрес(а) - и туда летит всё, что можно, за исключением простейшего autodiscovery, как на свитчах делается. Без повторных отправок, гарантий доставки и подобной хрени. Надо будет - пусть это клиенты поверх реализуют. Сильно надо будет - нарастёт отдельная либа, которую эти клиенты будут юзать. Чай, не энтерпрайз какой.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	115. "Третий выпуск реализации kdbus для ядра Linux "	+/–
	Сообщение от Crazy Alex (ok) on 20-Янв-15, 05:14
	Кстати, gvfs - это, как по мне, даже больший урод, чем пульс. Вместо нормального автомонтирования с доступностью всему софту имеем частное решение. А потом оказывается, что в файл-менеджере файлик юзер видит, а в deadbeef его засунуть - никак. Видит око, да зуб неймёт.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	116. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Crazy Alex (ok) on 20-Янв-15, 05:15
	Например, можно точно знать, кто прислал сообщение
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	117. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от arisu (ok) on 20-Янв-15, 05:16
	> Вообще-то скорее потому, что там, где есть i3 (и, соответственно, нет DE) > DBus вполне может и не быть. …потому что оно говно и от него стараются избавиться. > Да, а чем он тебя так раздражает? про кривокод даже на лоре писали, это уже давно не смешно. про то, что оно не текстовое — я писал, кажется. а если не писал, то сейчас пишу: оно не текстовое. собственно, всё: дальше мне уже неинтересно. то есть, мне было немного интересно, пока я на свою голову не почитал спеки формата. в общем, грустное оно. так никто не делит пышки.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	118. "Третий выпуск реализации kdbus для ядра Linux "	+/–
	Сообщение от arisu (ok) on 20-Янв-15, 05:19
	> Кстати, gvfs - это, как по мне, даже больший урод, чем пульс. > Вместо нормального автомонтирования с доступностью всему софту имеем частное решение. > А потом оказывается, что в файл-менеджере файлик юзер видит, а в > deadbeef его засунуть - никак. Видит око, да зуб неймёт. ну так DE-шки же. авторы DE-шек свято уверены, что есть только софт под их DE, который использует их библиотеки, и досадное недоразумение в виде ядра, которое лучше бы тоже переписать на их библиотеках. в итоге одни сочиняют KIO, другие gvfs, а вместе всё это как было кучей хлама, так и остаётся.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	119. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от arisu (ok) on 20-Янв-15, 05:28
	> Например, можно точно знать, кто прислал сообщение а зачем? что тебе дадут pid'ы? а uid'ы? зачем они? дайте каждому юзеру по токену, если надо, и пусть ними авторизуются. я токен могу с собой носить какой хочу и куда хочу. даже между юзерами передавать, если мне вдруг так удобней показалось.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	120. "Третий выпуск реализация kdbus для ядра Linux "	–1 +/–
	Сообщение от Vkni (ok) on 20-Янв-15, 08:45
	> Там не такая уж и кольцевая топология. Большинство сообщений летает всё же > не броадкастами, а подписчикам. Достаточно одного приложения, шлющего broadcast'ы, чтобы поставить систему раком. Поэтому должны быть ограничения на то, что передаётся. А раз так, то зачем нужно в ядро пихать-то? > Зато эта топология даёт хорошую реалтаймовую интроспекцию > и при нужде - возможность модификации на лету. При условиях, что не через ядро (иначе неправильный интроспектор грохнет систему), и поток невелик (интроспектор ведь не многопоточный, а ядер даже у смартфона бывает аж 8 штук!).
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	121. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Vkni (ok) on 20-Янв-15, 08:46
	> Here are some key features of "FramebufferUI": Это скорее список недостатков.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	122. "Третий выпуск реализация kdbus для ядра Linux "	–2 +/–
	Сообщение от Очередной аноним on 20-Янв-15, 14:32
	> Это ещё почему? Процессор в юзерспейсе медленнее работает? написано же - "минимизации переключения контекста процессов". Переключения контекста - удовольствие дорогое. Чтобы два разных юзерспейсовских пользовательских процесса "говорили" друг с другом через третий юзерспейсовский процесс (демон управления сообщениями) придется больше переключений сделать (потому что все равно эти три процесса будут с друг другом через какие-то уже существующие ядерные IPC взаимодействовать). А так один из процессов из цепочки исключается, ядро его функции берет на себя
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	123. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от arisu (ok) on 20-Янв-15, 17:17
	а всё потому, что они пытаются применять шину для того, для чего она не предназначена. господи, если я в тебя поверю, ты ответишь мне, зачем ты создал столько дебилов?
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	124. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от pavlinux (ok) on 20-Янв-15, 17:57
	>> Here are some key features of "FramebufferUI": > Это скорее список недостатков. Can i see you realization? Benchmarks? Compare key features? Or you just peace da ball?
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	125. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Vkni (ok) on 20-Янв-15, 18:17
	> Can i see you realization? Павлик, я в своё время посчитал кол-во "графических систем", сделанных под Linux - их около десятка. Неужели ты думаешь, что я настолько больной на голову, чтобы после этого создавать свой аналог DirectFB?
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	126. "Третий выпуск реализация kdbus для ядра Linux "	–1 +/–
	Сообщение от Аноним (??) on 20-Янв-15, 18:55
	кокой изощрённый способ саморефлексии
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	127. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Аноним (??) on 20-Янв-15, 18:58
	> Can i see you realization? Benchmarks? Compare key features? > Or you just peace da ball? mgimo finished
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	128. "Третий выпуск реализация kdbus для ядра Linux "	–1 +/–
	Сообщение от Аноним (??) on 20-Янв-15, 19:23
	> А другие POSIX-системы - не смешите. Нет их. Из живого есть ещё макось - но там обычно совсем свой софт. У *BSD ниша только уменьшается, что там осталось? Подыхающий солярис и изолированный мирок AIX? И сколько там процентов у линух-десктопа?
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	129. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от Олег (??) on 20-Янв-15, 22:00
	>> Это ещё почему? Процессор в юзерспейсе медленнее работает? > написано же - "минимизации переключения контекста процессов". Переключения контекста > - удовольствие дорогое. Ух, КЭП, а разработчики plan9 не в курсе. Надо им рассказать. Что-то мне подсказывает, что если всё делать по уму, то такая высокоуровневая вещь, как dbus, не может проводить много больше времени в переключениях контекста, чем в основной работе.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	130. "Третий выпуск реализация kdbus для ядра Linux "	+1 +/–
	Сообщение от Олег (??) on 20-Янв-15, 22:05
	>> Это ещё почему? Процессор в юзерспейсе медленнее работает? > написано же - "минимизации переключения контекста процессов". Переключения контекста > - удовольствие дорогое. И вообще, я бы послушал, что на это скажут разработчики dpdk. А то, может, они зря столько сил вбухивают, что бы всё наоборот из ядра в юзерспейс вынести.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	131. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от pavlinux (ok) on 21-Янв-15, 03:41
	>> Can i see you realization? > Павлик, я в своё время посчитал кол-во "графических систем", сделанных под Linux > - их около десятка. Неужели ты думаешь, что я настолько больной > на голову, чтобы после этого создавать свой аналог DirectFB? :D +100500
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	132. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от pavlinux (ok) on 21-Янв-15, 03:43
	>> Can i see you realization? Benchmarks? Compare key features? >> Or you just peace da ball? > mgimo finished йес, йес - э гёрл!
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	133. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от ZloySergant (ok) on 21-Янв-15, 14:53
	>а всё потому, что они пытаются применять шину для того, для чего она не предназначена. господи, если я в тебя поверю, ты ответишь мне, зачем ты создал столько дебилов? Угум, а в ответ получишь: "все вопросы - к эволюции, я ей - только пинка дал".
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	134. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от arisu (ok) on 21-Янв-15, 19:14
	>>а всё потому, что они пытаются применять шину для того, для чего она не предназначена. господи, если я в тебя поверю, ты ответишь мне, зачем ты создал столько дебилов? > Угум, а в ответ получишь: "все вопросы - к эволюции, я ей > - только пинка дал". это у него гнилой отмаз. как вдруг что хорошо получилось — так «славьте меня», а как вдруг что хреново — так это «эволюция виновата». ненене.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	135. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от ZloySergant (ok) on 22-Янв-15, 09:03
	>>>а всё потому, что они пытаются применять шину для того, для чего она не предназначена. господи, если я в тебя поверю, ты ответишь мне, зачем ты создал столько дебилов? >> Угум, а в ответ получишь: "все вопросы - к эволюции, я ей >> - только пинка дал". > это у него гнилой отмаз. как вдруг что хорошо получилось — так > «славьте меня», а как вдруг что хреново — так это «эволюция > виновата». ненене. Бога со святошами не путаешь? Мало ли чего им там по укурке ладаном привиделось...
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	136. "Третий выпуск реализация kdbus для ядра Linux "	+/–
	Сообщение от arisu (ok) on 22-Янв-15, 18:52
	> Бога со святошами не путаешь? так он только через них и говорит. напрямую пока не слышал. к счастью, наверное.
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	137. "Третий выпуск реализации kdbus для ядра Linux "	+/–
	Сообщение от Зачем on 31-Авг-17, 18:24
	> авторы DE-шек свято уверены, что есть только софт под их DE, который использует их библиотеки, и досадное недоразумение в виде ядра, которое лучше бы тоже переписать на их библиотеках. :-D
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема