Вышел cgroups v2

никто не просил.

Но кто если не я?

Вот это:

эта его функция — поглощение контроля над системой — ПЕРВИЧНА, а та функциональность, которой он прельщает разработчиков и пользователей — лишь наживка, а не цель его существования.

Вот это:

В частности обратить внимание на полное отсутствие чего либо общего между декларировавшимися целями и результатом внедрения systemd

Но кто если не я?

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

вивсе врети!

Два пункта. Поскольку первый я аргументировал вторым, то попрошу твоих аргументов в его опровержение. Ты хочешь сказать что systemd предлагался НЕ как всего лишь система инициализации?

В подверждение первого пункта говорит, я повторюсь говорит так же **объективная** история развития этого демона. Или может хроники событий для тебя объективным свидетельством не являются тоже?

Но ты выхватил суть. Пока что первый из адептов systemd. Самый перспективный, на предмет покаяния ^_^

Покайся, брат, и не участвуй больше в кознях дьявола.

с заведомо невменяемым оппонентом

Я не обижаюсь. Христа тоже невменяемым и бесноватым называли. Признать невменяемым проще всего, когда нечем больше крыть. И вот это люди, которые «требуют объективности», — размахивают диагнозами. Что две тысячи лет назад, что сейчас.

Просто мимо проходил.

Для человека в принципе статистическая норма - не задумываться к чему идет. Но может ты задумаешься?

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

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

А без хотя бы nano или grep - сможете? Не вижу разницы между набором nano, grep или journalctl в терминале. Хотя да, journalctl это длинновато.

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

Ваш journalctl хоть куда нибудь кроме линуха портировали?

Но ведь на линуксе нет вирусов!!1

не видно *измеримых* и *воспроизводимых* результатов. Я уж молчу подробном онтологическом и семиотическом анализе systemd.

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

в какой-то момент они стали по дефолту одну иерархию со всеми контроллерами делать

И чем это отличается от того, что описал я? Было несколько иерархий, стала одна. Причем наиболее существенным мне кажется не это, а то, что logind стал принципиально зависим от systemd.

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

Я презираю религию и религиозных людей

Спасибо, мне было жизненно важно знать твое мнение. Я убедился что пилят systemd нехристи и послушники сатаны.

насмехаюсь над твоей недологикой

Понимаю. Часто сталкиваюсь с тем, что когда не в состоянии оспорить, люди начинают тупо ржать. Вычитал, что такая тактика еще со времен Римских форумов известна: что нельзя оспорить то можно высмеять. Такая «аргументация» как правило хорошо действует на плебеев, по своей сути не склонных вдумываться в суть споров и прозвучавших аргументов. Примеры применения такого приема можно широко наблюдать в политической борьбе и пропаганде, кстати.

плюсую брата анонима!

пользователь openrc

А для systemd-филов — сделать systemd рекурсивным.

Если я правильно понял, смешивать контроллеры и процессы можно только в корне иерархии cgroups.

Есть, есть, просто глаза надо разуть.

Вот такого пиздеца в коде PID1 - недостаточно?

Отписок в багзилле на вопрос «как починить битый лог journald? Никак, wontfix, close!!» - недостаточно?

А вот вам заявленная простота unit-файлов, кушайте, не обляпайтесь.

И это при том, что разработчики свой код никак не тестируют. (Эта ссылка, кстати, напрямую относится к обсуждаемой теме)

Вот ещё один раунд намечается.

И вот пока сообщество не вынет голову из песка (и ты в их числе) - оно не увидит что его в данный момент имеют в опу. Поведение человеческого экземпляра типа «удак» формулами не описывается, но всем предельно понятно.

Вот такого пиздеца в коде PID1 - недостаточно?

Нет. Если у тебя есть идеи как переписать, то где пулл-реквест на гихабе?

Никак, wontfix, close!!» - недостаточно?

4.2!

По ссылке полнейший оффтопик. Дык, вместо того чтобы погнать ТС ссаными тряпками, Поттеринг подробно ответил.

Краткая суть: обращаться с битыми бинарными лог файлами нужно точно также как с битыми текстовыми файлами. Т.е. никак. В journald есть некоторая эвристика, но не более того. Никакого WONTFIX и близко нет, так как о баге и не сообщалось.

