Кей Сиверс (Kay Sievers), один из создателей подсистемы udev и активный разработчик systemd, сообщил (https://plus.google.com/108087225644395745666/posts/N3EixQ2Zcby) о достижении модулем Kdbus степени зрелости, позволяющей начать его использование совместно с systemd в тестовых целях. По предварительной оценке, включение в основную ветку ядра Linux ожидается в середине 2014 года.
В рамках проекта Kdbus развивается (http://www.opennet.me/opennews/art.shtml?num=36067) надёжная, быстрая и безопасная система обмена сообщениями, поддерживающая доставку сообщений как в мультикаст режиме (от одного отправителя к группе получателей), так и в режиме точка-точка. Функциональность Kdbus выходит за рамки DBus, но позволяет создать реализации DBus поверх рассматриваемой подсистемы ядра, не требующие запуска в пространстве пользователя отдельного демона D-Bus. Одну из таких реализаций развивает (http://www.opennet.me/opennews/art.shtml?num=36457) проект systemd.URL: https://plus.google.com/108087225644395745666/posts/N3EixQ2Zcby
Новость: http://www.opennet.me/opennews/art.shtml?num=38578
Консоль удаляют из ядра. DBus в него засовывают. Забавные ребята. С нелинейной логикой.
Консоль — интерфейс пользователя, не место ему в ядре. А вот kdbus там самое место, ибо IPC интерфейс. Всё правильно делают, это уже не раз обсуждалось.
Консоль там тоже вполне на месте, хотя, возможно, в предельно урезанном виде. Но плюс один IPC - это хорошо, конечно. В кои-то веки писаки systemd делают что-то полезное.
>Но плюс один IPC - это хорошо, конечно.Можно подумать, что IPC в Linux не было.
>Можно подуматьподумать таки нужно
>IPC в Linux не было
не было стандартно-универсального IPC - была куча разнородных костылей^W протоколов для каждой проги
ну а kdbus - это оптимизация dbus путем переноса в ядро. была же новость, что на x86 оно работает в 1.8 раз быстрее, на arm - в 3 раза быстрее
> не было стандартно-универсального IPCЧо?
TCP/IP - IPC
PIPE - IPC
SHM - IPC
SIGNAL - IPC
...Если бы Линух не был похож на зоопарк, функционал ядра 3.12 был бы уже в 95 году.
За эти 20 лет, не придумали почти ничего нового, только костыли местами переставляют.
>TCP/IP - IPC
>PIPE - IPC
>SHM - IPCэто протоколы нижнего уровня, а сверху как всегда набор прого-зависимых костылей
>SIGNAL - IPC
и много вы информации вы сигналом можете перекинуть?
>За эти 20 лет, не придумали почти ничего нового, только костыли местами переставляют.
"я знаю как нужно делать и буду всех учить!"
форкни ядро, сделай как надо - Линус вон смог например
>>TCP/IP - IPC
>>PIPE - IPC
>>SHM - IPC
> это протоколы нижнего уровня, а сверху как всегда набор прого-зависимых костылей
>>SIGNAL - IPC
> и много вы информации вы сигналом можете перекинуть?В системе счисления по основанию 32? - Дох...я!
И если чо, DBUS - это сигнальная "шина".> я знаю как нужно делать и буду всех учить!"
> форкни ядро, сделай как надо - Линус вон смог напримерЯ размышляю на тему, а ты в двойне дебил - не предложив своего, размышляешь обо мне.
>> не было стандартно-универсального IPC
> Чо?
> TCP/IP - IPC
> PIPE - IPC
> SHM - IPC
> SIGNAL - IPC
> ...Не надо путать низкоуровневые протоколы с высокоуровневыми.
Иначе дойдешь до "зачем нужен HTTP, если есть TokenRing?".
>>> не было стандартно-универсального IPC
>> Чо?
>> TCP/IP - IPC
>> PIPE - IPC
>> SHM - IPC
>> SIGNAL - IPC
>> ...
> Не надо путать низкоуровневые протоколы с высокоуровневыми.
> Иначе дойдешь до "зачем нужен HTTP, если есть TokenRing?".Не надо писать только знакомые слова, смешно получается.
Макс, давай делай систему званий, причём авторизированных и проверенных,
с указанием образования, должностей и места работы. Очень тяжело общаться с дебилами.
Тут pavlinux кагбэ намекает, что TokenRing не является протоколом МЕЖПРОЦЕССНОГО взаимодействия. Низкоуровневые они или высокоуровневые - не суть важно, процессы через них взаимодействовать могут.DBUS - это не более чем очередной велосипед, надстройка над уже имеющимися механизмами межпроцессного взаимодействия. С той лишь разницей, что для этого нового механизма зачем-то нужен демон, в то время как остальные протоколы работают без помощи демона и к тому же являются стандартами RFC и POSIX.
>[оверквотинг удален]
> Чо?
> TCP/IP - IPC
> PIPE - IPC
> SHM - IPC
> SIGNAL - IPC
> ...
> Если бы Линух не был похож на зоопарк, функционал ядра 3.12 был
> бы уже в 95 году.
> За эти 20 лет, не придумали почти ничего нового, только костыли местами
> переставляют.Уборка хлама в помещении - это процесс перестановки его (хлама) с места на место, до того момента пока расположение его (хлама) не станет походить на порядок.
А уж в каком порядке сегодня будут расставлены костыли, зависит от многих факторов, и том числе от того, как некоторые аккаунты себе это представляют (конечно же имеются в виду аккаунты участвующие в разработке ядра, а не те которые на opennet-е в основном обитают ;)
>Уборка хлама в помещении - это процесс перестановки его (хлама) с места на место, до того момента пока расположение его (хлама) не станет походить на порядок.Мусор - это драгоценность, оказавшаяся в ненужное время в ненужном месте.
Это еще не повод его (мусор) не выносить. Иначе есть все шансы утонуть в собственных отходах.
> Это еще не повод его (мусор) не выносить. Иначе есть все шансы
> утонуть в собственных отходах.Все три, выше отписавшихся, философа конечно правы, только это ваще не имеете никакого отношения к информатике.
Шины со стандартизированным форматом сообщения - не было.
> Чтобы возражать по существу надо, чтобы было это самое "существо". А тебя
> - вред обдолбанного идиoта.Всего лишь упорядоченное и логически законченное изложение ваших же мыслей и идей :-)
Бедный, тебе там где-то логика примерещилась?
> Бедный, тебе там где-то логика примерещилась?В моих словах ее не больше, чем в ваших. Но и не меньше тоже :-)
> Можно подумать, что IPC в Linux не было.IPC в котором подписчики могут получать интересующие их события неопределенной группой? И где это было? То что было - в самом зачаточном виде.
вообще-то amqp давно быстро и надежно трудиться на благо пользователей с очень гибкой системой подписки - куда уж больше?.
>> Можно подумать, что IPC в Linux не было.
> IPC в котором подписчики могут получать интересующие их события неопределенной группой?
> И где это было? То что было - в самом зачаточном
> виде.IPC - это протокол взаимодействия. Там нет событий, правил, формата сообщений.
Есть пакетный или потоковый (байтовый) канал. Чё вы туда засунете - ваши трудности.
знаю людей которые принципиально выпиливали софт который требует всякие dbus, а Леня его в ядро...
я знал людей которые принципиально выпилились, а Леня его в ядро...
> я знал людей которые принципиально выпилились, а Леня его в ядро...Так и в ядре его наверняка можно будет выключить
Если не считать фанатиков, обычно его выпиливали те, кому не сама шина не нравилась, а то, что на этой шине ваяли. Включая и Лёнино поделие.
> Если не считать фанатиков,... но никого больше и не останется.
Причем, ЧСХ, эти фанатики даже не понимают разницу между D-Bus и AF_UNIX.
Останется, останется. Это вам кажется, что всем нужно на всё динамически реагировать. А по факту в современном десктопе (стационар который) почти нет ситауций, где есть смысл что-то динамически крутить в настройках. А больше D-Bus довольно долго ни для чего не применялся.
> А по факту в современном десктопе (стационар который) почти нет ситауций, где есть смысл что-то динамически крутить в настройкахЗначит, для десктопов нужно создавать отдельные дистры, работающие совсем по иным протоколам, нежели ноутбучные.
Достаточно просто не устанавливать соответствующий функционал. Что и делают те, кто выпиливает d-bus. По факту, правда, надо его клиентские модули из соответствующего софта выкидывать, но это уже детали - как я говорил, он сейчас почти ни для чего, кроме динамической конфигурации, не используется.
> Достаточно просто не устанавливать соответствующий функционал. Что и делают те, кто выпиливает d-bus.Вы хотите сказать, что D-Bus используется только для _системных_ настроек?
> То, что вы перечислили - как раз подтверждение этому."Исключение только подтверждает правило"? Знаем, слышали :-)
> cgroups отлично используются без всякого systemd,
Это пока. Но движуха уже идет, google://tejun+heo+systemd
> kdbus от него оторвут даже если поттеринг сотоварищи попытаются прилепить
Не смешите мои тапочки :-)
Просто в upstart скопируют очередной кусок systemd, как это было уже неоднократно. А всякие слаквари скажут "а нам этот kdbus не очень-то и хотелось".> как оторвали eudev.
Опять же, не смешите мои тапочки. Учебный проект полутора студентов - это не "отрыв".
> А виртулаьные терминалы вообще никто выкидывать не будет, что и заявлено
Просто перестанут поддерживать. Alan Cox-то ушел.
Рано или поздно сломается совместимость с другими подсистемами, и при очередной чистке выкинут нафиг.
Окстись, "один чувак сказал в lkml" - это не движуха. Больше того - его (и Поттреинга за компанию) там вполне аргументированно послали. Я вообще не помню случаев, чтобы из линукс-ядра убирали какие-то возможности, а уж с cgroups, которые сейчас куча всего использует самыми разными странными способами - никто возожностями systemd не ограничится.По eudev - не знаю, учбеный проект или нет, но он жив, обновляется и отлично работает. И да, ядро линукса, помнится, тоже начинал писать студентик. А апстартовцы, кстати, тащат себе с большим разбором - и правильно делают, что тащат - если идея хороша - надо тянуть. Проблема systemd, собственно, не в том, что у них хороших идей нет - а в том,что они перемешаны с адовым бредом и идиотски реализованы.
А терминалы - если ыы не понимаешь, что они нужны адовой куче народу в условиях, где systemd нет и быть не может - это твои проблемы. Загляни в эмбед на досуге, много нового узнаешь.
> "один чувак сказал в lkml" - это не движуха.Не "один чувак", а мейнтейнер подсистемы croups.
> Больше того - его (и Поттреинга за компанию) там вполне аргументированно послали.
Кто послал? "Один чувак", который никаким боком к теме, а просто мимокрокодил?
> По eudev - не знаю, учбеный проект или нет, но он жив, обновляется
В основном тягают коммиты из апстрима и меняют число пробелов в отступах.
> отлично работает
Пользователи Calculate смотрят на вас с печалью.
> А апстартовцы, кстати, тащат себе с большим разбором
"Что сейчас успеваем - тащим сейчас, остальное потом утащим", да.
> А терминалы - если ыы не понимаешь, что они нужны адовой куче народу в условиях, где systemd нет и быть не может - это твои проблемы. Загляни в эмбед на досуге, много нового узнаешь.
systemd - вполне удачное решение для embedded систем. Быстрый, кастомизируемый. Angstrom уже продвигает его в качестве нового инита.
> systemd - вполне удачное решение для embedded систем.Лолшто? Мне из-за этой поделки пришлось бы кучу хлама в rootfs тащить.
> А терминалы - если ыы не понимаешь, что они нужны адовой куче
> народу в условиях, где systemd нет и быть не может -
> это твои проблемы. Загляни в эмбед на досуге, много нового узнаешь.И да, кстати, в каком месте в эмбеддовке используются виртуальные терминалы? Не последовательные (ttyS), а именно виртуальные (tty)?
>> А терминалы - если ыы не понимаешь, что они нужны адовой куче
>> народу в условиях, где systemd нет и быть не может -
>> это твои проблемы. Загляни в эмбед на досуге, много нового узнаешь.
> И да, кстати, в каком месте в эмбеддовке используются виртуальные терминалы? Не
> последовательные (ttyS), а именно виртуальные (tty)?Насколько я помню, один из основных аргументов в пользу поддержки сборки с CONFIG_VT=n - выкинуть функциональность, нафиг не нужную в embedded системах. Вследствие чего и начался вынос VT в юзерспейс.
>Кей Сиверс
>надёжная, быстрая и безопасная системаХм…
А что не так? udev вполне надежен, быстр и безопасен - последние лет шесть как минимум.
> А что не так? udev вполне надежен, быстр и безопасен - последние лет шесть как минимум.Кажется, Вы погорячились с этим утверждением. Шигорин вот кипятком писал после тесной интеграции сверхнадёжного udev с systemd.
> Кажется, Вы погорячились с этим утверждением. Шигорин вот кипятком писал после тесной
> интеграции сверхнадёжного udev с systemd.Это вопрос скорее религиозный, нежели технический.
> Кажется, Вы погорячились с этим утверждением. Шигорин вот кипятком писал после тесной
> интеграции сверхнадёжного udev с systemd.А Шигорин много по поводу чего писает кипятком, при том чаще всего это оказываются его персональные предпочтения и бзики, а вовсе не что-то прилично аргументированное с технической точки зрения.
> А что не так? udev вполне надежен, быстр и безопасен - последние
> лет шесть как минимум.правда, при добавлении сетевой карты может буквы дисковых устройств перемешать — но это же ерунда. подумаешь.
IPC, конечно, хорошо. Так постепенно и до микроядра дойдём.
Эволюционный путь тоже хорош, не хуже революционного :)
А посмотреть, какое именно IPC - не судьба? Это примерно так же относится к микроядру, как очереди SysV. И слава шайтану, в общем-то - лиуксовое ядро показало свою практичность, а для экспериментов полигонов и так хватает.
Лол. До Plan 9 ему всё равно ещё далеко.
> надёжная, быстрая и безопасная система обмена сообщениямиОни поначалу все такие.