А вот вам заявленная простота unit-файлов

А! Это тоже проходили. Давний вопрос, должен ли демон *знать* об init. Является дисциплиной спецолимпиады.

И это при том, что разработчики свой код никак не тестируют.

Даже не смешно. Может быть его ещё на машине без tmpfs тестировть? Баг, кстати, поправили. Хотя опять же, могли бы занять позицию: шлите патчи мы их отсмотрим и может быть примем.

Вот ещё один раунд намечается.

В защиту kdbus выступал Greg K-H. Я его понимаю. У него опыт стояния под индустриальными говномётами, когда из 2.5-2.6 выпиливали devfs и заменяли на udev.

Смысл в том, что kdbus не вносит изменений ни в одну из подсистем ядра. Это полностью «клиентский» модуль. И как бы не кидались какашками, всё-равно эффективного высокоскоростного IPC в ядре так до сих пор и нет.

Единственное в чём можно упрекнуть разработчиков, так это в том что они неверно оценили сложность реализации.

Насчёт bus1 — ещё ничего не ясно. Даже срача на HN не вышло.

И вот пока сообщество не вынет голову из песка

Опять двадцать пять!

И такой «критикой» завален весь интернет. Критика, это ведь не кидание какашками. Критика строится по принципу: а) что не так; б) почему это не так; в) как должно быть; г) почему это должно быть *так*. Очень желательно, пункт «в» сопровождать реализацией.

В противном случае — болтовня.

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

Поттеринг подробно ответил.

Это не ответ, а наливание воды в предыдущий комментарий «The only way to deal with journal corruptions, currently, is to ignore them». По сути - ответа на вопрос «таки как починить логфайл?» - нет.

Давний вопрос, должен ли демон *знать* об init.

Вопрос здесь в том, что за пределами «typical use-case» юнит превращается в гораздо более сложную и хрупкую конструкцию, чем «тупо sh-скрипт».

Даже не смешно. Может быть его ещё на машине без tmpfs тестировть?

Уход с темы засчитан. Непротестированность кейса это, впрочем, не отменяет. Мне вот интересно, а чего они, собственно, ожидали? Тащите всё в инит - тестируйте возможные комбинации. Ах растут по экспоненте? Ну так кто вам виноват, ССЗБ.

В защиту kdbus выступал Greg K-H

И что с того? Ну давай ещё Дреппера вспомним или Мигельку.

Смысл в том, что kdbus не вносит изменений ни в одну из подсистем ядра

Это не повод тащить в ядро очевидную какаху. Линус так и сказал - нефиг ей делать в ядре, чините свой юзерспейс.

Единственное в чём можно упрекнуть разработчиков, так это в том что они неверно оценили сложность реализации.

*Подавился пряником* Сложность реализации? Разве что в том смысле, что им *сложно* писать простой и надёжный код, сложно проектировать простые протоколы и *сложно* удержаться и не тащить в проект всё подряд.

всё-равно эффективного высокоскоростного IPC в ядре так до сих пор и нет.

Сокеты, shm. Эффективней этого - ещё не придумали.

И такой «критикой» завален весь интернет.

Сиверсу и остальным подробно и на пальцах объяснили в ядерной рассылке «что не так» с их проектами.

Очень желательно, пункт «в» сопровождать реализацией.

«Здравствуйте, меня зовут Кирилл. Я хочу, чтобы вы написали игру, экшон, суть такова...» И всё это, разумеется, «за так», чтобы кому-то что-то «доказать».

как должно быть

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

Я напоминаю, до сих пор не озвучено ни одного use-case, зачем нужен kdbus.

Линус так и сказал - нефиг ей делать в ядре, чините свой юзерспейс.

Во-первых, Линус так не говорил. Во-вторых, в ядре есть тот же binder. В-третьих, похрен на то что Линус *говорил*. Линус много чего *говорит*, но делает по большей части правильно.

Разве что в том смысле, что им *сложно* писать простой и надёжный код, сложно проектировать простые протоколы и *сложно* удержаться и не тащить в проект всё подряд.

Ты хоть смотрел код kdbus? Ты хоть смотрел код binder? И да, писать *простой* код и проектировать *простые* протоколы — сложно. А то сплошь и рядом путают простоту с тривиальностью...

Я напоминаю, до сих пор не озвучено ни одного use-case, зачем нужен kdbus.

Озвучен с самого начала: таскать по IPC данные порядка гигабайт.

Я презираю религию и религиозных людей, насмехаюсь над твоей недологикой

Насчет твоей «гордыни причастности к великому» персонаж попал в точку. Правда, в роли «великого» - школоло-поделка systemd.

Не тому отвечаешь. Нет, мне просто интересен этот проект.

аноним вполне подкрепил свои утверждения ссылками и в том что он говорит есть свой резон, а вот вы лишь пустословно отстаиваете божественность системд и их разработчиков - видимо ваш опус об отсутсвии объективной информации о системд был не более чем спланированнм набросом на вентилятор, фу так делать!

другой аноним

Не тому отвечаешь.

ЛОР глючит. Но содержимое мессаги правильно.

Во-первых, Линус так не говорил.

Вот тебе кошернейший бенчмарк от самого Линуса. Я тебе даже процитирую, чтоб ты не смог «не найти»:

Quite frankly, the whole «kdbus is important for performance» seems to

be *totally* invalidated by even a minimal look at profiles for that thing.

there's not a kernel function in sight in the top-15, and it's all

just overhead.

If somebody wants to speed up dbus, they should likely look at the

user-space code, not the kernel side.

My guess is that pretty much the entirely of the quoted kdbus

«speedup» isn't because it speeds up any kernel side thing, it's because it avoids the user-space crap in the dbus server.

IOW, all the people who say that it's about avoiding context switches

are probably just full of shit. It's not about context switches, it's about bad user-level code.

We don't add crap that then has to be disabled with secuirity rules

just because it was a bad interface. Just make the interface not do it in the first place. It's that simple.

Во-вторых, в ядре есть тот же binder.

Ну давай посмотрим на то, что есть в ядре.

[anonymous@localhost linux-4.4]$ find . -name '*binder*'
./include/uapi/linux/android/binder.h
./drivers/android/binder_trace.h
./drivers/android/binder.c
[anonymous@localhost linux-4.4]$
3703 ./drivers/android/binder.c

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

97 files changed, 34069 insertions(+), 3 deletions(-)

Ну хорошо, там есть «документация» и типа-тесты, поэтому великодушно выкинем половину. Остаётся 17k строк кода известного нам качества, которые потом надо будет поддерживать и тянуть до скончания времён, потому что Линус не ломает юзерспейс.

Кстати, почему эти перцы не берут биндер, вместо своего велосипеда? Потому что гугл не даст ломать его как угодно?

похрен на то что Линус *говорил*. Линус много чего *говорит*, но делает по большей части правильно

...и именно поэтому Сиверс получил пинок под зад с запретом принятия патчей. Остальные на очереди. Последним в серии, надеюсь, будет Грег.

Примеров что «незаменимых людей в ядре нет» - навалом, из последнего - Шарп.

Ты хоть смотрел код kdbus?

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

писать *простой* код и проектировать *простые* протоколы — сложно

Не умеешь - не берись. Я не знаю, герань разводи на балконе, как раз по скиллам. Какого чёрта вам тогда в ядре надо? Нам с этим жить потом.

Озвучен с самого начала: таскать по IPC данные порядка гигабайт.

И? Те же сокеты этого не позволяют делать?

Ну и на закуску: dbus is not an appropriate design for a kernel messaging layer for a variety of reasons.

Краткая суть: обращаться с битыми бинарными лог файлами нужно точно также как с битыми текстовыми файлами.

неверно. краткая суть: откуда на append-only бинарных журнальных файлах появляются коррапшены, и нормально ли это? представь себе БД с таким поведением. они там транзакции в школе не проходили? или семантику posix файловых систем? Леннарт вообще адекватно так journald с ext4 сравнил, лол.

Баг, кстати, поправили.

Баг, с моей скромной точки зрения, в полном пренебрежении практиками defensive programming, и это в проекте ни много ни мало «системы всего».

Краткая суть: обращаться с битыми бинарными лог файлами нужно точно также как с битыми текстовыми файлами. Т.е. никак.

С убитыми текстовыми файлами как раз таки можно работать, в этом суть.

И как бы не кидались какашками, всё-равно эффективного высокоскоростного IPC в ядре так до сих пор и нет.

Новости в мире Linux, и наверное ты хочешь сказать что dbus-like решение будет скоростным? Это менее реально, чем паранойя по поводу целей редхат и места системд в их достижении.

Про критику почитай страничку s6.

У него опыт стояния под индустриальными говномётами, когда из 2.5-2.6 выпиливали devfs и заменяли на udev.

Такая брехня пройдет только с нубами. DevFS выпиливалась под аплодисменты.

Озвучен с самого начала: таскать по IPC данные порядка гигабайт.

Какие приятные глупости

Озвучен с самого начала: таскать по IPC данные порядка гигабайт.

Какие приятные глупости

Если верить Грегу, то по dbus (не kdbus) уже таскаются гигабайты.

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

Ну с современным подходом к общению меж десктоп программами и системд, может я и поверю в это.

Мне кажется, это было еще до внедрения systemd. И системы были не десктопные, а car infotainment или что-то такое. Я еще подумал «епт, ну что за индусы это написали».

я не понимаю что мне мешает слать гигабайты другими IPC более эффективно, даже если dbus в ядре будет.

Да ничего, конечно. Но протакскивают kdbus именно под легендой «нам нужен быстрый IPC».

DevFS выпиливалась под аплодисменты.

Угу, я эти «апплодисменты» читал, ага.

откуда на append-only бинарных журнальных файлах появляются коррапшены, и нормально ли это

Ровно оттуда же откуда они появляются и в текстовых файлах. Скорее всего journald действительно сливает с архитектурной точки зрения специализированным системам.

Но вот вопрос: какую из них можно использовать в systemd? Я знаю одну. Но а) она не продакшен; б) в момент начала разработки systemd она была не так известна.

в полном пренебрежении практиками defensive programming

Ну-ну, не нужно бросаться высокопарными фразами... Тем более в такой нечёткой области. Я вообще не думаю что Поттеринг и Co рассматривают крах PID 1 как катастрофу. В ядре есть механизмы реакции на panic. А в виртуальных средах не нужны даже и они.

ты хочешь сказать что dbus-like решение будет скоростным

kdbus имеет крайне опосредованное отношение к D-Bus. Используется формат сериализации D-Bus, но вроде бы и ничего более.

Что значит «скоростным»? Если ты имеешь ввиду возможно ли уложить вызов IPC в один слайс, как в биндере, то — нет. А если ты имеешь ввиду возможно ли передавать данные порядка гигабайта без лишних копирований и переключений контекста, то — да.

Про критику почитай страничку s6.

Да читал я её, читал. И даже интересные вещи (по ссылкам) находил. Только критика systemd там настолько неубедительна, что её даже разбирать неинтересно. Видано ли, в разделе «Technical issue» не написать ни одной этой самое issue?

И сам проект интересен... Только у аффтара POSIX головного мозга. Т.е. cgroups и inotify идут лесом.

Ну и учитывая что в рамках проекта s6 уже порядка пятидесяти утилит, то налицо еще один systemd с блекджеком и шлюхами...

P.S. Посмотрел презенташку Поттеринга с последнего systemd.conf по cgroups1. Его послушать, так там вообще лютый АдЪ и ...ецЪ. Это к вопросам «качества».

Вот тебе кошернейший бенчмарк от самого Линуса.

Это бенчмарк D-Bus. И никакой кошерности в нём нет.

Кстати, почему эти перцы не берут биндер, вместо своего велосипеда?

Грек К-Х разбирал этот вопрос в своём блоге.

и именно поэтому Сиверс получил пинок под зад с запретом принятия патчей

Сиверс не получал никакого «запрета». Ситуация с Сиверсом — обычная и регулярная практика, с той только разницей что в данном случае она вылилась в публичную плоскость и сопровождалась некорректным поведением Линуса.

Ну и на закуску: dbus is not an appropriate design for a kernel messaging layer for a variety of reasons.

Судя потому что официальная разработка kdbus затормозилась, то советам в конце поста разработчики таки вняли.

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

Ты может его и в продакшене используешь? kdbus даже из Fedora Rawhide выкинули, а во все остальные проекты его даже и не включали.

DevFS выпиливалась под аплодисменты.

Угу, я эти «апплодисменты» читал, ага.

Тогда не рассказывай тут про «опыт стояния под говнометами». Если кто и стоял под говнометами, то это был Гуч.

Да ничего, конечно. Но протакскивают kdbus именно под легендой «нам нужен быстрый IPC».

серьёзно? мне казалось, что им нужен быстрый dbus и меньше проблем с bootstrap-ом системы.

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

осталось понять, зачем мне тут (k)dbus и почему я это не могу сделать другими средствами.

kdbus имеет крайне опосредованное отношение к D-Bus. Используется формат сериализации D-Bus, но вроде бы и ничего более.

на мой взгляд dbus это: 1. фиксированный формат сериализации, 2. возможности интроспекции и discovery сервисов и их команд, 3. возможность multicast - сообщений подписавшимся, 4. немного плюшек для отложенного старта сервисов и неявных зависимостей. Чего из этого нету в kdbus? Чего нету в dbus, но есть в kdbus - это минимум документации, тут Грегу надо отдать должное, читая её наконец-то можно понять что к чему.

Да читал я её, читал. И даже интересные вещи (по ссылкам) находил. Только критика systemd там настолько неубедительна, что её даже разбирать неинтересно. Видано ли, в разделе «Technical issue» не написать ни одной этой самое issue?

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

Ну и учитывая что в рамках проекта s6 уже порядка пятидесяти утилит, то налицо еще один systemd с блекджеком и шлюхами...

ты про systemd выводы таким же образом делаешь? тогда наверное дискуссию стоит свернуть.

P.S. Посмотрел презенташку Поттеринга с последнего systemd.conf по cgroups1. Его послушать, так там вообще лютый АдЪ и ...ецЪ. Это к вопросам «качества».

каким вопросам качества?

Чего нету в dbus, но есть в kdbus - это минимум документации, тут Грегу надо отдать должное, читая её наконец-то можно понять что к чему.

kdbus это messaging VFS. Судя по обрывкам реплик, эксперименты в юниксах идут с давних пор.

VFS даёт целую массу плюшек: интроспекцию (ты почему-то говоришь о ней как будто это что-то плохое), возможность многоадресной рассылки т.к. иерархия => легко определить понятие групп рассылки, возможность получения эффективных уведомлений о событиях, эффективные механизмы разграничения доступа.

В то же самое время такая VFS не создаёт ничего нового: задействованы только уже существующие ядерные механизмы/интерефейсы.

Т.е. мы не выдумываем подсистемы. Не меняем семантику уже существующих (в отличие от тех же AF_NETLINK, АF_PPOX, ethtool). Не изобретаем новые сисколлы. Не транжирим ценные «слотовые» ресурсы ядра.

Ещё раз повторюсь. Видимо, разработчики неправильно оценили сложность.

Похоже, что ты ищешь, какую-то страницу с откровениями, от которых станет ясно, что systemd использовать ну никак нельзя

Ну да. Типа того.

systemd это не плохой вполне работающий вариант

*Я* — в курсе.

что ты не только страничку про systemd там прочитал, а большую часть документации

Нет. Документацию не читал. И сравнений s6-systemd не читал, т.к. в то время s6 находился в зачаточном состоянии.

Надо будет обязательно посмотреть в образовательных целях.

Проблема только одна: отношение автора к линукс-специфичным API.

мне казалось, что им нужен быстрый dbus и меньше проблем с bootstrap-ом системы.

dbus уже стал одним из видов IPC.

dbus вродеж их скопростью не удовлетворяет. Мол kernel-userspace свичей много, надо быстрее, надо положить его в ядро.

Ну вот там давали ссылку на то, что мол переключения контекста и перформанс — это хрень и можно/нужно вместо этого починить дбас. Дбас не устроил их не только скоростью, а ещё тем, что это ещё один демон с кучей зависимостей и он недоступен в early boot/shutdown.

Во, нашёл классную ссылку https://lwn.net/Articles/405346/

Звучали даже предложения сделать AF_DBUS.

Так же стоит отметить проект DragonflyBSD, где ведётся попытка перевода взаимодействия с ядром на message-based интерфейс.

Это бенчмарк D-Bus.

Ложь. Обсуждение идёт именно kdbus'а, +двумя постами выше есть обсуждение, как выложенное чудо собирать, что оно собиралось.

И никакой кошерности в нём нет.

А с чего я должен верить тебе больше чем Линусу, м, балабол беспруфный?

Грек К-Х разбирал этот вопрос в своём блоге.

Ссылки нет - считаем что не или разбирал или лил воду на тему как всё будет о**енно.

Сиверс не получал никакого «запрета».

Key, I'm f*cking tired of the fact that you don't fix problems in the code *you* write, so that the kernel then has to work around the

problems you cause.

Greg - just for your information, I will *not* be merging any code from Kay into the kernel until this constant pattern is fixed.

Пруф. Ты снова намеренно лжёшь.

Судя потому что официальная разработка kdbus затормозилась, то советам в конце поста разработчики таки вняли.

Нет, они не сами «вняли», их послали переделывать. Отпиливать собственно желаемый ipc от тонны dbus'о специфичного г-на.

Как я понял насчёт биндера ты слился и use-casов так и не привёл, ок.

Я вообще не думаю что Поттеринг и Co рассматривают крах PID 1 как катастрофу.

Нормально, чо. Let it fail! Бугага. Вы там с поцерингом уже такую репутацию линупсу создали, что любо дорого. Скоро 95-я выньда от зависти в гробу начнет крутиться.

двумя постами выше есть обсуждение, как выложенное чудо собирать, что оно собиралось

Странно. У меня kdbus собирался без проблем. Единственное «но» ему нужен time64_t который появился только в 3.17.

Как я понял насчёт биндера ты слился и use-casов так и не привёл, ок.

Юзкейсы? Биндера? Дык, возьми любой андрод-телефон. Там биндер везде. Если тебе нужны ссылки, ну пожалуйста: http://elinux.org/Android_Binder там как раз внизу ссылка на пост Грега почему нужен kdbus.

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

Если ты не понял, то D-Bus давно и крепко пробрался в настольные системы. Если интересно, вот пост на тему (осторожно, Поттеринг по ссылке) http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html

Теперь, зачем необходимо передавать большие объёмы по шине.

Например, ты получаешь PDF-ник из недоверенного источника. Это очень не гут, т.к. все вьюверы (включая штатный) очень и очень сильно кривы и являются неиссякаемым источников эксплоитов.

По счастью, наличие эксплоита в PDF очень легко проверить. Но, тогда возникает вопрос, а что если и наш проверяльщик кривой?

Эта проблема имеет очень и очень простое решение. Поскольку наш проверяльщик не взаимодействует с пользователем, то его можно запустить в изолированном окружении. Тут выбор богат: DAC (под другим uid), LSM (SELinux, AppArmor и прочие), неймспейсы (их ещё называют LXC), на уровне гипервизора (см. напр. QubesOS), гипотетический контроллер безопасности для cgroups, или любые другие механизмы.

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

Сеть? Но лучше её убрать вообще (и лучше все семейства сокетов) и zero-copy нет. Файловая система? Но это сложно: нужно договариваться о точках рандеву, разрабатывать протокол взаимодействия. Вот и остаётся самый тупой вариант: послать PDF по IPC.

Естественно, юзкейсы не ограничиваются только проверкой. Есть целая проблема с построением миниатюр. Для самых параноидальных пользователей по IPC можно сделать и рендеринг: как в «лёгкой форме» декодирование и проверка, так и в «тяжёлой» передача графики по IPC (хотя, конечно для этого есть и другие механизмы).

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

А при должном проектировании, можно сделать так что передача гигабайт по IPC не будет вносить вообще никакого оверхеда.

Let it fail! Бугага.

Философия Эрланга, и всех highload-систем. Вон извращенцы из netflix юзают «chaos monkey», которая периодически вырубает случайную ноду.

Зато, когда к Амазону (а у нетфликса нет своей инфраструктуры) подобрался полярный лис, нетфликс был одним из немногих кто не полёг.

Так что не надо.

Философия Эрланга, и всех highload-систем. Вон извращенцы из netflix юзают «chaos monkey», которая периодически вырубает случайную ноду.

facepalm.mkv.gz (4.7G)

послать PDF по IPC

Есть целая проблема с построением миниатюр

Ты упоролся.